Leap 16 - Updates automatisieren

[Der Nippeser]

Hallo zusammen,

ich habe bei einem guten Freund letztes Jahr den Rechner von Win 10 auf Leap 15.6 umgestellt. Er ist auch sehr zufrieden und alles läuft so wie er es braucht.. Ich meine das System so konfiguriert zu haben, dass die Updates automatisch eingespielt werden (Online-Aktualisierung in YAST).
Wichtig ist mir an der Stelle, dass die Software auf dem aktuellen Stand bleibt, um Sicherheitslücken zu vermeiden.
Bei meinem eigenen System habe ich das tatsächlich auch gerne selber unter Kontrolle, spiele aber eigentlich immer alle Updates ein. Bisher ist da auch noch nie etwas schiefgegangen (und ich mache das auch schon mindestens 20 Jahre so). Meinem Freund möchte ich das allerdings ungern zumuten, da er von Computern eigentlich keine Ahnung hat.
Daher stellt sich mir die Frage nach der Automatisierung. Geht das irgendwie über eine zypper-Konfiguration? Oder direkt über rpm?
(Meine Fähigkeiten so etwas selbst zu programmieren tendieren leider gegen Null...)

Viele Grüße aus Köln!

 

[manzek]

Vermutlich dürfte ein Shell-Script, das beispielsweise im Autostart liegt, die einfachste Lösung sein.

Ich würde hier einfach ein Shell-Script erstellen (Textdatei mit Endung sh statt txt) mit folgendem Inhalt, dann die Datei ausführbar machen und in den Einstellungen dem Autostart hinzufügen.

#!/bin/bash

zypper up --allow-vendor-change

 

[Sauerland]

Kalle hat eines geschrieben, welches ca. 10 Minuten nach dem Hochfahren des Rechners ausgeführt wird.

Er hat dann auch noch Abfragen eingefügt, die das Script in einer Datei mit Fehlermeldung schreibt.

Läuft über systemd und timer.

Autostart wäre mir zu früh.

 

[susejunky]

Ich würde hier einfach ein Shell-Script erstellen (Textdatei mit Endung sh statt txt) mit folgendem Inhalt, dann die Datei ausführbar machen und in den Einstellungen dem Autostart hinzufügen.

#!/bin/bash

zypper up --allow-vendor-change

Das --allow-vendor-change kann zu "recht lustigen" Effekten führen.

Beispiel:

Wenn man Packman verwendet (um ffmpeg mit den nicht-freien Codecs zu erhalten) und die Packman-Pakete zum Zeitpunkt der Skript-Ausführung noch nicht verfügbar sind (was gelegentlich vorkommen kann), dann führt die Verwendung von --allow-vendor-change dazu, dass automatisch die openSUSE-Version der Pakete eingespielt wird (womit nur noch die freien Codecs verfügbar sind).

Unbeaufsichtigte Systemaktualisierungen halte ich grundsätzlich (d.h. auch ohne --allow-vendor-change) für eine schlechte Idee. Alle von mir betreuten Systeme werden nur unter Aufsicht (ggf. remote) aktualisiert.

 

[manzek]

Bei weiterer Überlegung würde das Script so auch nicht funktionieren, da bei der Ausführung immer noch die Abfrage kommt, ob man die Vorschläge so übernehmen möchte. Ansonsten hätte man noch das n-Flag einfügen müssen.
Auch ich mache keine unattended Updates; ich habe dafür die Konsole im Autostart und kann mit 2-3 Tastenschlägen und einmal PW meine Updates abrufen. Und auch bei --allow-vendor-change werde ich vorgewarnt, wenn das Packman-Repo nicht da ist. Dann sehe entweder viele Dateien die gelöscht werden sollen oder die Meldung, dass Paket xy den Vendor wechselt.

Aber gut, vielleicht ist es tatsächlich nicht die allerbeste Idee, einem Neuling --allow-vendor-change zu empfehlen.

Was ich dem TE aber auf jeden Fall empfehlen kann ( weil er ja schrieb, dass seine Programmierkenntnisse gegen Null tendieren), sich mit der Thematik einfach mal etwas näher zu befassen. Es gibt nichts, was man nicht lernen kann, und gerade heute in Zeiten von KI wird es einem doch recht leicht gemacht. Früher musste man sich stundenlang durch zum Teil uralte Forenbeiträge kämpfen; heute wird einem die Lösung auf einem Silbertablett präsentiert.