networkd wlan statische und dynamische ip-Adressen

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
Antworten
scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

networkd wlan statische und dynamische ip-Adressen

Beitrag von scientific » 20.06.2017 22:52:41

Hi Leute!

Angeregt durch eine Diskussion mit @TomL hab ich mir einmal systemd-networkd als Ersatz für NetworkManager angesehen.

Für WLAN habe ich wpa_supplicant in Verwendung, und der wählt auch brav das Netzwerk aus und verbindet sich damit.
ABER
Wie konfiguriere ich systemd-networkd so, dass ich für verschiedene Netzwerke verschiedene IP-Adressen habe?
Daheim brauch ich eine statische IP, unterwegs im Zug, beim WLAN vom Smartphone eine per DHCP zugewiesene, in der Arbeit eine fixe, aber eine andere wie daheim.

Ich habe bei Ubuntuusers eine Anleitung gefunden, aber die arbeitet mit /etc/network/interfaces und ohne systemd-networkd.

Wie mache ich das mit systemd-networkd richtig?

Ich werde einfach bei Google nicht fündig?

Liebe Grüße

scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

TomL

Re: networkd wlan statische und dynamische ip-Adressen

Beitrag von TomL » 20.06.2017 23:08:45

scientific hat geschrieben:Wie mache ich das mit systemd-networkd richtig?
Das geht nicht.

Im letzten Jahr hatten wir hier ein dazu passendes Thema.... dort kannst Du nachsehen, was für einen manuellen WLAN-Connect notwendig ist.Und das kriegste nicht passend mit systemd gelöst. Ich glaube auch nicht, dass systemd dafür gedacht ist. Natürlich kann man sich eine instanziierte Service-Unit basteln,aber das ist dann nur ein weiterer eigentlich unötiger Schritt, weil mans genauso gut direkt starten kann. Die Unit bringt da keinen Vorteil.
viewtopic.php?f=30&t=162459&hilit=ip+link#p1106279
viewtopic.php?f=30&t=162459&hilit=ip+li ... 5#p1106659

Ich habe akzeptiert, dass systemd nur ein Startsystem ist... und das es auch Grenzen hat. Für flexible Anwendungen zur Laufzeit kann mans nutzen, um beispielsweise Dienste zu starten, aber darüber hinaus...?... eher nicht. . Und eine etablierte Netzwerkverbindung ist kein Dienst... das geht viel einfacher direkt mit Boardmitteln.

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: networkd wlan statische und dynamische ip-Adressen

Beitrag von scientific » 21.06.2017 01:10:39

Das ist aber nicht gut...

Aber weißt du noch, wie ich den Status einer Verbindung mit systemd-networkd als Abhängigkeit oder Trigger nutzen kann, sodass eine andere Unit gestartet/gestoppt wird, wenn sich der Status einer Verbindung ändert? ("Connection established")

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

TomL

Re: networkd wlan statische und dynamische ip-Adressen

Beitrag von TomL » 22.06.2017 11:28:52

scientific hat geschrieben:Aber weißt du noch, wie ich den Status einer Verbindung mit systemd-networkd als Abhängigkeit oder Trigger nutzen kann, sodass eine andere Unit gestartet/gestoppt wird, wenn sich der Status einer Verbindung ändert? ("Connection established")
Ich würde es nicht für eine weise Entscheidung halten, wenn man sich auf einen einzigen Weg festschreibt, auch nicht, wenn er systemd heisst. Insofern würde ich auch nicht allein auf systemd-networkd beharren, sondern das nutzen, was am besten meine Anforderungen erfüllt. Und um das festzustellen, sollte man mal ganz pragmatisch die Schwächen bei den Alternativen feststellen. Darüberhinaus empfinde ich es sowieso als total überbewertet, wie das Netzwerk gestartet wird - mich interessiert doch nur, obs gestartet ist.
  • /etc/init.d/networking arbeitet zuverlässig, es startet das Netz beim Boot und beendet es beim Shutdown. Aber es kümmert sich einen Dreck um irgendwelche Abhängigkeiten, keine Infos über irgendwas an irgendwen. Das ist für ein statisches Netzwerk eines Endgerätes, welches keine Variationen dabei kennt, ausreichend gut geeignet. Von Flexibilität bei wechselnden Netzen keine Spur
  • systemd-networkd.... im Grunde genommen ist es für mich nur der legitime Nachfolger für /etc/init.d/networking. Die Informationskette an Abhängigkeiten ist zwar rudimentär besser, aber es fehlt vollkommen die notwendige Variabilität bei wechselnden Network-Connects, die ein mobiler Laptop und mehreren/vielen Gastgeber-SSIDs voraussetzt. Weil sich networkd ein bisschen besser in das systemd-Konzept einfügt, ist es imho eine bessere Alternative zu/etc/init.d/networking... aber eben auch nicht mehr.
  • Die Networkmanager spielen sich als Herren der NICs auf... weil sie das noch so von sysvinit gewohnt sind. Informationen an Abhängigkeiten über das, was sie tun ...?... allenfalls über die Dispatcher-Scripte. Der NWM kloppt bis heute beim shutdown eine offene WLAN-Verbindung weg, ohne systemd über die Notwendigkeit zu informieren, evtl. vorhandene remote-mounts vorher zu schließen.... was wiederum in nervigen 120-Sekunden-Stopjobs endet, die den Poweroff blockieren.
