< zurück >

autoupdate - ein Service-Script zur Durchführung von automatisch ablaufenden und regelmäßigen Systemaktualisierungen.

Das Problem

Nein, natürlich liegt hier kein wirkliches Problem vor, welches mit diesem Programm unbedingt gelöst werden muss. Das Programm ist eher als Folge von mehreren früheren Entscheidungen entstanden, die alle auf den Umstand zurückzuführen sind, dass ich bereits damals eigentlich überhaupt keine Lust mehr darauf hatte, mich mit Problemen zu befassen, für die ich nicht selber verantwortlich bin. Das war u.a. auch einer der großen Antriebe, wegen derer ich überhaupt zu Linux gewechselt bin. Ich hatte die vielen Probleme mit Windows schlichtweg satt und wollte stattdessen einfach nur mal störungsfreie PC-Systeme haben. Meine dann folgenden ersten Erfahrungen mit verschiedenen Desktops zweier sehr populärer Windows-Umsteiger-Linux-Distributionen waren allerdings ziemlich ernüchternd. Richtig zufriedenstellend lief das nämlich auch alles nicht. Ganz im Gegenteil, das hatte alles mehr den Anschein einer Dauerbaustelle, wegen ständiger Veränderungen/Aktualisierungen an den Systemen und deswegen ständig irgendwelche kleinen neu auftauchenden Problemen und Problemchen... womit das dann natürlich auch keine echte Lösung war. Erst mit meinem Wechsel zu Debian und kurze Zeit später mit der Entscheidung, vom Installer jetzt keine fertigen Desktop-Umgebungen mehr installieren zu lassen, habe ich mein Ziel erreicht, Probleme und Störungen fast vollständig zu eliminieren. Seit ca. 2 Jahren sind alle unsere Systeme mit einem mehr oder weniger gleichen Customer-Desktop-Environment auf Debian-Basis ohne GUI aufgesetzt. Dazu wurde dann manuell Lightdm und Openbox, die zwingend benötigten Komponenten für den X-Server und natürlich die von uns gewünschten Anwendungspakete installiert. Und damit läuft es, und läuft, und läuft, und läuft...

Tja, all diese Entscheidungen haben letztlich zum Wegfall einer großen Menge des vom Installer regulär installierten Ballastes für die Standard-Desktops geführt, der wie auch schon unter Windows häufig allein durch die Menge für das eine oder andere Problem verantwortlich war. Und das Fehlen dieses nun nicht mehr vorhandenen Ballastes hatte dann auch tatsächlich zur Folge, dass alle unsere Systeme heute so gut wie störungsfrei laufen, fast ohne Betreuungsaufwand ... und das nun wirklich schon über eine lange Zeit. Leider hatte diese Vorgehensweise aber dann den Nachteil, dass wir auf viele zu einem regulären Desktop-Environment gehörenden Komfort-Werkzeuge/-Tools verzichten mussten, wie z.B. den Network-Manager oder hier die vom Desktop-Environment durchgeführte Überprüfung auf vorhandene Systemaktualisierungen, die dann auch noch automatisch durchgeführt werden. Und um genau diese selbstverursachten Mängel wieder auszugleichen, sind einige der Tools auf dieser Web-Site entstanden, alle mit der Absicht, dass sie möglichst stabil und störungsfrei und völlig unaufgeregt und natürlich idealerweise mannlos ihren Job tun. So jetzt auch autoupdate.

Risiken?

Kann man das wirklich so machen oder ist das für das System vielleicht auch riskant? Ja, man kann das so machen... und ja, jeder Automatismus, der das System grundlegend verändern kann, beinhaltet Risiken für das System. Das war eben auch einer meiner Gründe, nicht die "unattended upgrades" zu verwenden, sondern den Upgrade-Prozess nur bei Anwesenheit des Anwenders und sichtbar im Vordergrund laufen zu lassen. Ganz klar, es kann trotzdem jederzeit irgendwas passieren, Stromausfall, Akkus des Laptops genau jetzt leer, ein gezogener Stecker, zufällig und fälschlicherweise aus der Historie eines anderen Terminals "systemctl poweroff -f -f" ausgewählt, usw.... und schon ist es passiert, alles kaputt...

