< 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:

1.

Ich erkenne keinen Unterschied darin, ob ich selber alle n Tage die entsprechenden Statements in einem Terminal tippe oder wenn sie maschinell durch autoupdate erfolgen, da in beiden Fällen der dann folgende Ablauf vollständig transparent ist und sichtbar im Vordergrund abläuft.

2.

Der von autoupdate durchgeführte Job hat darüber hinaus den Vorteil, dass die Job-Ausgaben der Systemaktualisierung nicht flüchtig sind, sondern als unterteiltes und somit leicht lesbares Job-Log in /var/log/autoupdate nachträglich bei einem Problem eingesehen werden können.

3.

Unsere Anwender sind über die Vorgänge informiert und beobachten die Upgrades auf Fehlerhinweise.

4.

Auf unseren Systemen sind keinerlei Fremd-Repos eingerichtet und es ist keine (proprietäre) Software aus fremden Quellen oder gar dubiosen PPA's installiert. Das Upgrade findet allein unter Verwendung des Repo's für Debian Stable statt.

5.

Die Erfahrungen aus den letzten 2 Jahren mit hunderten von Läufen haben gezeigt, dass der Prozess stabil über eine lange Zeit läuft.

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

Cinnamon unter:

Startmenu -> Einstellungen -> Systemeinstellungen -> Startprogramme

XFCE unter:  

Startmenu -> Einstellungen -> Sitzung- und Startverhalten -> automatisch gestartete Anwendungen

Openbox in:

/home/$USER/.config/openbox/autostart

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!

/home/thomas/.config/autostart/50_autoupdate.desktop

root:root  644

