News Fast 6,5 Jahre ohne Reboot: Raspberry Pi als echter Dauerläufer

Diese Protzerei mit der uptime ist so ein unfassbarer Unsinn...
Die Mühle ist also ungepatcht mit einem uralten Kernel unterwegs. Wow. Toll. Oder benutzt er k-splice?
Unsere Systeme haben alle ein uptime von unter drei Wochen. Warum? Weil wir ein vernünftiges redundanzkonzept haben, unsere Kisten(alles debian) stehen hinter loadbalancern, da melden sie sich ab, installieren was nötig ist, rebooten, prüfen ob alles cool ist und melden sich dann am loadbalancer wieder an. Alles safe, kein kunde hat was gemerkt. So macht man das


Aha erzähl mal mehr. Wieso muss der Rechner für einen Kernel update neu gestartet werden?
Jede vernünftige Distribution bietet einen Kernel Live Patch Service an.


RHEL dazu:
Live kernel patches (kpatches) avoid the need for a reboot when patching the kernel for select important and critical Common Vulnerabilities and Exposures (CVEs).


SUSE dazu:
KLP (Kernel Live Patching) makes it possible to apply the latest security updates to Linux kernels without rebooting. This maximizes system uptime and availability, which is especially important for mission-critical systems.)


Mehr dazu hier: https://docs.kernel.org/livepatch/livepatch.html



Was soll der Sinn eines reboote sein? Klär uns mal auf, danke.
Die critical security updates werden im Kernel Live geupdatet, dafür brauche ich doch das System nicht Reboot, pure Zeitverschwendung.

Der einzige Grund für einen reboot ist, Hardware Änderung (defekt oder Erweiterung)
 
Zuletzt bearbeitet:
Aha erzähl mal mehr. Wieso muss der Rechner für einen Kernel update neu gestartet werden?
Jede vernünftige Distribution bietet einen Kernel Live Patch Service an.
Naja, steht ja im Text von Red Hat dabei, die Stichworte wären "select" und "critical". Das ist ein Notbehelf für wirklich akute Sachen und nicht mit einem normalen Update zu vergleichen. Ich habe auch noch keine Distro gesehen, die bei einem Kernelupgrade keinen Neustart gewollt hätte und das ist auch der mit Abstand sauberste Weg, sicherzustellen, dass wirklich keine Überreste von alten Kernelfunktionen noch irgendwo im Gebrauch sind.

Der Link beschreibt auch zu großen Teilen die Limitierungen des Vorgangs und ich bin da auch bei dem, was hier schon mehr oder weniger so gesagt wurde: Wenn die Verfügbarkeit so wichtig ist, dann darf sie nicht von einer einzelnen Kiste abhängen.
 
Naja, steht ja im Text von Red Hat dabei, die Stichworte wären "select" und "critical". Das ist ein Notbehelf für wirklich akute Sachen und nicht mit einem normalen Update zu vergleichen. Ich habe auch noch keine Distro gesehen, die bei einem Kernelupgrade keinen Neustart gewollt hätte und das ist auch der mit Abstand sauberste Weg, sicherzustellen, dass wirklich keine Überreste von alten Kernelfunktionen noch irgendwo im Gebrauch sind.

Der Link beschreibt auch zu großen Teilen die Limitierungen des Vorgangs und ich bin da auch bei dem, was hier schon mehr oder weniger so gesagt wurde: Wenn die Verfügbarkeit so wichtig ist, dann darf sie nicht von einer einzelnen Kiste abhängen.

Wenn der Linux Kernel auf dem gebooteten System einwandfrei funktioniert, bedarf es zu diesem Zeitpunkt keiner neuen Funktionen, Gerätetreiber oder gleichen, das System läuft ja soweit einwandfrei. Lediglich Patches die der Sicherheit dienlich sind, sind erforderlich.

Welches Lösung, ob ein Kernel Update mit anschließenden reboot oder Kernel Live Patch ohne reboot richtig erscheint, ist eine persönliche Präferenz und hängt vielleicht noch vom System ab, welche Dienste er bereit stellt. Ein interner NTP Server der neben der DMZ mit Dual FW steht, bedarf gewiss keines reboot. Aber wie gesagt, das ist eine persönliche Entscheidung.
 
Das ufert hier doch total aus. Der Kerl betreibt seinen Raspi als Basis für einige Temperatursensoren. Solange er die nicht ins WWW hängt, kann ihm doch jegliches Gepatche gleich sein, oder nicht?

Ich meine, da draußen gibt es teilweise noch Router, die Lücken so groß wie Scheunentore haben, und hier wird darüber "gefachsimpelt" wie ein Raspi, privat als Broker für ein paar Temperatursensoren betrieben, akurat mit ständigen Kernelpatches und Softwareupdates betrieben werden MUSS.

Bei solchen Diskussionen mit "Fachleuten" wundert es mich mal gar nicht, dass die deutsche Digitalisierung ist wie sie ist.
 
