Ubuntu-Forum & Kubuntu-Forum | www.Ubuntu-Forum.de

Ich betreibe ein lokales Netz mit der TLD .netz (.net ist öffentlich und vergeben und .local ist auch für irgendwas reserviert). Den dauernd anwesenden Rechnern habe ich feste IP-Adressen (V4) verpaßt und gelegentliche Gäste werden über DHCP bedient. Sämtliche bekannten Rechner werden auf einem kleinen Server in der Datei /etc/hosts verwaltet. Neben der IP-Adresse steht dort auch ein kurzer leicht merkbarer Name in Groß- und Kleinschreibung, was für Aktionen auf der Kommandozeile sehr bequem ist. Einige Server haben nämlich keine graphische Oberfläche (wie KDE, XFCE, GNOME usw.) installiert.

Bis zum jüngsten Upgrade meines Produktivrechners auf Xubuntu 18.04 hat das über viele Jahre allerbestens funktioniert. Ab diesem Moment traten Fehler wie der folgende auf:

Zitat

ssh: Could not resolve hostname activy: Temporary failure in name resolution

Ziemlich schnell fand ich heraus, daß keineswegs die gesamte Namensauflösung kaputt ist, sondern nur die kurzen Aliase. Wenn ich statt ping activy oder ping ACTIVY beispielsweise ping activy.netz eingebe, funktioniert es. Damit entpuppten sich auch viele weiter Fehler nach dem Upgrade als Folgefehler dieses einen. Apache-Ausgaben auf dem Archivserver (der noch mit Debian 8 läuft) funktionieren mit dem FQDN (also http://2I1800.netz/seitenname/ statt nur http://2I1800/seitenname/). NFSv4 funktioniert bei Verlängerung des Servernamens in /etc/fstab usw.).
Was mit diesem Trick nicht funktioniert sind NTP und die Adressen von virtuellen Apache-Servern auf dem Archiv-Rechner (2I1800).

Weil es so verwirrend ist, nochmals zur Klarstellung: an den beiden Servern ACTIVY (Gateway, DHCP, NTP) und 2I1800 (Archiv, Apache, NFS, Samba usw.) habe ich nicht das geringste verändert, nur auf dem "Client" mit Xubuntu und die Probleme gibt es auch erst seit dem Upgrade.

Die ausführliche hosts-Liste steht auch nur auf dem Server ACTIVY (IP = 192.168.192.77), während die anderen in der /etc/resolv.conf einen Eintrag wie
enthalten. Seit dem Upgrade funktioniert das nicht mehr; diese Datei gibt es nicht mehr sondern sie ist auf @resolv.conf verlinkt, worin folgendes steht:

Offenbar mischt sich da neuerdings dieser unsägliche systemd ein und bringt alles durcheinander. Was kann ich tun?

Nachfolgend zitiere ich noch meine hosts-Datei (gekürzt) auf dem DHCP-Server namens ACTIVY:


Vieles von diesen Einträgen ist obsolet, weil es die Systeme gar nicht mehr gibt, aber sie haben auch noch nie gestört.

Dank deiner Erklärung habe ich ein wenig von den Zusammenhängen (was systemd da eigentlich treibt) verstanden und dann das Paket resolvconf zwar nicht gelöscht, aber versucht, es abzuschalten mit systemctl disable systemd-resolved; danach habe ich den Link auf die irgenwo anders liegende ../run/resolvconf/resolv.conf gelöscht und stattdessen eine neue /etc/resolv.conf mit den statischen Angaben auf den DHCP-Server angelegt, welcher auch die vollständige /etc/hosts mit allen Netzwerkkomponenten im LAN enthält. Anschließend das System neu gestartet.

Danach ging überhaupt keine Namensauflösung mehr, nur noch statische IP-Adressen. Da war ich erst mal überfordert, habe aber dank timeshift in wenigen Minuten den Zustand von heute früh erneuern (wiederherstellen) können. Zum Glück habe ich 3 bootfähige Systeme auf dieser Hardwäre, welche timeshift verstehen und wo es auch eingerichtet ist (es bleiben also immer noch 2 lauffähige Reparatursysteme, falls eines tot ist). Hoffentlich war es nur ein Flüchtigkeitsfehler.

Zitat von »Fredl«

Zitat von »ebbi97a«

stattdessen eine neue /etc/resolv.conf mit den statischen Angaben auf den DHCP-Server angelegt

Auf Activy? Der hatte kein Problem, es ging um den Produktivrechner.

Entschuldigung! Das war eine verquere Ausdrucksweise meinerseits. Der Unterschied zwischen den und dem sticht eben nicht in's Auge.
Die Änderungen habe ich auf dem Produktivrechner I5TUXEDO (IP = 192.168.192.25) gemacht; der hat zwar eine feste IP-Adresse und steht in seiner eigenen /etc/hosts, soll sich aber die Namen aller (anderen) Hosts im LAN aus der Liste auf ACTIVY holen. Dort habe ich natürlichts nichts geändert.

Zitat von »Fredl«

Laut man-page von systemd-resolved wird eine vorhandene /etc/resolv.conf eingelesen und verwendet, wenn es eine echte Datei und kein Symlink auf /run/systemd/resolve/resolv.conf ist. Du kannst den Dienst also weiter laufen lassen und musst nur die alte resolv.conf wieder herstellen.

Allerdings sollten die enthaltenen Informationen (domain und nameserver) ohnehin via DHCP empfangen und gesetzt werden.

Werde ich heute abend nochmals versuchen; danke einstweilen.

Zitat von »fredl/ebbi97a«

Werde ich heute abend nochmals versuchen; danke einstweilen.

Genial! Du hast mich gerettet. Nicht nur die Pings funktionieren in allen Varianten wieder, sonder auch die virtuellen Apache-Server auf 2I1800 (Archiv-Rechner) kann ich vom Schreibtischrechner aus wieder abfragen. Ob NTP wieder richtig hinhaut habe ich noch nicht untersucht.

Hoffentlich bleibt das jetzt so und wird nicht bei jeder Aktualisierung von systemd wieder kaputt geschrieben.
______________________________________________________________________________________________

Nur nachrichtlich (langatmig):

Seit gestern abend und heute habe ich viel gelernt, weil ich das aber nicht regelmäßig brauche, werde ich es beim nächsten ähnlichen Fall mit Sicherheit wieder vergessen haben; deswegen notiere ich es hier.

Noch bewahre ich eine timeshift-Sicherung vom letzten lauffähigen Xenial-Stand (16.04) auf. Dort wollte ich nachschauen, was genau in der /etc/resolv gestanden war; zu meiner großen Überraschungen war sie vollkommen leer. Erst glaubte ich an einen Fehler, was ich aber verwarf, weil mich timeshift noch nie im Stich gelassen hat.

Im Lauf des Tages habe ich mir folgendes zusammen gereimt:

1. Die statisch sauber notierten Resolverdateien (/etc/resolv) hatte ich nur auf den Servern, wo keine graphisch Oberfläche installiert ist.
   
2. Auf den Arbeitsplatzrechnern mit graphischer Oberfläche habe ich die Daten immer über diese kleinen Netzwerksysmbole in der oberen oder unteren Bildschirmleiste eingeben (heißen die Dinger network manager ??). Dort kann man die wichtigsten Parameter eingeben.
   
3. Auf meinem Arbeitsrechner I5TUXEDO habe ich 2 Ethernet-Schnittstellen, die unterschiedlich konfiguriert sind; ein Netzwerkabel steckt immer nur in einer von ihnen. Ist alles in Ordnung (alle Rechner laufen störungsfrei) steckt das Kabel in der Schnittstelle mit fester IPv4-Adresse und Verweis auf ACTIVY als DNS. Ist die Welt untergegangen (z.B. Plattenschaden auf einem Server) stecke ich das Kabel in die andere Schnittstelle, die auf DHCP steht (nach dem Motto such' dir selbst was passendes!).
   
4. So kann ich im Notfall zwar nicht mehr an meine Archivdaten, aber immer noch zum Recherchieren ins Internet.
   
5. Es könnte wohl sein, daß der graphische Konfigurator aus der Oberfläche die Resolver-Datei zur Laufzeit mit den gewünschten Werten gefüllt hat und die restliche Zeit nichts drin war.

Egal ― jetzt werde ich die restlichen Umstellungsfehler anpacken, von denen sich mindestens 2 automagisch (als Folgefehler) schon gelöst haben. Sollte ich irgendwo nicht weiter kommen, muß ich wohl wieder hier im Forum nerven.

Zitat von »Fredl«

Systemd ist gar nicht so ein kinderfressendes Monster wie man glaubt. Immerhin bringt es etwas Abwärts-Kompatibilität mit und ist -genau genommen- relativ gutmütig. Man will halt immer mehr automatisch erledigen lassen, damit die Anwender immer weniger selbst tun (und mitdenken) müssen. Ob das der richtige Weg ist, muss jeder für sich entscheiden. Manchmal kommt bei solchen maschinellen Entscheidungen halt auch Ungewolltes heraus, speziell wenn der User seine Werkzeuge partout nicht aus der Hand geben möchte.

Das ist wohl die vernünftigste Sichtweise; gegen den Fortschritt kann man sich nicht stemmen, der hat immer den längeren Atem. Das hatte ich vor einigen Generationen von postgreSQL mal versucht, als die allen Anwender eine sehr unbequeme Änderung (Abschaffung der SERIAL-Felder) aufgezwungen hatten. Damals hatte ich beschlossen, daß ich bis an mein Lebensende kein Änderungen mehr benötigen werde, weil das Vorhandene perferkt für die Verwaltung meiner zigtausend Photos geeignet war. Etwa 3 Generationen habe ich die Aktualisierungsverweigerungen durchgehalten, dann war die alte postgreSQL-Version auf dem zugrundeliegenden Debian-System nicht mehr lauffähig. Daraufhin habe ich das System auf einer alten Hardware eingefroren und geplant, es nötigenfalls als virtuelle Maschine zu verewigen.
Das ging gerade die nächsten 2 Jahre gut:
Die Datenpflege fand nämlich nicht auf dem Archivrechner ohne graphische Oberfläche statt, sondern natürlich auf einem graphischen Client und es kamen zuletzt pgAdmin III und phpPgAdmin (im Webbrowser) zum Einsatz. Zunächst meldete pgAdmin xx nach einer Aktualisierung, daß es mit dieser alten Datenbank nicht mehr könne und auch der Browserclient fing irgendwann zu mucken an. Es blieb mir also nichts anderes übrig, als die Datenbankcluster in tagelanger Arbeit zu migrieren; insgesamt dauerte es mit Verstehen, Einlesen, Lernen und Durchführen mehrere Wochen, bis alles wieder funktionierte. So stur werde ich nicht mehr sein.

Zum Problem mit NTP:
Durch die Reparatur der Namensauflösung hat es sich nicht gelöst. Beim Herumsuchen in den Konfigurationsdateien bin ich aber darauf gestoßen, daß es nicht nur eine /etc/systemd/resolved.conf gibt, sondern auch eine /etc/systemd/timesyncd.conf. Jetzt mache ich mir Hoffnung, daß auch hier der systemd die alten Strukturen überlagert; muß ich also lesen und verstehen, vielleicht ergibt sich dann eine ganz logische Lösung.

Zitat von »Horsemanchip«

Man könnte ja verhindern, dass die resolv.conf von anderen Anwendungen überschrieben wird:

Habe eine heilige Scheu, an solchen für mich undurchschaubaren Dingen zu rühren, aber wenn es gar nicht anders geht…

Nachbemerkung:
Unter meinen Probiersystemen auf der gleichen Hardware (nicht virtualisiert) befindet sich übrigens auch ein Devuan 2; dort sind die Resolver-Dateien noch ganz konservativ und man kann und darf selbst kontrollieren, was sie bewirken sollen. Einsehen, daß auf graphischen Client-Maschinen dieses alte direkte Konfigurationskonzept nicht mehr durchhaltbar ist sowie den meisten Anwender auch nicht zumutbar scheint, kann ich auch. Werde mich wohl so organisieren müssen, daß ich mich auf den graphischen Clients in Zukunft auch "führen" lasse, würde aber auf den graphiklosen Servern aber doch gerne das Heft in der Hand (be)halten. Daß es kaum anders laufen kann haben die proprietären Großen für den Massenmarkt (Windows und MacOS) in den letzten Jahren / Jahrzehnten ja eindringlich vor Augen geführt.

Zitat von »Fredl«

Natürlich hatte ich auch solche Episoden der Update-Verweigerung. Schlimm wird es, wenn man zusehen und einsehen muss, daß ein Rechner langsam immer mehr Funktionen nicht mehr erfüllen kann, für die er eingerichtet wurde, aber ein "sanftes" Upgrade auch nicht mehr geht. Oder wenn einem die nötigen Paketquellen wegen Überalterung entzogen wurden. Man muss stets wachsam sein, um nicht den letzten Zeitpunkt zu verpassen, der eine völlige Neuinstallation erspart.
…
Einzig, das bisher erworbene Wissen völlig zu erneuern und die bestimmt fortschrittlicheren Möglichkeiten effektiv zu nutzen ist für einen alten Sack wie mich eine respektable Hürde.

Damit hast du auch die beiden größten psychologischen Hürden angesprochen, die mir zu schaffen machen. 2 Jahrzehnte lang Kenntnisse angesammelt, die weitgehend wertlos sind. Inzwischen gehe ich zielstrebig auf die 70 zu und kann in meinem Bekanntenkreis solche Schwierigkeiten nicht ansprechen. Denen muß ich schon mit ihrem Windows helfen; bei manchen ist auch schon mit dem Fernseher das Ende der Fahnenstange erreicht.

Zitat von »Fredl«

Aufgrund deiner NTP-Frage habe ich mir kurz die Liste der bei mir installierten man-pages angesehen: …
Wenn man das als Gesamtbild betrachtet, sieht es eigentlich ganz vernünftig und relativ vertraut aus. Zumindest kann man sich unter den Bezeichnungen etwas vorstellen und es hat keine so chaotische Struktur wie die über die Jahrzehnte gewachsenen Administrations-Tools. Darüberhinaus bieten die Dienste eben bessere Möglichkeiten der Zusammenarbeit und eigenständigen Konfiguration (das Thema hatten wir schon...)
…
Aktueller Tipp : Wirf einen Blick in 'man systemd.network'. Da steht u.a. drin, wie und von welchen Diensten Angaben zu DNS, DHCP, NTP, usw. eruiert und gesetzt werden.
Tipp Nr.2: Da du ja einen DHCP-Server betreibst würde sich das Setzen der NTP-Adresse(n) von diesem aus anbieten. Es gibt eine eigene Option dafür, und was ich so quergelesen habe, werden per DHCP erhaltene Vorgaben von systemd übernommen. Alles andere wäre ja auch unsinnig.

Das klingt hilfreich. NPT hat sich folgendermaßen (nicht gelöst, aber) erledigt:
Beim Upgrade wurde der ntpd deaktiviert und das Teil vom systemd hat übernommen. Statt mit ntpq kann ich den Status jetzt mit timedatectl, systemctl status systemd-timesyncd abfragen. Im Prinzip genügt mir das. Unschön ist, das munin jetzt keine Daten vom ntpd mehr findet und ich auf dessen wunderschöne Diagramme verzichten muß; fällt wohl unter die Altlast Nostalgie.

Danke für deine Hilfe und jedenfalls weiß ich mich jetzt mit solchen quälenden Gedanken nicht allein auf der Welt. Ist eben der Lauf der Welt: alles fließt (πάντα ῥεῖ).