Laufzeit und Neustart
- Thread starter anbischo
- Start date
Ja ok, dass ist ein Grund. Aber kann ein Node, wenn man eine Stabile Produktionsumgebung hat, ohne Probleme 100 Tage oder mehr laufen? wie Stabil läuft so ei System?
Es ist absolut unwahrscheinlich, dass es 100 Tage keine entsprechenden Updates gibt. Und wenn man nicht rebootet, kann man sich deren Einspielen auch Sparen. Wenn eure Produktionsumgebung den Ausfall eines Knotens für die Dauer des Reboots nicht aushalten kann, habt ihr ein Problem in euren Setup und solltet es so umstellen, dass es das kann.
Im Zeitalter KI-unterstützter Sicherheitsforschung vergeht eigentlich keine Woche, ohne dass neue Sicherheitspatches fällig werden.
Ja, ich kann den Node in den Wartungsmodus stellen und die VMs migrieren dann auf den anderen Nodes. Mir ging es eigenlich nur generell, wie lange so ein Node stabil laufen kann. Aber Danke für deinen Hinweis
WENN man gute Hardware hat (!) UND man Updates nicht zwingend installieren muss/will, DANN sind ein paar hundert Tage Uptime gar kein Problem.
Willkommen in der Linux Welt
Willkommen in der Linux Welt
Danke für deine Antwort.WENN man gute Hardware hat (!) UND man Updates nicht unbedingt installieren muss/will, DANN sind ein paar hundert Tage Uptime gar kein Problem.
Willkommen in der Linux-Welt
Jup. Und das läuft auch auf einem 08/15-PC problemlos deutlich länger als 100 Tage, wahrscheinlich sogar jahrelang. Vorausgesetzt natürlich, der PC raucht nicht irgendwann ab. Ist ja schließlich Linux und nicht Windows, das man einmal pro Woche neu starten muss, damit es stabil läuft.
Aber im Moment werden beinahe täglich neue Kernel-Lücken entdeckt, und KVM/LXC basieren letztlich auf Kernel-Funktionalitäten. Man muss also schon froh sein, wenn man mal wieder auf eine Uptime von mehr als einer Woche kommt. Also ja, diese Updates sollte man natürlich installieren!
Eine hohe Uptime des Server OS war vielleicht vor 20 Jahren noch etwas, worauf man stolz sein konnte. Heute bedeutet es eher, dass man seine Systeme nicht besonders gut wartet bzw. sicherheitsrelevante Kernel-Updates unnötig lange hinauszögert.
Last edited:
Danke, für einen äußerst guten BeitragJup. Und das läuft auch auf einem 08/15-PC problemlos deutlich länger als 100 Tage, wahrscheinlich sogar jahrelang. Vorausgesetzt natürlich, der PC raucht nicht irgendwann ab. Ist ja schließlich Linux und nicht Windows, das man einmal pro Woche neu starten muss, damit es stabil läuft.
Aber im Moment werden beinahe täglich neue Kernel-Lücken entdeckt, und KVM/LXC basieren letztlich auf Kernel-Funktionalitäten. Man muss also schon froh sein, wenn man mal wieder auf eine Uptime von mehr als einer Woche kommt. Also ja, diese Updates sollte man natürlich installieren!
Eine hohe Uptime des Server OS war vielleicht vor 20 Jahren noch etwas, worauf man stolz sein konnte. Heute bedeutet es eher, dass man seine Systeme nicht besonders gut wartet bzw. sicherheitsrelevante Kernel-Updates unnötig lange hinauszögert.
Naja, wenn ihr das Pech habt in eurer Firma (wie in den meisten Firmen) am chronischen Patchverhinderungsmanagement ("Change-Management") zu leiden, also sicherstellen müsst, dass ihr überall den gleichen Versionsstand habt und ein Update keine Probleme verursacht, dann wäre envtl. der Proxmox Offline Mirror was für euch. Damit könnt ihr einen bestimmten Versionsstand einfrieren, sodass bei Updates nur der auf euren Nodes landet.
Trotzdem finde ich es unverantwortlich auf Teufel komm raus hohe uptimes haben zu wollen. Bestimmt ein regelmäßiges Wartungsfenster (im Idealfall täglich, sonst wöchentlich oder zwei-wöchentlich), wo ihr dann der Reihe nach die Nodes patcht.
Trotzdem finde ich es unverantwortlich auf Teufel komm raus hohe uptimes haben zu wollen. Bestimmt ein regelmäßiges Wartungsfenster (im Idealfall täglich, sonst wöchentlich oder zwei-wöchentlich), wo ihr dann der Reihe nach die Nodes patcht.
Fairerweise muss man aber sagen, dass auch Minor-Kernel-Updates, die vermeintlich nur Sicherheitsupdates enthalten, auch schon negative Seiteneffekte erzeugt haben. Das ist eher unwahrscheinlich, aber in gewissen Edge Cases kann das schon mal vorkommen. Ich verstehe also, dass man das zuerst testen will, bevor man es einfach ausrollt.
@anbischo Am Ende des Tages ist es halt ein Abwägen: Nicht alle Bugs sind gleich kritisch für eine Virtualisierungsplattform und nicht alle Bugs sind in jeder Umgebung ausnutzbar. Das wirklich seriös abzuschätzen, halte ich gerade im KMU-Bereich für, eher schwierig, deshalb ist es sicher besser, wenn man im Zweifelsfall die Patches zeitnah installiert. Stur mindestens 100 Tage oder noch länger warten, um eine hohe Uptime im Dashboard zu erreichen, macht heutztage definitv keinen Sinn mehr.
Ausser vielleicht das Ding läuft komplett isoliert, mit VMs die ebenfalls komplett offline sind, und nur zwei Leute haben Zugriff darauf, die eh schon root Rechte haben.
Last edited:
@Fairerweise muss man aber sagen, dass auch Minor-Kernel-Updates, die hauptsächlich nur Sicherheitsupdates enthalten, auch schon negative Seiteneffekte erzeugt haben. Das ist eher unwahrscheinlich, aber in gewissen Edge Cases kann das schon mal vorkommen. Ich verstehe auch, dass man das zuerst testen will, bevor man es einfach ausrollt.
Aber am Ende des Tages ist es halt ein Abwägen: Nicht alle Bugs sind gleich kritisch für die Virtualisierungsplattform und nicht alle Bugs sind in jeder Umgebung ausnutzbar. Das wirklich seriös abzuschätzen, halte ich gerade im KMU-Bereich für, äußerst schwierig, deshalb ist es sicher besser, wenn man im Zweifelsfall die Patches zeitnah installiert. Stur mindestens 100 Tage oder noch länger warten, um eine hohe Uptime im Dashboard zu erreichen, macht heutztage definitiv keinen Sinn mehr.
Ausser vielleicht läuft das Ding komplett isoliert irgendwo, mit VMs die ebenfalls komplett offline sind, und nur zwei Leute haben Zugriff darauf, die eh schon root Rechte haben.
proxuser77
@
Johannes S
Ihr habt beide recht und danke für eure Antwort. Wir haben aufgrund einer kritischen Infrastruktur enormen Aufwand bezüglich Change Management und Dokumentation. Man kommt bei den Patches einfach nicht so schnell nach. Die Vorgehensweise und Ausfallsicherheit zu gewährleisten dauert oft 6 Wochen und kann aufgrund von Kritis nicht beschleunigt werden.
Last edited:
Benutzt ihr bei euren "Kritis" Aufgaben denn wenigstens die bezahlten Enterprise Repositories die ein wenig besser getestete Software anbieten?
Hmm, wird das denn bei den Entscheidern auch so gesehen?
Häufig es läuft! Also wird kein Geld mehr ausgegeben oder eingeplant.
Wie? sagen wir Admins...
Und manchmal muss man auch abwägen was das kleine Übel ist, da man out of the box nicht selektiv aktualisieren kann.
<Eigentlich> wäre ein Update fällig, aber ich habe wenig Lust mir dadurch Probleme mit CEPH einzufangen. In Abwägung kann und werde ich also warten bis es hier eine Lösung gibt, da ich im Augenblick nicht die Zeit habe, das ganze CEPH zu löschen und das Restore einzuspielen.
Okay, ich kenne mich mit Ceph nicht aus. Aber das ist doch im Kontext dieses Threads kein Argument. Und am Ende des Tages ist es auch in deinem Kontext wahrscheinlich keine dauerhafte Lösung, oder?
Was du aber u.U. tun könntest, um den Rest des Systems trotzdem aktuell zu halten, ist, die relevanten Ceph-Pakete auf „hold” zu setzen, mit
apt-mark hold package-name. Das kann aber natürlich, ebenfalls keine dauerhafte Lösung sein.
Last edited:
Ich weiß du kannst nichts dafür, aber Blödsinn und nutzloses Compilance-Theater bleibt Blödsinn, auch wenn das mit kritischer Infrastruktur begründet wird. Könnte aber erklären, warum ganze Krankenhäuser durch Citrix-Lücken o.ä. sich von der Versorgung abmelden müssen, da gab es bestimmt auch irgendein "Change-Management", dass den Patch noch nicht freigegeben hat. Gleichzeitig sagen aber in solchen Umfeldern geltende Vorgaben oft, dass dringende Sicherheitslücken zeitnah (und sechs Wochen sind echt nicht zeitnah) installiert werden müssen. Da bin ich dann der Meinung: Wenn man eh sich entscheiden muss, gegen welche Compilance-Vorgabe man verstößt, dann doch bitte in der Variante, wo dann kritische Patches zeitnah installiert werden. Und in einen vernünftig designeten Cluster sollte es ja ohne Probleme möglich sein die einzelnen Knoten so zu patchen, dass das Gesamtsystem ohne Auswirkunge auf einzelne Anwendungen weiterläuft.
Folgendes kann imho auch technisch unbedarften Entscheidern vorgelegt werden, das zeigt auf wie lange (aktuell < 23 Stunden) es dauert, bis bekannt gewordene Lücken (die nicht mal öffentlich bekannt sein müssen, wo jeder heute eine KI als Hilfe nutzen kann) großflächig ausgenutzt werden: https://zerodayclock.com/
Und schon vor KI war es so, dass im Linux-Kernel ständig CVEs gemeldet wurden, weil die Kernelentwickler (meines Erachtens zu Recht) der Meinung sind, dass jeder Fehler im Kernel ein potentielles Sicherheitsrisiko ist. Die Folgen in Compilance-Höllen sind ihnen dabei durchaus bewusst, aber eben auch (zurecht) der Meinung, dass das kein Grund wäre keine CVEs zu vergeben:
Man bedenke, dass das noch aus der Zeit vor KI kommt, Greg Kroah-Hartman ist einer der Kernelentwickler, die an der Vergabe von CVEs beteiligt sind. Aber die Marschrichtung sollte klar sein
Mir ist übrigens auch klar, dass es noch deutlich schlimmer als eure sechs Wochen geht, auf der Froscon gab es einen Vortrag zu Patchmanagement, wo einer der beiden Speaker (Redhat-Mitarbeiter) erzählte, dass er Kunden kennt, wo nur einmal im Jahr mit einen Jahr Vorlauf (!) gepatcht werden kann. Solchen Buden wünsche ich unironisch tatsächlich, dass sie mal geransomwart werden, die Verantwortlichen lernen ja offensichtlich nur durch Schmerzen.