[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 &

-f

force upgrade

Was soviel bedeutet, wie das Update jetzt erzwingen, auch wenn die Wartezeit zum nächsten Update noch nicht errreicht ist. Dieser Parameter wird eigentlich bei manuellem Start im Terminal verwendet. In solchem Fall ist der Parameter -w 0 natürlich obligatorisch, weil ansonsten zunächst 20 Sekunden gewartet werden würde. Und nein, es ist nicht vorteilhaft, die Wartezeit bei -f direkt auf 0 zu setzen, weil für einen maschinellen Lauf mit diesem Parameter durchaus auch eine Wartezeit notwendig sein kann.

-d n

next upgrade in n days

Die nächste Prüfung auf eine Systemaktualisierung erfolgt nach n Tagen. Die Default-Wartezeit sind 3 Tage.

-w n

wait n seconds after login    

Nach dem Login zunächst die eingestellte Zeit abwarten... vielleicht braucht das Netzwerk noch einen Moment. Die Default-Wartezeit sind 20 Sekunden.

-s

perform simulation

Mit diesem Parameter wird das System nicht verändert, sondern der komplette Lauf findet nur als Simulation statt.

-u name

User-Name

Am Besten ist dieser Parameter mit "Special Feature" bezeichnet. In unserem Netzwerk hat jeder Anwender auf dem Datenserver ein zusätzliches Private-Network-Homedir, ergänzend zu seinem lokalen Homedir auf dem Rechner. Dort speichern die Anwender beispielsweise ihre persönlichen Office-Dokumente, etc. ab. In jedem dieser User-Network-Homedirs existiert weiterhin das Verzeichnis "Backup", in dem z.B. automatisch bei Beendigung des Programms Thunderbird unmittelbar die lokale prefs.js gesichert wird. In dieses Verzeichnis (im Script als

/home/$UserName/SHome/Backup/log

hinterlegt) erstellt autoupodate aber auch einen kurzen Log-Eintrag darüber, ob die Aktualisierung gelaufen ist oder ob der User das vielleicht abgelehnt hat. Damit habe ich die Möglichkeit, von zentraler Stelle ausgehend über den Zugriff des Servers zu kontrollieren, ob es bei einzelnen Systemen Probleme gibt. Wenn die Zyklen im Großen und Ganzen passen, fast immer erfolgreich sind und ich nicht ständig "Abgelehnt" vorfinde, ist für mich alles in Ordnung, es ist  kein Wartungseingriff notwendig.... Thema erledigt.

Soll dieses Feature also ebenfalls genutzt werden, muss natürlich der Pfad im Code auf die entsprechenden neuen Gegebenheiten angepasst werden. Das dazugehörige Statement ist recht einfach im Main-Bereich des Scripts zu finden, wenn nach /home/$UserName gesucht wird. Die notwendige Änderung ist ebenfalls einfach und m.M.n. selbsterklärend.

Das angelegte zentrale Control-Log hat -hier beispielhaft für meinen PC-. folgenden Inhalt:

05-05-2018-19-29 Starting: autoupdate (Full-Upgrade on <thomaspc> at 2018-125)

05-05-2018-19-29 Updates canceled by user!

05-05-2018-19-29 Job end

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

06-05-2018-10-50 Starting: autoupdate (Full-Upgrade on <thomaspc> at 2018-126)

06-05-2018-10-51 Update succesful! Next update at 2018-131

06-05-2018-10-51 Job end

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

11-05-2018-11-40 Starting: autoupdate (Full-Upgrade on <thomaspc> at 2018-131)

11-05-2018-11-42 Update succesful! Next update at 2018-136

11-05-2018-11-42 Job end

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

16-05-2018-09-22 Starting: autoupdate (Full-Upgrade on <thomaspc> at 2018-136)

16-05-2018-09-24 Update succesful! Next update at 2018-141

16-05-2018-09-24 Job end

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

21-05-2018-18-50 Starting: autoupdate (Full-Upgrade on <thomaspc> at 2018-141)

21-05-2018-18-50 Update succesful! Next update at 2018-146

21-05-2018-18-50 Job end

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:

/etc/apt/apt.conf.d/50autoupdate

root:root  644

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:

/usr/share/polkit-1/actions/autoupdate.policy

root:root  644

/usr/local/bin/pkexec-run

root:root  755

Und natürlich das eigentliche Programm:

/usr/local/bin/autoupdate

root:root  755

Abschließend hier ein paar persönliche Anmerkungen von mir, warum ich der Meinung bin, dass es absoluter Unsinn ist, wenn ein User speziell für diese Aufgabe erneut sein eigenes Password eingeben soll:

1.

Der User meldet sich beim Systemstart bereits mit Pwd und Username an.

2.

Welchen Sinn sollte es also haben, dass er ca. 20 Sekunden später zum Start von autoupdate das gleiche eigene Password noch mal eingeben muss, er hat sich doch jetzt gerade erst bei der Anmeldung legitimiert?

Welcher Sicherheitsgewinn besteht überhaupt darin, wenn er quasi direkt hintereinander zweimal das gleiche Password eingeben muss?

3.

Zum Programm gehört eine Polkit-Rule (im Tarfile enthalten) mit dem Namen /usr/share/polkit-1/actions/autoupdate.policy. Diese Regel sorgt dafür, dass der User beim Start des Programms autoupdate kein PWD eingeben muss. Er kann wegen dieser Regel aber auch NUR das Script autoupdate ohne PWD-Abfrage starten, sonst ist ihm absolut nichts anderes erlaubt, was höhere Rechte erfordert.

BTW, er startet autoupdate ja nicht mal selber, das Script startet über den Autostart. Darüber hinaus weiß der User ja nicht mal, dass er es starten könnte, oder dürfte, wenn er wüsste, was wo, wie. Und selbst dann, wenn er es herausfinden und manuell starten würde, passiert eh nix anderes als das nach aktuellen Updates besucht wird... genau das, was ja sowieso das Ziel dieses Scripts ist. Fazit: Hier besteht also kein Handlungsbedarf.

4.

An die Betrachtung der Frage mit oder ohne Password schließt sich darüber hinaus unmittelbar die Folgefrage an "Welches Password soll/muss erneut eingegeben werden?"

Soll er erneut sein eigenes eingeben, oder gar alternativ das Root-Pwd? Müsste er sein eigenes Password erneut eingeben, wird es m.M.n. lächerlich... bei  zweimaliger Eingabe des gleichen PWDs quasi direkt hintereinander  würde ich meinen Admin fragen, ob er sie noch alle auffem Christbaum hat und ob er der Meinung ist, das ich über die Zeit von 20 Sekunden einen Persönlichkeitswechsel vollzogen habe oder ausgetauscht wurde.

Und alternativ das root-Password? Keinesfall! Hierbei vertrete ich die Sichtweise, dass ein "betreuter" IT-User keinesfalls das root-Password kennen muss. Deshalb nicht, weil dem User damit unmittelbar weite Möglichkeiten eröffnet werden, gravierenden Einfluss auf meinen Arbeitsaufwand für diese IT-Betreuung auszuüben. Für seine normale tägliche Arbeit ist diese Kenntnis nicht notwendig, und System-Wartungstechnisch wird er ja "betreut".

Ich vertrete konsequent die Meinung, dass einem solchen eher sachunkundigen User keinesfalls Möglichkeiten eingeräumt werden dürfen, mit denen er selber das System verändern kann. Zu was solche fahrlässig angewandten Berechtigungen führen und welchen Aufwand und Kosten das wegen präventiver oder reparativer Maßnahmen wiederum verursacht, konnte man kontinuierlich über die Jahre beim Redmonder Betriebssystem beobachten. Zum einen schützt dieses Maßnahme die Integrität des installierten Betriebssystems vor dem User, und weiterhin schützt es den User davor, dass Fehler in der Bedienung, beim Surfen, durch Mail-Attachments, etc. dazu führen, das Schadsoftware unbemerkt seine Berechtigungen verwendet, um die Kontrolle über den Rechner oder vorhandene persönliche Daten zu übernehmen... gerade das ist beispielsweise bei Verwendung des Pakets "sudo" mit den obligatorischen Timeout-Einstellungen des sudo-Befehls die einfachste Sache der Welt. Hat der User jedoch keine Berechtigungen, können diese auch nicht unbemerkt missbraucht werden... und wenn nichts eingegeben werden muss, kann auch nichts abgegriffen oder belauscht werden....so einfach ist das. Mit anderen Worten, die Eingabe eines Passwortes speziell für diese Aufgabe verschlechtert meiner Ansicht nach sogar deutlich die allgemeine Sicherheit.

Allerdings muss ich einräumen, dass das für alleinverantwortliche End-User so nicht praktikabel ist. Diese User brauchen natürlich ihre Admin-Rechte für all die Tätigkeiten, die zur Wartung eben notwendig sind. Und wenn sie damit nicht sorgsam umgehen und das System damit quasi selber kompromittieren, müssen sie ggf. eben auch einen Schaden hinnehmen.

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

Vers. 1.1

02.04.2018

Bugfixes

Vers. 1.2

05.05.2018

Bugfixes

Vers. 1.3

21.05.2018

 

 

 

 

15.04.2019

1. Bugfixes: Timing-Problem bei der Zuordnung des Special-Feature-NetHome-Dirs des Users (siehe Command-Line-Params) behoben. Die Festlegung des Pfades erfolgte vor der Wartezeit aufs Netzwerk. Bei verzögerter Netzverbindung wurde deshalb vorschnell auf /var/log ausgewichen, obwohl nach der Wartezeit die Netz-Laufwerke verfügbar waren.

2. Überarbeitung des Codes (Semantik und Pragmatik)

Desktop-Starter für XDG-Autostart eingefügt

< zurück >