debsums listet nicht alle geänderten Konfigurationsdateien

[MSfree]

Ich habe den Hinweis gefunden, daß man mit debsums -ac nach geänderten Konfigurationsdateien suchen kann.

Warum zeigt mir debsums aber nicht an, daß ich

Code: Alles auswählen

/etc/default/grub
/etc/network/interfaces
/etc/ssh/sshd_config
/etc/systemd/journald.conf

geändert habe?

Gibt es da etwas zuverlässigeres als debsums?

[tobo]

Ich habe den Hinweis gefunden, daß man mit debsums -ac nach geänderten Konfigurationsdateien suchen kann.

Warum zeigt mir debsums aber nicht an, daß ich

Code: Alles auswählen

/etc/default/grub
/etc/network/interfaces
/etc/ssh/sshd_config
/etc/systemd/journald.conf

geändert habe?

Vermutlich, weil diese Dateien nicht kopiert, sondern generiert werden (zumindest die ersten 3 davon). Es existiert kein Paket, welches z.B. die Datei /etc/network/interfaces bereitstellt. Generiert vermutlich dann durch irgendwelche *.postinst in /var/lib/dpkg/info/.

Code: Alles auswählen

grep -P '(/etc/default/grub|/etc/network/interfaces|/etc/ssh/sshd_config|/etc/systemd/journald.conf)$' /var/lib/dpkg/info/*.conffiles

[hikaru]

Gibt es da etwas zuverlässigeres als debsums?

Du könntest dir irgendwo eine Standardinstallation* halten, und dazu diffs erzeugen.

*) Was auch immer man darunter verstehen möchte.

[schwedenmann]

Hallo

siehe auch hier,wenn es nur um die Überwachung /etc geht

etchkeeper und changetrack

viewtopic.php?t=175023

mfg
schwedenmann

[MSfree]

Danke ertmal bis hier.

siehe auch hier,wenn es nur um die Überwachung /etc geht

etchkeeper und changetrack

viewtopic.php?t=175023

Im Grunde geht es mir darum, für Backupzwecke die Konfiguratrionsänderungen zu kennen. Ich habe natürlich Notizen, was ich eingerichtet habe und was geändert wurde. Aber wir kennen alle Murphy, irgendwas vergißt man immer. Eine einfache nachträgliche Kontrolle wäre halt schön, scheint es aber nicht zu geben.

Sollte das System mal neu aufgesetzt werden müssen, restauriere ich einfach alle installierten Pakete. Die Liste bekommt man einfach mit apt-mark showmanual, zusammen mit den Konfigurationsdateien hat man ein sehr kompaktes "Backup", das in ein paar MByte paßt, ohne das komplette System sichern zu müssen. (Daten sind selbstverständlich separat ge-rsync-t). High availability ist bei mir nicht notwendig, eine Restaurierung muß nicht innerhalb von Minuten möglich sein, da reichen auch ein paar Tage.

Eine permanente Überwachung halte ich in diesem Zusammenhang für Kanonen, die auf Spatzen schießen.

[schwedenmann]

Hallo

gerade mal per diif und synaptic gescuht und das hier gefunden

dirdiff

https://manpages.ubuntu.com/manpages/fo ... iff.1.html

Wenn du sowieso ein backup von /etc hast, sollte man doch per dirdiff (habe ich jedenfalls so verstanden) die Unterschiede zwischen /etc und /backup/etc rausfinden können.

mfg
schwedenmann

[JTH]

Im Grunde geht es mir darum, für Backupzwecke die Konfiguratrionsänderungen zu kennen.

Du könntest dir irgendwo eine Standardinstallation* halten, und dazu diffs erzeugen.

Man könnte sich gezielt die Dateien raussuchen, die eben nicht als simple Datei aus einem Paket stammen, sondern auf irgendeine Weise, neben postinst z.B. auch vom Installer, erzeugt wurden. sources.list und fstab z.B. werden ja vom Installer angelegt.

Sowas hier

Code: Alles auswählen

find /etc -type f -not -exec sh -c 'dpkg -S "{}" >/dev/null 2>&1' \; -print

würd dir die „erzeugten“ Dateien auflisten, evtl. ist es noch sinnvoll, Symlinks (z.B. in /etc/systemd/system) einzuschließen. Das ist aber tatsächlich ne ganze Latte und sowas wie .dpkg-old-Dateien könnte man dort noch rausfiltern.

[tobo]

Man könnte sich gezielt die Dateien raussuchen, die eben nicht als simple Datei aus einem Paket stammen, sondern auf irgendeine Weise, neben postinst z.B. auch vom Installer, erzeugt wurden. sources.list und fstab z.B. werden ja vom Installer angelegt.

Sowas hier

Code: Alles auswählen

find /etc -type f -not -exec sh -c 'dpkg -S "{}" >/dev/null 2>&1' \; -print

würd dir die „erzeugten“ Dateien auflisten [...]

Angelehnt an oben würde dann so was (in schnell) gehen:

Code: Alles auswählen

find /etc -type f ! -exec grep -q {}$ /var/lib/dpkg/info/*.conffiles \; -print

[reox]

Ich bin mir nicht sicher ob debsums das auch kann, aber mit debsums2 kannst du auch alle Dateien anzeigen lassen, die nicht in einem Paket enthalten sind, also zB die von install scripten generierten: https://github.com/reox/debsums2 (Ist eine py3 kompatible variante zum Original viewtopic.php?t=151947)
Es hat dann sogar noch jemand weiter entwicklelt, um python packages zu testen: https://github.com/lorenzo-dev1/integrity_checker

[MSfree]

Code: Alles auswählen

find /etc -type f ! -exec grep -q {}$ /var/lib/dpkg/info/*.conffiles \; -print |\
grep -v -E "(old$|dist$|\~$)"

liefert eine Liste ohne die beim (dist-)upgrade angelegten Backupkopien.

Jetzt müßte man "nur" noch feststellen können, welche Dateien von dieser List nicht mehr dem Originalzustand entsprechen.

Kann man diese durch Aufruf der Post-Inst Skripte in einem temporären Verzeichnis anlegen lassen?

[JTH]

Angelehnt an oben würde dann so was (in schnell) gehen:

Code: Alles auswählen

find /etc -type f ! -exec grep -q {}$ /var/lib/dpkg/info/*.conffiles \; -print

Ah, jo, das ist signifikant schneller. Liefert allerdings potentiell einige Dateien mehr, die zwar in /etc liegen, aber – bewusst oder unbewusst – nicht als Conffile deklariert sind. Ob das für den Backupzweck relevant, problematisch oder egal ist, müsste man im Einzelfall entscheiden.

nvme-cli z.B. hat (bei mir hier) 4 Dateien in /etc liegen, die dpkg -S auch dem Paket zuordnet, die in /var/lib/dpkg/info/nvme-cli.conffiles allerdings nicht gelistet sind.

Jetzt müßte man "nur" noch feststellen können, welche Dateien von dieser List nicht mehr dem Originalzustand entsprechen.

Kann man diese durch Aufruf der Post-Inst Skripte in einem temporären Verzeichnis anlegen lassen?

Puh, das ist sicher irgendwie möglich. Aber nicht trivial, indem du die Skripte mit irgendwelchen Parametern aufrufst. Maintainerskripte können ja theoretisch beliebig geschriebene Skripte sein, die sich nicht per z.B. Umgebungsvariable mitteilen lassen, wo sie ihre Daten hinschreiben sollen. Um diese Unterschiede herauszufinden, müsstest du dir vermutlich tatsächlich

irgendwo eine Standardinstallation* halten, und dazu diffs erzeugen.

*) Was auch immer man darunter verstehen möchte.

Alternativ könntest du diese Dateien einmal initial mit sichern und bei folgenden Sicherungen schauen, ob sich die aktuelle Datei im Vergleich zur älteren Sicherung, statt zum Paketoriginalzustand, verändert hat.

[tobo]

Ah, jo, das ist signifikant schneller. Liefert allerdings potentiell einige Dateien mehr, die zwar in /etc liegen, aber – bewusst oder unbewusst – nicht als Conffile deklariert sind. Ob das für den Backupzweck relevant, problematisch oder egal ist, müsste man im Einzelfall entscheiden.

nvme-cli z.B. hat (bei mir hier) 4 Dateien in /etc liegen, die dpkg -S auch dem Paket zuordnet, die in /var/lib/dpkg/info/nvme-cli.conffiles allerdings nicht gelistet sind.

Die Quellen, die ich finde, sprechen da aber eine andere Sprache (nur 1 Datei):
https://packages.debian.org/bookworm/am ... i/filelist

Code: Alles auswählen

$ apt-file list nvme-cli | grep /etc
nvme-cli: /etc/nvme/discovery.conf
$ dpkg -L nvme-cli | grep /etc
/etc
/etc/nvme
/etc/nvme/discovery.conf
$

[MSfree]

Ich hatte gerade die Idee, über das Datum der Paketinstallation zu gehen. Dumm nur, daß man zu einer Datei, die keinem Paket zugeordnet werden kann, auch kein Vergleichsdatum ermitteln kann.

Die Liste, die

Code: Alles auswählen

find /etc -type f ! -exec grep -q {}$ /var/lib/dpkg/info/*.conffiles \; -print |\
grep -v -E "(old$|dist$|\~$)"

erzeugt, ist bei mir 237 Zeilen lang. Die kann ich zur Not auch manuell durchgehen. Zusammen mit der Liste, die debsums -ac erzeugt, habe ich erstmal einen aktuellen Stand.

[JTH]

[…] habe ich erstmal einen aktuellen Stand.

Gut, dann können wir den Thread ja kapern

Die Quellen, die ich finde, sprechen da aber eine andere Sprache (nur 1 Datei):
https://packages.debian.org/bookworm/am ... i/filelist

Tja und was machen wir nun? Bei mir siehts eben anders aus – 2.4+really2.3-3 aus Bookworm:

Code: Alles auswählen

$ dpkg -L nvme-cli | grep /etc
/etc/nvme/discovery.conf
/etc/nvme/hostid
/etc/nvme/hostnqn
/etc/udev/rules.d/70-nvmf-autoconnect.rules
/etc/udev/rules.d/71-nvmf-iopolicy-netapp.rules
$ grep /etc /var/lib/dpkg/info/nvme-cli.{conffiles,list}
/var/lib/dpkg/info/nvme-cli.conffiles:/etc/nvme/discovery.conf
/var/lib/dpkg/info/nvme-cli.list:/etc/nvme/discovery.conf
/var/lib/dpkg/info/nvme-cli.list:/etc/nvme/hostid
/var/lib/dpkg/info/nvme-cli.list:/etc/nvme/hostnqn
/var/lib/dpkg/info/nvme-cli.list:/etc/udev/rules.d/70-nvmf-autoconnect.rules
/var/lib/dpkg/info/nvme-cli.list:/etc/udev/rules.d/71-nvmf-iopolicy-netapp.rules

Die gelisteten Ordner, da irrelevant, rausgekürzt. apt-file gibt natürlich dasselbe aus wie bei dir.

Ich nehm mal an, dass nvme-cli bei einem Upgrade ein notwendiges oder zumindest sinnvolles rm_conffile im postinst vergessen hat. Die enthaltenen Udev-Rules z.B. wurden anscheinend irgendwann von /etc/udev nach /lib/udev verschoben, wie von der Debian-Policy empfohlen. Meine Installation des Pakets ist schon älter.