Testing: Network-Manager - wie ich mir den Ablauf vostelle

[wckl]

Hallo,
nach den verschiedenen Problemen mit Network-Manager möchte ich grob beschreiben, wie ich mir den Ablauf vorstelle:

- Ich schalte das Gerät ein, üblicherweise ist es mit dem Kabel an das Netzwerk angeschlossen, der Router läuft schon.
- Zwischenzeitlich mache ich irgendetwas anderes.
- Der Rechner ist nach einiger Zeit hochgefahren und hat schon:
1. Mit ntpd einmalig die Zeit eingestellt.
2. Mit fetchmail sämtliche Postfächer abgeholt.
- Wenn ich mich dann einlogge, sind 1. und 2. erledigt und ich muß auf nichts warten.
(- Wenn ich dann den Rechner von hier nach da trage und eben das Kabel ziehe, soll der Network-Manager die Verbindung über WLAN / WiFi herstellen. ... usw.)

Laut journalctl -o short-monotonic ist der Ablauf allerdings:
- Network-Manager startet, es wird gemeldet daß er gestartet ist,
- sofort startet ntpd, und meldet nach einiger Zeit: "Temporary failure in name resolution (-3)"
offensichtlich ist der Network-Manager noch längst nicht fertig und stellt die Verbindung noch nicht her.
- Erst wenn ich mich angemeldet habe kann ntpd die Zeit endlich einstellen und
- fetchmail holt verspätet die Post ab, so daß ich die E-Mails erst nach einiger Verzögerung ansehen kann.

Es kann ja sein, daß ich das System falsch konfiguriert habe -
kann mir jemand bei der richtigen Konfiguration helfen, damit der oben beschriebene Wunschablauf funktioniert?

Installiert ist immer noch /etc/init.d Init-V-System,
gleichzeitig aber auch systemd.

Vielen Dank für Hinweise.
wckl

[bullgard]

Hallo wckl,

nach den verschiedenen Problemen mit Network-Manager möchte ich grob beschreiben, wie ich mir den Ablauf vorstelle:
- Ich schalte das Gerät ein, üblicherweise ist es mit dem Kabel an das Netzwerk angeschlossen, der Router läuft schon.
- Zwischenzeitlich mache ich irgendetwas anderes.
- Der Rechner ist nach einiger Zeit hochgefahren und hat schon:
1. Mit ntpd einmalig die Zeit eingestellt.
2. Mit fetchmail sämtliche Postfächer abgeholt.
- Wenn ich mich dann einlogge, sind 1. und 2. erledigt und ich muß auf nichts warten.wckl

Ich glaube, Du hast falsche Vorstellungen.
Aus Sicherheitsgründen sollte Dein Rechner erst dann die Mails aus sämtlichen Postfächern abholen, nachdem Du Dich ordentlich am Rechner eingeloggt und mit Paßwort ausgewiesen hast.

(- Wenn ich dann den Rechner von hier nach da trage und eben das Kabel ziehe, soll der Network-Manager die Verbindung über WLAN / WiFi herstellen. ... usw.)
Laut journalctl -o short-monotonic ist der Ablauf allerdings:
- Network-Manager startet, es wird gemeldet daß er gestartet ist,
- sofort startet ntpd, und meldet nach einiger Zeit: "Temporary failure in name resolution (-3)"
offensichtlich ist der Network-Manager noch längst nicht fertig und stellt die Verbindung noch nicht her.
- Erst wenn ich mich angemeldet habe kann ntpd die Zeit endlich einstellen und
- fetchmail holt verspätet die Post ab, so daß ich die E-Mails erst nach einiger Verzögerung ansehen kann.

Das ist so aus Sicherheitsgründen eingerichtet und normal.

Es kann ja sein, daß ich das System falsch konfiguriert habe -

kann mir jemand bei der richtigen Konfiguration helfen, damit der oben beschriebene Wunschablauf funktioniert?

Ja. Eine (übersichtliche) Möglichkeit ist, daß Du entweder systemd oder Init-V-System alten Stils installierst, aber nicht beides vermengst. Mein Eindruck ist, daß Du für dieses Vermengen (noch ) nicht die nötigen Kenntnisse hast:

Installiert ist immer noch /etc/init.d Init-V-System, gleichzeitig aber auch systemd.

Gruß
bullgard

[wckl]

Ich glaube, Du hast falsche Vorstellungen.
Aus Sicherheitsgründen sollte Dein Rechner erst dann die Mails aus sämtlichen Postfächern abholen, nachdem Du Dich ordentlich am Rechner eingeloggt und mit Paßwort ausgewiesen hast.

Wieso verletzt es die Sicherheit, wenn ntpd die Zeit abholt und einstellt und fetchmail als Systemdämon meine Postfächer abholt und sie exim übergibt? Das sind doch root-Prozesse, oder habe ich da etwas falsch verstanden?

[TomL]

