[solved] Upgrade auf Bullseye hinterlässt "/etc/cron.daily/bsdmainutils.dpkg-remove"

[funkymaster]

Hallo,

das Update lief ohne Probleme durch.
Beim Bereinigen wie in Punkt 4.2.6. Bereinigen alter Konfigurationsdateien beschrieben, bleibt jedoch oben genannte Datei über.
Genauer gesagt wird diese während dem Upgrade von
/etc/cron.daily/bsdmainutils
in
/etc/cron.daily/bsdmainutils.dpkg-remove
umbenannt.

Leider konnte ich auf die Schnelle nicht festellen, was mit der Datei passieren soll.
Hat jemand eine Idee?

Danke!

[JTH]

Die kannst du einfach so löschen, sie wurde anscheinend (963178) nur versehentlich angelegt.

Unabhängig von dieser konkreten Datei sind die .dpkg-remove-Dateien immer Konfigurationen, die vom dazugehörigen Paket obsolet gemacht wurden und gelöscht werden können. Außer du willst dir, vor dem Löschen, vorsichtshalber Daten daraus merken. Zum Hintergrund siehe man dpkg-maintscript-helper unter „Removing a conffile“.

[mcb]

.....
Unabhängig von dieser konkreten Datei sind die .dpkg-remove-Dateien immer Konfigurationen, die vom dazugehörigen Paket obsolet gemacht wurden und gelöscht werden können. Außer du willst dir, vor dem Löschen, vorsichtshalber Daten daraus merken. Zum Hintergrund siehe man dpkg-maintscript-helper unter „Removing a conffile“.

Sorry darf ich mich hier einfach mal dranhängen:

Code: Alles auswählen

root@mb:~# find /etc -name '*.dpkg-*' -o -name '*.ucf-*' -o -name '*.merge-error'
/etc/fwupd/remotes.d/lvfs-testing.conf.dpkg-old
/etc/ca-certificates.conf.dpkg-old
/etc/initramfs-tools/initramfs.conf.dpkg-old

Die kann ich einfach löschen - da sie eh nicht mehr genutzt werde? Mir sind auch keine Fehler aufgefallen.

[JTH]

Die kann ich einfach löschen - da sie eh nicht mehr genutzt werde? Mir sind auch keine Fehler aufgefallen.

Ganz generell: Ja, auch die .dpkg-old kann man löschen. Aber: Bei denen sollte man erst recht nachgucken, ob sie nicht Einträge enthalten, die man behalten/übernehmen möchte. Die .dpkg-old entstehen, wenn ein Paket neue Defaultwerte für seine Konfigs mitbringt und man selbst die Konfig bearbeitet hat (= sie nicht mehr die alten Defaultwerte enthält).

Also als Unterschied: Die .dpkg-remove oben sind (ohne die extra Endung) eine Konfigdatei, die das Paket gar nicht mehr benutzt. Die .dpkg-old entstehen, wenn ein Paket seine Defaultwerte ändert und die Datei (ohne extra Endung) aber weiterhin benutzt!

Als Hintergrund von Raphaël Hertzog: Everything you need to know about conffiles: configuration files managed by dpkg.

[mcb]

Die kann ich einfach löschen - da sie eh nicht mehr genutzt werde? Mir sind auch keine Fehler aufgefallen.

Ganz generell: Ja, auch die .dpkg-old kann man löschen. Aber: Bei denen sollte man erst recht nachgucken, ob sie nicht Einträge enthalten, die man behalten/übernehmen möchte. Die .dpkg-old entstehen, wenn ein Paket neue Defaultwerte für seine Konfigs mitbringt und man selbst die Konfig bearbeitet hat (= sie nicht mehr die alten Defaultwerte enthält).

Also als Unterschied: Die .dpkg-remove oben sind (ohne die extra Endung) eine Konfigdatei, die das Paket gar nicht mehr benutzt. Die .dpkg-old entstehen, wenn ein Paket seine Defaultwerte ändert und die Datei (ohne extra Endung) aber weiterhin benutzt!

Als Hintergrund von Raphaël Hertzog: Everything you need to know about conffiles: configuration files managed by dpkg.

Danke !!!

Ich glaube ich habe es "verstanden" in

Code: Alles auswählen

/etc/initramfs-tools/initramfs.conf.dpkg-old

hatte ich die Kompriemierung geändert. In der neuen /etc/initramfs-tools/initramfs.conf ist wieder der default Wert drin.

Gibt es noch eine einfache Erklärung wieso laut Debiananleitung die Datei stört ?!? Ich denke die wird vom System ignoriert?

So erstmal genug aufgeräumt:

Code: Alles auswählen