Wenn der Linux Kernel auf dem gebooteten System einwandfrei funktioniert, bedarf es zu diesem Zeitpunkt keiner neuen Funktionen, Gerätetreiber oder gleichen, das System läuft ja soweit einwandfrei. Lediglich Patches die der Sicherheit dienlich sind, sind erforderlich.
Bleibt die Frage, ob die für irgendeine alte Zwischenversion auf Dauer angeboten werden.
Ein interner NTP Server der neben der DMZ mit Dual FW steht, bedarf gewiss keines reboot.
Auf der anderen Seite stört er da aber auch nicht. Am Ende muss man natürlich abwägen, wie groß der Aufwand und wie sensibel die Angriffsfläche ist. Aber da mache ich mir bei einem Upgrade definitiv um andere Sachen sorgen, als um die paar Minuten Downtime für einen Reboot.
Ich meine, da draußen gibt es teilweise noch Router, die Lücken so groß wie Scheunentore haben, und hier wird darüber "gefachsimpelt" wie ein Raspi, privat als Broker für ein paar Temperatursensoren betrieben, akurat mit ständigen Kernelpatches und Softwareupdates betrieben werden MUSS.
Da gibst du doch schon selbst einen guten Grund an. Der Raspi hängt im LAN, wenn ich das richtig verstanden habe und wenn da jemand reinkommt, weil der Router weit offen steht, dann ist es doch besser, wenn der Raspi das nicht auch tut. Da muss man bei so einem Anwendungsfall wohl nicht päpstlicher als der Papst sein, aber in sechs Jahren sammelt sich da schon was an Lücken an.
Bei solchen Diskussionen mit "Fachleuten" wundert es mich mal gar nicht, dass die deutsche Digitalisierung ist wie sie ist.
Stimmt, eigentlich bedarf es da keiner Diskussion. Systeme sollten nach Möglichkeit aktuell gehalten werden und fertig. ;)
Ausnahmen bilden (eingebettete) Systeme, die wirklich keinerlei Netzwerkzugang haben.
 
Da gibst du doch schon selbst einen guten Grund an. Der Raspi hängt im LAN, wenn ich das richtig verstanden habe und wenn da jemand reinkommt, weil der Router weit offen steht, dann ist es doch besser, wenn der Raspi das nicht auch tut. Da muss man bei so einem Anwendungsfall wohl nicht päpstlicher als der Papst sein, aber in sechs Jahren sammelt sich da schon was an Lücken an.
Schon richtig. In der Zeit schon. Die Frage ist aber immer: Was genau? Und was bedarf dann eines wirklichen Reboots?

Hier im Topic wird gesagt, dass man wegen der Kernelupdates schon längst hätte neu starten MÜSSEN. Was, wenn es gar keine Notwendigkeit dafür gab? Ich kenne nun nicht alle Kernelbugs in und auswendig, erinnere mich aber trotzdem an nichts, wo man per LAN einen root Zugriff hätte haben können. Erinnern tu ich mich an Angriffe, wo man physischen Zugriff auf das System haben musste. Die anderen großen Probleme über Netzwerkkommunikation der letzten Jahre wie z.B. Heartbleed waren alle nicht direkt mit Kernel-Updates verbunden.

Stimmt, eigentlich bedarf es da keiner Diskussion. Systeme sollten nach Möglichkeit aktuell gehalten werden und fertig. ;)

Ausnahmen bilden (eingebettete) Systeme, die wirklich keinerlei Netzwerkzugang haben.
Grundsätzlich ja. Und selbst bei bei Geräten ohne Netzanbindung sollte man die Software auf aktuellem Stand halten, weil man ja nicht ausschließen kann, dass jemand mit lokalem Zugriff das Gerät kompromittieren könnte.

Ändert alles nix an der beachtlichen Tatsache, dass das System diese Lange Zeit am Stück gelaufen ist.
 
Hier im Topic wird gesagt, dass man wegen der Kernelupdates schon längst hätte neu starten MÜSSEN.
Habe ich so jetzt nicht gelesen. Eher den Hinweis, dass eine so hohe Uptime durchaus auch ein Zeichen von Schluderei sein kann.
Erinnern tu ich mich an Angriffe, wo man physischen Zugriff auf das System haben musste.
Unter den Umständen hilft eh höchstens noch Vollverschlüsselung. Die allermeisten Geräte kann man lokal kompromittieren, indem man die Werkseinstellungen wiederherstellt oder die Datenträger ausbaut. Selbst verschlüsselte Geräte sind da nicht sicher, weil man immer eine unverschlüsselte Bootsequenz braucht, in die man Schadcode einführen könnte.
Die anderen großen Probleme über Netzwerkkommunikation der letzten Jahre wie z.B. Heartbleed waren alle nicht direkt mit Kernel-Updates verbunden.
Das mag schon sein, aber ich sag mal so: In der Zeit, in der ich mich schlau gemacht habe, welche Lücken wo existieren und ob und inwiefern die mich jetzt betreffen und welche Softwareteile ich da updaten oder patchen müsste, habe ich das System schon zigfach einfach komplett geupdatet und neu gestartet. Es gibt Situationen, in denen das nicht so einfach geht, aber die sind eben meist hausgemacht.
Ändert alles nix an der beachtlichen Tatsache, dass das System diese Lange Zeit am Stück gelaufen ist.
Och naja, die meisten Systeme, an denen nicht viel gemacht wird, könnten das wohl. Das wichtigste Utensil für einen Rekordversuch wäre da meiner Meinung nach eine USV.
 
Zurück