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. Ich betreibe zu Hause einen HP ProLiant MicroServer N36L mit 5TB Plattenplatz mit 15.2 Auf dem befindet sich alle unsere Bilder, Filme und Musik. Weiterhin betreibe ich auf ihm auch Nextcloud und einen HTTPS Apache. Die Cloud und HTTPS ist vom Internet aus erreichbar. Aktuell habe ich YAST2 so konfiguriert, dass die Online-Aktualisierung täglich automatisch ausgeführt wird. Konfiguriert habe ich Optional, Empfohlen, Sicherheit, Paketverwaltung und YAST. Als ich mich näher mit dem Tool beschäftigt habe, habe ich festgestellt, dass Patches, die einen Reboot benötigen, nicht installiert werden. Ich bekomme aber auch keine Meldung darüber. Wenn ich nicht noch andere PCs hätte und so Kernel-Patches mitbekommen würde, würden diese Patches auf dem Server möglicherweise länger nicht gemacht werden. Um diese Mail zu schreiben, habe ich auf dem Server das Online- Aktualisierung Modul wieder aufgerufen und da wurde mir gesagt, dass sich von zwei Repositories das Zertifikat geändert hat. Wann sich die geändert haben weiss ich nicht, aber ich denke seit dem wurden Updates aus diesen Repositories nicht mehr gemacht. Das ist ja gut so, was mich aber stört ist, dass ich keine Info darüber bekommen habe. Ich sitze nicht jeden Tag am PC und mir wäre es am liebsten, wenn der Server möglichst automatisch und ohne dauerndes Nachsehen aktualisiert werden würde. Und wenn manuelles Eingreifen notwendig ist, man wenigstens darüber Informiert wird. Wie haltet ihr eure Server aktuell ? Gibt es was Besseres als die automatische Online-Aktualisierung ? Danke für einen Tipp. viele Grüße Werner Franke
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.
Ich betreibe zu Hause einen HP ProLiant MicroServer N36L mit 5TB Plattenplatz mit 15.2 Auf dem befindet sich alle unsere Bilder, Filme und Musik. Weiterhin betreibe ich auf ihm auch Nextcloud und einen HTTPS Apache. Die Cloud und HTTPS ist vom Internet aus erreichbar.
Aktuell habe ich YAST2 so konfiguriert, dass die Online-Aktualisierung täglich automatisch ausgeführt wird.
Konfiguriert habe ich Optional, Empfohlen, Sicherheit, Paketverwaltung und YAST.
Als ich mich näher mit dem Tool beschäftigt habe, habe ich festgestellt, dass Patches, die einen Reboot benötigen, nicht installiert werden. Ich bekomme aber auch keine Meldung darüber. Wenn ich nicht noch andere PCs hätte und so Kernel-Patches mitbekommen würde, würden diese Patches auf dem Server möglicherweise länger nicht gemacht werden.
Um diese Mail zu schreiben, habe ich auf dem Server das Online- Aktualisierung Modul wieder aufgerufen und da wurde mir gesagt, dass sich von zwei Repositories das Zertifikat geändert hat. Wann sich die geändert haben weiss ich nicht, aber ich denke seit dem wurden Updates aus diesen Repositories nicht mehr gemacht. Das ist ja gut so, was mich aber stört ist, dass ich keine Info darüber bekommen habe.
Ich sitze nicht jeden Tag am PC und mir wäre es am liebsten, wenn der Server möglichst automatisch und ohne dauerndes Nachsehen aktualisiert werden würde. Und wenn manuelles Eingreifen notwendig ist, man wenigstens darüber Informiert wird.
Wie haltet ihr eure Server aktuell ? Gibt es was Besseres als die automatische Online-Aktualisierung ?
Danke für einen Tipp.
viele Grüße Werner Franke
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) -- cu jth
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
Am 04.08.21 um 10:08 schrieb Werner Franke:
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, nee, das war ein Missverständnis. Automatisiert lief hier nur "zypper lp", bei anstehenden wird eine Message getriggert, bei der ein Klick das "/sbin/yast2 --gtk online_update" startet. (Theoretisch könnte man das mit "xdotool" auch automatisch beantworten, das war aber hier nicht der Plan) Vollautomatisch (würde ich auch nicht empfehlen) würde ich "zypper lu", "zypper lp" und/oder "zypper pchk" loggen lassen und Patches mit "zypper patch" installieren lassen. Im Gegensatz zum Yast-Online-Modul sind das reine Cmdline-Tools mit vielen nützlichen Optionen... -- cu jth
Hallo Werner, 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.
Wie haltet ihr eure Server aktuell ? Gibt es was Besseres als die automatische Online-Aktualisierung ?
Die Online-Aktualisierung läuft hier auch automatisch und die Kernel-Aktualisierung muss ich auch manuell machen. Das ist auch gut so, denn nur so kann ich entscheiden, wann der Server neu gestartet werden kann und anschließend prüfen, ob alles sauber läuft. Ich überwache meine Server mit Icinga2 und habe mir dazu noch ein Skript geschrieben, dass die Kernelversion im Repo mit der laufenden Kernelversion vergleicht. Weichen die voneinander ab, gibt es eine Warnung per Mail von icinga2. Meine Lösung mit icinga2 mag für Dich vielleicht zu groß sein, ich wollte sie Dir aber trotzdem nicht vorenthalten. Das kannst Du natürlich auch per Cron machen, wenn Du nur einen einzelnen Check machen willst. Hier ist mein Prüfskript # Nagios plugin return codes check_ok=0 check_warning=1 check_critical=2 # Refreshes the package repositories to get the newest available package information zypper --non-interactive refresh > /dev/null 2>&1 # Query installed and Available Kernel Versions kernel_in=$(uname -r | egrep -o [0-9]+\.[0-9]+\.[0-9]+\-[lp0-9]+\.[0-9]+\.[0-9]+) # bis leap 15.1 #kernel_av=$(zypper info kernel-default | sed -n '/Version/p' | egrep -o [0-9]+\.[0-9]+\.[0-9]+\-[lp0-9]+\.[0-9]+\.[0-9]+) # ab leap 15.2 kernel_av=$(zypper info kernel-default | sed -n '/Version/p' | egrep -o [0-9]+\.[0-9]+\.[0-9]+\-[lp0-9]+\.[0-9]+) kernel_av=$(egrep -e ".*" <<< "$kernel_av") # Major Kernel Versions kernel_maj_in=$(sed 's/\.[0-9]*\-[0-9]*//' <<< "$kernel_in") kernel_maj_av=$(sed 's/\.[0-9]*\-[0-9]*//' <<< "$kernel_av") if [ -z $kernel_av ] then echo "KERNEL VERSION WARNING - Kernel version from repository not readable" exit $check_warning elif [ "$kernel_in" == "$kernel_av" ] then echo "KERNEL VERSION OK - Newest Version installed ($kernel_in)" exit $check_ok elif [ ! "$kernel_maj_in" == "$kernel_maj_av" ] then echo "KERNEL VERSION CRITICAL - Newer MAJOR Kernel version available ( Installed: $kernel_in ; Available: $kernel_av )" exit $check_critical else echo "KERNEL VERSION WARNING - Newer Kernel version available ( Installed: $kernel_in ; Available: $kernel_av )" exit $check_warning fi
Danke für einen Tipp.
Gerne viele Grüße Mark
Hi Mark, Am 03.08.21 um 08:44 schrieb Mark Wenzel:
Hallo Werner,
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.
Wie haltet ihr eure Server aktuell ? Gibt es was Besseres als die automatische Online-Aktualisierung ?
Die Online-Aktualisierung läuft hier auch automatisch und die Kernel-Aktualisierung muss ich auch manuell machen. Das ist auch gut so, denn nur so kann ich entscheiden, wann der Server neu gestartet werden kann und anschließend prüfen, ob alles sauber läuft.
Ich überwache meine Server mit Icinga2 und habe mir dazu noch ein Skript geschrieben, dass die Kernelversion im Repo mit der laufenden Kernelversion vergleicht. Weichen die voneinander ab, gibt es eine Warnung per Mail von icinga2. Meine Lösung mit icinga2 mag für Dich vielleicht zu groß sein, ich wollte sie Dir aber trotzdem nicht vorenthalten. Das kannst Du natürlich auch per Cron machen, wenn Du nur einen einzelnen Check machen willst. Hier ist mein Prüfskript
# Nagios plugin return codes
[...]
Danke für einen Tipp.
Gerne
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
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)
Hallo Joachim, Am 04.08.21 um 13:29 schrieb Joachim Weber:
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.
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
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)
On Mon, 2 Aug 2021 18:21:16 +0200 Werner Franke <werner_franke@arcor.de> 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... Gruß, Tobias.
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 <werner_franke@arcor.de> 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 04.08.21 um 09:57 schrieb Werner Franke:
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 <werner_franke@arcor.de> 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
Wenn Du nur Nextcloud und Apache am Netz hast, würde ich vor allem mal meine FW gründlich checken, ob der Rest zu ist und die beiden hübsch limitiert. 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. Dass sicherheitskritische Kernel- und sonstige Dinger auf den Apachen durchschlagen, halte ich für sehr unwahrscheinlich. -- cu jth
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
Hallo Jörg, Am 8/4/21 um 11:07 AM schrieb Jörg Thümmler:
Am 04.08.21 um 09:57 schrieb Werner Franke:
Hallo Tobias,
siehe unten...
[...]
Wenn Du nur Nextcloud und Apache am Netz hast, würde ich vor allem mal meine FW gründlich checken, ob der Rest zu ist und die beiden hübsch limitiert.
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.
Dass sicherheitskritische Kernel- und sonstige Dinger auf den Apachen durchschlagen, halte ich für sehr unwahrscheinlich.
Den Update Prozess habe ich nach dem Muster von Joachim Weber abgeändert und muss nun beobachten ob es auch wunschgemäß funktioniert. Insofern ist dieser Thread für mich fertig. Aber ich würde gerne nochmal auf deinen Punkt "FW gründlich checken" zurückkommen. Der FW ist nämlich ausgeschaltet und nach dem Einschalten komme ich nicht mehr auf Nextcloud. Aber ich mache dazu einen neuen Thread auf, denn das passt nicht so recht zum Subject oben. "OT: Server vom Internet schützen" viele Grüße 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 Mi., 4. Aug. 2021 um 12:34 Uhr schrieb Eric Schirra <ecsos@opensuse.org>:
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
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 <ecsos@opensuse.org>:
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
participants (8)
-
Eric Schirra -
Joachim Weber -
Jörg Thümmler -
Mark Wenzel -
Martin Schröder -
Tobias Crefeld -
Werner Flamme -
Werner Franke