Um zum Abschluss zu kommen..
Der Support hat sich gemeldet, den Fehler erkannt und gebannt.
Was auch immer es war... danke an alle und auch an die "Ich bin ein Toller und Du solltest lernen Dich besser Auszudruecken denn sonst verstehe ich Dein Problem nicht" 
Werden wohl die netcup DNS-Server sein, da haben wir dann wohl auch gleich das Problem erkannt
Ich benutze nicht die NS von Netcup...
Wenn das mit dem PTR-Record nochmals vorkommt, melde es dem Support! Es gab da in der Vergangenheit einige Bugs, bei denen der rDNS-Eintrag von selbst resettet wurde.
Mein letzter Stand von vor einigen Tagen ist, dass der neueste/letzte Bug nun endgültig behoben sein sollte. Ist mir kürzlich nämlich auch wieder passiert.
Genau das habe ich gemacht....
Beides ist für den Serverbetrieb unktitisch. (Der PTR allenfalls für Mailserver)
Es gibt gelegentlich (sehr selten) solche automatische resets auf die default-Werte.
Einfach wieder ändern und gut ist's
Genau das habe ich gemacht... 
Der Hostname im SCP spielt eigentlich keine Rolle.
Du meinst den PTR Record, keine Route
Dass dieser keine Rolle spielt ist ja ok, jedoch ist es trotzdem nicht ok dass der sich einfach selbst abaendert...
Sorry fuer meine nicht so gezielte Ausdrucksweise... PTR dann eben... ist aber auch nicht ok dass da auf einmal was komplett falsches drin steht...
Ich rede hiervon:
Macht es das ein wenig klarer fuer Dich?
Edit:
Im Bild 1 wurde der alte default Hostname von Netcup eingetragen/angezeigt und die IPv6 Route sollte eigentlich auf den selben rDNS wie die IPv4 zeigen...
Ich habe beides nun wieder hergestellt... aber es ist trotzdem seltsam weshalb hier falsche Werte standen. Zumal diese von mir nicht geaendert wurden
Hallo Zusammen,
ich bin gerade ein wenig alarmiert... ich wollte soeben einen Snapshot von einem meiner drei Server fahren und sehe mit Erschrecken dass fuer diesen einen Server ein komplett falscher Hostname eingetragen ist (der uralte default von Netcup) und in der Network Anzeige ein komplett falscher und kryptischer Netzwerk Route eingetragen wurde. Die beiden anderen Server sind unangetastet.
Ich habe das nun wieder richtig eingetragen, aber sehr seltsam/alarmierend ist es doch?
Der Support ist informiert, aber wir wissen ja alle was davon im Moment zu halten ist.
Hatte das von Euch schon mal jemand?
Gruss Fezzi
Hallo Lars,
vielen Dank fuer Deine Rueckmeldung in dieser Angelegenheit.
Wir arbeiten aktuell sehr aktiv am SCP – sowohl an neuen Features, einige hast du bestimmt auch schon gesehen – als auch an internen Verbesserungen, die für Kunden vielleicht nicht direkt ersichtlich sind, aber die Zuverlässigkeit des SCP in verschiedenen Bereichen erhöhen und somit auch Vorfälle wie diesen unwahrscheinlicher machen oder idealerweise ganz verhindern.
Na ja, neue Features beheben nicht das Problem das vorhandene Features immer wieder mal, fuer den ein oder anderen, Probleme verursachen.
Zu den von dir beschriebenen Themen ist bei unserem SCP-Team ein entsprechendes Bug-Ticket offen.
Das macht Hoffnung.... habe ich doch noch vor 14 Tagen in einer Support Mail lesen muessen dass hier kein Ticket besteht!
Da du zwei Störungen dieser Art mit Abstand von mehreren Monaten erlebt hast, gehe ich davon aus, dass du recht regen Gebrauch von der Snapshot-Funktionalität machst und daher auch weißt, dass diese Vorfälle trotz allem eine Seltenheit sind.
Ja leider musste ich Feststellen dass das ( und wir reden hier von einem offline Snapshot) immer ein Gluecksspiel ist und immer wenn ich es dann doch mal brauche/benutze (denn das ist so selten wie die Vorfaelle angeblich sind) weis ich nie ob ich jetzt gleich wieder zum Telefon greifen muss und hoffentlich jemand beim Notfall Support ran geht und das Problem zeitnah beheben kann.
Wie auch immer, ich hoffe das das NetCup in den Griff bekommt, denn so wie es im Moment ist, ist es fuer Leute die Eure Server produktiv nutzen, nicht wirklich benutzbar, da man immer damit rechnen muss dass man "im Falle dass" auf den Notfall Support angewiesen ist.
Vielen Dank nochmal fuer Deine Rueckmeldung und es waere schoen wenn wir in der Sache auf dem laufenden gehalten werden.
Komplette Sicherheit ist sowieso nie gegeben.
Darum geht es ja auch nicht, sondern um funktionierende Snapshots...
Die Snapshots selbst benutze ich z.B. nur als Moment Backup bei Wartungsarbeiten am Live System.
Quasi, Snapshot erstellen-> Full System Upgrade ausführen -> das wichtigste Testen -> Snapshot nach 2 Tagen wieder löschen.
Da ich ja nur ein kleines Wartungsfenster von 3 Stunden Nachts habe wäre es natürlich blöd wenn der Snapshot hängt.
Bisher ist das noch nicht passiert.
Die normalen/reinen Daten Backups speichere so oft inkrementell weg, das es um längen besser und schneller als ein Snapshot ist.
Genau so ist es... einer von wenigen Gruenden warum ein Snapshot funktionieren sollte wenn er schon beworben wird... und entsprechend getaktete Backups (taeglich, stuendlich, woechentlich, etc) auf eine externe Quelle sind sowieso Pflicht.
Aber dass ein Snapshot immer wieder mal haengt und man dann selbst gar nichts machen kann, ausser hoffen dass die Notbereitschaft erreichbar ist und entsprechende kompetent ist (ich hatte auch schon anderes erlebt) dass ist eben nicht gut und deshalb waere es schon mal angebracht andere Aussagen als die von mir Zitierte von seitens NetCup zu bekommen.
Ich weis ja nicht ob hier jemand vom NetCup Tema mit liest... wenn ja, macht doch mal eine klare Ansage diesbezueglich, ich und bestimmt auch andre wuerden sich freuen.
Da doch jeder wissen sollte, dass lokal auf demselben Host abgelegte Snapshots nur so lange sicher sind, wie auch dessen Plattensystem nicht komplett crasht, kann ich mir nicht wirklich vorstellen, dass dir der Support bezüglich "natürlich sind die Snapshots sicher" so geantwortet hat.
Hier die ganze Mail fuer Dich und andere... 
Bxxx Axxx commented:
Guten Tag Herr Fexxi,
natürlich sind die Snapshots sicher. 2 Incidents dieser Art innerhalb fast einem Jahr sind hier nicht referenzfähig.
Mit freundlichen Grüßen,
netcup Team
Nichts... Ich habe das im Zusammenhang mit meinem Posting zum Snapshot gelesen.... ich suche keine Backup Loesung, die habe ich schon, aber ich moechte eine bessere Loesung fuer eine haengende Maschine wenn diese wg. eines offline Snapshots haengt und dazu ist NetCup bisher offensichtlich nicht gewillt eine Loesung anzubieten... obwohl es vielen hier schon passiert ist...
Letzte Aussage des gut informierten Supports dazu:
natürlich sind die Snapshots sicher. 2 Incidents dieser Art innerhalb fast einem Jahr sind hier nicht referenzfähig.
In dem Zusammenhang auch mal veeam for Linux anschauen. Ist für die private Nutzung kostenlos. Damit lässt sich sehr einfach ein Backup vom kompletten Server erstellen.
Ein Snapshot ist kein Backup!
Ich frage mich gerade was dann die Snapshot Funktion noch fuer einen Wert hat?
Speziell wenn dieser auf einem Produktiv System benutzt wird... 9 Stunden Ausfall bis der Prozess gekillt wird? Da benutzt man das besser nicht!
Dass es kein Backup ist, ist ja klar und dass sollte jedem bewusst sein aber wenn es beworben wird und als funktionierendes Feature bereit steht dann sollte es auch funktionieren. Es gibt Einsatz Zwecke wo ein solcher Snapshot sehr hilfreich ist/sein kann.
Ich hatte am 28.06 wieder so ein Problem
und ohne Notfall Support waere ich aufgeschmissen gewesen. Das i-Tuepfelchen ist nun, dass sich seit dem weder die Technik noch der Support bei mir gemeldet haben und erst nach Nachfrage die Kommunikation aufgenommen haben. Jetzt findet man weder das Ticket vom Oktober 2023 noch das vom 28.06 (welches der Notfall Techniker eroeffnet hat) 
Anyway, um es klar zu sagen, die Snapshot Funktion ist im Moment fuer Produktiv System nicht nutzbar da unzuverlaessig.
Sollte ich, wieder erwarten, zuverlaessige Informationen vom Support bekommen werde ich diese hier posten.
In diesem Sinne... die Hoffnung stirbt zuletzt...
Hallo Zusammen und im speziellen an den NetCup Support!
Erst mal Danke an den Techniker der mir frueh Morgens am 28.06 aus der Klemme geholfen hat und das ganze wieder zum laufen gebracht hat.
Was ist passiert.... zum wiederholten Male ist es zu einem Loop bei der Snapshot Erstellung auf einem RS Server gekommen und wenn das passiert, dann ist das ohne Zutun der NetCup Technik nicht moeglich den Server wieder zu starten. Die Task haengt dann offensichtlich und wird nicht ueberwacht und evtl. nach "Leerlauf X" einfach gekillt.
Dies war nicht das erste Mal und beim letzten Vorfall im Oktober 2023 wurde mir versichert dass das Problem behoben ist.
die Ursache liegt außerhalb Ihres Einflussbereichs.
Wir fangen solche Vorkommen zukünftig automatisiert ab.
Ist es offenbar nicht!
Und nein, es hat nichts mit einer speziellen Konfiguration von meiner Seite zu tun was das evtl. ausloest. Wir sprechen von einem offline Snapshot.
Wieder musste ich den Notfall Support anrufen, welcher bei meinem dritten Anruf dann doch das Telefon abgehoben hat und mich nicht an den Anrufbeantworter durch stellen lies.
Ich sitze in Thailand und der Anruf verursacht kosten... welche ich gerne auf meine Kappe nehme wenn denn dann auch sofort jemand erreichbar ist.
Wenn nicht, erreichen Sie einen unserer Techniker rund um die Uhr direkt über diese Telefonnummer: +49 721 754 0 755 5
Der Techniker war sehr freundlich und hat mir versichert dass er das entsprechen Eskaliert und ich zeitnah Informiert werde was da nun wieder los war....
Wir alle wissen dass es mit dem Support und dessen Kommunikationsfähigkeit bei NetCup ziemlich im argen liegt... aber ist es wirklich zu viel verlangt nach 7 Tagen zumindest mal eine Mail mit einer Ticket Nummer zu bekommen?
Gerne wuerde ich wieder mal einen offline Snapshot meines RS machen aber solange es von Seiten NetCup keine Info gibt ob es wieder funktioniert lasse ich das lieber.
Hallo NetCup Support, was gibt es nun hierzu zu sagen?
Warum haengt ein Offline Snapshot auf Euren Maschinen?
Was gibt es hier fuer Loesungsansaetze?
Oder ist die Funktion nur PR Schall und Rauch?
Wenn letzteres, dann ist ja gut.. aber dann kommuniziert klar, das das kein funktionierendes Feature ist.
Und fuer die die jetzt denken dass ich die Funktion als Backup Funktion benutzen wuerde, nein, dem ist nicht so, denn ein Snapshot ist kein Backup aber ein hilfreiches Feature welches, wenn es schon beworben wird, auch reibungslos funktionieren sollte. It's not Rocket Science....
In diesem Sinne, ich freue mich hoffentlich bald von den zustaendigen Verantwortlichen zu hoeren.
LG
Fezzi
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...
Danke dass Du nochmal nachgefasst hast.
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.
Backup ≠ Snapshot
Sehe ich auch so..
Anyway... nachdem ich dann Gestern noch die folgende Mail bekam
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...
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?
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:
Codenameserver 8.8.8.8 nameserver 1.1.1.1Und die /etc/resolv.conf sieht weiterhin so aus:
Codenameserver 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::8844die 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::e1e6ich 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::1nachdem 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::e1e6Ich 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...
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
