Hallo Jörg, Am 03.08.21 um 07:41 schrieb Jörg Thümmler:

Am 02.08.21 um 18:21 schrieb Werner Franke:

...

Hallo zusammen,

mit der folgenden Frage erhoffe ich mir Tipps zu einer guten Vorgehensweise wie ich einen Server möglichst automatisch up-to-date halten kann.

[...]

Hi,

das ist eigenartig. Ich würde sagen, hier (ist aber aktuell 15.1 und damit aus den updates raus) wurde das immer korrekt angezeigt und auch Kernel-Updates installiert und eine Warnung ausgegeben, wenn updates einen Reboot oder Neustart eines Daemons brauchen. Ich habe die Standardeinstellungen dazu nie geändert, nur online updates beim Installieren "eingeschaltet". Sowohl die Warnung im XFCE kam (weiß nicht genau, worauf die zurückgreift, könnte zypper sein), als auch, dass "zypper lp" korrekt updates anbot.

Ich habe täglich cron-gesteuert "zypper lp" laufen lassen und bei existierenden updates yast2 starten lassen:

zstr=`zypper -q lp | grep -v "Warning: " | grep -v "Warnung: "| tr -d "\n\t\r "`

zstr sollte leer sein, wenn keine Fehler oder Updates da sind.

mit

/sbin/yast2 --gtk online_update

kann man sich dann per Klick (bei mir läuft die ganze Überwachung über eine lokale php-Seite) das Online-update schön auf den Desktop holen (muss aber $DISPLAY und $LANG vorher passend machen)

Ich verwende NICHT den von dir angegebenen Befehl, sondern ein YAST Modul, das man glaube ich erst nachinstallieren muss, damit es in YAST auftaucht. Aber wie bekommst du es hin, dass "/sbin/yast2 --gtk online_update" seine Arbeit macht ? Das ist doch ein interaktives Tool, bei dem man klicken muss. Ich habe es auf dem Server mal als root aufgerufen und da komme ich bis an die Stelle, wo man unten rechts auf "Übernehmen" klicken muss. Ist das anders wenn man es in einem Cronjob aufruft ? Ist ein weiterer Parameter hilfreich: root@hpserver (-bash) /sbin/yast2 online_update --help Grundsyntax: yast2 online_update interactive yast2 online_update <Kommando> [verbose] [Optionen] yast2 online_update help yast2 online_update longhelp yast2 online_update xmlhelp yast2 online_update <Kommando> help Gruss Werner

Hallo Werner, ich mache meine Updates cron-gesteuert per Script. Mein Desktop ist zwar kein direkter Server, aber ich habe Verzeichnisse per NFS für unsere Familienrechner freigegeben. Außerdem läuft hier ein Apache,  damit ich Updates, etc. für ein phpBB3-Forum testen kann. Am 04.08.21 um 10:16 schrieb Werner Franke:

Hi Mark,

Am 03.08.21 um 08:44 schrieb Mark Wenzel:

...

Hallo Werner,

Für das Problem Kernel-Patches und Reboot habe ich für mich eine Lösung gefunden, indem ich nach den Updates ein "/usr/bin/zypper list-patches" absetze, in dem Ergebnis nach "reboot" suche und mir eine Meldung sende, dass ich den Kernem-Patch händisch machen muss.

Aber ich habe noch keine Lösung, wie ich bei sonstigen Fehlern (beispielsweise geänderte Repository-Zertifikate), an diese Information kommen kann, weil das Update-Tool diese nicht meldet. Wenn ich die robleme aber nicht mitbekomme, kann ich auch nicht darauf reagieren.

viele Grüße Werner

In dem Script laufen folgende zypper Anweisungen: zypper --gpg-auto-import-keys ref zypper lu zypper -vvv up -y -l --details --with-interactive --download-in-advance wenn RC = 103     'zypper -vvv up -y -l --details --with-interactive --download-in-advance wenn RC = 102   "Reboot erforderlich!"   sReboot = 1 wenn RC <> 0       "Install updates not successfull, Return_Code="RC       Exit RC zypper needs-rebooting wenn RC = 102    sReboot = 1 sonst  zypper ps -s Da das Script ja automatisiert ausgeführt wird, erhalte ich vom cron eine Mail mit den Script-Ausgaben. Wenn der Switch sReboot gesetzt ist, wird aus dem Script heraus ein *systemd reboot* angestoßen. Das hat bisher auch problemlos funktioniert. Da ich weiß, wann das Update-Script ausgeführt wird, bin ich darauf eingestellt. -- Joachim Weber, Bonn Retired IT-Dinosaurier PC Hilfe/Notdienst und IT-Consulting (z/OS und Linux)

Am 04.08.21 um 19:50 schrieb Werner Franke:

[...] Danke. Hört sich gut an.

Werden bei zypper up auch alle Patches installiert oder ist danach noch ein zypper patch notwendig ?

(Bin dabei mein Script wie oben umzubauen...)

Gruss Werner

