Hallo tab,

sorry, ich habe den Beitrag hier komplett vergessen...

Wie sich herausgestellt hat ist die /etc/resolv.conf mit dem Attribut "immutable" versehen da es so (von NetCup Seite) offensichtlich gewollt ist... Entsprechend modifiziertes Image... Ich habe hierzu im Forum einige (teilweise schon ein wenig aeltere Beitraege) gefunden die das Thema in einem anderen Kontext angesprochen haben (deshalb ist es nicht so einfach zu finden).

Der NetCup Support auessert sich dazu nicht und verweist auf eigene Verantwortung da Root Server... blabla.. ich habe da auch nicht mehr erwartet... so be it..

Es gibt hierzu nun einige Loesungen die zum Ziel fuehren...

1. Quick & Dirty einfach das "immutable" Attribut der /etc/resolv.conf deaktivieren, die eigenen IPs eintragen und das "immutable" wieder setzen.
2. Es nachtraeglich mit netplan oder systemd vernuenftig nach konfigurieren... was aber fuer ungeuebte und evtl. schon produktiv laufende System kritisch werden kann.
3. Schon von Anfang an ein eigenes Image zum aufspielen auf den Server nutzen.

Danke dass Du nochmal nachgefasst hast.

Zitat von tab

Ich hatte das ja weiter obenschon mal geschrieben mit der /etc/systemd/resolved.conf. Es hatte bei dir aber wohl nichts bewirkt. Darüber läuft das aber normalerweise bei systemd-resolved. Und da stehen ja definitiv auch die netcup Nameserver drin. Hattest du damals nach der Änderung die VM oder wenigstens systemd-resolved mal neu gestartet? Das muss man natürlich, sonst bewirkt eine Änderung in der o.g. Datei nichts (jedenfalls bis zum nächsten Neustart).

Ja, natuerlich habe ich sowohl sytemd-resolved als auch (man weis ja nie) die Kiste neu gestartet. Beides hatte den selben outcome.

Zitat von RAD750

Backup ≠ Snapshot

Sehe ich auch so..

Anyway... nachdem ich dann Gestern noch die folgende Mail bekam

Zitat

vielen Dank für Ihre Geduld.

Wir konnten Das Problem von unserer SEite aus beheben. Sie können jetzt wie gewohnt Ihren Server starten und einen Snapshot erstellen.

habe ich nochmals versucht ein wenig nach zufassen um zu verstehen was passiert ist und was man macht/gemacht hat damit so etwas in Zukunft ausgeschlossen werden kann.

Hier die Info...

Zitat

die Ursache liegt außerhalb Ihres Einflussbereichs.

Wir fangen solche Vorkommen zukünftig automatisiert ab.

Ok... Notfall Support konnte zum Glueck Helfen....

Was da genau im Background schief lief werde ich berichten sobald sich die Technik auf das Ticket kommende Woche meldet.

Man sollte fuer solche Situation immer einen Notfall Plan haben falls es sich um was Produktives handelt...

Hallo Zusammen,

Ich hatte bisher mit den Snapshots hier keine Probleme... ein Offline Snapshot lief immer unterhalb einer Minute ab.

Der Snapshot den ich aber gerade angestossen habe ist seit mehr als 10 Minuten unterwegs....

Ich denke hier ist was faul....

Hatte das schon mal jemand von Euch?

Zitat von Valkyrie

Jemand mit mehr Ahnung von der systemd-Netplan Symbiose kann sich natürlich einklinken, aber so funktioniert es bei mir auf meiner letzten verbleibenden Ubuntu Maschine, auch 20.04. Da musst du nur die Netplan Konfiguration bearbeiten.

Die /var/run/systemd/resolve/resolv.conf hat sich daraufhin wie erwartet aktualisiert:

Code

nameserver 8.8.8.8
nameserver 1.1.1.1

Und die /etc/resolv.conf sieht weiterhin so aus:

Code

nameserver 127.0.0.53

Hmmmm... okay.. hatte gerade mal Zeit...

die yaml Datei entsprechend bearbeitet... dann netplan apply ... danach die var/run/systemd/resolve/resolv.conf gecheckt und die sagt dann folgendes

nameserver 46.38.225.230
nameserver 46.38.252.230
nameserver 2a03:4000:0:1::e1e6
# Too many DNS servers configured, the following entries may be ignored.
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888
nameserver 2001:4860:4860::8844