Bezogen auf unsere Systeme halte ich die Risiken aus folgenden Gründen allerdings trotzdem für sehr gering:

Und heute, nach mehr als 2 Jahren Laufzeit dieses Jobs auf mehreren Systemen, bin ich in keinster Weise mehr beunruhigt. Es hat bisher auf keiner unserer Maschinen damit oder deswegen Probleme gegeben... ganz im Gegenteil, dieses Script sorgte während der ganzen Zeit zuverlässig dafür, dass keines unserer Systeme überaltert, weil ich als "Admin" das vielleicht nicht regelmäßig kontrolliere und die notwendigen Arbeiten durchführe.

Die Abhängigkeiten

autoupdate hat folgende Abhängigkeiten:

- Geschrieben und getestet für/auf Debian und Raspian

- xterm zur Anzeige des Fortschrittsfensters beim/während des Upgrades

- dialog oder zenity zur Anzeige der Dialoge ( dialog ist effektiv und klein, zenity sieht toll aus, benötigt aber sehr viel overhead, funktional ist beides identisch)

- polkit, zur Berechtigungsprüfung

- wrapper zum Start des Scripts durch den Anwender ...(der das natürlich nicht selber tut, sondern idealerweise im Autostart des Users ausgeführt wird)

- script-Policy zur Einrichtung einer Berechtigung für ansonsten unberechtigte Anwender, die es dem User erlaubt, autoupdate zu starten

Von den verwendeten Funktionen xterm, dialog, zenity, das Policykit sowie die Tools des Paketmanagments apt und apt-get sind nicht alle Bestandteil einer Standard-Installation mit Debian/Raspian und ggf. müssen Pakete manuell nachinstalliert werden: Möglicherweise fehlen xterm, dialog oder zenity. Wegen der Anzeige des Tracefensters ist xterm zwingend notwendig. Von den  beiden Dialog-Box-Alternativen ist letztendlich nur eine notwendig. Sind jedoch beide vorhanden, wird bevorzugt zenity verwendet.

Mit dem folgenden Befehl kann geprüft werden, ob die Pakete bereits installiert sind:

dpkg -l xterm dialog zenity

Wenn Pakete fehlen, können sie einzeln oder alle auf einmal nachinstalliert werden:

apt update

apt install xterm dialog  [ zenity ]

Das Programm

Die Aufgabe von autoupdate ist es, in regelmäßigen Abständen im Debian-Repository auf vorhandene Aktualisierungen zu prüfen und diese dann auch zu installieren. Und das gerade auch vor dem Hintergrund, wenn entweder der Anwender an der Tastatur nicht oft genug oder nicht zuverlässig genug selber daran denkt, oder wenn dieser Anwender weder über die Kenntnisse noch über eine root-Berechtigung verfügt, um diese Aktualisierung überhaupt manuell durchzuführen zu können. Das letztere ist bei uns die Regel.

autoupdate wird nicht beim Systemstart durchgeführt, sondern es wird erst gestartet, nachdem sich der User angemeldet hat. Das ist so gewollt, weil ich es für zwingend notwendig erachte, dass gerade ein solcher für die Systemstabilität hochgradig relevanter Prozess nicht einfach still im Hintergrund ablaufen sollte. Wenns "knallt", soll es der Anwender unmittelbar live erkennen und sich dann sofort bemerkbar machen können... am Besten, bevor ein zu spät erkannter Schaden an den installierten Paketen nachher eine völlige Neuinstallation erforderlich macht oder das schlimmstenfalls vielleicht sogar persönliche Daten verloren gehen.

