Beiträge von spectre

  • DNS Migrations Problem

    Zitat von [netcup] Claudia M.

    spectre , fein, dass der Support helfen konnte! :)

    Möchtest du hier mit der Community teilen, wie das Issue behoben werden konnte?

    Öhm, ehrlichgesagt keine Ahnung. Ich vermute, ihr habt nochmal ein Update bei der Denic getriggert und euch da als DNS eingetragen. Der Support hielt sich kurz:

    Zitat
    Code
    Guten Tag,

vielen Dank für Ihre Geduld.
Die Nameserver Ihrer Domain wurden angepasst.
Das Problem sollte in Kürze behoben sein.

Mit freundlichen Grüßen

  • DNS Migrations Problem

    Zitat von ASS

    Hm,

    ja, wirklich seltsam, dass das noch immer nicht gemacht ist.

    Wie sehn denn deine Einträge für den NC NS aus?

    Ich weiß zwar nicht ob das der NC Parser zulässt (ich würde erwarten, dass nicht), aber vielleicht ist ja dein Zoneneintrag im NC NS falsch und das Update schlägt ständig fehl.

    So lange DF nicht abschaltet ist das ganze allerdings auch eher Prio 2...

    Hmmm, die werden alle als "gültig" angezeigt:

    Bildschirmfoto zu 2021-11-29 10-58-56.png


    Aber kann natürlich sein, ich bin schon n b00n was DNS angeht, geb ich ja auch gerne zu. Sieht für mich auch plausibel aus, aber wissen tu ichs nicht.


    Und ja, da hast du Recht, solange DF noch liefert ist es zwar ärgerlich aber kein Weltuntergang. Ich hoffe nur dass die nicht allzubald abschalten.

  • DNS Migrations Problem

    Hmja, schön ist das nicht. Hätte gerne das WE genutzt um ein Paar Sachen einzurichten, das klappt jetzt leider nicht. Und du hast natürlich Recht, sobald DF den Stecker zieht geht gar nichts mehr. Wegen der Forulierung, ja naja hatte ich ja geschrieben das war nicht als Flame gemeint. Dem Support habe ich das hier geschrieben:


    Code
    Hallo NCler, ich habe ein Problem beim Umzug einer Domain zu euch. Der whois zeigt
leider immernoch auf den alten DNS (bei Domainfactory) obwohl scheinbar alles
geklappt hat. Die Domain heißt XXX. Im Forum habe ich das auch
beschrieben und die meinten ich soll mich mal an den Support wenden:
https://forum.netcup.de/netcup-intern/technik/p169688-dns-migrations-problem/#post169739


    Bisher nur die Bestätigung, dass es weitergeleitet wurde. Ich hoffe/denke mal dass das heute gelöst wird.

  • DNS Migrations Problem

    Mit das wichtigste meinst du den whois, oder? Das stimmt, den hatte ich vergessen.


    Interessanterweise sagt das whois aber auch, dass der geändert wurde am 25.11. Abends (da habe ich bestellt), aber er zeigt iimmernoch auf dieselben Server. Support ist schon kontaktiert gestern morgen) aber bisher noch unverändert. Mal abwarten.


    Zu dem Flame: Also ich glaube das hast du das reingelesen. Ich war im Großen und Ganzen mit DF schon zufrieden, aber habe fälschlicherweise geglaubt dass deren Record (mit SOA) als nsupdate an die Denic geht, und deswegen halt vielleicht der Netcup DNS (der ja auch ein SOA hat) mit dem DF DNS darum ringt, Requests für meine Domain zu beantworten. Das habt ihr ja geschrieben dass das nicht so stimmt, wiegesagt, ich kenne ich da nicht so aus mit DNS. Primär finde ich es eine unendliche Erleichterung dass Netcup ne API anbietet, das ist wirklich der Hauptgrund. Wird irgendwann lästig bei 10+ Domains, die Records händisch zu pflegen.


    Aber falls das wie ein Flame rübergekommen sein sollte tut es mir jedenfalls leid. Zum Flamen im Internet bin ich mittlerweile zu oll glaube ich :)

  • DNS Migrations Problem

    Zitat von Olivetti

    ich würde den NC-support mal anschreiben, evtl. bist du ja gestern mit in den domain-hänger reingeraten.

    Code
    whois …