die Abfrage danach von resolvectl status gibt mir jedoch das gewohnte Bild

er:~# resolvectl status
Global
       LLMNR setting: no                  
MulticastDNS setting: no                  
  DNSOverTLS setting: no                  
      DNSSEC setting: no                  
    DNSSEC supported: no                  
  Current DNS Server: 46.38.225.230       
         DNS Servers: 46.38.225.230       
                      46.38.252.230       
                      2a03:4000:0:1::e1e6 
          DNSSEC NTA: 10.in-addr.arpa     
                      16.172.in-addr.arpa 
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa 
                      18.172.in-addr.arpa 
                      19.172.in-addr.arpa 
                      20.172.in-addr.arpa 
                      21.172.in-addr.arpa 
                      22.172.in-addr.arpa 
                      23.172.in-addr.arpa 
                      24.172.in-addr.arpa 
                      25.172.in-addr.arpa 
                      26.172.in-addr.arpa 

die /etc/resolv.conf ist nach wie vor immutable, das habe ich nicht geaendert...

der Inhalt dieser ist

nameserver 46.38.225.230
nameserver 46.38.252.230
nameserver 2a03:4000:0:1::e1e6

ich frage mich, wo die NC NS herkommen die in der var/run/systemd/resolve/resolv.conf stehen... es kann nicht von der yamel datei sein, denn die hat im Original keine NS eingetragen

network:
  version: 2
  ethernets:
    eth0:
      addresses:
        - 46.38.245.28/23
        - 2a03:4000:b:ba:78f8:caff:fe33:9c9b/64
      match:
        macaddress: 7a:f8:ca:33:9c:9b
      routes:
        - to: 0.0.0.0/0
          via: 46.38.244.1
        - on-link: true
          to: ::/0
          via: fe80::1

nachdem ich die original yamel wieder hergestellt habe (netplan apply) schaut die var/run/systemd/resolve/resolv.conf

wieder so aus

# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 46.38.225.230
nameserver 46.38.252.230
nameserver 2a03:4000:0:1::e1e6

Ich komme nicht drauf... und will aber auch nicht zuviel am System rumschrauben da ich das Gefuehl habe es gibt hier eine einfach Erklaerung und auch Abhilfe... ich bin nur zu Blind diese zu sehen...

Zitat von m_ueberall

Ich vermute, es handelt sich um ein von Netcup gestelltes Installationsabbild? Denn bei Installationen von der Upstream-Installations-DVD oder normalen Updates wird das "immutable"-Attribut standardmäßig nicht gesetzt (zumindest habe ich das seit Ubuntu 12.04 nie selbst beobachten können). Wenn dem so ist, würde ich einmal beim Support nachfragen, ob/warum man hier eine Konfigurationsänderung vorgenommen hat, welche das Standardverhalten der einschlägigen Hilfswerkzeuge beeinflusst (denn laut Definition sollte das automatisierte "Anfassen" von als unveränderbar markierten Dateien niemals funktionieren). Normalerweise(TM) will man durch ein entsprechendes Attribut ja gerade jegliche nicht-explizite, nicht-manuelle Änderung ausschließen.

(Gerade bei der Ferndiagnose von Fällen wie "Nach dem Reboot/einer gewissen Zeit funktioniert die DNS-Auflösung nicht mehr" kann man damit vor Abschluss einer längeren Analyse schnell (temporäre) Abhilfe schaffen, aber das ist eher mit einem Griff nach einer Brechstange zu vergleichen, weswegen man dann in der entsprechenden Datei nach Möglichkeit auch einen Kommentar/eine Begründung hinterlassen sollte. )

Hallo m_ueberall,

beim Support habe ich schon nachgefragt, die fuehlen sich nicht zustaendig

Ich sehe das wie Du... leider ist in der /etc/resolv.conf kein entsprechender Text...

Mein Ansatz ist jetzt folgender... ich werde (nach snapshot und backups) am Sonntag mal die yaml Datei mit den nameserver infos befuellen.... danach einen netplan apply und checken was fuer IPs dann aktiv sind (resolvectl status) sollten dann immer noch die von NC drin sein werde ich der resolv.conf mal das attribut i wegnehmen und nochmals versuchen....