Du kannst nehmen, was Du willst, eine fiese Macke haste immer. Was ist die Alternative? Nix von den dreien zu verwenden und eine eigene Logik zu implementieren und einfach zu sagen "ist mir doch egal, wie das Netz zustande kommt, hauptsache die Informationskette stimmt". Genau das habe ich gemacht. Ich habe einen eigenen Networkmanager geschrieben. Es ist nur ein Script und beim Vergleich zum NWM wahrlich kein echter Networkmanager... aber er tut das, was er soll und unterstützt mich mit ausreichender Menüführung, ohne dass ich echte Mängel bemerke. Für mich ist es ein NWM,
  • der bei Systemstart via eigner Unit selnic.service ein Netz verbinden und bei Shutdown trennen kann
  • der bereits bei systemstart userbezogene Mounts herstellen kann (nur sinnvoll, wenn netz, user und mount quasi-statisch sind)
  • der kein Daemon ist, sondern kurzerhand auch mobil mit Dialog-Bedienung flexibel fremde SSIDs handhaben kann. Das heisst, er kann auch nach WISP scannen, eine wpa-supplicant-confg für einen WISP nach Standards herstellen und diesen WISP danach als Menüpunkt anzubieten
  • der bei erfolgter Verbindung die systemd-Unit "network-is-connect.service" startet, die bei mir zwar nur /bin/true ausführt, die man aber selber umbauen kann.
  • der vor dem Trennen des Netzes die systemd-Unit "network-disconnect.service" startet, die man wie zuvor umbauen kann
  • der im Menü remote-mounts via "mountctl.service" verbinden und trennen kann, wenn man sich unterwegs in fremder SSID via OpenVPN nachhause verbunden hat. Vergisst man die mounts zu trennen, wenn das Netzwerk getrennt werden soll... kein Problem...mountctl.service steht in Conflict zu network-disconnect.service.
Darüber hinaus habe ich auch noch die Remote-Mounts komplett von der Bootphase entlöst. Warum soll ich mich in der Bootphase überhaupt mit den Problemen rumplagen, ob das Netz schon gestartet ist, ob das Ziel "Samba-Server" überhaupt erreichbar ist (in fremden Netzen isses das nämlich nicht) und Shares mounten, ohne zu wissen, welcher User sich überhaupt anmelden wird und ob er gewisse Mounts vielleicht gar nicht darf? Das erfordert doch nur wieder total unnötiges lokales Rechtemanagement und damit unnötigen Zusatzaufwand für mich auf jedem Client, für jeden User. Ich starte nach der Anmeldung des User via PAM-Event die zuvor oben erwähnte mountctl.service im requires-Zusammenwirken mit meiner schon erwähnten network_wait_online_service, die aber effektiv nur das Ziel auf Erreichbarkeit prüft. Und da schließt sich der Kreis... es gibt keine Informationslücken....

Ob das alles so richtig ist...?... der richtige Weg...?... keine Ahnung... aber es funktioniert genial und ohne Probleme und ohne viel Aufwand. Der Aufwand lag in der Entwicklung, unverhältnismäßig hoch... aber genau das macht mir ja Spass.... das tue ich gerne.

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: networkd wlan statische und dynamische ip-Adressen

Beitrag von scientific » 22.06.2017 14:09:05

Ich muss am anderen Gerät schauen, da hatte ich die Seite offen.
Man kann NetworkManager ein Skript in dispatcher.d/pre-down geben, welches einen Mount beendet. Oder eben welches ein Target beendet, an dem remote-Mounts hängen.
Networkmanager wartet mit dem beenden der Verbindung so lange, bist die Skripte in pre-down mit exit 0 beendet wurden.

Ach nein, das hab ich von der systemd-Mailingliste!

Der Hinweis mit den pre-down-Dktipten wurde noch ergänzt, dass die Mountprogramme das können sollten, nicht beim Fehlen der Netzverbindung einzufrieren...
Denn Networkmanager kann auch nichts tun, wenn ihm eine Verbindung unter der Hand wegstirbt.

Und nach meinen Beobachtungen nach, muss uch den systemd-Entwicklern wieder einmal recht geben...

