Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: Ubuntu-Forum & Kubuntu-Forum | www.Ubuntu-Forum.de. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 160

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

1

28.10.2018, 19:06

Namensauflösung (DNS) nach Upgrade kaputt

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

Quellcode

1
2
3
domain netz
search netz
nameserver 192.168.192.77
enthalten. Seit dem Upgrade funktioniert das nicht mehr; diese Datei gibt es nicht mehr sondern sie ist auf @resolv.conf verlinkt, worin folgendes steht:

Quellcode

1
2
3
4
5
6
/etc/resolv.conf                                      304/304               100%
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53

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:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
Datei: hosts            Zeile 1 Spalte 0   1601 Bytes                        34%
#       Fassung ohne Domainwerweiterungen, weil die von dnsmasq erzeugt werden sollen !
# ...

127.0.0.1       localhost

#       >>> 1. Netzwerkschnittstelle <<<

192.168.192.77  ACTIVY  activy

192.168.192.7   P450    p450
#               virtuelle Web-Server:
192.168.192.7   p450-privat
192.168.192.7   p450-offen
192.168.192.7   p450-test
192.168.192.7   p450-drupal

192.168.192.8   2I1800  2i1800
#               virtuelle Web-Server:
192.168.192.8   2i1800-privat
192.168.192.8   2i1800-offen
192.168.192.8   2i1800-test
#192.168.192.8  2i1800-drupal

192.186.192.11  A4000T  a4000t
192.186.192.12  A4000PPC        a4000ppc
192.186.192.22  PC600-W2K       pc600-w2k
192.186.192.23  PC600   pc600   # Linux
192.168.192.24  P2800   p2800
192.168.192.25  I5TUXEDO        i5tuxedo        # Linux (Xubuntu)
192.168.192.32  pulsar-m        S900-M  s900-m  # MacOS9

192.168.192.88  THING   thing

#               NAS u.ä.
192.168.192.92  NAS326  nas326

#192.168.192.204        NPIA742FC       npia742fc       lj-p2015n       # HP LaserJet P2015n (Drucker)

#       2 alternative LAN/WAN-Gateways auf der selben Adresse
#        (immer nur eines aktiv!):
#192.168.192.252        DC-200  dc-200
192.168.192.252 FB-7170 fb-7170

#       >>> 2. Netzwerkschnittstelle <<<

192.168.168.77  ACTIVY2 activy2
192.168.168.252 HT-486  ht-486
192.186.186.6   D800    d800
192.168.168.202 X2P2800 x2p2800
192.168.168.192 SILVERFAST      silverfast

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters   
   ... ...

Vieles von diesen Einträgen ist obsolet, weil es die Systeme gar nicht mehr gibt, aber sie haben auch noch nie gestört.
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »ebbi97a« (01.11.2018, 15:01)


2

29.10.2018, 20:15

Wenn das Paket resolvconf ein bislang funktionierendes Netzwerk stört und du es für nichts anderes brauchst, entferne es einfach. Dann wird auch deine echte /etc/resolv.conf wieder greifen wie gehabt.

Übrigens hat in dieser eine 'search'-Zeile wenig Nutzen, wenn es ohnehin nur eine Domain abzusuchen gibt. Die Suchliste wird bereits aus dem 'domain'-Eintrag gefüllt.

Das Rätsel ist, woher dieser Nameserver-Eintrag 127.0.0.53 kommt. Schau mal mit netstat, ob da noch ein lokaler DNS installiert wurde, etwa dnsmasq.
--
edit: Achja, steht ja in Zeile 4... Also dann diesen Dienst permanent deaktivieren, falls er sich nicht einfach entfernen lässt.
mir is wurscht

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 160

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

3

30.10.2018, 17:58

1. Versuch gescheitert; morgen mache ich weiter

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.
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »ebbi97a« (30.10.2018, 19:51)


4

31.10.2018, 01:15

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.

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.
mir is wurscht

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 160

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

5

31.10.2018, 07:22

Mißverständnis

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.

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.
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »ebbi97a« (31.10.2018, 09:01)


  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 160

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

6

31.10.2018, 21:08

Paßt!

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.
_______________________________
Welches System hätten's denn gern?

7

31.10.2018, 23:53

Erstmal schön, daß es jetzt wieder läuft.

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.

Wie auch immer...

Ich hab noch eine Überraschung übrig: Meine /etc/resolv.conf entsteht bei jedem Rechnerstart neu, frag mich jetzt nicht durch welchen Automatismus. Daß die enthaltenen Daten vom DHCP-Server bezogen werden, ist klar, aber ich konnte gerade nicht herausfinden, wer sie tatsächlich schreibt. Der hier eingesetzte dhclient sagt nichts darüber in seiner man-page. Aber eigentlich kann es nur er sein.

Das vielleicht nur als (weitere) Erklärung der leeren Datei in deinen Backups. Wenn das zu sichernde System gerade nicht läuft, dann müsste die Datei leer sein, nachdem sich das System ordnungsgemäß beim DHCP-Server abgemeldet hat.

--
Wenn das Problem damit gelöst ist setze bitte noch das passende Präfix vor die Überschrift, damit das jeder gleich erkennen kann. Danke!
Wie man ein Thema markiert ist in unseren Einsteiger-Infos erklärt.
mir is wurscht

Beiträge: 834

Registrierungsdatum: 08.11.2015

Derivat: unbekannt

Version: gar kein Ubuntu

Architektur: 64-Bit PC

Desktop: LXDE

Andere Betriebssysteme: Debian 9.5 "stretch" / 4.9.0-8-amd64

  • Nachricht senden

8

01.11.2018, 08:01

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