Nserver: ns2.namespace4you.de
Nserver: ns.namespace4you.de
Status: connect
Changed: 2021-11-25T19:31:54+01:00


    Oha, ich hab zwar bei der Bestellung Probleme gehabt, bin aber davon ausgegangen dass das nur an der Last liegt. Vielen Dank für den Tipp!

  • DNS Migrations Problem

    Zitat von michaeleifel

    Hast du mal den DNS Netcup gefragt was er dazu sagt?


    Wenn dort deine erwarteten Einträge zurückkommen würde ich vermuten dass die Propagation / Providerwechsel noch nicht abgeschlossen ist.

    Ja, hatte ich, habe ich vergessen zu schreiben. Der Netcup DNS ist perfekt konfiguriert und reagiert auch zackig, wenn ich an den DNS Einstellungen was ändere. Nur eben der authoritative Server der zeigt noch auf den Domainfactory DNS:



    Zitat

    2 Dinge die du machen kannst:

    1.) DNS Flush Cache bei den öffentlichen Resolvern auslösen und danach prüfen ob die neue Information verfügbar ist

    2.) Netcup DNS Server direkt fragen.

    Oh, ich wusste gar nciht wie man einen DNS Flush Cache auslösen kann. Muss ich mal danach suchen. Vielen Dank für den Tipp!

  • DNS Migrations Problem

    Ah, vielen Dank für den Tipp. Ja, das wäre gut. Vielelicht bin ich ja übervorsichtig aber naja :)

  • DNS Migrations Problem

    Verdammt das war die EINE Stelle die ich nicht anonymisiert habe, die nicht durch mein Skript geht. Das ist meine Problemdomain, ja. Könntest du deinen Post bitte editieren? Ich hab es auch geändert.


    Aber, ja, zeigt auf eine Netcup-IP, weil die hat sich auch nicht geändert. Nur der DNS Provider hat sich geändert. Die Records sollen erstmal alle identisch bleiben.


    EDIT: Na toll das Forum hier hat eh ne Historyfunktion, also ist glaube ich editieren auch sinnlos. Hrmpf.

  • DNS Migrations Problem

    Hallo liebes Forum.


    Keine Ahnung ob das hier der richtige Ort ist, aber ich weiß auch ehrlichgesagt nicht, wo ich es hinposten soll. Und mir ist auch klar dass das Problem das ich beschreibe nicht bei Netcup liegt. Aber alles von Anfang an:


    Ich schiebe schon lange vor mir her, etliche Domains (10 Stück oder so) von Domainfactory zu Netcup umzuziehen. Heute wegen BF habe ich es dann endlich komplett durchgezogen, der gute Preis hat mich motiviert :) Jedesmal also derselbe Act: df.eu Produkt gekündigt, Authcode auswendig lernen :D, rüber zu Netcup, registriert, Authcode eintippen, DNS Einstellungen machen, bäm. Hat 9 Mal perfekt geklappt und eine Domain "hängt". Und dummerweise halt genau die, die ich zum weiterarbeiten bräuchte. Und ich checke einfach nicht woran es liegt.


    Vorab: Alle Domainnamen und IP-Adressen sind anonymisiert (per sed, damit mir kein Fehler passiert).


    Fangen wir ganz easy an:


    OK, namespace4you, also wird noch von DF beantwortet. Soweit kann das ja am Cache liegen (ist erst 12 Stunden her). Mir fällt ein, die Domains habe ich ja schon gestern Abend umgezogen, so um 20 Uhr. Das ist also schon 26+ Stunden her...


    Wenn man den DF DNS direkt fragt:


    Und das irritiert mich. Der DNS von DF stellt sich also breitbeinig hin und sagt, nö, ich bin hier noch die SOA. Ist er aber doch nicht mehr, nachdem ich den weggezogen habe?


    Und die SOA hat ja 2560 Sekunden TTL, sollte dann nicht nach spätestens einer Stunde fehlendem SOA Eintrag der Cache leer sein und die Records nach oben propagiert werden? Das passiert aber nicht, die NIC Rootserver sagen immernoch, dass DF die Autorität ist (obwohl das ja Netcup sein sollte):


    Ich bin jetzt nicht so der DNS Checker muss ich zugeben. Interpretiere ich SOA einfach falsch? Und relevant ist der Tag TTL (86440 Sekunden) die der NIC Rootserver drin hat? Also einfach Tee trinken für die nächsten 12 Stunden und dann löst sich das Problem in Wohlgefallen aus?


    Danke euch schonmal für die Unterstützung!

  • VServer bootet nach Specte/Meltdown Patch nicht mehr: Kenel Panic

    Hi nochmal an alle! Vielen Dank für eure zahlreichen Ratschläge. Ich habe das Problem gefixed. Vorab: Es lag nicht an NetCup und auch nicht an dem gepatchten Host, das war nur ein unglücklicher zeitlicher Zufall. Der Support hatte also Recht, dass es mein Problem ist.


    Zunächst habe ich mal die Startnachrichten verlangsamt (Kernel commandline boot_delay=xyz) um zu sehen, wie weit er kommt. Zu meiner Überraschung war das initramfs zu dem Zeitpunkt, an dem er stirbt (so etwa nach 2.5 Sekunden) gerade am hochfahren. Also kam das, wie ja H6G vermutet hatte, doch als Fehlerursache in Betracht. Ich war ja ohnehin skeptisch, dass es am Debian Kern liegt (weil den *so* viele Leute nutzen und es sonst ja dutzende Bugreports geben müsste), aber das initramfs wird ja von den initramfs-tools selbst gebaut.


    Dann habe ich mir mal eines unter die Lupe genommen. Also binwalk, dann das offset für die Payload bestimmt, dann dd, gunzip und cpio. Dabei habe ich dann festgestellt, dass in /lib die klibc fehlt. Also nachgesehen, das Paket war installiert -- aber auf meinem Host hat die Datei /lib/klibc-k3La8MUnuzHQ0_kG8hokcGAC0PA.so gefehlt! Also apt-get install --reinstall klibc, und sie war wieder da. Dann update-initramfs -u und alles ging wieder.


    Warum die Datei plötzlich "weg" war, lässt sich jetzt nicht mehr sagen. Meine Vermutung ist aber, dass, nachdem die Datei gefehlt hatte, irgendwann die intiram-Skripte von einem Systemupdate (nicht notwendigerweise einem Kernelupdate) neugebaut wurden (das kann z.B. auch durch unattended-upgrades passieren, die ich als nightly cronjob habe). Damit war die Falle gestellt und hat nur auf einen Reboot gewartet. NetCup bootet dann meine Instanz durch und PLOPP, mein System startet nicht mehr.


    Nochmal vielen Dank an alle, die mitgeholfen haben. Das Brainstorming hat mich dann letztlich zur Korrekten Lösung geführt.

  • VServer bootet nach Specte/Meltdown Patch nicht mehr: Kenel Panic

    mlohr: Klaro, ist ja eine berechtigte Frage. Die Logs sagen 14.9.2017 16:30Z. Die dpkg-Logs sagen außerdem dass ich am 4.7.2017 auf linux-image-4.9.0-3-amd64:amd64 upgedatet habe. Das heißt, ich habe garantiert schonmal erfolgreich den 4.9.30-2+deb9u2 gebootet -- und der geht jetzt einfach nicht mehr.


    Heute habe ich es noch nicht probiert, ich frickel auch mal mit der Kernel Commandline rum, um den Fehler besser einzugrenzen. Außerdem wären natürlich auch die Zeilen vor dem Oooops interessant, evtl kann ich ihn mit einem vga=xyz Befehl dazu bewegen, mehr Zeilen anzuzeigen, damit man sieht, was da tatsächlich das Problem verursacht.


    Aber vielen Dank auf jeden Fall für die Hilfe, ich bin ja auch daran interessiert, die Root Cause zu finden (obwohl ich natürlich schon arg vermute, dass es was mit dem Host-Patch zu tun hat).


    Kraeutergarten: Ich weiß gar nicht, wie ich die Anzahl CPUs verändern kann, glaube ehrlichgesagt in meinem Tarif geht das gar nicht, kann das sein? Habe jedenfalls in der Management-Console nichts derartiges gefunden.

  • VServer bootet nach Specte/Meltdown Patch nicht mehr: Kenel Panic

    Aha und gerade habe ich auch eine Antwort auf meine Supportanfrage erhalten, die schon eher dreist ist:


    Code
    An Ihrem System, also Ihrer Installation, wurde durch das dringend nötige und sicher auch in Ihrem Sinne durchgeführte Update nichts verändert. Sie besitzen bei uns einen virtuellen Server. Wir stellen Ihnen die Laufzeitumgebung bereit. Zu individueller Software und zur Einrichtung können wir keinen Support geben. Nach Einrichtung haben wir keinen Zugriff mehr auf Ihr System. Die Einrichtung und Konfiguration Ihrer Dienste und Pflege obliegt Ihrer Verantwortung.

    Neee, ist klar. Die Kernel, die vorher einwandfrei gebootet hat und nach dem Patch des Hosts direkt sofort eine Panic auslöst hat ÜBERHAUPT nichts mit dem Patch zu tun. Hier gibt es nichts zu sehen, lösen Sie ihr Problem selbst!


    Veräppeln kann ich mich selber. Dass da ein direkter Zusammenhang besteht zwischen dem Host-Patch und meinem nicht mehr bootendem Guest ist offensichtlich. Den Zusammenhang zu leugnen ist völlig lächerlich.

  • VServer bootet nach Specte/Meltdown Patch nicht mehr: Kenel Panic

    Kraeutergarten: Ich hatte auf deinen Beitrag schon geantwortet, https://forum.netcup.de/admini…hr-kenel-panic/#post89097 :)


    H6G: Ja, habe das Initramfs in dem Rescue-System neu generiert. Also alle sogar, weil ich zu faul war die genaue Version rauszusuchen. Glaube aber, dass zu dem Zeitpunkt, wo er stirbt (keine 2 Sekunden nach dem Start) das Initramfs noch gar nicht in Benutzung ist (liegt zwar im Speicher, aber ist noch zu früh, glaube ich).


    Drücke dir jedenfalls für deine drei anderen Kisten auch die Daumen...!

  • VServer bootet nach Specte/Meltdown Patch nicht mehr: Kenel Panic

    Zitat von H6G
    Code
    root@zeta:/home/pzillmann# sha1sum /boot/vmlinuz-4.9.0-5-amd64 