Ein zypper up (mit den Parametern) installiert alles was an Updates vor liegt (incl. der Patches). Ein zypper patch ist nicht mehr notwendig. Schau dir auch mal diesen Link an: https://en.opensuse.org/SDB:Zypper_manual_(plain) https://en.opensuse.org/SDB:Zypper_manual_(plain) -- Joachim Weber, Bonn Retired IT-Dinosaurier PC Hilfe/Notdienst und IT-Consulting (z/OS und Linux)

Hallo Tobias, siehe unten... Am 03.08.21 um 21:18 schrieb Tobias Crefeld:

On Mon, 2 Aug 2021 18:21:16 +0200 Werner Franke wrote:

[..]

...

Das ist ja gut so, was mich aber stört ist, dass ich keine Info darüber bekommen habe. [..] aktualisiert werden würde. Und wenn manuelles Eingreifen notwendig ist, man wenigstens darüber Informiert wird.

Eigentlich geht es um "Automation". Und die besteht bei mir aus kurz gefasst aus Monitoring, Jobreports und Log-Überwachung.

Ersteres kann man in kleinen Umgebungen auch erst mal weglassen.

Der zweite Punkt ist erläuterungsbedürftig. Im Kern sind es Cronjobs, die möglichst so geschrieben sind, dass sie im Normalfall keinen Output liefern und im Fehlerfall eine E-Mail versenden. Ideal ist, wenn es ein Tool gibt, dass man nur noch aufrufen muss, aber ansonsten muss man halt selber skripten. Generell sollte man dafür sorgen, dass E-Mails insbesondere von und an root sinnvoll weitergeleitet werden. Ich habe schon X Systeme gesehen, bei denen der Mailspool von root vollgemüllt war statt den Betreiber über ein Problem zu informieren.

Die wahrscheinlich einfachste Form, eine Log-Überwachung einzurichten ist Logwatch. Ist vielleicht etwas Geschmackssache, aber mir ist es lieber, einmal am Tag von jedem System einen solchen Report zu bekommen als nichts zu hören und zu hoffen, dass alles rund läuft. Eigentlich ist Logwatch mehr als Log-Überwachung, weil es auch Monitoring-Funktionen übernimmt wie z.B. eine Auflistung der aktuellen Volume-Auslastung.

...

Wie haltet ihr eure Server aktuell ? Gibt es was Besseres als die automatische Online-Aktualisierung ?

Ich bin kein besonderer Freund von automatischen Updates. Einmal am Tag läuft ein Job, der alle Updates vorab herunterlädt und eine E-Mail mit der Liste der anliegenden Patches zuschickt. Wenn man Updates automatisch installiert, sollte man wenigstens den Output von "zypper ps -s" überwachen. Andernfalls kann es vorkommen, dass Updates sehr lange Zeit nicht wirksam sind, weil die betreffenden Services (oder Kernel) nicht neu geladen werden.

Von automatischen Reboots (bzw. Service-Neustarts) halte ich insbesondere bei entfernten Systemen noch weniger, weil es immer passieren kann, dass das System oder der Service nicht wieder startet. Dann ist man zwar "sicher", da aktuell gepatcht - aber offline...

Automatische Updates können zu Problemen führen. Aber wenn man die nicht macht UND sich nicht in regelmäßigen und kurzen Abständen darum kümmern kann, kann das zu noch viel größeren Problem führen, wie wir in regelmäßigen Abständen erfahren können. Mein Server ist nicht so wichtig, aber er hängt am Internet und da halte ich es für wichtig, dass Security Patches so schnell wie möglich installiert werden. Und da ich mich nicht dauernd darum kümmern will, müssen die automatischen Updates funktionieren. Als ich herausgefunden hatte, das kernel-Patchen nicht installiert werden, habe ich um das Update-Scrip /usr/lib/YaST2/bin/online_update, das den Update durchführt, ein Script gemacht, das nach dem Update ein "/usr/bin/zypper list-patches" macht und im Ergebnis nach "reboot" sucht. In dem Fall sende ich mir eine Meldung, dass ein Kernel-Patch ansteht. So etwas kann man natürlich auch VOR einem Update machen, wenn dieser Kernel-Patches installieren würde. Aber ja, man muss es machen, sonst läuft man in das von dir beschriebene Problem. Für das Problem Kernel-Patches und Reboot habe ich für mich eine Lösung gefunden, aber noch nicht für sonstige Fehler (beispielsweise geänderte Repository-Zertifikate), die man nicht mitbekommt, weil das Update-Tool diese nicht meldet. Aus diesem Grund habe ich diese Frage geschrieben... viele Grüße Werner

Am 2021-08-04 um 11:07 schrieb Jörg Thümmler:

[...]

Mit Nextcloud kenne ich mich nicht aus, aber für den Apachen und seine Module (inkl. SSL, wenn Du https hast) kann man ja die mit zypper gemeldeten Patches danach filtern und die automatisch einspielen und den Webserver neu starten lassen. Sollte mit ein wenig scripting gehen.

Nextcloud ist eine Anwendung, die einen Webserver (hier vermutlich den Apache) braucht, um ins Netz zu kommen. Die Pakete enthalten alle ein "nextcloud" im Namen.

Dass sicherheitskritische Kernel- und sonstige Dinger auf den Apachen durchschlagen, halte ich für sehr unwahrscheinlich.