Wir werden sehen... es laeuft ja eigentlich alles soweit so gut, jedoch was ich so alles ueber die NC NS bisher gelesen und gehoert habe ... besser umstellen...

Danke fuer Deinen Input... ich werde berichten sobald ich den Knoten geloest habe

Zitat von H6G

Es sieht nicht nach einem systemd-resolved Problem aus.

Hilft es, wenn du cloud-init temporär deaktivierst und dann einen Reboot machst?

Externer Inhalt gist.github.com

Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.

Alle externen Inhalte anzeigen

Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

Ich kann mich an das Problem bei Ubuntu 18 erinnern, weiß aber nicht mehr, was der Auslöser war.

Auf jeden Fall deaktiviere ich immer cloud-init und systemd-resolved.

Alles anzeigen

Hallo H6G....

interessanter Ansatz... werde ich mal probieren... leider habe ich den RS schon produktiv im Einsatz... das werde ich dann mal an einem Sonntag machen (offline Snapshot und Backups first of course) .... ich melde mich wieder wenn es geklappt hat... oder auch nicht...

Zitat von tab

Also ich glaube in den netcup Images ist das kein echtes cloud-init Problem.

Da stehen wohl nur die netcup Resolver in der /etc/systemd/resolved.conf

Es dort zu ändern und den systemd-resolved Dienst neu zu starten wird vermutlich auch reichen.

Edit: Hmm, wahrscheinlich doch nicht, duie Ausgabe von resolvectl sieht völlig anders aus als in meinem netcup Ubuntu-Image. Und auch die /etc/resolv.conf ist bei mir ein Symlink und war es auch von Anfang an, soweit ich mich erinnern kann. Den habe ich zwar mittlerweile mal geändert, als ich Unbound lokal installiert habe, aber "immutable" ist mir jedenfalls nicht im Gedächtnis.

Hallo tab...

ja, das dachte ich auch zu Beginn... hatte jedoch null Auswirkung.

Nur zum vergleichen, wie sieht denn Deine resolvectl Ausgabe aus?

Ich habe die Vermutung dass ich die resolv.conf einfach mal leoschen kann und dann den Symlink neu Anlege dass es dann funktioniert...

Da ich den RS leider schon produktiv benutze werde ich das mal an einem Sonntag durchspielen (offline Snapshot und Backups first of course) und berichten...

Seltsam ist das ganze allemal...

Zitat von Ecki

was gibt resolvectl.status denn aus ?

Wenn es immer noch die Netcup Server sind, ist irgendeine Cloud Config noch aktiv ?

resolvectl status wirft das aus

xxxx@server:~# resolvectl status
Global
       LLMNR setting: no                  
MulticastDNS setting: no                  
  DNSOverTLS setting: no                  
      DNSSEC setting: no                  
    DNSSEC supported: no                  
  Current DNS Server: 46.38.225.230       
         DNS Servers: 46.38.225.230       
                      46.38.252.230       
                      2a03:4000:0:1::e1e6 
          DNSSEC NTA: 10.in-addr.arpa     
                      16.172.in-addr.arpa 
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa 
                      18.172.in-addr.arpa 
                      19.172.in-addr.arpa 
                      20.172.in-addr.arpa 
                      21.172.in-addr.arpa 
                      22.172.in-addr.arpa 
                      23.172.in-addr.arpa 
                      24.172.in-addr.arpa 
                      25.172.in-addr.arpa 
                      26.172.in-addr.arpa 

Zitat von Valkyrie

Jemand mit mehr Ahnung von der systemd-Netplan Symbiose kann sich natürlich einklinken, aber so funktioniert es bei mir auf meiner letzten verbleibenden Ubuntu Maschine, auch 20.04. Da musst du nur die Netplan Konfiguration bearbeiten.

.......

EDIT: Hast du das ganze per eigener ISO oder Netcup Image aufgesetzt? Im letzteren ist gegebenenfalls noch Cloudconfig Gedöns drin, was dir dazwischen funkt.

Alles anzeigen

Genau, NetCup Image und das Cloud Gedoens ist das was mir hier ein wenig Kopfzerbrechen verursacht...

Jedoch ist es bei mir eine 50-cloud-init.yaml (weil cloud) in der erst mal nur folgendes steht (original IPs etc abgeaendert)

