Forum Linux.debian/ubuntu Lister les modifications de conf

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
1
9
juil.
2019

Bonjour à tous,

Je viens de migrer mon système sur Debian 10, et à la suite de la mise à jour, j'en viens à me demander s'il existe un moyen simple d'identifier les fichiers de configurations ayant été modifié par rapport aux paquets d'origine ?

Des fois, un fichier .dpkg-dist existe à côté du fichier de conf d'origine, dès fois le fichier est dans le répertoire /usr/share/… j'ai l'impression que cela varie en fonction des paquets et qu'il n'y a pas de règle fixe.

Est-ce qu'il existe un outil ou script déjà existant pour ça ?

  • # Une piste

    Posté par  . Évalué à 3. Dernière modification le 09 juillet 2019 à 14:56.

    dpkg stocke tout les "meta-fichiers" liés au package dans /var/lib/dpkg/info.

    C'est à cet endroit que tu vas retrouver:

    • Les fichiers .postinst, .preinst, .postrm, .prerm qui sont les scripts executés lors des étapes du même nom

    • Les fichiers .md5sums contenant les sommes MD5 des fichiers.

    • Les fichiers .list qui contiennent la liste des fichiers installés par le package.

    • Les fichiers .shlibs servant à configurer le loader (lib partagées embarquées par le paquet).

    • Et et et … les fichiers .conffiles qui contiennent les fichiers configuration gérés par les paquets.

    Donc grosso modo, le petit bout de shell suivant devrait te permettre de traquer les fichiers qui t'intéressent:

    for file in *.conffiles; do 
   cat ${file} | while read conffile; do 
     [ -f ${conffile}.dpkg-dist ] && echo "${conffile}.dpkg-dist exists ";
   done