Ich würde bei diesen Anforderungen sysvinit komplett entfernen, ebenso ntp und den Networkmanager und dann noch (falls überhaupt aktiv) das /etc/init.d-Script 'networking' deaktivieren. Der Networkmanager ist in dem Szenario m.E. die größte Schwachstelle, dessen Arbeitsweise imho einigermaßen unkalkulierbar ist. Den würde ich unbedingt entsorgen und stattdessen mit systemd-networkd für Eindeutigkeit sorgen.

Den Zeit-Sync übernimmt nun systemd-timesyncd, das Netzwerk wird von systemd-networkd gestartet, und zwar eth0 direkt und wlan0 via wpa-supplicant. Und nachdem eine IP gegeben ist, startet systemd als vorgegebener User 'fetchmail'. Ich bin ziemlich zuversichtlich, dass das klappen wird.

Ob allerdings laufende Programme den Wechsel dynamisch zu einem anderen Interface hinkriegen, wenn dem aktiven eth0 kalt die strippe gezogen wird, weiss ich nicht. Zumindest 'meinen' Palemoon muss ich neu starten, damit er danach vom anderen Interface läuft.

J.m.2.c.

[rendegast]

Du könntest dem nm vorgeben, das Netzwerk auch ohne Login zu starten.
Heißt wohl "system-connections" o.ä.

[wckl]

Ich habe ein wenig zum systemd gestöbert ... und bin ausreichend verwirrt.

Ist systemd-timesyncd der passende Ersatz für ntpd ? Dann würde ich mich ich lieber damit befassen.

Gibt es einen entsprechenden Dienst für fetchmail ?

(Debian hat sich doch entschieden systemd anstelle von sysvinit zu verwenden?)

[rendegast]

Ist systemd-timesyncd der passende Ersatz für ntpd ?

Es ist erstmal nur eine Alternative.
Ist das Netzwerk aber ob der Einstellung des network-manager noch nicht online,
läuft er genauso gegen die Wand.

[wckl]

Vermute ich da richtig?
NetworkManager und systemd passen nicht so richtig zusammen?

[rendegast]

Dafür gibt es keine Belege.
nm ist ein Dienst, der unter systemd wie auch sysvinit läuft.

Seine Aufgabe ist Einstellung des Netzwerks.
Er könnte / wird mit einem systemd-networkd kollidieren,
falls die sich um dasselbe interface kümmern wollen.
Das ist aber bei allen Diensten so, die für gleiche Aufgaben gedacht sind.

nm ist erstmal Desktop-bezogen, daher fängt er normalerweise erst mit login des/eines Benutzers mit der Arbeit an.
Das kann aber eingestellt werden, oben schon erwähnt.

[wckl]

Du könntest dem nm vorgeben, das Netzwerk auch ohne Login zu starten.
Heißt wohl "system-connections" o.ä.

Das habe ich leider nicht verstanden. Wo und wie mach ich das?

[rendegast]

https://wiki.ubuntuusers.de/NetworkMana ... _ohne_GUI/
Es muß wohl die Konfigurationsdatei für das jeweilige Netzwerk statt
~/.gconf/system/networking/connections/
im Verzeichnis
/etc/NetworkManager/system-connections/
eingestellt werden.
(Oder gibt es ein Häkchen irgendwo im GUI?)

Ob da auch ein Verlinkung funktioniert? (damit der Benutzer noch konfigurieren kann)
oder Probleme schafft?

Wieweit die Schalter
'Automatisch verbinden' (wohl autoconnect=true)
'Für alle Benutzer verfügbar'
da hineinspielen?

[wckl]

Bisher haben mich alle meine Versuche nicht weitergebracht:
- ntpd startet zwar ohne Fehlermeldungen, braucht aber ewig lange und viele Versuche, NetworkManager greift zwischendurch immer wieder ein und konfiguriert die eth0 erst nach dem Start von ntpd ! (Wenn ich den Ablauf im journalctl richtig verstehe.)
- Fetchmail als "system wide fetchmail daemon" wird ebenfalls zu einem Zeitpunkt gestartet, zu dem das Netzwerk nicht fertig konfiguriert ist: [ 29.893316] xxx fetchmail[1391]: konnte kanonischen DNS-Namen von pop.xxx.yy (pop.xxx.yy) nicht finden: Temporärer Fehler bei der Namensauflösung

Andererseits:
Auf einem anderen Laptop im Netzwerk läuft ebenfalls NetworkManager. Wenn ich diesen einschalte, sich KEINER anmeldet, kann ich trotzdem diesen Rechner per ssh erreichen.

Warum kann NetworkManager ntpd, fetchmail und andere Dienste nicht so berücksichtigen, daß sie auch ohne Anmeldung eines Nutzers verfügbar sind - so wie das ohne NetworkManager ja funktioniert?

[catdog2]

Auf einem anderen Laptop im Netzwerk läuft ebenfalls NetworkManager. Wenn ich diesen einschalte, sich KEINER anmeldet, kann ich trotzdem diesen Rechner per ssh erreichen.

Das Häkchen für die system-connections wurde ja schon erwähnt.