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

  • Ich habe von allen jetzt gehört das Ihre Server schon neugestartet wurden.Gibt es auch noch einige bei welchen dies noch nicht der Fall war?

    Da seitens Netcup kein anderer Status veröffentlicht wurde als „wir sind noch dabei“ und auch die Netcup Status Seite noch „in Bearbeitung“ zeigt gehe ich mal davon aus das Netcup noch nicht fertig ist!

  • Meine 3 Server warten alle noch auf den Restart.

    Bei 2 steht jedoch was von neuer KVM-Version im SCP..

    CentOS 7 / nginx / php-fpm / postfix / rspamd / clamav / dovecot / nextcloud running on RS 1000 SSDx4 G8 / VPS 500 G8 / VPS 2000 G8 Plus

  • Bei mir steht auch bei 2 Servern der Hinweis mit der neuen KVM Version und dass ich einen Powercycle auslösen soll.

    Beide Server wurden seit mehreren Monaten nicht neu gestartet (also auch kein von Netcup ausgelöster Neustart in den letzten Tagen), deshalb hab ich sie beide neu gestartet. Die Meldung bzgl. der KVM Version ist jetzt zwar weg, aber folgt jetzt noch irgendwann der Reboot durch Netcup???

    Oder kann ich gefahrlos an der Einrichtung des Servers rumbasteln, ohne das er plötzlich inmitten irgendeines Prozesses abgeschossen wird?

  • Hmmm... Neustart durch nc gestern gegen 18:45h, und seit 4:16h heute morgen: sda abort. SSD platt. Reboot nicht möglich (hängt nach OS-Auswahl).

    Das muss nun nicht mit dem Patch zusammenhängen, ist aber "höhckscht unerfreulisch". Schnief...

  • dmesg | grep isolation

    [ 0.000000] Kernel/User page tables isolation: enabled

    bei mir sieht das Ergebnis so aus ...

    [ 0.000000] x86/pti: Kernel page table isolation enabled

    dürfte eine Frage der Linux Distri sein;


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


    und evtl. welchen Fortschritt habt ihr mittlerweile erziehlt;

    Grüße / Greetings

    Walter H.


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

  • 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ß

  • 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.

    Klassiker. Kenne den Spass auch vom Job. Bei älteren Dell Systemen sah man auch schön die hohgeganngen Elkos.

    ich habe bei meinem "kritischen" System den ACPI Reboot über die Feiertage getestet ob es Dienste gibt die Probleme machen bevor es da zu Problemen kommt. Noch sieht alles gut aus.



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

    An dieser Stelle mal ein dickes Dankeschön an das ganze Team für die zeitnahe Behebung der Sicherheitslücken und ausführliche Information.

    Mein kleiner vServer hat den Reboot gestern Nacht gut überstanden, die Patches für Ubuntu hatte ich schon vorher eingespielt. Die Downtime mus unter 30 Minuten gewesen sein, sonst hätte ich nen Alarm bekommen. Also alles im grünen Bereich.


    Ich wünsche allen Beteiligten trotz der vielen Arbeit ein schönes Wochenende!

  • nachdem ich die Patch Aktion hier aufmerksam verfolgt habe war nun heute morgen auch ich an der Reihe.


    Die Ausfallzeit hielt sich in Grenzen mit knapp 45 Minuten. Allerdings wurde der Server nicht schön heruntergefahren durch einen ACPI Shutdown sondern hart ausgeschaltet. Alles war eingerichtet und getestet für einen graceful shutdown ...


    Netcup - das war nicht nett , auch wenn sich die Ausfallzeit in Grenzen gehalten hat.

  • iLion: journalctl --since="1 day ago" ?


    Damit beginnt das Log (wie ich auch manuel in /var/log/syslog gefunden habe) um 22:59 Uhr. Laut UptimeRobot wurde mein Server aber gegen 22:39 Uhr neu gestartet. Die erste "UP" Meldung von UptimeRobot stammt von 23:01 Uhr.

    Ich hatte gestern gegen 19:24 Uhr meinen Server per manuellem APCI Signal über das Server Control Panel abgeschaltet. Zum einen, um zu testen wie schnell er auf den Befehl reagiert, zum anderen weil ich auch schon die Meldung zur neuen KVM Version im Control Panel hatte.

    Ich habe den Server seit einem Jahr und hatte noch nie solche Probleme mit mailcow bzw. dem SOGo-Part und mich macht es etwas unruhig, dass der Neustart durch netcup doch nicht so sauber für das Gast-System abgelaufen sein könnte, wie ursprünglich angekündigt. :/

  • 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ß