Der Aufruf des Programms autoupdate erfolgt also nur im Autostart des Desktop-Environments vom Hauptbenutzer dieses PC. Das bedeutet, dass ich davon ausgehe, dass jeder PC einen Hauptbenutzer hat, der diesen PC regelmäßig bedient. Sofern es weitere Benutzer gibt, so sind diese eben nur weitere Benutzer, bei denen dieser Job eigentlich nicht erforderlich ist. Die regelmäßigen Anmeldungen des Hauptbenutzers sorgen für eine ausreichende Aktualität des installierten Betriebssystems.

Es ist immer der gleiche Eintrag zum Start des Programms notwendig, ganz egal in welchem Deskop das passieren soll:

/usr/local/bin/pkexec-run autoupdate &

Der Eintrag erfolgt beim Desktop

Bei allen anderen wird es mehr oder weniger ähnlich sein.  Mein aktuell eingerichteter und jetzt von mir favorisierter Autostart erfolgt auf unseren Client-PCs über den XDG-Autostart, der zudem auf unseren Systemen auch noch weitere individuelle Starter enthält. Die Kennziffer '50' beeinflusst als Prefix nur die Reihenfolge der eingerichteten Autostarts. Für diese Autostart-Variante wird kein '&' zur Steuerung des Prozesses in den Hintergrund angefügt!

[Desktop Entry]

Type=Application

Exec=/usr/local/bin/pkexec-run autoupdate

Terminal=false

Wenn sich der User anmeldet, öffnet sich nach ca. 20 Sekunden (Default-Wartezeit) die folgende Abfrage, mit der der User entscheiden kann, ob die Systemaktualisierung jetzt durchgeführt werden kann/darf. Wenn der Anwender sich für "Nein" entscheidet, passiert in dieser angemeldeten Sitzung nichts mehr, es wird nicht neu nachgefragt. Erst nachdem sich der Anwender nach einer Abmeldung oder einem Systemstart erneut anmeldet, wird er auch erneut gefragt. Die Abfrage wird solange bei jeder Anmeldung erneut einmalig wiederholt, bis er die Aktualisierung hat durchlaufen lassen. Danach erfolgt die nächste Abfrage erst wieder, wenn die eingestellte Wartezeit von n Tagen überschritten ist.. Als Default-Wert sind 3 Tage Wartezeit eingestellt, bis die nächste Abfrage erscheint. Die Default-Werte können über Commandline-Parameter natürlich verändert werden.

Mit Verwendung des Programms dialog öffnen sich vor und nach der Aktualisierung diese 2 Dialog-Boxen:

 

Mit Verwendung des Programms zenity öffnen sich diese 2 Dialog-Boxen:

 

Wie ich zuvor schon festgestellt habe, besteht funktional für den Anwender keinen Unterschied in diesen Dialogen. Zenity sieht wirklich klasse aus, installiert aber auch eine große Menge an abhängige Pakete. Dialog macht exakt das gleiche, ist hingegen aber eine wirklich sehr schlanke Anwendung.

Wenn die Systemaktualisierung mit Click auf [OK] bestätigt wird, öffnet sich automatisch ein weiteres Fenster, in dem der vollständige Ablauf verfolgt werden kann. Hier ist es jetzt zuerst nur die Prüfung via "apt update", mit der bei diesem Joblauf festgestellt wurde, dass das System aktuell ist. Wären jedoch zu aktualisierende Pakete vorhanden, ist der weitere Jobverlauf natürlich auch zu sehen, welche Pakete geladen werden, der Download und schließlich auch die Installation der Pakete.

 

Falls es bei der Rückverfolgung von Problemen oder für eine sonstige Diagnose notwendig ist, die Systemaktualisierungen zu prüfen, so kann das mithilfe der gespeicherten Logs geschehen. Im Verzeichnis /var/log/autoupdates wird für jeden Lauf ein eigenes Log mit Datum versehen angelegt:, welches dann folgenden Inhalt hat... hier als Beispiel von einem anderen Tag:

cat /var/log/autoupdates/thomaspc_180327.log

27-03-2018-22-07 /usr/local/bin/autoupdate on thomaspc started (2018-086)

=============================================================================================

Install updates on <thomaspc>

=============================================================================================

Perform update:

Holen:1 http://security.debian.org/debian-security stretch/updates InRelease [63,0 kB]

Ign:2 http://ftp.de.debian.org/debian stretch InRelease

Holen:3 http://ftp.de.debian.org/debian stretch-updates InRelease [91,0 kB]

OK:4 http://ftp.de.debian.org/debian stretch Release

Holen:5 http://security.debian.org/debian-security stretch/updates/main Sources [129 kB]

Holen:6 http://security.debian.org/debian-security stretch/updates/main amd64 Packages [361 kB]

Holen:7 http://security.debian.org/debian-security stretch/updates/main Translation-en [158 kB]

Es wurden 802 kB in 0 s geholt (1.379 kB/s).

Paketlisten werden gelesen...

=============================================================================================

Perform full upgrade:

Paketlisten werden gelesen...

Abhängigkeitsbaum wird aufgebaut....

Statusinformationen werden eingelesen....

Paketaktualisierung (Upgrade) wird berechnet...

Die folgenden Pakete werden aktualisiert (Upgrade):

  libicu57

1 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

Es müssen 7.700 kB an Archiven heruntergeladen werden.

Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.

Holen:1 http://security.debian.org/debian-security stretch/updates/main amd64 libicu57 amd64 57.1-6+deb9u2 [7.700 kB]

apt-listchanges: Lese Changelogs...

Es wurden 7.700 kB in 1 s geholt (4.712 kB/s).

Lese Datenbank ...

Lese Datenbank ... 5%

Lese Datenbank ... 10%

:::

Lese Datenbank ... 100%

Lese Datenbank ... 187295 Dateien und Verzeichnisse sind derzeit installiert.

Vorbereitung zum Entpacken von .../libicu57_57.1-6+deb9u2_amd64.deb ...

Entpacken von libicu57:amd64 (57.1-6+deb9u2) über (57.1-6+deb9u1) ...

libicu57:amd64 (57.1-6+deb9u2) wird eingerichtet ...

Trigger für libc-bin (2.24-11+deb9u3) werden verarbeitet ...

=============================================================================================

Perform autoclean:

Paketlisten werden gelesen...

Abhängigkeitsbaum wird aufgebaut....

Statusinformationen werden eingelesen....

=============================================================================================

Perform autoremove:

Paketlisten werden gelesen...

Abhängigkeitsbaum wird aufgebaut....

Statusinformationen werden eingelesen....

Die folgenden Pakete werden ENTFERNT:

 linux-image-4.9.0-3-amd64

0 aktualisiert, 0 neu installiert, 1 zu entfernen und 0 nicht aktualisiert.

Nach dieser Operation werden 190 MB Plattenplatz freigegeben.

Möchten Sie fortfahren? [J/n]

=============================================================================================

Update succesful! Next update at 2018-091

27-03-2018-22-08 Job end

Die Parameter zur Steuerung des Jobs

Im weiter oben aufgeführten Beispiel wird das Programm ohne Parameter gestartet. Diese Variante verwende ich beispielsweise auf allen virtuellen Rechnern, also den VMs. Ohne ausdrückliche Vorgaben werden hierbei für die Wartezeiten die Default-Werte verwendet. Für uns hat sich das als völlig ausreichend erwiesen. Auf unseren echten Systemen ist lediglich der User-Parameter angefügt (siehe Erklärung weiter unten), was dann im Openbox-Autostart gleichermaßen auf allen Maschinen wie folgt aussieht:  

/usr/local/bin/pkexec-run autoupdate -u $USER &

Oder auf nicht täglich gestarteten Systemen mit einer etwas höheren Wartezeit von 5 Tagen:

/usr/local/bin/pkexec-run autoupdate -u $USER -d 5 &

