Beiträge von [netcup] Felix P.

    Guten Tag,

    Zitat


    Allerdings wurde der Server nicht schön heruntergefahren durch einen ACPI Shutdown sondern hart ausgeschaltet

    in dem Fall hat Ihr Server nicht auf den ACPI Shutdown reagiert und wurde nach 5 Minuten hart abgeschaltet. In dem Fall sollten Sie Ihre Software prüfen und richtig konfigurieren.

    Damit jeder Leser hier den Fortgang verfolgen kann, bitte ich nochmals darum keine individuellen Probleme hier zu lösen. Sie können dafür eigene Beiträge öffnen.


    Mit freundlichen Grüßen


    Felix Preuß

    Guten Tag,


    wir sind nach wie vor mit der Migration beschäftigt. Es zeichnet sich aktuell ab, dass es zu leichten Verzögerungen kommen wird. Diese sind darauf zurück zu führen, dass die Migrationsscripte noch nicht das abdecken, was wir abdecken möchten.


    Sobald wir konkrete Termine nennen können, werden wir diese den betroffenen Kunden mitteilen,


    Mit freundlichen Grüßen und ein angenehmes Wochenende

    Felix Preuß

    Guten Morgen,


    unser Team arbeitet nach wie vor an den Updates und den daraus resultierenden Reboots. Es gibt keine relevanten Statusänderungen.

    Vereinzelnd kam es auf den Nodes zu Hardwarefehlern, welche die Ausfallzeit verlängert haben. Betroffene Kunden wurden hier separat angeschrieben.

    Es ist leider nicht ungewöhnlich, dass RAID-Controller Cache-Batterien sich bei einem Reboot verabschieden. Das bedeutet das auch Mitarbeiter im Rechenzentrum damit beschäftigt sind, die Caches auszutauschen.

    Zitat

    wobei Frage an [netcup] Felix: welche Linux Distribution kommt als Wirtsystem zum Einsatz?

    Wir haben unterschiedliche Hardware und unterschiedliche Distributionen im Einsatz. Details zur Distribution geben wir nicht bekannt, da dieses auch unerheblich für die Gastsysteme ist, zumal Gastsysteme ja auch zwischen den Nodes, z.B. bei einem Lastausgleich, verschoben werden.


    Mit freundlichen Grüßen


    Felix Preuß

    Statusupdate #2:

    Wir haben ein Benchmark einmal vor dem Sicherheitsupdate ausgeführt und ein weiteres Mal nach dem Sicherheitsupdate. Dafür wurde ein RS8000 genutzt.

    Das Ergebnis:

    Code
    vorher:
    System Benchmarks Index Score 5673.4
    Code
    nachher:
    System Benchmarks Index Score 5479.8

    Ich denke die Sorge, dass durch das Sicherheitsupdate vieles langsamer wird, ist damit unberechtigt.

    Weiteres Statusupdates werden folgen.

    @bthomba: Wir spielen zusätzlich Microupdates in die Prozessoren ein. Damit sind wir nach aktuellem Kenntnisstand save gegen Meltdown.

    Zitat


    Über welchen Zeitraum werden die Sicherheitsupdates sein? Oder ist dies noch unklar?

    Wir können nicht vorhersagen wie lange dieses dauert (siehe vorangegangene Posts mit Erklärung).

    Zitat

    Und werden die Server währenddessen auch direkt Neugestartet oder erst später?


    Da die Sicherheitsupdates erst nach einem Neustart aktiv werden, werden die Nodes, wie zuvor beschrieben, auch neu gestartet.

    Mit freundlichen Grüßen

    Felix Preuß

    Statusupdate #1:

    Von Meltdown sind Root-Server, VPS, Storage-Server seitens der Wirtssysteme (Nodes) nicht betroffen, da diese Produkte auf KVM basieren. Wir können hier einen auf Performance optimierten Kernel nach wie vor nutzen. Die Gäste müssen allerdings geupdatet werden.

    Wir starten ab 10:50 Uhr mit den Sicherheitsupdates hinsichtlich Spectre auf den Wirtssystemen.


    Managed vServer werden vor dem Neustart der Nodes auch einen neuen Kernel erhalten. So ersparen wir uns hier einen doppelten Reboot.

    Bitte updaten Sie Ihre eigenen Systeme wenn Sie diese selbst managen sobald es für diese Sicherheitsupdates gibt. Damit das Update nicht mit unseren Reboots in einen Konflikt kommt, nach Möglichkeit nach unseren Reboots.

    Mit freundlichen Grüßen

    Felix Preuß

    Guten Tag,

    Zitat

    [netcup] Felix So sehr ich Verständnis für die Maßnahme habe, aber eine kurze Info vorher wäre schon hilfreich. Gibt es da wirklich gar keine Möglichkeit, das wenigstens ein paar Minuten vorher im SCP oder sonst wo anzuzeigen?

    Das Updatescript o.ä. wird doch wissen: Node XXX ist an Stelle YYY in der Warteschleife und kommt somit wahrscheinlich innerhalb der nächsten halben Stunde an die Reihe. Ihr werdet ja kaum alle Hostsysteme gleichzeitig anstoßen... :)

    es gibt Nodes die rebooten komplett in 5 Minuten und welche die dafür 30 Minuten brauchen. Um hier planen zu können dürften wir jeden Node nur zu einem zuvor geplanten Zeitpunkt neustarten. Das wäre bei der Anzahl die wir an Nodes haben eine künstliche Verzögerung die eine Verlängerung der Reboots von vermutlich mehr als 7 Tage zur Folge hätte.

    Alternativ könnten wir alle Server sofort zeitgleich neu starten. Damit wären dann aber auch alle Server die ein Kunde hat zeitgleich weg. Das wollen wir nicht.

    Normalerweise werden Reboots von Nodes nach Möglichkeit Nachts und nach längerer Vorankündigung durchgeführt. Bei den hier bestehenden Sicherheitslücken müssen wir leider so schnell wie nur möglich aktiv werden.

    Wir werden hier über den Fortschritt der Reboots berichten, sobald sich genauere Zahlen und Statistiken dazu ableiten lassen.


    Mit freundlichen Grüßen

    Felix Preuß

    Guten Tag,

    wir geben jeden Gast 300 Sekunden Zeit für einen ACPI Reboot, bevor resettet wird.

    Zitat

    Wie es scheint bekommen "die Großen" mehr Infos zu dieser Lücke kommuniziert. Ist das dann ein Linux / vmware / netapp / etc Patch? Von diesem wird es wohl noch einige verbesserte Versionen geben, so daß es es weitere reboots geben wird.


    Wir haben unterschiedliche Systeme. Da so gut wie alle Systeme davon betroffen sind werden alle Kernel und CPU-Microcodes geupdatet werden.

    Zitat

    Eine Frage meinerseits währe noch:

    Sie schließen damit die Lücke "nur" auf Ihrer eigenen Seite, also auf Ihrem Node/root/Hardware nehme ich an? Wer einen normalen vServer besitzt muss sich selbst noch Kernel-Patches kümmern, da die Lücke weiterhin auf der eigene Verwaltungsebene ausgenutzt werden kann.

    Es ist noch nicht erwiesen ob durch das Update auf dem Wirt automatisch alle Gäste sicher sind. Prinzipiell ist es sicherlich ratsam das Sie auch alle Kernelupdates auf einem Gast einspielen die es gibt.

    Mit freundlichen Grüßen


    Felix Preuß

    Sehr geehrte Kundinnen und Kunden,

    der 4. Januar 2018 wird in die Geschichte eingehen. Medien überschlagen sich heute mit Berichten zu einer Sicherheitslücke in CPUs. Es gibt bereits etliche Spekulationen unter anderem das CPUs langsamer werden usw.. Wir denken es ist wichtig, dass Sie die Fakten kennen und wissen was netcup in dieser Angelegenheit unternimmt.

    Ein Überblick:

    Heise berichtet dazu: https://www.heise.de/security/meldu…es-3931562.html

    Golem berichtet: https://www.golem.de/news/memory-le…801-131938.html

    Selbst die Tagesschau berichtet dazu heute: http://www.tagesschau.de/ausland/intel-…luecke-101.html

    Unser Support erhält dazu auch etliche Anfragen. Sie als unsere Kundinnen und Kunden wollen zu recht wissen, wie netcup mit der Sicherheitslücke umgeht. Damit wir Informationen gebündelt an Sie weitergeben können und damit auch Sie sich mit anderen Kundinnen und Kunden austauschen können, haben wir diesen Beitrag eröffnet. Wir werden hier Neuigkeiten bekannt geben, sobald wir diese haben.

    Zunächst das Wichtigste:

    Wir nehmen Sicherheit sehr ernst und tun alles, damit wir Ihnen die bestmögliche Sicherheit anbieten können die es gibt. Wir gehen nicht davon aus, dass unsere CPUs wesentlich langsamer werden, wenn wir die Sicherheitslücken durch einen Softwarepatch schließen, da wir auf unseren Servern ausreichend freie CPU-Ressourcen haben. Unsere Nodes für Root-Server sind z.B. im Schnitt nur zu 60% ausgelastet, was die CPU-Leistung angeht. Darüber hinaus setzen wir neue CPUs von Intel (R) ein. Diese sollen laut Experten keine merkbaren Performance-Einbußen bei einem Softwarepatch erfahren.

    Zum aktuellen Stand:

    Seit heute morgen schreiben wir alle Kundinnen und Kunden an, die einen vServer, Root-Server, Storage-Server oder managed private Server bei uns beziehen und verweisen auf diesen Forenbeitrag. Darüber hinaus verweisen wir darauf, dass wir alle vServer, Root-Server, Storage-Server oder managed private Server neustarten, sobald wir einen getesteten Patch für unsere Systeme haben. Wir können aufgrund der Dringlichkeit nicht ankündigen, wann der Neustart genau passieren wird, da wir keine künstliche Verzögerung zwecks Planungen machen können. Wir werden die Nodes allerdings möglichst seriell (sprich nacheinander) Neustarten. Wenn Sie mehrere vServer, Root-Server, Storage-Server oder managed private bei uns gebucht haben, werden diese somit nach Möglichkeit nacheinander neu gestartet werden. Wenn Sie eine Failvoder-IP bei uns gebucht haben, können Sie eine HA-Cluster somit aufrecht erhalten.

    Kundinnen und Kunden die einen managed private Server / managed vServer oder managed dedizierten Server bei uns gebucht haben, brauchen nichts weiter zu unternehmen. Wir kümmern uns darum, dass alle gebuchten Dienste nach dem Neustart wieder korrekt arbeiten.

    Dedizierte Managed Server werden wir auch sehr zeitnah mit dem Patch versehen und nach Rücksprache mit unseren Kundinnen und Kunden neustarten.


    Nodes unserer Webhosting-Cloud werden nacheinander neugestartet werden. Hier wird es nur eine sehr kurze Nichterreichbarkeit von Webhosting-Accounts geben.

    Unsere Bitte:

    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.

    Vielen herzlichen Dank!