Beiträge von m_ueberall

    "Interessante" Bepreisung:

    Code
    '20210404 - www_netcup_de - Aktionsangebot_ VPS Ostern L OST21 - 2 vCores, 8GB RAM, 160GB SSD, 4,56EUR pro Monat.pdf'
    '20210404 - www_netcup_de - Aktionsangebot_ VPS Ostern M OST21 - 2 vCores, 4GB RAM, 40GB SSD, 4,32EUR pro Monat.pdf'
    '20210404 - www_netcup_de - Aktionsangebot_ VPS Ostern S OST21 - 1 vCore, 2GB RAM, 20GB SSD, 1,84EUR pro Monat.pdf'

    Der VPS Ostern M hat eine stündliche Abrechnung, muss aber 12 Monate im Voraus bezahlt werden.

    Danke für die Korrektur (das Obige gilt auch für den "VPS Ostern S")… Nachdem ich nun zum wiederholten Male beim Ablesen in der Zeile verrutscht bin, ist es Zeit, ins Bett zu gehen, glaube ich. :P

    Fürs Protokoll: Es gibt derzeit wohl 20 verschiedene Ostereier-Fundstellen, von welchen fünf auf eine "Zusätzliche IPv4 OST21" verweisen. Außer beim "Funny Bunny" (sechs Monate) betragen die VPS-/RS-Mindestvertragslaufzeiten leider wieder durchweg 12 Monate. Da ich den Suchspaß nicht verderben will, nenne ich an dieser Stelle keine weiteren Details. ;)

    [...] die /etc/network/interfaces.d/50-cloud-init.cfg sieht jetzt so aus:

    mhm - ich gebs für heut erst mal auf...vielleicht bringt ja die Zeit doch noch was...
    Danke erst mal an alle, die versucht haben zu helfen.

    Noch zwei kurze Anmerkungen:

    1. Die IPv6-Adresse in der Zeile "dns-nameservers" sollte als separater Eintrag unter die Zeile mit "address 2a03:4000:..."
    2. Auch die Namensgebung der Datei "50-cloud-init.cfg" sowie das Vorhandensein mehrerer Dateien mit dem Namen "*cloud-config*" lässt darauf schließen, dass Cloud-init den Dateiinhalt modifizieren könnte (was ich nicht direkt überprüfen kann, da ich das genannte Netcup-Debian-10-Abbild nicht verwende); im Zweifelsfall sollte man die vorgenannte Datei "50-cloud-init.cfg" umbenennen (um zu kennzeichnen, dass sie manuell erstellt wurde) und Cloud-init anweisen, die Netzwerkkonfiguration in Zukunft (=nach einem Reboot oder expliziten Anstoß der Neuerstellung von Konfigurationsdateien) nicht mehr anzufassen; siehe gelb markierte Anmerkung hier (manuell etwas nach oben scrollen).

    Distribution ist Debian 10, installiert aus dem Debian 10 minimal Image aus dem SCP

    […]

    Die Datei / den Ordner /etc/netplan/50-cloud-init.yaml gibt es auf dem Server nicht - eine Suche danach auf dem Server war erfolglos. […]
    Was da per find / -name '*cloud-init*' gefunden wird ist für mich nicht ganz klar - das ist ne ziemliche "Unmenge" auch in Dirs, die was mit dem Systemstart zu tun haben.
    Wenn es mit der festgeschriebenen resolv.conf neu gestartet wird, werden überhaupt keine Namen intern mehr aufgelöst […]

    Mir ist vollkommen unklar, woher diese offensichtlich fehlerhaften doppelten Nameservereintragungen 46.38.225.230 in der resolv.conf kommen - und das auf allen 5 gemieteten Serverinstanzen...
    Wenn die dann in der resolv.conf manuell gelöscht werden, passt es, dig zeigt die richtigen Werte an. Also ist definitv dieser ominöse 46.38.225.230 fest irgendwo konfigurierte DNS-Server ursächlich - wo immer der auch da eingebaut wird...

    […]

    Zunächst verwundert mich, dass eine explizit geschützte Datei resolv.conf mit einer einzigen Zeile ("nameserver 1.1.1.1" o. ä.) dazu führt, dass keine Auflösung mehr erfolgt. Das Ergebnis sollte identisch zu dem sein, was man mit dig bei expliziter Vorgabe des DNS-Servers erhält – kann es sein, dass bei dig +short abc-def.de @1.1.1.1 kein Ergebnis zurückgeliefert wird (und auch nicht mit 8.8.8.8, 9.9.9.9)? Letzteres würde in der Regel auf Probleme mit den DNS-Einträgen für die Domäne bei Netcup zeigen. (Man kann alternativ auch weltweit DNS-Server abfragen, siehe https://www.whatsmydns.net/ – hier kann es immer wieder zu wenigen Fehlern kommen, aber wenn gar nichts gefunden wird, liegt dies fast eindeutig daran, dass die DNS-Einträge der eigenen Domäne fehlerhaft sind.) Wird das erwartete Ergebnis gefunden, würde ich vermuten, dass beim ersten Test ggf. ein Schreibfehler in resolv.conf vorlag – denn das System sollte beim Booten zwar erfolglos versuchen, resolv.conf erneut zu schreiben, dies sollte bei korrektem Inhalt jedoch keine merkliche Verzögerung mit sich bringen und insbesondere nicht dazu führen, dass gar keine Auflösung von Domänennamen mehr funktioniert (letzteres Problem verlangsamt den Bootvorgang allerdings erheblich!)

    Es ist logisch, dass die vorgegebenen DNS-Serveradressen 46.38.225.230 bzw. 46.38.252.230 irgendwo herkommen müssen; entweder, sie finden sich explizit in einer Konfigurationsdatei (sollte sich finden mittels grep -r 46.38.252.230 /etc) oder – wahrscheinlicher – sie werden via DHCP erfragt. Informationen dazu sollten sich in der Datei /etc/network/interfaces finden.

    Für die Beantwortung der Frage wäre es hilfreich, zu wissen, welche Distribution in welcher Version über welchen Weg installiert wurde. Meine Vermutung wäre, dass sich die erforderlichen Einstellungen im Verzeichnis /etc/netplan/ (und dort ggf. in der Datei 50-cloud-init.yaml) finden. Wenn dort standardmäßig alles via dhcp(4/6) übernommen wird, lässt sich das ändern. Gegebenenfalls sieht die Datei ähnlich wie folgt aus?

    Code: /etc/netplan/50-cloud-init.yaml
    # This file is generated from information provided by the datasource.  Changes
    # to it will not persist across an instance reboot.  To disable cloud-init's
    # network configuration capabilities, write a file
    # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
    # network: {config: disabled}
    network:
        version: 2
        ethernets:
            eth0:
                dhcp4: true

    Wie man die Datei entsprechend anpasst, findet sich unter anderem hier oder ausführlicher hier.

    Fürs Protokoll: Es gibt aber eine andere Möglichkeit, die DNS-Auflösung temporär (lies: wirklich nur als Workaround gedacht!) blitzschnell "bootfest" zu korrigieren: Den Inhalt von /etc/resolv.conf ansehen (das ist meistens ein symbolischer Link, der auf eine andere Datei verweist), die Datei (also den Link) löschen, neu erstellen, und als Administrator vor Überschreibung schützen:

    Code
    #cat /etc/resolv.conf    #Ergebnis kopieren
    #rm -f /etc/resolv.conf
    #$EDITOR /etc/resolv.conf    #Texteditor der Wahl verwenden, falls $EDITOR nicht definiert ist
    ####An dieser Stelle den alten Inhalt einfügen und die Zeilen mit "nameserver" ersetzen durch "nameserver 1.1.1.1"
    ####(Statt 1.1.1.1 geht auch 8.8.8.8 oder 9.9.9.9; diese können theoretisch auch nebeneinander verwendet werden)
    #chattr +i /etc/resolv.conf    #"immutable"-Bit; kein Programm wird die Datei abändern können, bis es wieder gelöscht wird
    ####(Letzteres geht mit "chattr -i ...")

    Ob wir zu Ostern schon einen Vorgeschmack auf die nächste G10-Servergeneration bekommen? Ich hoffe ja, dass diese in Zukunft auch ein paar Xeon-Platinum-83252S-basierte RS umfassen wird, welche sich von AMD-angebtriebenen Counterparts durch den Basistakt abgrenzen können (denn nicht alles lässt sich immer optimal parallelisieren und ob man immer dann vom Turbo-Modus profitiert, wenn man sich eine CPU mit x anderen Kunden teilt, wage ich bei meinem Karma auch zu bezweifeln)… Aber schau'n wir 'mal.

    Verstehe ich das richtig: Wenn man einen neuen DNS Eintrag mit blabla als "A" Eintrag macht und dann eine z.B. myfritz Adresse: jhjkh6t5675675hjhj.myfritz.net:0815 (nur ein Beispiel) angibt, dann wird blabla.meinedomain.de an die Myfritz-Adresse weitergeleitet?

    Und bei CNAME Einträgen kann ich keine Portangabe in der zu weiterleitenden Adresse angeben?

    Fast (DNS-A(AAA)-Einträge akzeptieren keine Portangaben). Ja, dort auch nicht.

    Da ihr offenbar noch nicht sicher seid was darauf alles laufen muss, würde ich an eurer Stelle zunächst auf einen VPS setzen ohne Mindestlaufzeit. Ist zwar teurer als 12 Monate Mindestlaufzeit, aber eben auch flexibler.

    cw_pn : Die Möglichkeit, die Mindestvertragslaufzeit bei einem RS (Root-Server) gegen Aufpreis auf bis zu einen Monat zu reduzieren, gibt es natürlich auch; in Verbindung mit einem RS ist ferner das Buchen des "Root-Server Service Level A+" möglich, was – selbstverständlich nur neben dem eigenverantwortlichen Betreiben mehrerer Server – Ausfallzeiten verkürzen kann.

    die Geschichte mit dem 'gestrandeten' Frachter im Suez-Kanal find ich schon bedenklich;

    wenn man bedenkt von welchem 'Single-point-of-failures' wir uns im Real Life abhängig machen

    Genau! https://twitter.com/supermathskid/status/1375565658667253766 (NSFW)

    Das wär für die Schiffe aber keine leichte Übung. Das wär ja fast Kinski-like à la Fitzcarraldo.

    Genau! https://twitter.com/Atemkristall/status/1375574789939720193