Neben der direkten Programmsteuerung mit Commandline-Parametern besteht zusätzlich auch noch die Notwendigkeit, apt selber korrekt zu konfigurieren. Es ist nämlich durchaus möglich, dass ein Maintainer für die Aktualisierung seines Paketes einen interaktiven Hinweis in das neue Paket eingebaut hat, der während der Installation angezeigt und vielleicht sogar abgefragt wird. Nach meinen bisherigen Erfahrungen waren das immer Abfragen, ob eine bereits bestehende "Conf" beibehalten werden soll oder ob die neue "Conf" des aktualisierten Paketes verwendet werden soll. Tja, für die Funktionalität gewisser bereits installierter Programme wäre es absolut dramatisch, wenn eine bestehende "Conf" einfach überschrieben wird ... wenn man z.B. an Network-Shares des Servers denkt, oder an einen Mailserver, oder an einen Printserver, oder an eine lokale Cloud. Insofern habe ich mich entschieden, apt so zu konfigurieren, dass generell und ohne Zweifel grundsätzlich immer die bestehende Conf beibehalten wird.

Diese Einstellung erfolgt in der folgenden Datei:

Wichtig: Bitte für alle Dateien unbedingt auf korrekt gesetzte Rechte achten! Alle notwendigen Dateien sind im Tar-File enthalten.

Die Berechtigungen

Damit der sich am System anmeldende Hauptbenutzer überhaupt dazu berechtigt ist, unter seiner UID ein bestimmtes Programm zu starten, welches danach unter der UID von 'root' und somit mit root-Rechten läuft, muss dieser Anwender natürlich eine entsprechende Berechtigung erhalten. Diese Berechtigung erfolgt durch eine spezielle Policy im Debian-Policykit. Nach Abwägung aller Rahmenbedingungen habe ich mich entschlossen, keine namentlich an den Anwender gebundene Berechtigung über PKLA-Rules zu vergeben, sondern den Aufruf von autoupdate pauschal zu erlauben. Unsere User verfügen jeder über 2 Systeme und jeder dieser User muss sowieso auf seinem System dazu berechtigt sein. Meldet sich ein User auf einem anderen System an, so hätte er zwar die Berechtigung, aber sie findet keine Anwendung, weil der Programmlauf ja im Autostart des Hauptbenutzers eingerichtet ist. Darüber hinaus wissen die User weder von diesem Programm, noch von der Berechtigung. Und selbst wenn, könnten sie nur eine Systemaktualisierung außerhalb der Reihe starten. Insofern schien mir der Aufwand für usergebundene PKLA-Berechtigungen einfach maßlos übertrieben, geradezu sinnlos ... und ich hab's deshalb gelassen.

Ausschließlich für die Berechtigung der User sind neben dem Script zwei weitere Dateien notwendig:

Und natürlich das eigentliche Programm:

Zu guter Letzt:

Haftungsausschluss

Das von mir geschriebene Programm autoupdate ist als Bash-Script nur ein komfortabler Wrapper für die Linux-Programme apt und apt-get. Das bedeutet, autoupdate selber verändert das System nicht, sondern überlässt das ausschließlich den von Debian dazu vorgesehenen Programmen.

Ich erhebe keinen Anspruch darauf, dass autoupdate vollständig fehlerfrei programmiert ist und ich behaupte das auch nicht. Sowohl durch Programmierfehler im Programm autoupdate, wie auch in den verwendeten System-Tools, sowie durch ggf. zeitgleich auftretende äußere mechanische Einflüsse, wie auch durch den Anwender selber verursacht durch Änderungen am Programm, durch unsachgemäße oder fehlerhafte Einstellungen oder falsche Parameterübergaben bei den Programmen ist Datenverlust möglich.

Deshalb schließe ich jede Haftung für Schäden an Software oder Hardware oder Vermögensschäden oder für Datenverlust aus, die durch die Benutzung des Programms autoupdate enstehen. Die Benutzung des Programms erfolgt auf eigenes Risiko.

Das klingt beunruhigender als es wirklich ist, denn ich nutze das Programm für die Aktualisierungen auf all unseren Systemen seit längerem ohne jegliche Probleme. Allerdings überprüfe ich selber auch regelmäßig die Logs und schaue auf Unregelmäßigkeiten.

Änderungsprotokoll

< zurück >