done

    • [^] # Re: Une piste

      Posté par  . Évalué à 2.

      Pour une raison qui m'échappe, la coloration syntaxique a totalement f*cké le bout de shell:

      • Un {mathjax} s'est glissé là … à supprimer.
      • Des backquotes (`) se sont également glissés là … à supprimer également.

    • [^] # Re: Une piste

      Posté par  (site web personnel) . Évalué à 2.

      Merci ça me met sur la piste !

      Malheureusement, ça ne me liste pas tous les fichiers. Je prend l'exemple de dovecot, il n'y a pas de fichier .dpkg-dist, et le script /var/lib/dpkg/info/dovecot-core.postinst contient le code suivant :

        CONFFILES="dovecot.conf \
    dovecot-dict-auth.conf.ext \
    …
    conf.d/auth-vpopmail.conf.ext"

  […]

  for conffile in $CONFFILES ; do
    # Tell ucf that the file in /usr/share/dovecot is the latest
    # maintainer version, and let it handle how to manage the real
    # configuration file in /etc/dovecot.
    ucf --three-way /usr/share/dovecot/$conffile /etc/dovecot/$conffile
    ucfr dovecot-core /etc/dovecot/$conffile
    if [ "$conffile" != "dovecot.conf" ] && [ -f "/etc/dovecot/$conffile" ] &&
                [ `echo $conffile | cut -b -7` != "conf.d/" ]; then
      chmod 0640 /etc/dovecot/$conffile
      chgrp dovecot /etc/dovecot/$conffile
    fi
  done

      J'ai l'impression, qu'il n'y a donc pas de procédure pour identifier les changements de manière exhaustive, s'il faut identifier les scripts à la main, ça rend la tâche beaucoup plus compliquée !

      • [^] # Re: Une piste

        Posté par  . Évalué à 2.

        A la lecture de la page de man d'ucf, j'ai l'impression que l'outil questionne l'utilisateur pour savoir ce qu'il doit faire.

        Si il le fait systématiquement, à priori tu seras notifié lors de ton upgrade du changement de fichier de config.

        J'y ai également lu que ucf pouvait créer des ucf-new ou ucf-old pour les fichiers modifiés.

        De ce coup, vu que, comme tu le dis, c'est géré dans les scripts de postinst je ne vois qu'une issue: le find bourrin … :-(

  • # L'outil existe

    Posté par  . Évalué à 1. Dernière modification le 09 juillet 2019 à 15:30. 

    apt install debsums
debsums -es

    • [^] # Re: L'outil existe

      Posté par  (site web personnel) . Évalué à 2.

      Malheureusement il n'est pas non plus exhaustif. Par exemple il ne me ressort pas /etc/ssh/sshd_config, ou le paramétrage de dovecot (voir le commentaire plus haut).

      J'ai l'impression que deux système coexistent pour contrôler les modifications de conf…

      • [^] # Re: L'outil existe

        Posté par  (site web personnel) . Évalué à 3.

        Effectivement, il y a dpkg qui sait si un des conffiles d'un paquet a été modifié par l'administrateur tandis qu'une nouvelle version du paquet embarque une configuration différente, et qui peut proposer un prompt pour choisir la version modifiée ou la nouvelle version. En fonction de la réponse, du côté interactif ou non, des options passées via apt/dpkg, on peut se retrouver avec des fichiers suffixés .dpkg-dist, .dpkg-old, .dpkg-new.

        Et il y a ucf qui permet d'être plus subtil que « version A ou version B », et de fusionner des modifications. Même si c'est bien mieux sur le papier, en pratique ça n'est presque pas utilisé. Sur mon système principal je vois 17 scripts postinst qui contiennent ucf, sur 4400+ paquets… Il y a probablement plus malin pour faire l'équivalent de la manipulation debsums (avec les bonnes options) ou dpkg --audit, directement avec ucf, mais de mon côté je vérifierais les paquets éventuellement concernés par des modifications de type ucf via grep -l ucf /var/lib/dpkg/info/*.postinst.

        Debian Consultant @ DEBAMAX

  • # Précisions

    Posté par  (site web personnel) . Évalué à 3.

    En fait mon besoin n'est pas de faire une sauvegarde de la conf du système, mais de faire une documentation des options que j'ai pu activer, et pourquoi. Comme cela fait quelques années, j'ai modifié le système petite touche par petite touche, et il est possible que certains changements de conf ne sont plus justifiés aujourd'hui. D'où mon but aujourd'hui de pouvoir identifier les changements…

    Je pensais pas poser une colle :) Debian me paraissait doté d'outils pour tout ce genre de manipulations…

    • [^] # Re: Précisions

      Posté par  . Évalué à 2.

      En fait mon besoin n'est pas de faire une sauvegarde de la conf du système, mais de faire une documentation des options que j'ai pu activer, et pourquoi.

      Sur un système préexistant cela risque de ne pas être facile à cause de l'imperfection des outils existants comme tu l'as vu plus haut.

      Pour un nouveau système, il est probable qu'un outil de gestion de configuration soit la bonne réponse. Puppet, Rudder (trop lourd je pense), Chef, etc.

    • [^] # Re: Précisions

      Posté par  . Évalué à 2.

      Ça me semble particulièrement compliqué. Par exemple, comment gérer les fichiers que tu aurais pu ajouter (genre dans /etc/apache2/site-available/)?

      J’utilise Puppet pour gérer mon infra, mais ça m’arrive parfois de faire certaines choses à la main. Quand ça m’arrive et que finalement je veux intégrer les changements dans Puppet, j’installe une nouvelle machine et je change la configuration jusqu’à ce que j’ai qq chose qui fonctionne comme avant.

      • [^] # Re: Précisions

        Posté par  (site web personnel) . Évalué à 2.

        Je les notes au fur et à mesure. Ça fait quelques années que j'ai commencé, et je continue d'actualiser le document, j'y note également les points de vigilance, les commandes d'urgence etc.

        C'est à mi-chemin entre un document d'exploitation, et un aide mémoire.

        Si tu veux regarder ce que ça donne.

  • # etckeeper

    Posté par  (Mastodon) . Évalué à 2.

    Pour suivre les modifications dans ton /etc. En complément des autres outils mentionnés au dessus ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.