Das war mal eine Woche!
Unsere Mitarbeiterinnen und Mitarbeiter sind an die Grenzen des Arbeitszeitgesetzes gestoßen. Wir Führungskräfte haben fast durch gearbeitet. Ich bin zudem am 09.01.2018 noch glücklicher Vater unseres zweiten Kindes geworden. Ich wollte es ja Meltdown nennen, aber dann habe ich mich Dank Intel (R) doch für einen anderen Namen entschieden 
Vielen Dank für das viele Verständnis das Sie als Kundinnen und Kunden uns geschenkt haben!
Liebe Grüße
Felix Preuß
Godzilla :
So soll das zumindest sein. Wir lassen jetzt zur Sicherheit nochmal einen Check über alle Nodes laufen. Bitte wenden Sie sich ggf. an unseren Support. Dieser kann prüfen, ob hier etwas schief gelaufen ist.
KORN3Y :
Selbstverständlich wird es hier Updates geben, auch wenn hier die Sicherheitlücken hier nach aktuellen Kenntnisstand nicht ausnutzbar sind. Um hier die Anzahl der Neustarts gering zu halten, werden wir diese erst durchführen wenn es weitere, erforderliche, Patches gibt und diese auch sicher laufen.
Das riecht danach. Wir haben jetzt eventuell eine Möglichkeit gefunden, selbst die Systeme zu patchen. Dieser Patch wird aktiv, sobald es einen ungeplanten Restart gibt. Die Systeme die wir mit den Patch versehen haben, sind bislang nicht mehr neu gestartet (das ist jetzt 12 Stunden her). Wir beobachten das weiter und hoffen sehr das Intel(R) endlich mit offenen Karten spielt.
Statusupdate #9:
Wie bereits angekündigt, haben wir unterschiedliche Distributionen auf den Wirtssystemen im Einsatz. Auch gibt es hier Unterschiede bei der eingesetzten Hardware-Generation, da es noch nicht für jede Hardware Patches von den Herstellern gibt.
Die Entwickler von Debian sind z.B. noch dabei einen Patch für ibrs zu entwickeln. CentOS hat hier z.B. bereits Updates herausgebracht. In ersten internen Tests deutet es sich allerdings an, dass diese nicht wirklich gegen die Angriffsszenarien von Spectre schützen. Auch hier wird es sicherlich von den Entwicklern noch Updates geben.
Spectre kann in einer auf KVM basierten Virtualisierungsumgebung nach aktuellen Kenntnisstand nicht wirklich für einen Datenzugriffsmissbrauch angewendet werden. Da viele Patches in sehr kurzer Zeit entwickelt wurden, sind diese zum Teil fehlerhaft. Die Sicherheitslücken und die fehlerhaften Patches halten seit dem 04.01.2018 die gesamte IT-Branche in Atem. Heute wurde bekannt, dass Intel(R) bei einigen CPU-Generationen wieder fehlerhafte Patches veröffentlicht hat. Wir werden aus diesen Gründen die Patches erst nach ausgiebigen Tests einspielen. Gegen das deutlich gefährlichere Angriffsszenario Meltdown sind alle unsere Systeme abgesichert. Gegen Spectre sind alle Nodes geschützt, die auf CentOS basieren, wobei diese Patches nach neuen Kenntnissen, wie oben geschrieben, auch nicht ausreichend sind und Updates erhalten werden.
Wann wir genau die weiteren Updates einspielen können, ist Stand heute überhaupt nicht voraussagbar. Mehrere Mitarbeiter testen Rund um die Uhr alle Patches um so schnell wie möglich zu einer Entscheidung zu kommen, wann diese eingespielt werden können. Wir werden Sie dazu in einer separaten E-Mail und auch auf http://www.netcup-status.de informieren. Auch am bevorstehenden Wochenende werden wir für Sie arbeiten.
Wir bitten um Ihr Verständnis und um Ihre Geduld. Wir sind nach wie vor in der Sache involviert und werden nach der ersten großen Patchwelle jetzt im Hintergrund für Sie arbeiten. Sollten neue, akute Probleme auftauchen, werden wir sofort aktiv werden und Sie nach Möglichkeit vorausschauend informieren.
Ich wünsche uns allen ein erholsames Wochenende, nach der vermutlich aufregendsten Woche der IT-Branche. So viele Überstunden haben unsere Mitarbeiterinnen und Mitarbeiter noch nie in einer Woche angesammelt. Alles was mit dem deutschen Arbeitszeitgesetz vereinbar war wurde von ihnen geleistet. Führungskräfte haben wenige Stunden geschlafen und durchgearbeitet.
Mit freundlichen Grüßen
Felix Preuß
Guten Abend,
wie geschrieben gibt es aktuell Nodes die sich ohne unser Zutun hart abschalten. Daran arbeiten wir.
Statusupdate #8:
Wir sind mit den Updates bei folgenden Systemen fertig: Root-Server, VPS, Storage-Server, managed vServer, managed pServer, gesamte Webhosting-Cloud.
Es folgen nun noch managed dedizierte Server die wir in Rücksprache mit den Kunden mit Updates versorgen.
Mit freundlichen Grüßen
Felix Preuß
Guten Tag templis,
Wenn jetzt eine ungepatchte Virtuelle Maschine dieses Feature noch nicht weg gepatcht hat, hat diese dann dennoch die Möglichkeit auszubrechen und den Speicherinhalt von anderen Maschinen auszulesen?
gerade deswegen haben wir ja geupdatet. Innerhalb der VMs kann ggf. noch ein nicht erlaubter Speicherzugriff erfolgen. Deswegen sollten hier auch neue Updates eingespielt werden. Das liegt bei Servern ohne gebuchten Management in der Hand unserer Kundinnen und Kunden.
Nach aktuellem Kenntnisstand kann aus einer VM nicht ausgebrochen werden. Zudem war Spectre nur sehr schwierig in einer KVM Umgebung anwendbar.
Mit freundlichen Grüßen
Felix Preuß
Statusupdate #7:
Langsam aber sicher ist das Ende der ersten Update-Phase zu sehen. Mehr als 95% unserer Nodes sind mit Updates versorgt. Die letzten Nodes der Webhosting-Cloud sind gerade dabei neu zu starten.
Es gibt allerdings noch einige Nodes die Probleme bereiten. Nodes von Root-Server mit Intel(R) E5-2600 CPUs und Intel(R) E5-2600v2 CPUs starten in unregelmäßigen unerwartet neu. Betroffen davon sind auch VPS-Produkte, die auf Servern mit dieser Intel-CPU-Generation liegen. Wir können hier leider nicht zu Neustarts informieren, da die Nodes wegen CPU-Fehler eigenständig neu starten. Betroffene Kunden die auf Hardware mit diesen CPUs liegen und die bereits einmal unerwartet neu gestartet ist werden wir daher gezielt anschreiben. Unsere Techniker und Softwareentwickler arbeiten auf Hochtouren um die Ursache dafür zu finden. Wenn wir bis Montag keine Lösung gefunden haben, werden wir den betroffenen Kunden einen Wechsel auf eine andere Hardwarearchitektur anbieten. Auch der Hersteller der Server HPE ist mit involviert.
Vereinzelnd mussten wir auch VPS und Root-Server anderer CPU-Generationen rebooten. Aufgrund eines Softwarefehlers wurden nicht alle Kunden über die erneuten Reboots informiert. Wir bedauern diesen Fehler und bitten dafür um Entschuldigung.
Täglich werden neue Kernelpatches, Microupdates und Qemu-Updates veröffentlicht. Wir sind dabei diese in einer separaten Testumgebung mit allen von uns angebotenen Distributionen zu testen. Auch werden alle Hardwarekonstelationen auf Verträglichkeit geprüft. Derzeit sind viele der Patches noch fehlerbehaftet und können daher von uns nicht eingespielt werden. Weitere Reboots sind daher Stand heute noch nicht geplant.
Wir empfehlen allen Kundinnen und Kunden neue Kernelupdates zu prüfen. Fertigen Sie ggf. einen Snapshot an, damit Sie einfach auf eine alte Version zurück wechseln können.
Sobald es weitere Updates gibt, werden wir hier darüber berichten.
Mit freundlichen Grüßen
Felix Preuß
Seit Ihrem KVM Update von gestern abend geht zumindest CentOS jedoch doch. Darf ich fragen, was das Problem war?
Es gab ein weiteres Update für Qemu. Vermutlich konnte Qemu von seinen Entwicklern so angepasst werden, dass auch CentOS 7 wieder funktioniert hat. Das ist jetzt allerdings eine rein spekulative Aussage. Details habe ich nicht geprüft.
Guten Abend,
zunächst möchte ich unser Bedauern dafür ausdrücken, dass die Updates länger brauchen als zunächst angenommen. Wir haben bewusst die 72 Stunden als voraussichtlich angekündigt und auf diesen Beitrag verwiesen. Auch auf netcup-status.de gibt es entsprechende Informationen. Wer diesen Beitrag aufmerksam verfolgt weiß, dass wird alles länger dauern als 72 Stunden.
Die gesamte IT-Branche ist gezwungen auf täglich erscheinende Updates zu reagieren. Es gibt Betriebssysteme wie Windows 10 aber auch CentOS die nicht mit den aktuellen Patches zurecht kommen, die es wiederum gegen die Sicherheitslücken gibt, um ein Beispiel zu nenne warum das Thema Spectre und Meltdown so kompliziert ist. Hinzu kommen viele Inkompatibilitäten da die Patches zum Teil unter enormen Zeitdruch veröffentlicht wurden. Hinzu kommt das auch wir leider Fehler machen. Ein großer Teil unserer Mitarbeiterinnen und Mitarbeiter ist seit Bekanntwerden der Sicherheitslücken mit dem Thema beschäftigt und wir tun wirklich unser bestmögliches um der Sache Herr zu werden.
Gründe warum wir keinen genauen Zeitplan vorgeben können und warum wir - und alle anderen IT-Dienstleister in Deutschland und vermutlich der gesamten Welt auch - so schnell wie möglich reagieren müssen haben wir genannt. Zumindest in Deutschland würden IT-Dienstleister gegen geltendes Recht verstoßen, wenn sie nicht alles daran setzen um die Daten ihrer Kunden zu schützen. Wer die Berichte in den Medien zu Meltdown und Spectre verfolgt, weiß sicherlich was dieses bedeutet.
Ich muss nochmals dazu auffordern in diesem Beitrag sachlich zu bleiben. Jeder unserer Kunden muss die Möglichkeit haben diesen Beitrag zu verfolgen. Es ist nicht erwünscht das hier Doppelpost entstehen, die das selbe Thema haben. Wenn dieses nicht klappt, müssen wir diesen Beitrag leider moderieren.
Ich muss nochmal folgende Sätze aus dem ersten Thema zu diesem Beitrag aufgreifen:
Damit dieser Forenbeitrag übersichtlich bleibt, bitten wir darum hier keine Spekulationen zu führen. Bitte stellen Sie Fragen oder versorgen Sie diesen Beitrag mit Informationen aus verlässlichen Quellen.
Alle Beiträge die nicht in diesen Thread passen werden gelöscht werden. Bitte eröffnen Sie ggf. ein separates Thema dafür.
Vielen Dank!
Mit freundlichen Grüßen
Felix Preuß
Guten Tag,
ich habe dazu ja hier bereits einen Link gepostet: https://forum.netcup.de/sonstiges/smal…hema/#post88912
Darüber hinaus haben wir einen gewissen Vorteil, dass KVM eingesetzt wird. Wir müssen aber alle damit rechnen, dass es weitere Updates geben wird. Das hatte ich ja auch hier schon geschrieben,
Ich möchte darum bitten das in diesem Beitrag keine Diskussionen zu Spectre und Meltdown an sich geführt werden. Dazu gibt es bereits sehr viele Diskussionen im Internet. Wir müssen es gemeinsam schaffen, dass der Beitrag übersichtlich bleibt. Er soll alleine dem Umgang von netcup mit Meltdown und Spectre so wie den konkreten Fragen zu den Abläufen dienen. Gut 27.000 Menschen lesen hier bereits mit. Wir müssen es schaffen alle interessierten Kundinnen und Kunden zu erreichen.
Vielen herzlichen Dank!
Mit freundlichen Grüßen
Felix Preuß
Statusupdate #6:
Mittlerweile sind > 30% der Root-Server, VPS, Storage-Server und managed pServer so wie managed vServer neugestartet.
Die Webhosting-Cloud ist zum großen Teil neu gestartet.
Es gab einen Fehler aufgrund dessen bei einigen Nodes der ACPI-Shutdown nicht richtig funktioniert hat. Dieses konnten wir nachstellen und fixen. Vielen Dank für Ihren Nachdruck in dieser Sache. Es tut uns Leid, dass wir dieses nicht früher erkannt haben.
Ersatzteile wurden heute geliefert. Für morgen stehen weitere Lieferungen an.
Die Benachrichtigungen via E-Mail kurz vor den Reboots werden seit heute morgen verschickt.
Die Arbeiten gehen während der Nacht weiter. Nach ersten Hochrechnungen wird es noch 48 - 56 Stunden dauern, bis alle Systeme geupdatet und nacheinander neu gestartet wurden. Wir haben vorsorglich jetzt mehr Ersatzteile bestellt als es die üblichen Lagerbestände vorsehen.
Hui, Schrecksekunde vorüber! 
Danke für die Aufklärung!
Seb2704 :
Das sieht nach einem individuellen Problem aus. Bitte wenden Sie sich einmal an den Support mit Verweis auf diesen Beitrag, damit dieser einmal durchcheckt ob am Wirt alles Okay ist. Sieht etwas nach einem fehlenden RAID-Controller-Cache aus.
Vielen Dank!
Dort stand jetzt aber nicht "Max Mustermann", oder? 
Die Ankündigung geht an alle Produkte des Typs Root-Server, VPS und Storage-Server raus.
Mit freundlichen Grüßen
Felix Preuß
Guten Morgen,
das mit dem "Suspend-to-Disk" geht bei einem einzelnen System. Wenn ein ganzer Node mit mehreren hundert GB RAM suspended wird, wird dieses längere Downtimes mit sich bringen.
Hinsichtlich der ACPI-Shutdown-Probleme forschen wir jetzt weiter. Auch wird es ab heute E-Mails geben, kurz bevor der Reboot durchgeführt wird.
Sehr spannend zur Thematik Spectre im Linux-Kernel ist folgender Artikel: http://kroah.com/log/blog/2018/01/06/meltdown-status/
Z.B. Red Hat / CentOS bringen angeblich Fixes gegen Spectre mit. Es deutet vieles darauf hin, dass diese nicht ausreichend sind. Allerdings ist Spectre an sich in der Tat sehr schwer ausnutzbar.
Viele Grüße
Felix
Guten Abend,
wir haben die Zeit in der wir auf neue Hardware warten genutzt, um unsere Reportingmöglichkeiten an unsere Kundinnen und Kunden zu optimieren. Ab morgen werden wir in der Lage sein, Kunden via E-Mail kurz vor einem vServer-Neustart zu informieren. Hier wird dann ein Zeitfenster von einer Stunde genannt werden, in dem der vServer neugestartet wird.
Hinsichtlich der Probleme bzgl. der ACPI-Shutdowns forschen wir noch. Wir können dieses Problem definitiv bei bestimmten Node-Typen (abhängig von der genutzten Distribution und Softwareversion) ausschließen. Wir nehmen die Kritik zum Anlass um dieses jetzt allerdings bei allen möglichen Konstellationen zu überprüfen. Dazu haben wir uns Testsysteme auf den entsprechenden Nodes angelegt und werden morgen prüfen, was bei den Neustarts passiert. Wenn es Probleme auf unserer Seite gibt, werden wir natürlich alles daran setzen, um diese zu beseitigen.
Ich wünsche Ihnen eine angenehme Nacht!
Mit freundlichen Grüßen
Felix Preuß
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.
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ß
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ß
Guten Abend,
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ß
Statusupdate #4:
Jetzt werden die ersten Webhosting-Nodes neu gestartet.
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.