network:
    version: 2
    ethernets:
        eth0:
            addresses:
            - xx.xx.245.xx/23
            - xxxx:xxxx:b:ba:xxxx:caff:xxxx:9c9b/64
            match:
                macaddress: 7a:xx:xx:xx:xx:9b
            routes:
            -   to: 0.0.0.0/0
                via: xx.xx.244.1
            -   on-link: true
                to: ::/0
                via: fe80::1

fuege ich dann die gewuenschten NS hinzu, was kein Problem darstellt...

network:
    version: 2
    ethernets:
        eth0:
            addresses:
            - xx.xx.245.xx/23
            - xxxx:xxxx:b:ba:xxxx:caff:xxxx:9c9b/64
            match:
                macaddress: 7a:xx:xx:xx:xx:9b
            routes:
            -   to: 0.0.0.0/0
                via: xx.xx.244.1
            -   on-link: true
                to: ::/0
                via: fe80::1
            nameservers:
                addresses:
                - 8.8.8.8
                - 4.4.4.4
                - 2001:4860:4860::8888

ist der output danach in der /var/run/systemd/resolve/resolv.conf .... die Alten, sowie die Neuen hinzugefuegten

nameserver 46.38.225.230
nameserver 46.38.252.230
nameserver 2a03:4000:0:1::e1e6

nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888

Die /etc/resolv.conf ist aber nach wie vor immutable mit dem Inhalt

nameserver 46.38.225.230
nameserver 46.38.252.230
nameserver 2a03:4000:0:1::e1e6

Die /etc/resolv.conf ist kein Symlink sondern statisch wie die Abfragen zeigen

xxxx@server:~# ls -al /etc/resolv.conf
-rw-r--r-- 1 root root 81 Aug  7 20:33 /etc/resolv.conf
xxxx@server:~# readlink -f /etc/resolv.conf
/etc/resolv.conf
xxxx@server:~# realpath /etc/resolv.conf
/etc/resolv.conf

Zitat von frank_m

Du musst die DNS Server natürlich da anpassen, wo sich auch darum gekümmert wird. Das kann systemd sein, es gibt aber auch noch andere Tools, die das übernehmen können. Du bist der Sysadmin, du solltest es am besten wissen.

Bist du sicher, dass ein VPS das richtige für dich ist? Die Frage lässt erahnen, dass dir die Grundlagen fehlen. Wie willst du den Server denn absichern gegen Attacken und Hacking? Geh davon aus, dass im Moment auf deinen öffentlichen IP Adressen pro Sekunde ein Angriff erfolgt.

Dachte mir schon das solch ein Kommentar auftaucht anstatt zu lesen und evtl. zielfuehrende Infos zu geben.

Mach Dir mal ueber meine Grundlagen keine Gedanken , ich weis sehr wohl wie ich einen Server absichere und was da so abgeht von aussen... Trotzdem Danke fuer Dienen Kommentar.

Zitat von Valkyrie

Setzt Ubuntu nicht schon länger auf Netplan?

Wenn du mal unter /etc/netplan schaust, müsste da eine .yaml Datei sein. Die kannst du entsprechend den Docs abändern.

Dann ein netplan generate und netplan apply und schon passt es.

Das ist klar... das Szenario ist das das zwar zieht aber die NC eigenen DNS immer noch vor den Alternativen ziehen... und das kommt wohl von der

immutable resolv.conf

Hallo Zusammen,

bevor ich mich and die Abaenderung der DNS Resolver mache kann mir hier vielleicht jemand einen Tip geben.

Auf einer frischen Ubuntu 20.04 LTS installation (RS 4000 G9.5) ist die /etc/resolv.conf mit dem Attribut "immutable" versehen. Weshalb?

Die Datei ist auch kein Symlink wie es eigenlich sein sollte?

Ich sehe dass offensichtlich systemd fuer die Namensaufloesung zustaendig ist ... denn unter /var/run/systemd/resolve/resolv.conf sind genau die NC NS angegeben welche in der /etc/resolv.conf zementiert sind.
Hat von Euch schon mal jemand unter Ubuntu 20.04 LTS die DNS Server von denen von NC auf oeffentliche (Google etc.) umgeaemdert?

Wenn ja, worauf ist hier zu achten dass es auch update/upgrade sicher ist?

Danke schon mal fuer zielfuehrende Hinweise.