apt list –upgradeable <-- Pakete für Reboot ermitteln

[mzurhorst]

Hallo zusammen.

Ich bastele gerade an einem kleinen Python-Script, welches mir Informationen über meine Debian-VMs via MQTT an eine Zentrale sendet.
Dieses Script soll zwei Infos einsammeln zu dem Status der bereitstehenden Upgrades:

• Gesamtzahl der bereitstehenden Upgrades
• Hinweis, ob ein Reboot erforderlich ist nach Installation

Der erste Teil war einfach, aber an dem zweiten Teil knobele ich nun.
Wo genau wird festgelegt, ob ein Paket einen Neustart erfordert?

Es gibt das kleine Tool reboot-notifier, aber aus dessen Source [1] werde ich nicht schlau. Das greift anscheinend erst NACH der Installation. Ich benötige diesen Hinweis aber VOR der Installation, damit ich den Reboot einplanen kann.

Meine Vermutung ist, dass Debian irgendwo in den Metadaten eines Pakets dafür ein Flag hat.
Nur kann ich in der Dokumentation nichts finden.

(Mein erster Verdacht nach Sichtung dieses "reboot-notifier" Bash Scripts war, dass "linux-base" eine Kategorie von Paketen sei, welche immer einen Reboot benötigen. Aber so eine Kategorie gibt es nicht bei Debian.)

Hat hier im Forum jemand eine Idee, wo das spezifiziert wird?

Vielen Dank und Grüße,
Marcus


[1] https://salsa.debian.org/debian/reboot- ... t-required

[JTH]

Hallo zusammen.

Moin.

Meine Vermutung ist, dass Debian irgendwo in den Metadaten eines Pakets dafür ein Flag hat.

Nein, so etwas gibt es nicht. Es ist auch technisch nicht so generell notwendig. Die einzigen Pakete, nach deren Update ein Reboot wirklich regelmäßig notwendig ist, sind die Kernel-Pakete linux-image-*. Alle anderen Bestandteile kann man, auch wenn es im Einzelfall aufwändiger sein mag, im laufenden Betrieb auf einen neuen Stand bringen. Dienste z.B. neustarten, wo notwendig. Letzteres tun die jeweiligen Pakete aber sowieso normalerweise schon in ihren postinst-Skripten.

Ein Fall, der durch postinst-Skripte nicht abgedeckt sein kann, ist ein Update einer Bibliothek, die von einem Dienst benutzt wird. Ein danach notwendiges Neustarten betroffener Dienste kann man z.B. ganz leicht mit needrestart automatisieren.

(Mein erster Verdacht nach Sichtung dieses "reboot-notifier" Bash Scripts war, dass "linux-base" eine Kategorie von Paketen sei, welche immer einen Reboot benötigen. Aber so eine Kategorie gibt es nicht bei Debian.)

linux-base ist ein Hilfspaket, von dem alle linux-image-* abhängen. Deshalb wird es wohl als Grund für den Reboot angegeben. reboot-notifier benachrichtigt nämlich eben, wie die Paketbeschreibung sagt, von sich aus nur nach einem Kernelupdate, dass ein Reboot notwendig ist. Oder wenn – von anderen Paketen, in manchen postinst-Skripten wird das gemacht – eine Datei /var/run/reboot-required angelegt wurde (cron.daily aus reboot-required).

Der erste Teil war einfach, aber an dem zweiten Teil knobele ich nun.
Wo genau wird festgelegt, ob ein Paket einen Neustart erfordert?

[…] Das greift anscheinend erst NACH der Installation. Ich benötige diesen Hinweis aber VOR der Installation, damit ich den Reboot einplanen kann.

Einheitlich festgelegt ist das nirgendwo. Weil es wie gesagt kaum zwangsläufig notwendig ist. Die Datei /var/run/reboot-required ist ein semi-einheitlicher Mechanismus, um einen Reboot nahezulegen. Aber das kann immer nur währen/nach dem Update eines Pakets passieren.

Wenn du das unbedingt vorher erkennen willst, ob für dich ein Reboot notwendig erscheint, müsstest du wahrscheinlich eine Liste von Paketen pflegen, die ihn erfordern könnten. (Die eigentlich nur linux-image-* enthalten muss )

Hast du schon mal überlegt, unattended-upgrades zu benutzen?

[mzurhorst]

Hallo JTH,

danke für die ausführliche Erklärung.
Ich möchte ausdrücklich nicht die Updates unbeaufsichtigt lassen, zumindest für den Moment noch nicht.
Aber weil ich aktuell immer die inzwischen 7 VMs abklappere, und dort dann die Pakete manuell hoch ziehe, wollte ich mir das ersparen und mir eine Telegram Nachricht von der Zentrale senden lassen, auf welchem der Rechner denn nun gerade ein Paket bereitstehen würde.

Na gut, dann probiere ich es doch mal mit einem Filter, wo ich den Kernel und die glibc rein nehme.
Sofern solch ein Paket nicht dabei ist, dann könnte ich z.B. auch diesen Client via MQTT zurück melden, dass er doch bitte das dist-upgrade ausführt. Quasi "Unattended mit Genehmigung" .
Sollte mir dann irgendwann nochmal ein Paket auffallen, dann könnte ich das immer noch in meinen Filter aufnehmen. Würde ich ja spätestens dann merken, wenn ich mich einlogge und die MOTD beim Login einen Reboot einfordert, den es der Logik nach nicht geben sollte.

Top. Danke.

Grüße,
Marcus

[JTH]

Ich möchte ausdrücklich nicht die Updates unbeaufsichtigt lassen, zumindest für den Moment noch nicht. […]

Na gut, dann probiere ich es doch mal mit einem Filter, wo ich den Kernel und die glibc rein nehme.
Sofern solch ein Paket nicht dabei ist, dann könnte ich z.B. auch diesen Client via MQTT zurück melden, dass er doch bitte das dist-upgrade ausführt. Quasi "Unattended mit Genehmigung" .

Noch als Anmerkung dazu: Man kann unattended-upgrades Pakete mitgeben, die es nicht automatisch aktualisieren darf. Könnte man z.B. für den Kernel und libc machen (steht in der Standardconfig sogar, auskommentiert, schon drin).

Außerdem kann man das periodische Ausführen von unattended-upgrades auch abschalten und nur das dahinterstehende Werkzeug selbst für, naja, eben ein unattended Upgrade benutzen, das aber von Hand und nicht periodisch angestoßen. Das Werkzeug bringt auch für den Zweck ein paar Dinge mit, die vielleicht praktisch sind: Upgrades in kleinteiligen Schritten, falls zwischendurch doch etwas schiefgeht; eben einen direkten Reboot, wenn notwendig (auch zu späterer, festgelegter Zeit), etc.

[mzurhorst]

Oh, das muss ich mir doch noch mal genauer anschauen.
Aber nun bin ich schon halbswegs durch mit der Python-Exkursion, da möchte ich zumindest den MQTT Teil und die Telegram Benachrichtigung aufs Handy gerne erledigen.
Alles für die Wissenschaft

[JTH]

Alles für die Wissenschaft

Natürlich, beim Selbstmachen lernt man ja auch andere Dinge, als mit der Fertiglösung