Vermutlich ist das die alte Angst des erfahrenen Admins, dass ein Kernel-Update schief gehen könnte und das System dann beim Reboot nicht wieder hoch kommt. Ich betreue in der Firma gut zwei Dutzend SAP-Systeme, die schon in gewissem Maße wichtig sind ;) Normalerweise spiele ich alle Patches (auch für den Kernel) täglich ein. Ich glaube, von Anbeginn an hat zypper die Option, mehrere Kernel installiert zu lassen. Daher haben z. B. meine Datenbankhosts manchmal 3-10 Kernel auf der Platte (weil die Bleche nur selten rebootet werden), während die Applikationsserver (= VMs) jede Woche durchgestartet werden. Der systemd-Dienst "purge-kernels" sorgt beim Reboot dafür, dass alle Kernelversionen, die nicht in der Datei /etc/zypp/zypp.conf bei "multiversion.kernels" angegeben sind, entfernt werden. Also laufen die Maschinen weiter mit einem installierten Kernel, bis beim nächsten Reboot der neueste Kernel gebootet wird und die alten entsorgt werden. Es ist also nicht so, dass beim installieren eines neuen Kernels der alte aus dem Filesystem gelöscht wird und so der laufende Kernel in der Luft hängt. Übrigens bekommt man, wenn ein Patch einen Reboot erforderlich macht, von zypper einen Returnwert von 103 (oder 104?) zurück, den man auswerten kann. Dass ein initrd-Bau auf dem Host fehlschlägt - was ja auch ein Grund sein kann, dass man keine Kernel-Updates einspielen will -, habe ich schon lange nicht mehr erlebt. Das passiert ja auch jedes Mal, wenn ein neues Kernelmodul ("*-kmp-*", "rpm -qa '*-kmp-*' | sort") installiert wird. Werner

Am Mittwoch, 4. August 2021, 09:57:31 CEST schrieb Werner Franke:

Automatische Updates können zu Problemen führen. Aber wenn man die nicht macht UND sich nicht in regelmäßigen und kurzen Abständen darum kümmern kann, kann das zu noch viel größeren Problem führen, wie wir in regelmäßigen Abständen erfahren können.

Mein Server ist nicht so wichtig, aber er hängt am Internet und da halte ich es für wichtig, dass Security Patches so schnell wie möglich installiert werden. Und da ich mich nicht dauernd darum kümmern will, müssen die automatischen Updates funktionieren. Als ich herausgefunden hatte, das kernel-Patchen nicht installiert werden, habe ich um das Update-Scrip /usr/lib/YaST2/bin/online_update, das den Update durchführt, ein Script gemacht, das nach dem Update ein "/usr/bin/zypper list-patches" macht und im Ergebnis nach "reboot" sucht. In dem Fall sende ich mir eine Meldung, dass ein Kernel-Patch ansteht.

So etwas kann man natürlich auch VOR einem Update machen, wenn dieser Kernel-Patches installieren würde. Aber ja, man muss es machen, sonst läuft man in das von dir beschriebene Problem.

Für das Problem Kernel-Patches und Reboot habe ich für mich eine Lösung gefunden, aber noch nicht für sonstige Fehler (beispielsweise geänderte Repository-Zertifikate), die man nicht mitbekommt, weil das Update-Tool diese nicht meldet. Aus diesem Grund habe ich diese Frage geschrieben...

Du kannst aber auch in der Konfiguration des Yast-Online-Update folgende Dinge einstellen: - Interaktive Patches überspringen (oder eben nicht) - Ja, ich akzeptiere die Lizenzvereinbarung (anhacken) Bin mir aber nicht ganz sicher ob das Tool nur Patche installiert/updated oder auch alle anderen Pakete. Denn momentan stehen bei mir Updates an. Diese erscheinen aber nicht in dem Online-Update-Tool. Warum also nicht einfach ein zypper ref und ein zypper up -y --with-interactive --auto-agree-with-licenses in einer Batch packen und aufrufen? Die Ausgaben in eine Logdatei schreiben lassen und diese dann am Schluß in der Batch versenden. Das ganze als cronjob in eine der Verzeichnisse /etc/cron.{daily|hourly|monthly|weekly} legen. Gruß Eric

Am Mittwoch, 4. August 2021, 12:59:21 CEST schrieb Martin Schröder:

Am Mi., 4. Aug. 2021 um 12:34 Uhr schrieb Eric Schirra :

...

Warum also nicht einfach ein

zypper ref

und ein

zypper up -y --with-interactive --auto-agree-with-licenses

in einer Batch packen und aufrufen?

Ich habe hier in /etc/crontab:

# updates 0 0 * * * root zypper --non-interactive patch --auto-agree-with-licenses

okay. Kann man machen. Bei deinem Bespiel dürften aber zum Beispiel keine Pakete aktuallisiert werden. Nur Patche. Außerdem kein Updates von z.B nvidia. Denke ich zumindest mal. Ist ja interaktiv zu beantworten. Und selbst wenn du with-interactive hättest, würde es nicht funktioniren, da Standard Antwort bei dir nein ist. Gruß Eric