Meldung über dringende Wartungsarbeiten am Wirtssystem aufgrund QEMU-Bug

  • Wie nach Hause gehen?


    Meine Domains auf dem managed server (bzw. "unmanaged" server) sind alle tot.
    Die confixx-Auflösung von Domain auf server funktioniert nicht.


    Es kommt die Confixx-Meldung.

    Zitat

    Die Domain "xxxx" ist nicht verfügbar.

    ERR_NAME_RESOLUTION_FAILED


    jetzt verlieren wir den wichtigen US-Verkehr.
    Das Ping auf die Domains xxxxx funktioniert und wird korrekt auf dem A-record by netcup aufgelöst.
    Tracert genauso

  • Hat alles ohne wirkliche Probleme geklappt.


    Allerdings waren 2 der 3 von mir betreuten VServer nach dem Neustart nicht mehr erreichbar. War allerdings trivial. Das ISO mit der Debian CD war noch gemounted und folglich startet der Server die "CD". ;) Naja, Problem erkannt und CD rausgeworfen. Fertig...


    Gute Nacht..

  • Danke für das rasche Update.


    Auch wenn ich die Mail erst gesehen hatte, als der Server bereits seit 2 Stunden wieder problemlos lief. Downtime war knapp 10 Minuten laut logs.

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

  • Danke an den Einsatz vom Netcup-Team am Feierabend/Feiertag.


    Bei mir betrug die Downtime etwa 15 Minuten.
    Komisch war allerdings, dass HTTP sofort erreichbar war, SSH aber erst einige Minuten später.
    Zuerst dachte ich Fail2Ban hätte mich ausgesperrt, aber selbst von meinem mobilen Internet ging es nicht.
    Einige Minuten später ging es dann auf einmal ohne Probleme - warum auch immer. Vielleicht hat einfach das Starten von SSHD etwas länger gedauert...


    Zu den Beschwerden bzgl. Datenverlust:
    Wer trotz regulärem Shutdown per ACPI einen Datenverlust hat, ist meiner Meinung nach selbst Schuld. Da ist dann etwas grob falsch konfiguriert.
    Außerdem gibt Netcup sowieso keine Garantie bzgl. Datenverlust ab. Backups muss jeder selbst machen, theoretisch könnten alle Festplatten auf der Stelle ausfallen und die Daten sind weg.


    Und zur späten E-Mail:
    Wenn für jemanden das so ein kritisches System ist, sollte er sich eine eigene E-Mail-Adresse für solche wichtigen Benachrichtigungen anlegen und dieses Postfach per Push auf dem Smartphone empfangen. Somit kann so eine Meldung nicht untergehn.
    Natürlich wäre es dazu toll, wenn man bei Netcup mehrere E-Mail-Adressen konfigurieren könnte. (Eigene Mailadresse für Rechnungen und für technische Belange)


    Aber nochmals ein großes DANKE ans Netcup-Team. :thumbup:

  • Möchte mich auch bei Netcup für die schnelle Reaktion auf die Sicherheitslücke bedanken! Genau so muss es laufen.


    Für alle, deren Server nach dem Neustart nicht mehr ging: Testet ab und an oder nach größeren Konfigurationsänderungen ob der eigene Server einen Neustart übersteht. Zugegebenermaßen lernt man das bei Netcup aufgrund der sehr langen uptimes ganz ohne Neustart nicht ;). Bei meinem letzten Hoster gab es so alle 1-2 Monate Reboots aus dem Nichts, da lernt man seine Server so zu konfigurieren, dass da nix schief geht.
    Speziell der Kollege, der seine wichtigen Daten im RAM nicht beim runterfahren speichert. Ganz klar selbst Schuld und Konzept nochmal überdenken (netcup kann nichts für eine falsche Konfiguration so ärgerlich es auch ist. Erstmal an die eigene Nase fassen.)!

  • Hallo,


    also zwei meiner drei Maschinen hatte eine Downtime von knapp 10 Minuten.
    Ich denke das ist ok.


    der dritte meiner VS wurde aber anscheinend vergessen .... Der ist nach wie vor online und hat keinen Neustart gesehen.
    Auch für diesen hatten ich eine Infomail erhalten. Gab es Notes die keinen reboot benötigten ?

  • Mein Server läuft wieder, leider ist er aber nur über IPv4 erreichbar (und kommt von innen auch nicht über IPv6 nach draußen). Meine Einstellungen haben sich natürlich nicht geändert.


    # ip -6 route
    2a03:4000:2::1 dev eth0 metric 1024

    2a03:4000:2:188::/64 dev eth0 proto kernel metric 256
    fe80::/64 dev eth0 proto kernel metric 256


    # ping6 2a03:4000:2::1
    PING 2a03:4000:2::1(2a03:4000:2::1) 56 data bytes
    From 2a03:4000:2:188::1 icmp_seq=1 Destination unreachable: Address unreachable
    From 2a03:4000:2:188::1 icmp_seq=2 Destination unreachable: Address unreachable
    From 2a03:4000:2:188::1 icmp_seq=3 Destination unreachable: Address unreachable


    2a03:4000:2::1 sollte eigentlich der Gateway nach draußen sein, ist aber nicht erreichbar.

  • Hallo forthy,
    bei mir sieht die IPv6-Konfiguration etwas anders aus und funktioniert:

    Code
    # ip -6 route
    (Mein IPv6-Adress-Bereich)/64 dev eth0  proto kernel  metric 256
    fe80::/64 dev eth0  proto kernel  metric 256
    default via fe80::1 dev eth0  metric 1024


    Bei dir fehlt mir in der route irgendwie der default (bin mir aber nicht 100% sicher, dass der gebraucht wird). Eventuell kannst du mal versuchen, den fe80::1 zu hinterlegen und schauen ob es besser wird.
    (Ich wundere mich zwar, warum ich eine Link-Local Adresse als IPv6-Gateway kriege, aber nun gut.)
    Vorher musste ich natürlich meine IPv6-Adresse manuell hinzufügen (per DHCP wird mir keine zugewiesen).


    Grüße

  • der dritte meiner VS wurde aber anscheinend vergessen .... Der ist nach wie vor online und hat keinen Neustart gesehen.
    Auch für diesen hatten ich eine Infomail erhalten. Gab es Notes die keinen reboot benötigten ?


    War bei mir auch so. Habe mich gestern Abend gewundert das einer meiner vServer nicht neugestartet wurde.
    Seite 08:55 Uhr ist er allerdings nicht mehr erreichbar. Vermute Netcup holt den Neustart jetzt nach.

  • Ich kann nur sagen, nie mehr managed Server !!!


    Das Team startet spät am Abend einen Server neu , worauf die Software auf einem wichtigsten User hängen bleibt wegen einer Misconfig.


    Und dann geht das sogenannte "Server-Management-Team" bei Netcup schlafen und ist erst um 10 nach über 12 Stunden erreichbar.

  • Ich kann nur sagen, nie mehr managed Server !!!


    Das Team startet spät am Abend einen Server neu , der daraufhin hängen bleibt wegen einer Misconfig.


    Und dann geht das sogenannte "Server-Management-Team" bei Netcup schlafen und ist erst um 10 nach über 12 Stunden erreichbar.

    Das das Server-Management Team auch mal Feierabend machen muss, siehst Du doch auch ein, oder?

    Learn to sit back and observe. Not everything needs a reaction

    • Offizieller Beitrag

    Ich kann nur sagen, nie mehr managed Server !!!


    Das Team startet spät am Abend einen Server neu , der daraufhin hängen bleibt wegen einer Misconfig.


    Und dann geht das sogenannte "Server-Management-Team" bei Netcup schlafen und ist erst um 10 nach über 12 Stunden erreichbar.


    Der Notfallsupport steht rund um die Uhr zur Verfügung. Wenn aus Ihrer Sicht eine Störung vorliegt, können Sie den Notfallsupport nutzen um die Störung zu melden damit diese behoben wird.


    Auch konnte ich keine Meldung an mail@netcup.de feststellen.


    Ihr Managed Server ist erreichbar, und auch die Confixxoberfläche arbeitet ordnungsgemäß. Bitte senden Sie uns eine eMail an mail@netcup.de in der Sie uns beschreiben an welcher stelle sie eine Störung beobachten können. Ich kann diese zum jetzigen Zeitpunk nicht nachvollziehen.

    • Offizieller Beitrag

    Notfallnummer 40 € für 15 Minuten.


    Sollte der Fehler jedoch in unserem Einfluss- bzw. Verantwortungsbereich liegen, so ist der Notfallsupport kostenlos.


    Wenn Sie sich entscheiden den Notfallsupport nicht anzurufen, haben Sie dennoch die Möglichkeit eine Mail an mail@netcup.de hinein zu senden. Diese werden ebenso bearbeitet.

  • Die Mails habe ich geschrieben, wurde aber erst am nächsten Morgen beantwortet.
    Die http spezial Config habe ich geändert, aber der Server wurde bis 9.50 Uhr nicht neu gestartet.


    Das Wichtigste was ich brauche, als managed Server Kunde, ist den Server selbst neu starten zu können.
    Das ist bei anderen Providern möglich, bei Netcup aber, so weit ich weiss, nicht.
    Der Server und der httpd service liefen monatelang ohne Neustart, nur durch den Neustart beim QEMU Bug wurde die Misconfiguration offensichtlich.

  • Hmm, bei mir scheint es auch eine geringfüge Störung nach dem einspielen des Patches zu geben:
    Normalerweise läuft der Server nach einem Neustart, als auch bei einem shutdown -h now und anschliessenden Web-Controlpanel PowerOff sowie PowerOn/Neustart tadelos.Nach dem einspielen des Patch ist IPv6 Konnektivität in Richtung fe80::1 GW jedoch gestört.IPv4 klappt wunderbar aber das IPv6 Gateway macht immer mal wieder sporadische Probleme.

    Allerdings kann ich die Konnektivität wieder selbst herstellen indem ich zunächst alle Routes für IPv6 lösche und die local networksettings
    neu initialisiere:"route flush -inet6; sh /etc/netstart".Danach braucht es noch ein ping6 auf den zuständigen router mittels ff02::2%em0 und nach etwas warten klappt die IPv6 Konnektivität wieder. Kann das eventuell an problematischen Router advertisements liegen?