Comment vérifier les fichiers de configuration modifiés sur un système Debian?

Comment trouver tous les fichiers de configuration gérés par Debian qui ont été modifiés par défaut?

Pour trouver tous les fichiers de configuration gérés par Debian qui ont été modifiés par défaut, vous pouvez utiliser une commande comme celle-ci.

dpkg-query -W -f='${Conffiles}\n' '*' | awk 'OFS="  "{print $2,$1}' | md5sum -c 2>/dev/null | awk -F': ' '$2 !~ /OK/{print $1}'

Edit (fonctionne avec les systèmes localisés):

dpkg-query -W -f='${Conffiles}\n' '*' | awk 'OFS="  "{print $2,$1}' | LANG=C md5sum -c 2>/dev/null | awk -F': ' '$2 !~ /OK/{print $1}' | sort | less

Edit (fonctionne avec les paquets avec OK dans le nom du fichier):

dpkg-query -W -f='${Conffiles}\n' '*' | awk 'OFS="  "{print $2,$1}' | LANG=C md5sum -c 2>/dev/null | awk -F': ' '$2 !~ /OK$/{print $1}' | sort | less

de man debsums:

  debsums -ce
          List changed configuration files.

Désolé pour necro, mais si la réponse de @ naught101 était correcte pour les fichiers modifiés , cela n'aidait en rien l' ajout de fichiers. La solution de @ Graeme est bien, mais dépend de etckeeper; Je ne veux pas modifier le système de fichiers.

find /etc -type f | grep -vFf <(debsums -e -r /etc | sed 's/[[:space:]]*OK$//')

Recherchez les fichiers dans / etc / qui debsumsne signalent pas la validité. Cela signifie que les fichiers non suivis ou les fichiers qui ne sont pas "OK" (les hachages ne correspondent pas).

J'aime généralement installer etckeeper sur le système à peu près immédiatement. Avec quelque chose comme etckeeper, je peux trouver non seulement lorsque le fichier est différent, mais je peux en fait obtenir un diff de comment il est différent.

Voir:

• Utilisation du contrôle de révision pour les fichiers de configuration du serveur?
• Quel outil recommandez-vous pour suivre les modifications sur un serveur Linux / Unix?

Ou debsums -e | grep FAILED qui affichera également tous les conffiles manquants

(du paquet debsums)

C'est peut-être exagéré, mais puisque quelqu'un a mentionné etckeeper et au cours de mon enquête, je suis tombé sur cet autre joyau qui pourrait être plus utile si vous essayez de comprendre ce qui se passe "après coup".

http://devstructure.com/blueprint/

Blueprint est un simple outil de gestion de la configuration permettant de procéder à l’ingénierie inverse des serveurs. Il comprend ce que vous avez fait manuellement, le stocke localement dans un référentiel Git, génère un code capable de recréer vos efforts et vous aide à déployer ces modifications en production.

Ceci s'écarte un peu de la question initiale en ce sens qu'il donnera également des fichiers de configuration ADDED, par opposition à ceux modifiés. Bien que les fichiers qui ne sont inclus dans aucun paquet deb soient également interceptés. Les deux comportements peuvent être souhaitables.

Cela dépend d'avoir utilisé etckeeper avec git vcs idéalement dès le départ, même si cela devrait également fonctionner si vous ajoutez et validez des fichiers précédemment modifiés après la première validation. Notez que Ubuntu a configuré que etckeeper utiliserait Bazaar par défaut (sponsor Canonical Bazaar), plutôt que le paramètre par défaut git défini par les développeurs d’etckeeper.

L'idée est d'obtenir une liste de tous les commits qui ne sont pas faits automatiquement après l'exécution d'apt. Puis listez les fichiers modifiés dans tous les dossiers sauf le premier commit:

filter_sed="/committing changes in \/etc after apt run\$/d"

etckeeper vcs log --oneline |
  sed "$filter_sed; \$d; s/ .*//" |
  xargs etckeeper vcs show --name-only --format=format: |
  sort |
  uniq |
  sed "/^\$/d"

La chaîne de filtre peut également être étendue pour englober d'autres commits s'ils sont nommés de manière cohérente. Peut-être bon pour les installations directement à partir d'un fichier deb ou du code source.

Un fichier remarquable que cela prend pour moi est le suivant xorg.conf: vous devez actuellement ajouter cela à / etc / X11 vous-même si vous en avez besoin. De plus, mes default/grubmodifications sont récupérées. Il semble que cela soit copié à partir de / usr / share par un script post-installation plutôt que d'être répertorié dans le cadre d'un paquet. Si un fichier comme celui-ci a été modifié, les méthodes associées à dpkg ne le révéleront pas.