root@mb:~# find /etc -name '*.dpkg-*' -o -name '*.ucf-*' -o -name '*.merge-error'
/etc/ca-certificates.conf.dpkg-old
root@mb:~# 

[funkymaster]

@JTH: Super, danke für die Antworten!

@mcb: Bei mir hat sich bei den Konfigurationsdateien folgende Vorgangsweise bewährt:

1. Bei den Abfragen während dem Upgrade immer die aktuelle Konfiguration behalten (N ist normalerweise eh schon die Standardaktion)
2. Nach dem Upgrade ein Backup von der Konfigurationsdatei
3. Die Änderungen/Neuerungen von .dpkg-dist manuell in die aktuelle Konfigurationsdatei mergen
4. .dpkg-dist Datei löschen

Aufpassen muss man aber, wenn man eine eigene zusätzliche Konfigurationsdatei anlegt.

Ein gutes Beispiel ist da unattended-upgrades.
Die Datei /etc/apt/apt.conf.d/50unattended-upgrades bleibt bei mir unangetastet und meine eigene Konfiguration kommt in /etc/apt/apt.conf.d/52unattended-upgrades-local.
Das hat den Vorteil, dass sich unattended-upgrades selbst akualisieren und die /etc/apt/apt.conf.d/50unattended-upgrades automatisch updaten kann.
Der Nachteil besteht aber darin, dass man eventuell notwendige Änderungen der Konfiguration nicht automatisch mitbekommt.

Deswegen habe ich mir solche Fälle z.B. in meiner persönlichen Updateanleitung vermerkt.
Und immer die Unattended upgrade result: Emails lesen.

mfg

Edit: .dpkg-old auf .dpkg-dist geändert.

[ingo2]

@mcb: Bei mir hat sich bei den Konfigurationsdateien folgende Vorgangsweise bewährt:

1. Bei den Abfragen während dem Upgrade immer die aktuelle Konfiguration behalten (N ist normalerweise eh schon die Standardaktion)
2. Nach dem Upgrade ein Backup von der Konfigurationsdatei
3. Die Änderungen/Neuerungen von .dpkg-old manuell in die aktuelle Konfigurationsdatei mergen
4. .dpkg-old Datei löschen

Aufpassen muss man aber, wenn man eine eigene zusätzliche Konfigurationsdatei anlegt.

Dann versuch' damit mal einen remote server via SSH updaten.
Wenn du da nicht deine alte /etc/ssh/sshd_config behältst, bist du anschließend fast sicher ausgesperrt!

Und aktuell noch ganz wichtig:
Lies' mal vorher die release notes von Bullseye bezüglich des Upgrades via SSH durchdurch! https://www.debian.org/releases/bullsey ... -available

[funkymaster]

@ingo2: Lies dir doch meinen Beitrag nochmal genau durch. Dann wirst du feststellen, dass wir der gleichen Meinung sind.

Wahrscheinlich hat dich in meinem ursprünglichen Post die .dpkg-old irritiert.
Ich hab das jetzt geändert.

Dazu muss ich sagen, dass ich hier auf einem Server tatsächlich ein etwas seltsames Verhalten hatte.
Scheinbar dürfte die Abfrage case-sensitive sein, denn wenn ich mit n antworte, werden die neuen Konfigurationsdateien als .dpkg-old abgelegt und die aktuellen Konfigurationsdateien bleiben aber unberührt.
Bei einer Antwort mit N oder einem einfachen Bestätigen der Standardantwort, werden die neuen Konfigurationsdateien wie zu erwarten als .dpkg-dist abgelegt.

Kennt das Verhalten auf die Art jemand?

[JTH]

Scheinbar dürfte die Abfrage case-sensitive sein, […]

Nope, das kann ich widerlegen Groß- oder Kleinbuchstabe ist bei der Abfrage egal. Vielleicht hast du dich versehentlich, unbemerkt vertippt?

[funkymaster]

Nope, das kann ich widerlegen Groß- oder Kleinbuchstabe ist bei der Abfrage egal. Vielleicht hast du dich versehentlich, unbemerkt vertippt?

Danke, dafür. Also

Code: Alles auswählen

tolower

Gut, das wäre geklärt.

Nur verstehe ich das Verhalten dann trotzdem nicht.
Auszug aus term.log:

Code: Alles auswählen

smartmontools (7.2-1) wird eingerichtet ...