Ich hab meine Webseiten bei einem Provider, der leider zum Earten nur einen FTP-Zugang anbietet, obwohls eine Linux-Maschine ist.
Zätzlich beendet der Server nach 3 Minuten ohne Aktivität die Verbindung...
Curlftpfs packt das aber nicht. Stirbt einem gemounteten Verzeichnis entweder die Netzwerkverbindung weg (z. B. Ich bin im Zug und fahre in einen längeren Tunnel ein) oder beendet der Server die Verbindung, weil ich zu lange nicht am gemounteten Verzeichnis getan habe, hängt das System beim nächsten stat oder ls oder save auf das Verzeichnis. Selbst wenn zwischenzeitlich die Verbindung wieder da ist.

Da hilft dann nur ein

Code: Alles auswählen

 kilalll -s 9 curlftpfs

Das ist richtig lästig. Und meines Erachtens ei mne große Schwäche von curlftpfs. Und wie ich so mitgekriegt habe, auch von nfs und cifs. Das ist nämluch auch ohne Networkmanager und systemd ein Problem, das man nur mit Krücken irgendwie umschiffen kann...

Eine meiner Krücken ist die ftp-keepalive@.service Geschichte, die ich im Thread von jue erläutert habe.
Eine zweite Krücke ist ein Timer, der jede Minute prüft, ob die Verbindung noch steht, und ggfs. Die Mounts beendet.
Die müssen dann mit SIGKILL auf das Mountprogramm beendet werden... Alles andere hilft da nicht mehr. Das müsste aber mit Killmode in der systemd-Mount-Unit auch zu machen sein. So weit bin ich aber noch nicht.

Ich finde, dass ich soviel wie möglich mit dem selben Eerkzeug erledigt haben will, und nicht eine Aufgabe auf mehrere Werkzeuge. Sprich, ich möchte soviel wie möglich mit systemd erledigt haben, da ich dann nur in den Konfigurationen von systemd auf die suche gehen muss.

Und wenn es sein muss, dann soll sich auch nm um die Verbindungen kümmern. Ich arbeite mich gerade in den dispatcher ein, damit der zuverlässig units und targets starten und beenden kann... Damit ich den Rest wieder mit systemd erledigen kann.

Die Geschichte mit den Shares und den unterschiedlichen Rechten verstehe ich immer noch nicht so recht... Muss ich mir mal näher ansehen, wenn ich die Muse dazu hab.

Lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

TomL

Re: networkd wlan statische und dynamische ip-Adressen

Beitrag von TomL » 22.06.2017 17:25:00

scientific hat geschrieben:Die Geschichte mit den Shares und den unterschiedlichen Rechten verstehe ich immer noch nicht so recht...
Das ist einfach.... Du muss Dir nur die Frage beantworten, wer bei vorhandensein mehrerer Client-User und unterschiedlich berechtigter Shares die Shares mounten soll. Denn gemountet werden muss ja, und der, der mountet, muss berechtigt sein. Entweder mountet einer alles und für alle, losgelöst von dem, was der einzelne User effektiv braucht. Oder jeder User mountet genau das, was er darf. Also....:

1. EIN berechtigter User (vielleicht der Admin, vielleicht Du) mountet alle auf einem Client notwendigen Shares für alle User, die sich evt. anmelden könnten. Es werden also immer alle shares gemountet, auch die, die vielleicht nur ein User bekommen soll und der sich speziell an diesem Rechner eher selten anmeldet.... aber er könnte sich ja anmelden. Bei mir heisst es dann "Papa, wieso komme ich hier wieder nicht an meine Daten ran, so ein Mist, ich brauchs für die Schule". Automounts...?... wieviele soll ich einrichten...?... für jeden User...?...neee, kommt ja gar nicht in Frage! Tja.... weil nur ein User mountet, ist es auch eigentlich nicht erforderlich, mehr als nur diesen einen Samba-User auf dem Server anzulegen. Das funktioniert gut, solange Du nicht die Homedirs des Servers sharen willst.
Nachteile: 1. Samba weiss nicht, wer seine Shares nutzt. 2. Auf allen Clients ist ein extra Rechtemanagement für die Shares notwendig, um Client-Seitig zu bestimmen, welche User was darf und welcher nicht. 3. Sollen auch die Home-Dirs geshared werden, z.B. als persönlicher (!) Speicherordner im lokalen Homedir, ist doppeltes Rechte- und Usermanagement notwendig.

Ich schätze mal, dass es das Modell ist, was die meisten nutzen. Hab ich ja auch jahrelang. Mir gefällt das allerdings jetzt überhaupt nicht mehr. Oder als Alternative

2. Jeder User mountet selber mit seinem Samba-Account bei seiner Anmeldung am Display-Manager die Shares, die er braucht, mit den Rechten, die ihm Samba einrichtet. Versucht er mehr zu mounten, als er darf, verhindert Samba das. Nachteil: Kenn ich ich im Moment keine. Vorteile: Am Client muss ich nix mehr machen, ausser den User im Linux einrichten und meine Services kopieren.

Antworten