Wie kann man auf einem Debian-System nach geänderten Konfigurationsdateien suchen?

Wie finde ich alle von Debian verwalteten Konfigurationsdateien, die vom Standard geändert wurden?

Um alle von Debian verwalteten Konfigurationsdateien zu finden, die vom Standard geändert wurden, können Sie einen Befehl wie diesen verwenden.

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

Bearbeiten (funktioniert mit lokalisierten Systemen):

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

Bearbeiten (funktioniert mit Paketen mit OK im Dateinamen):

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

von man debsums:

  debsums -ce
          List changed configuration files.

Tut mir leid, Necro, aber während die Antwort von @ naught101 für geänderte Dateien richtig war , half es nicht für hinzugefügte Dateien. @ Graemes Lösung ist nett, hängt aber vom Etckeeper ab; Ich möchte das Dateisystem nicht ändern.

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

Suchen Sie nach Dateien in / etc /, debsumsdie nicht als gültig gemeldet werden. Dies bedeutet entweder nicht verfolgte Dateien oder Dateien, die nicht "OK" sind (Hashes stimmen nicht überein).

Ich mag es im Allgemeinen, etckeeper ziemlich sofort auf dem System einzurichten. Mit so etwas wie etckeeper kann ich nicht nur feststellen, wann die Datei anders ist, sondern ich kann tatsächlich einen Unterschied feststellen, wie genau sie anders ist.

Sehen:

• Verwenden Sie die Versionskontrolle für Serverkonfigurationsdateien?
• Welches Tool empfehlen Sie, um Änderungen auf einem Linux / Unix-Server zu verfolgen?

Oder debsums -e | grep FAILED zeigt auch alle fehlenden Conffiles an

(aus dem debsums-paket)

Das mag übertrieben sein, aber da jemand etckeeper erwähnt hat und ich nachforschte, dass ich auf dieses andere Juwel gestoßen bin, ist es möglicherweise nützlicher, wenn Sie versuchen, Dinge "nachträglich" herauszufinden.

http://devstructure.com/blueprint/

Blueprint ist ein einfaches Konfigurationsmanagement-Tool, mit dem Server zurückentwickelt werden. Es stellt fest, was Sie manuell getan haben, speichert es lokal in einem Git-Repository, generiert Code, mit dem Sie Ihre Bemühungen neu erstellen können, und unterstützt Sie bei der Bereitstellung dieser Änderungen in der Produktion.

Dies weicht ein wenig von der ursprünglichen Frage ab, da ADDED-Konfigurationsdateien im Gegensatz zu nur den geänderten Dateien angezeigt werden. Obwohl Dateien, die in keinem Deb-Paket enthalten sind, auch abgefangen werden. Beide Verhaltensweisen können durchaus wünschenswert sein.

Dies hängt davon ab, dass Sie etckeeper im Idealfall von Anfang an mit git vcs verwendet haben. Dies sollte jedoch auch funktionieren, wenn Sie zuvor geänderte Dateien nach dem ersten Commit hinzufügen und festschreiben . Beachten Sie, dass Ubuntu etckeeper so konfiguriert, dass es standardmäßig Bazaar verwendet (Canonical Sponsor Bazaar), und nicht den von den etckeeper-Entwicklern festgelegten Git-Standard.

Die Idee ist, eine Liste aller Commits zu erhalten, die nach und nach nicht automatisch ausgeführt werden. Listen Sie dann die Dateien auf, die mit Ausnahme des ersten Commits geändert wurden:

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"

Die Filterzeichenfolge kann auch erweitert werden, um andere Festschreibungen einzuschließen, wenn sie konsistent benannt sind. Könnte für Installationen direkt aus einer Deb-Datei oder aus dem Quellcode gut sein.

Eine bemerkenswerte Datei, die dies für mich aufnimmt, ist meine xorg.conf- Sie müssen sie derzeit selbst zu / etc / X11 hinzufügen, wenn Sie sie benötigen. Auch meine default/grubÄnderungen wurden übernommen, anscheinend wurde dies von einem Post-Installationsskript aus / usr / share kopiert, anstatt als Teil eines Pakets aufgelistet zu werden. Wenn an einer Datei wie dieser eine Änderung vorgenommen wurde, wird sie von dpkg-bezogenen Methoden nicht angezeigt.