Konfigurationsdatei »/etc/default/smartmontools«
 ==> Geändert (von Ihnen oder von einem Skript) seit der Installation.
 ==> Paketverteiler hat eine aktualisierte Version herausgegeben.
   Wie möchten Sie vorgehen? Ihre Wahlmöglichkeiten sind:
    Y oder I : Die Version des Paket-Betreuers installieren
    N oder O : Die momentan installierte Version beibehalten
       D     : Die Unterschiede zwischen den Versionen anzeigen
       Z     : Eine Shell starten, um die Situation zu begutachten
 Der Standardweg ist das Beibehalten der momentanen Version.
*** smartmontools (Y/I/N/O/D/Z) [Vorgabe=N] ? n
Neue Version der Konfigurationsdatei /etc/init.d/smartmontools wird installiert ...

Konfigurationsdatei »/etc/smartd.conf«
 ==> Geändert (von Ihnen oder von einem Skript) seit der Installation.
 ==> Paketverteiler hat eine aktualisierte Version herausgegeben.
   Wie möchten Sie vorgehen? Ihre Wahlmöglichkeiten sind:
    Y oder I : Die Version des Paket-Betreuers installieren
    N oder O : Die momentan installierte Version beibehalten
       D     : Die Unterschiede zwischen den Versionen anzeigen
       Z     : Eine Shell starten, um die Situation zu begutachten
 Der Standardweg ist das Beibehalten der momentanen Version.
*** smartd.conf (Y/I/N/O/D/Z) [Vorgabe=N] ? n
Removing obsolete conffile /etc/smartmontools/run.d/10powersave-notify ...
Created symlink /etc/systemd/system/smartd.service → /lib/systemd/system/smartmontools.service.
Created symlink /etc/systemd/system/multi-user.target.wants/smartmontools.service → /lib/systemd/system/smartmontools.service.

dpkg.log:

Code: Alles auswählen

2021-08-18 14:27:11 upgrade smartmontools:amd64 6.6-1 7.2-1
2021-08-18 14:27:11 status half-configured smartmontools:amd64 6.6-1
2021-08-18 14:27:11 status unpacked smartmontools:amd64 6.6-1
2021-08-18 14:27:11 status half-installed smartmontools:amd64 6.6-1
2021-08-18 14:27:12 status unpacked smartmontools:amd64 7.2-1
...
...
2021-08-18 14:27:19 configure smartmontools:amd64 7.2-1 <none>
2021-08-18 14:27:19 status unpacked smartmontools:amd64 7.2-1
2021-08-18 14:29:34 conffile /etc/default/smartmontools keep
2021-08-18 14:30:02 conffile /etc/smartd.conf keep
2021-08-18 14:30:02 status half-configured smartmontools:amd64 7.2-1
2021-08-18 14:30:05 status installed smartmontools:amd64 7.2-1

[JTH]

Hmm, ich seh da noch keine Auffälligkeiten:

/etc/default/smartmontools ist modifiziert und wird wie ausgewählt – den Logs nach – beibehalten:

Code: Alles auswählen

Konfigurationsdatei »/etc/default/smartmontools«
*** smartmontools (Y/I/N/O/D/Z) [Vorgabe=N] ? n

2021-08-18 14:29:34 conffile /etc/default/smartmontools keep

/etc/init.d/smartmontools ist nicht modifiziert und wird einfach überschrieben:

Code: Alles auswählen

Neue Version der Konfigurationsdatei /etc/init.d/smartmontools wird installiert ...

/etc/smartd.conf ist modifiziert und wird wie ausgewählt beibehalten:

Code: Alles auswählen

Konfigurationsdatei »/etc/smartd.conf«
*** smartd.conf (Y/I/N/O/D/Z) [Vorgabe=N] ? n

2021-08-18 14:30:02 conffile /etc/smartd.conf keep

Den Rest ignorier ich mal.

Aufällig – verkehrt – wäre es, wenn du nach der Installation eine /etc/default/smartmontools.dpkg-old oder /etc/smartd.conf.dpkg-old hast. War das so? Wenn ja könnten die vielleicht auch von einem vorherigen, älteren Update kommen. Müsstest mal auf die Zeitstempel gucken.

[funkymaster]

Aufällig – verkehrt – wäre es, wenn du nach der Installation eine /etc/default/smartmontools.dpkg-old oder /etc/smartd.conf.dpkg-old hast. War das so? Wenn ja könnten die vielleicht auch von einem vorherigen, älteren Update kommen. Müsstest mal auf die Zeitstempel gucken.

Genau so war es.
Alt können die Files nicht sein, weil ich diese, wie in der Anleitung beschrieben, vor dem Upgrade gelöscht habe.
Zeitstempel gibt es keinen mehr, weil ich die .dpkg-old Dateien nach dem Mergen leider schon gelöscht habe.

Eventuell versuche ich mal, das Verhalten in einer VM nachzustellen.

Danke für die Hilfe!