www.kernelcare.com

Debian Support soll im Juni/Juli diesen Jahres implementiert werden. Die sind etwas fixer mit den Patches als bspw. KSplice.
 
Nichts für ungut. NIE im LEBEN käme mir sowas in die Tüte! :eek:

Haltet Ihr es wirklich für sinnvoll, eine "Cloud Linux, Inc." an das Kronjuwel des eigenen Servers, den Kernel, hinzulassen? Man weiß nichts außer einer Adresse in den Staaten (ausgerechnet), nicht mal ein Verantwortlicher wird benannt. Woher sollte das Vertrauen kommen, dass diese unbekannten Leute den Kernel immer korrekt patchen? Die könnten mit einem Federstrich ALLE Server ihrer Kunden erledigen.
 
Und bei Debian, CentOS und Co lässt du dir von allen Entwicklern den Reisepass vorlegen, bevor du Updates installierst? ;)
 
Nein, aber da würde ich immerhin auf das Open Source Prinzip der "vielen Augen" vertrauen. Von dieser Firma ist aber nichts weiter bekannt.
 
Thunderbyte said:
Nein, aber da würde ich immerhin auf das Open Source Prinzip der "vielen Augen" vertrauen. Von dieser Firma ist aber nichts weiter bekannt.
Click to expand...
Naja, also diese Firma ist in amerikanischen Kreisen sogar sehr bekannt, da die http://www.cloudlinux.com/ entwickelt haben, was dort jeder zweite Hoster für seine Webspace-Server einsetzt. Ich denke die wissen schon was sie tun, auch wenn ich deine Bedenken nachvollziehen kann.
 
In Zeiten von "Cloud" sollten wir eigentlich bei einem neuen Paradigma angekommen sein:

Wenn dein Service so kritisch ist, dass ein Server-Reboot nicht "mal einfach" gemacht werden kann, dann sollte genug Redundanz hinzugefügt werden, damit ein Reboot auf Service-Level keine Downtime verursacht.
Wenn man das hat ist sogar eine Neuinstalation ohne Downtime nicht weit.
 
elias5000 said:
In Zeiten von "Cloud" sollten wir eigentlich bei einem neuen Paradigma angekommen sein:

Wenn dein Service so kritisch ist, dass ein Server-Reboot nicht "mal einfach" gemacht werden kann, dann sollte genug Redundanz hinzugefügt werden, damit ein Reboot auf Service-Level keine Downtime verursacht.
Wenn man das hat ist sogar eine Neuinstalation ohne Downtime nicht weit.
Click to expand...
Nur, dass vielleicht nicht jeder 2-3 Server gleichzeitig betreiben möchte, nur um eine Service-Downtime durch Reboots zu vermeiden. Trotz der irreführenden Namensgebung, hat "CloudLinux" nichts mit einer "Cloud" zu tun. Dabei geht es hauptsächlich darum, die einzelnen Hosting-Accounts sowohl auf Filesystem-, als auch auf Resourcen- und Prozessebene vollständig voneinander zu isolieren.
 
Last edited by a moderator:
IMOI hat elias5000 einen sehr wichtigen Punkt angesprochen: einen kurzen reboot für ein Kernelupdate kann ich mir nur dann nicht leisten, wenn das System permanent zur Verfügung stehen muss.
In diesem Fall komme ich aber um eine Hochverfügbarkeitslösung sowieso nicht herum.

Man braucht diesen Service also genau in der Schnittstelle, in der man keinen kurzen Reboot für ein Kernelupdate durchführen kann, gleichzeitig aber keine Hochverfügbarkeit braucht. Ich persönlich kann mir kein konkretes Szenario vorstellen, bei dem das Sinn macht.

Denn selbst wenn ich unterstelle, dass dieses System bei kritischen Sicherheitslücken einen Vorteil hätte, verzögert sich durch die Patchaufbereitung die Bereitstellung eines Patches noch weiter. Dann kann ich den eigentlichen Reboot nach "gewöhnlichem" Patch auch gleich in eine vernünftige Zeit legen. Gut, ich bin kein Systemadministrator, vermutlich wird es konkrete Szenarien geben, die mir persönlich aber einfach nicht bekannt sind, von daher lerne ich gerne dazu.
 
Alderon said:
Denn selbst wenn ich unterstelle, dass dieses System bei kritischen Sicherheitslücken einen Vorteil hätte, verzögert sich durch die Patchaufbereitung die Bereitstellung eines Patches noch weiter. Dann kann ich den eigentlichen Reboot nach "gewöhnlichem" Patch auch gleich in eine vernünftige Zeit legen. Gut, ich bin kein Systemadministrator, vermutlich wird es konkrete Szenarien geben, die mir persönlich aber einfach nicht bekannt sind, von daher lerne ich gerne dazu.
Click to expand...
Die verwenden nicht nur "offizielle" Patches, sondern sind zum Teil fixer mit dem Patchen bzw. Stopfen von Sicherheitslücken, als die Kernel-Entwickler. Als Beispiel, siehe hier Post #14.

Ein passendes Szenario wäre ein Shared-Webserver mit internationalen Kunden drauf, bzw. Besuchern aus verschiedenen Zeitzonen, wie es bei vielen internationalen Hostinganbietern der Fall ist. Man möchte hier nicht unbedingt HA, aber trotzdem die Uptime so hoch wie möglich halten, um z.B. 10 Tickets a la "Warum ist meine Website down" bei einem Neustart zu vermeiden, sowie die vorherige Ankündigung, Planung, usw. usf. Es gibt also durchaus Umgebungen, in denen sowas brauchbar ist.
 
infinitnet said:
Die verwenden nicht nur "offizielle" Patches, sondern sind zum Teil fixer mit dem Patchen bzw. Stopfen von Sicherheitslücken, als die Kernel-Entwickler. Als Beispiel, siehe hier Post #14.
Click to expand...

Bitte die Kernelhacker (aka upstream) nicht mit den Distromaintainern verwechseln.
Der Bug wurde hier schon gefixt:
https://git.kernel.org/cgit/linux/k...s&id=4291086b1f081b869c6d79e5b7441633dc3ace00

Der Bug war auch schon knapp 5 Jahre im Kernel und wurde bei einem regulären Review gefunden, daraufhin wurde er auch gleich gefixt. Das Problem liegt darin, dass einzelne Distros ewig brauchen, was ja auch verständlich ist, da ein "nackter" Kernel auch gerne mal regressions enthält und Backporting Zeit benötigt.
Das sieht man auch schön daran, dass Distros wie Arch den Patch schon am 12.05 integriert haben, da Arch keine Serverdistro ist und sich ansonsten an Profis richtet.

Edit:
Sorry, nicht bei einem regulären Review, sondern es wurde ein Absturz an Suse gemeldet, woraufhin Jiri Slaby den Fehler entdeckt hat.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top