Quellcode

1
# chattr +i /etc/resolv.conf


Nur so ne Idee.^^
Hast Du Schnotten an der Nase, bist Du in der Schnupfenphase! :)












banane tanzt.gif

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 160

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

9

01.11.2018, 10:56

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.

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.
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von »ebbi97a« (01.11.2018, 11:15)


10

02.11.2018, 00:25

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,

Mir scheint Du bist auf dem besten Weg, dich mit systemd anzufreunden :)

Auf meinem Debian ist das zwar installiert, aber ich hatte noch die Wahl ob es auch aktiviert werden soll. Natürlich sagt man dazu erstmal 'nein' :) Über kurz oder lang wird man sich aber dafür entscheiden müssen, um nicht in die von Dir geschilderte Sackgasse zu geraten. 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.

Aufgrund deiner NTP-Frage habe ich mir kurz die Liste der bei mir installierten man-pages angesehen:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
systemd-analyze                       systemd-halt.service                  systemd-modules-load.service          systemd-sysctl
systemd-ask-password                  systemd-hibernate-resume              systemd-mount                         systemd-sysctl.service
systemd-ask-password-console.path     systemd-hibernate-resume-generator    systemd-networkd                      systemd-system.conf
systemd-ask-password-console.service  systemd-hibernate-resume@.service     systemd-networkd.service              systemd-system-update-generator
systemd-ask-password-wall.path        systemd-hibernate.service             systemd-networkd-wait-online          systemd-sysusers
systemd-ask-password-wall.service     systemd-hostnamed                     systemd-networkd-wait-online.service  systemd-sysusers.service
systemd-backlight                     systemd-hostnamed.service             systemd-notify                        systemd-sysv-generator
systemd-backlight@.service            systemd-hwdb                          systemd-path                          systemd-timedated
systemd-binfmt                        systemd-hybrid-sleep.service          systemd-poweroff.service              systemd-timedated.service
systemd-binfmt.service                systemd-importd                       systemd-quotacheck                    systemd-timesyncd
systemd-cat                           systemd-importd.service               systemd-quotacheck.service            systemd-timesyncd.service
systemd-cgls                          systemd-inhibit                       systemd-random-seed                   systemd-tmpfiles
systemd-cgtop                         systemd-initctl                       systemd-random-seed.service           systemd-tmpfiles-clean.service
systemd-cryptsetup                    systemd-initctl.service               systemd-reboot.service                systemd-tmpfiles-clean.timer
systemd-cryptsetup-generator          systemd-initctl.socket                systemd-remount-fs                    systemd-tmpfiles-setup-dev.service
systemd-cryptsetup@.service           systemd-journald                      systemd-remount-fs.service            systemd-tmpfiles-setup.service
systemd-debug-generator               systemd-journald-audit.socket         systemd-resolve                       systemd-tty-ask-password-agent
systemd-delta                         systemd-journald-dev-log.socket       systemd-resolved                      systemd-udevd
systemd-detect-virt                   systemd-journald.service              systemd-resolved.service              systemd-udevd-control.socket
systemd-escape                        systemd-journald.socket               systemd-rfkill                        systemd-udevd-kernel.socket
systemd-fsck                          systemd-journal-upload                systemd-rfkill.service                systemd-udevd.service
systemd-fsckd                         systemd-kexec.service                 systemd-rfkill.socket                 systemd-update-utmp
systemd-fsckd.service                 systemd-localed                       systemd-run                           systemd-update-utmp-runlevel.service
systemd-fsckd.socket                  systemd-localed.service               systemd-shutdown                      systemd-update-utmp.service
systemd-fsck-root.service             systemd-logind                        systemd-sleep                         systemd-user.conf
systemd-fsck@.service                 systemd-logind.service                systemd-sleep.conf                    systemd-user-sessions
systemd-fstab-generator               systemd-machine-id-commit.service     systemd-socket-activate               systemd-user-sessions.service
systemd-getty-generator               systemd-machine-id-setup              systemd-socket-proxyd                 
systemd-gpt-auto-generator            systemd-modules-load                  systemd-suspend.service


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...)
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. :D

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.
mir is wurscht

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 160

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

11

02.11.2018, 10:04

Einsicht in's Unvermeidliche

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. :D

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.

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 (πάντα ῥεῖ).
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »ebbi97a« (02.11.2018, 10:09)


12

02.11.2018, 21:46

Jaja, der Panther und das Reh... :)

2 Jahrzehnte lang Kenntnisse angesammelt, die weitgehend wertlos sind.
Naja, ganz so schlimm ist es nun auch wieder nicht. Immerhin ist Wissen vorhanden, daß nur angepasst und erweitert werden muss. Das ist aber immer und überall so.

kann in meinem Bekanntenkreis solche Schwierigkeiten nicht ansprechen. Denen muß ich schon mit ihrem Windows helfen
Das ist eben das Los derer, die in jungen Jahren ihrer Zeit voraus waren. Irgendwann werden die Zurückgebliebenen immer anhänglicher. :)

Unschön ist, das munin jetzt keine Daten vom ntpd mehr findet
Hmm, ohne jetzt genau zu recherchieren, würde ich annehmen, daß ein munin aus den gleichen Paketquellen mit den veränderten Gegebenheiten klarkommen sollte. Schließlich landen Pakete üblicherweise erst dann im stable-Zweig, wenn sie zum Rest des Systems passen. Zumindest bei Debian ist das so, und sollte bei Ubuntu LTS-Versionen auch so sein. Selbst wenn es bei Ubuntu keinen namentlichen "stable"-Zweig gibt. (Wird schon einen Grund geben ;))
mir is wurscht