Umgang mit Sicherheitslücken in CPUs (Meltdown & Spectre)


    Der Server ist eingerichtet und vor 2 Tagen getestet für ACPI Shutdown - es gab nicht einmal eine LOG Meldung. Die VM wurde einfach ausgeschaltet.


    Netcup - bitte nicht den schwarzen Peter dem Kunden zuschieben, das ist keine Lösung.

    Der Shutdown-Befehl wird bei uns via ACPI in die VMs gesendet, wie ja auch groß bekannt gegeben wurde. Andere Kunden können sicherlich bestätigen, dass die VMs einen ACPI Shutfown erhalten haben. Es liegt uns fern einen schwarzen Peter Kunden zuzuschieben.

    Wie weit ist der Prozess schon vortgeschritten?

    Kann man eigentlich irgendwo sehen auf welchem Hostsystem man sich befindet oder welches Hostsystem aktuell neugestartet wird?



    Meine sieben Server sind nun auch durch, es hat alles reibungslos geklappt,auch der Windows Server wurde odnungsgemäß heruntergefahren und neu gestartet! Meine zwei managed Server hatten den Neustart noch nicht, aber ich denke da wird es auch keine Probleme geben.

    Vor 30 Minuten wurde ein weiterer Server von mir neugestartet (Zwischenstand: 2 von 6).


    Beides waren sanfte Shutdowns per ACPI. Die laufenden LXC-Container hatten genug Zeit um sauber herunterzufahren (nach 30-45 Sekunden hatten beide Server ihren Shutdown bereits abgeschlossen). Nach weiteren 20 Minuten wurden beide Server ohne Probleme wieder hochgefahren.


    Ich habe die Vermutung, dass die Server nach Preismodell oder Bestelldatum abgearbeitet werden. Nach meinem RS2000 (gestern Abend um 23 Uhr) wurde heute um 16 Uhr mein RS1000 neugestartet. Meine VPS10, VPS20, VPS50 usw. wurden noch nicht beachtet.

    wieviele virtuelle Server sind auf so einem "fetten" Wirtsystem gehostet?

    ich habe auf meinem einen Dienst, welcher realtiv lange zum beenden dauert in weiser voraussicht bereits beendet,

    um sicher zu stellen, daß der Reboot mit 5 Minuten garantiert funktioniert;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Guten Tag,


    die Server neu zu starten ist eine Sache. Wenn dann aber beim Boot zu wenig Ressourcen zur Verfügung stehen, dass der MYSQL dienst nicht mehr starten kann dann kann ich nur sagen, lasst euch etwas mehr Zeit!!!


    Als Kunde erwarte ich mir zumindest, dass mein Server wieder läuft wie vorher nach einem Neustart. Ich habe den Server nun 2 Stunden später nochmals per ACPI neu gestartet und es läuft wieder alles, aber eigentlich möchte ich mich darum gar nicht kümmern müssen!


    Da wir insg, 16 Root Server und 2 Vserver betreiben möchte ich nicht jedes mal eingreifen müssen.

    Guten Abend,


    Quote

    Wenn dann aber beim Boot zu wenig Ressourcen zur Verfügung stehen, dass der MYSQL dienst nicht mehr starten kann dann kann ich nur sagen, lasst euch etwas mehr Zeit!!!


    alle Server haben die Ressourcen mit denen sie gebucht wurden. Diese haben sie immer und egal zu welcher Zeit wir Neustarts durchführen.


    Mit freundlichen Grüßen


    Felix Preuß

    Quote from Timon_78

    Sind dann alle vServer durch? Habe immer noch eine lange Uptime im scp

    die Frage, ob denn alle vServer neu gestartet weden müssen,

    zumal ja vServer auf andere Nodes verschoben werden - und das im laufendem Betrieb(?)


    bei meinen sind auch noch lange Uptimes im SCP

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    netduck :


    Einige Webhostingserver booten etwas länger wegen einem Quotacheck.


    Timon_78 :


    Wir sind noch lange nicht mit den Reboots durch. Wie geschrieben, wir teilen es hier mit, wenn alle Reboots beendet sind. Rechnen Sie bitte aber nicht vor Anfang nächste Woche mit dem Ende.


    Vieles deutet auch darauf hin, dass die kommenden 14 Tage weitere neue Kernelupdates und Microcodeupdates von Intel veröffentlicht werden. In diesem Fall müssen wir und andere Cloudanbieter erneut Updates und Reboots durchführen.


    Mit freundlichen Grüßen


    Felix Preuß

    Quote from [netcup] Felix

    Vieles deutet auch darauf hin, dass die kommenden 14 Tage weitere neue Kernelupdates und Microcodeupdates von Intel veröffentlicht werden. In diesem Fall müssen wir und andere Cloudanbieter erneut Updates und Reboots durchführen.

    Dürfen wir dann davon ausgehen das diese Updates nicht eine solche Dringlichkeit wie die derzeitigen haben und Sie die Reboots dann in der Nacht durchführen können oder müssen diesen dann auch Tagsüber rebootet werden?

    Irgendwie unbefriedigend wie NetCup das handhabt, man weiß jetzt nie genau wann die eigenen Server abgewürgt werden. Wenn sich das jetzt auch noch bis nächste Woche hinziehen soll waren das jetzt effektiv ein paar Tage wo man ständig in Unsicherheit schwebt.

    Quote from Purzelbaum

    Irgendwie unbefriedigend wie NetCup das handhabt, man weiß jetzt nie genau wann die eigenen Server abgewürgt werden. Wenn sich das jetzt auch noch bis nächste Woche hinziehen soll waren das jetzt effektiv ein paar Tage wo man ständig in Unsicherheit schwebt.

    Da kann ich dir Teilweise zustimmen.

    Einerseits verstehe ich die Dringlichkeit seitens Netcup das Update drauf zu spielen. Andererseits ging / geht es mir auch wie dir mit der ständigen Unsicherheit wie dir. Vor allem weil bei mir jede Minute in welcher der Server Ungeplante offline geht schlecht ist besonders wenn das bis zu 30+ Minuten dauern kann. Aber ich hoffe das nach dieser Situation eventuell die Nächsten ähnlichen Situationen besser geplant werden können und eventuell eine Nachricht ins SCP eingefügt werden kann wenn der Server Rebooten soll.

    Also mir wurde der Rootserver heute Nachmittag auch einfach abgeschossen und die Datenbanken haben sich sehr drüber gefreut.

    Wenn ich im VCP einen ACPI Shutdown auslöse, fährt mein Server in unter 30 Sekunden einwandfrei runter. Da ich das ab und an zwecks Offline-Snapshots oder Kernelupdates mache, hat das schon viele Male und immer einwandfrei geklappt, es war also nie notwendig den Server abzuschießen. Also scheint mir da gerade leider doch eher das Problem bei Netcup zu liegen.

    Ich hab volles Verständnis dafür, dass das gerade eine blöde Sitation für alle ist, aber dass die Server teilweise offenbar grundlos abgeschossen werden geht nicht. Falls weitere Patches folgen, gebt bitte einen groben Zeitrahmen an, denn ich fahre dann lieber selber für ein halben Tag sauber runter, als dass mir da beim nächsten Mal etwas zerschossen wird. Zumal es nach diesem erzwungenen Neustart zum ersten Mal auch das Problem gab, dass nicht alles sauber hochgelaufen war (Plesk Panel war tot) und ich erst selber nochmal sauber rebooten musste.


    Ich gehe jetzt mal davon aus, dass es technisch keinen Unerschied macht, ob wir per VCP den ACPI Shutdown auslösen oder Netcup das macht. Wenn doch, bitte ich um Hinweise was für Debian zu berücksichtigen ist, damit es klappt. Wie gesagt, der ACPI Shutdown funktioniert bei mir einwandfrei in unter 30 Sekunden.

    Guten Morgen,


    ich kann nur noch einmal betonen, dass wir keine vServer bei einem regulären Reboot hart abschalten. Jeder vServer erhält ein ACPI-Shutdown-Signal. Zur Sicherheit haben wir dieses jetzt nochmal manuell überprüft. Wenn Server hart abgeschaltet werden, dann nur wenn diese nicht innerhalb von 5 Minuten auf das Signal reagiert haben.


    Es tut uns Leid, dass wir keinen genauen Zeitplan vorgeben können, nach dem die Reboots stattfinden. Die Gründe dazu habe ich bereits direkt am Anfang genannt. Bei derart kritischen Sicherheitslücken verzögern wir künstlich gar nichts. Wie unsere Mitbewerber können wir leider nur große Zeitfenster vorgeben, innerhalb derer Reboots ausgeführt werden. Zudem versuchen wir Kunden die ein Failover-Cluster betreiben dadurch zu unterstützen, dass wir vServer eines jeden Kunden nacheinander Neustarten.


    Quote

    Dürfen wir dann davon ausgehen das diese Updates nicht eine solche Dringlichkeit wie die derzeitigen haben und Sie die Reboots dann in der Nacht durchführen können oder müssen diesen dann auch Tagsüber rebootet werden?


    Wenn dieses keine kritischen Sicherheitsupdates sind, ja. Bislang sind Performance-Optimierungen angekündigt. Diese werden wir dann, so der Plan, wie reguläre Updates ausrollen. Das bedeutet das wir die Updates zwischen 23 und 05 Uhr Morgens und mit der Angabe eines 30 minütigen Zeitfensters durchführen und diese mit größerer Vorlaufzeit ankündigen können.


    Statusupdate #5:


    Unsere Mitarbeiter arbeiten nach wie vor auf Hochtouren. Die gesamte Nacht wurde durchgearbeitet .


    Derzeit kommt es zu Verzögerungen bei den Reboots, da unser Ersatzteillager einen kritischen Stand bei einigen Servertypen erreicht hat. Bedingt durch die Reboots kam es vermehrt zu defekten RAID-Controllern des Herstellers HPE. Bei Servern von DELL haben wir keine Probleme gehabt. Wir wollen es jetzt nicht riskieren das es durch weitere Reboots zu weiteren defekten RAID-Controllern kommt und wir dann keine Ersatzteile mehr haben. HPE ist informiert und liefert uns per Express weitere RAID-Controller. Sie können sich sicher sein, dass wir im Nachgang prüfen werden, warum HPE hier derartige Qualitätsprobleme aufweist.


    Die Ersatzteile werden voraussichtlich am Montag 9 Uhr da sein. Sobald die Ersatzteile da sind, werden wir mit den Reboots fortfahren.


    Vielen Dank für Ihre Geduld!


    Ich wünsche Ihnen allen einen erholsamen Sonntag.



    Mit freundlichen Grüßen


    Felix Preuß