65911c2e164b577ae0822936a60c0816e2434bae  /boot/vmlinuz-4.9.0-5-amd64

    Nur mal so als Idee.

    Ansonsten würde ich wirklich auf die Hardware tippen. Scheint aber bei einigen Probleme zu geben. Der Kernel läuft ber bei mir momentan auf 4/7 Maschinen ohne Probleme.

    Jupp, ist bei mir exakt derselbe:


    Code
    gula [/boot]: sha1sum vmlinuz-4.9.0-5-amd64 
65911c2e164b577ae0822936a60c0816e2434bae  vmlinuz-4.9.0-5-amd64


    Oben hatte ich nur die SHA256SUM gepostet und vergessen dazuzuschreiben, welcher Hash es ist.


    EDIT: Das wichtigste habe ich natürlich vergessen zu fragen... was ist mit den 3/7 restlichen Maschinen?


    Viele Grüße,

    Johannes

  • VServer bootet nach Specte/Meltdown Patch nicht mehr: Kenel Panic

    Kraeutergarten: Hmmm, wie lang müsste ich warten? Ich habe ein Dutzendmal Poweroff gemacht (weil wenn er mit der Kernel Panic hängt, geht Ctrl-Alt-Del nicht mehr, deswegen aus, teilweise Bootreihenfolge geändert, wieder an) -- aber wenn man da länger warten müsste hat das eventuell nicht gereicht? Maximal habe ich das System 1 Minute am Stück ausgehabt. Hat das Einfluss darauf, an welche Hardware auf meine virtuelle Hardware gebunden wird?

  • VServer bootet nach Specte/Meltdown Patch nicht mehr: Kenel Panic

    Florian: Ich hab's so gemacht: Erst Rescue System gebootet (grml). Also Bootreihenfolge auf Netzwerk, und Rescue-Image aktivieren. Dann per PXE ins Resuce Image booten. Megapraktisch, macht einen ssh auf, kannste dich direkt einloggen. Dann rootfs mounten:


    # mkdir x

    # mount /dev/vda1 x


    dev, proc und sys bindmounten:


    # mount --bind /dev x/dev

    # mount --bind /sys x/sys

    # mount --bind /proc x/proc


    Dann die Kernel kopieren


    # cp /boot/vmlinuz-4.9.0-1-grml-amd64 /boot/initrd.img-4.9.0-1-grml-amd64 x/boot


    Und die Module auch


    # cp -a /lib/modules/4.9.0-1-grml-amd64 x/lib/modules


    Dann chroot machen. Shell angeben, wenn bei dir auch keine zsh installiert ist (ich nutze Bash):


    # chroot x /bin/bash


    Jetzt biste in deinem System. Da machste dann noch


    # update-grub


    Und der sollte den grml-Kernel erkennen und der grub.cfg hinzufügen. Dann raus


    # Ctrl-D

    # umount x/dev

    # umount x/proc

    # umount x/sys

    # umount x

    # sync


    Dann neubooten und in Grub die grml-Kernel auswählen. Funktioniert bei mir...

  • VServer bootet nach Specte/Meltdown Patch nicht mehr: Kenel Panic

    Oliver: Danke, Bierchen ist gerade in der Gefriertruhe weil man natürlich genau in so einer Situation keines im Kühlschrank stehen hat ;) dd-dump zu ziehen kann bei meiner Leitung dauern, ich glaube ich werfe das aber trotzdem mal an. Kann nicht schaden.


    Kraeutergarten: Der Kernel ist schon der richtige (keine zurückgehaltenen Pakete) aktuell -- ich hatte nur den Paketnamen verwendet (linux-image-4.9.0-5-amd64), die Kernelversion ist aber natürlich 4.9.65-3+deb9u2:


    Code
    gula [~]: dpkg -l|grep linux-image                                                                   
ii  linux-image-4.14.0-2-amd64        4.14.7-1                       amd64        Linux 4.14 for 64-bit PCs
ii  linux-image-4.9.0-3-amd64         4.9.30-2+deb9u5                amd64        Linux 4.9 for 64-bit PCs
ii  linux-image-4.9.0-5-amd64         4.9.65-3+deb9u2                amd64        Linux 4.9 for 64-bit PCs
ii  linux-image-amd64                 4.9+80+deb9u3                  amd64        Linux for 64-bit PCs (meta-package)