[solved] bullseye ohne wicd

[whiizy]

Ich habe noch eine genügsame Workstation, die bei mir schon über viele dist-upgrades gegangen ist - aktuell ist gerade bullseye dran. Ist ein LXDE/Openbox, in das mit der Zeit auch schon ein paar gnome-Pakete gesickert sind. Etwas Luxus zur Netzkonfiguration hatte ich mir einzig mit wicd geleistet, aber ausgerechnet den mißgönnt mir bullseye jetzt wieder . Beim simulierten dist-upgrade habe ich noch rechtzeitig bemerkt, daß wicd entfernt wird. Neuaufleben lassen wollte ich die gute alte /etc/network/interfaces in diesem Fall auch nicht mehr, also musste vorher noch ein Ersatz her. Ist ja blöd, wenn erst während oder nach dem dist-upgrade das Netzwerk flöten geht ...

Normalerweise benutze ich im LAN eine statische IP. Für das Upgrade an einem schnelleren Internet-Zugang brauchte ich aber temporär einen DHCP-connect. Habe mich dann erstmals für den systemd-networkd.service entschieden. Nach etwas Sucherei klappte das auch unter buster noch durch Anlegen einer /etc/systemd/network/dhcp.network

Code: Alles auswählen

[Match]
Name=e*

[Network]
DHCP=yes

# systemctl enable systemd-networkd

Da ich nicht genau wusste, ob eth0 nach dem Upgrade erhalten bleibt oder durch predictable interface names (en*) ersetzt wird, habe ich den Match auf e* gesetzt. Die resolv.conf musste ich allerdings händisch auf meinen gewünschten DNS setzen.

Mit diesem Netzwerk lief das dist-upgrade sauber durch und Konnektivität war auch anschließend noch vorhanden. Gut.

Dann fiel mir aber auf, daß ich sogar zwei IPs per DHCP bezogen hatte!
Der Grund war, daß automatisch ein Connectionmanager connman installiert worden war. Wo die Abhängigkeit herkam, ist mir derzeit noch unklar (eventuell aus einer LXDE Verquickung). Unter Preferences>Connman Settings startet ein grafisches Tool zur Netzwerkkonfiguration, laut Prozessliste namens connman-gtk.

Habe beschlossen, diesem Tool erstmal eine Chance zu geben, da es auch WLAN verwalten kann, welches ich in seltenen Ausnahmen auf der Kiste verwende. Den systemd-networkd.service habe ich wieder disabled und in der Folge auch nur noch eine einzelne DHCP-IP.

Connman-gtk scheint unter Debian bullseye nur eine einzige eth-Verbindung namens "Wired" zuzulassen. Diese ließ sich zwar bequem von DHCP auf statische Adresse ändern, aber bei jedem Zurückwechseln auf DHCP gehen die statischen Einträge wieder verloren und müssen erneut gesetzt werden, grummel. Ob und wie man mehrere Verbindungen unter Debian's connman konform einrichten kann, muss ich erst noch erkunden. Scheint wohl nur auf einen Standard-User ausgelegt zu sein, der sein eth einmal einrichtet und dann nie wieder.

Positiv zu vermerken ist, daß "Wireless" mit Connman-gtk eingerichtet werden kann und auch funktioniert. Hier wäre mit systemd-networkd vermutlich noch viel Zusatzarbeit nötig.

Was noch herauszufinden ist, warum die /etc/resolv.conf nicht mit dem nameserver aus connman-gtk bestückt wird. Einerseits gut zu wissen, daß ich mich auf meine eigene resolv.conf "verlassen" kann, aber irgendwie auch doppelt-gemoppelt, wenn das Setting in connman dort nicht landet (oder auch der DNS vom DHCP). Ich habe den vagen Verdacht, daß dazu noch systemd-resolved.service oder Ähnliches laufen muss.

Wer mir bei den unklaren Punkten die Sucherei etwas abkürzen kann - sehr gerne!

[KP97]

Hier wäre mit systemd-networkd vermutlich noch viel Zusatzarbeit nötig.

Gar nicht mal, ich hatte vor einiger Zeit mal eine Anleitung geschrieben: 41289
Ist schon etwas her, aber genauso kann man es machen. Dann habe ich vor einiger Zeit mal iwd getestet. Funktioniert auch ganz hervorragend für Wlan, entweder nur auf der Konsole
oder man kann auch eine grafische Oberfläche kompilieren.
Alles sehr simpel und es braucht keinen wpasupplikant: https://github.com/J-Lentz/iwgtk

[whiizy]

Hui,
jetzt habe ich wenigstens schonmal eine Ahnung, wie sich Wireless zusätzlich zu Wired in systemd-networkd unterbringen ließe. Danke KP97, ist schonmal "gebookmarkt"! Es stellen sich aber auch damit wieder ähnlich schattierte Fragen ... sind die selbstgemachten Units sauber in systemd und Debian intergriert (auch wenn sie ihren Job gut machen) ... wie wird die resolv.conf jeweils gehändelt ... will man bei jedem Netzwerkwechsel Dateien umbenennen ... und erinnert man sich dann daran ...
Das waren jetzt aber auch nur allererste Assoziationen.

[KP97]

Wenn Du das einmal eingerichtet hast, läuft das problemlos, da muß man nichts umbenennen, was denn auch, Du hast doch alles abgedeckt.
Mit systemd-resolved wird ein Link nach /run/systemd gelegt, und das bleibt dann auch so. /run ist ja virtuell und wird bei jedem Neustart neu angelegt, das weißt Du ja sicher.
Selbst nur mit einer resolve.conf in /etc ohne den Link nach /run funktioniert es, es muß natürlich die richtige Router IP eingetragen sein.
Das sind meine Einträge, mal als Muster

nameserver 192.168.0.1
nameserver 80.69.96.12

Die Services sind systemd-konform, sonst würden sie nicht funktionieren.
Ansonsten verstehe ich Deine Bedenken nicht, probiere es einfach aus.

[whiizy]

Also ich habe auch keine Zweifel, daß deine vollständige systemd-Integration funktioniert. Hatte deinen Link wie gesagt auch erstmal nur überflogen ->

"Also den wpa-Service disabled und die beiden Dateien zum wlan umbenannt. Sollte ich wlan nutzen wollen, brauche ich nur den Service wieder enablen und die Dateien wieder umbenennen."

Ich kann mit connman-gtk wie gesagt auch damit leben, daß ich manuell je nach Netzwerk den nameserver-Eintrag ändern muss. Ich denke es wird auch funktionieren wenn ich beide nameserver statisch eintrage, je nach Wireless oder Wired ist ja einer der beiden nameserver nicht erreichbar und dann sollte der andere antworten. Wird wohl auch funktionieren, aber schön finde ich das eigentlich nicht. Besser fände ich, wenn die jeweilig konfigurierte Verbindung die resolv.conf eindeutig setzen würde.

Wie ich jetzt noch gesehen habe spielt connman unter Debian per default DNS-Proxy und lauscht auf Port 53 UDP auf ich meine 127.0.1.1. Aber auch diese Adresse wird ja nicht automatisch in die /etc/resolv.conf eingetragen (zumindest auf meinem System). Da ich dieses DNS-caching von connman nicht möchte/brauche, habe ich es wie folgt abgestellt, angelehnt an https://wiki.archlinux.org/title/ConnMan

Kurz in Worten: connman soll mit der Option --nodnsproxy gestartet werden.

Code: Alles auswählen

Hilfsmittel ist ein systemd drop-in:

/lib/systemd/system# mkdir connman.service.d
/lib/systemd/system/connman.service.d# touch disable_dns_proxy.conf
->
[Service]
ExecStart=
ExecStart=/usr/sbin/connmand -n --nodnsproxy

Einlesen und Aktivieren:
systemctl daemon-reload
systemctl stop connman.service
systemctl start connman.service

[KP97]

Also ganz generell kann nur ein Tool das Netzwerk managen, parallel zwei Tools verursachen Fehler.
Entscheide Dich für eines und konfiguriere es entsprechend.

[whiizy]

Ganz klar. Ist momentan ja auch weiterhin so. Wicd von buster ist futsch. Connman.service von bullseye mit connman-gtk ist erstmal mein Ersatz.

Grafisch hakelt die Netzwerkkonfig so scheint es wie eh und je ein wenig (KDE oder Gnome wirken in dieser Beziehung recht ausgereift) und wenn es Hand und Fuß haben soll, muss man sowieso systemnah werkeln.

PS: Irgendwie ist mir immer noch nicht klar, wie connman mit der resolv.conf prinzipiell umgeht, werde mal weiter suchen ...

[whiizy]

PPS: Deine Erwähnung von /run, KP97, hat mich glaube ich noch in die richtige Richtung gestupst.
connman-gtk erzeugt beim Start einer Verbindung dynamisch eine /var/run/connman/resolv.conf, Beispiel:

Code: Alles auswählen

# Generated by Connection Manager
nameserver 192.168.88.44

Also habe ich die jetzt mal symbolisch verlinkt:

Code: Alles auswählen

/etc# ln -s /var/run/connman/resolv.conf resolv.conf

Somit werden die nameserver jetzt je nach Verbindung aktualisiert.

Allerdings scheint diese Generierung von connman-gtk etwas buggy zu sein. Sobald mal ein IPv6 nameserver per DHCP bezogen wurden, wird dieser beim Verbindungswechsel meist nicht wieder sauber aus der resolv.conf entfernt. Zwingt mich dazu, das sicherheitshalber immer zu kontrollieren und dann ggf. noch von Hand zu löschen. Werde diesbezüglich mal nach bugreports schauen und ansonsten wohl selbst einen aufmachen.

[KP97]

Dieser connman scheint eine Abhängigkeit von LXQT bzw. LXDE zu sein.
An anderer Stelle hatte @edmund schon einmal eine Fehlermeldung beschrieben, die der connman in seinem systemd-networkd verursachte, weil der Service des connman beim Rechnerstart mit ausgeführt wurde. Ich meine mich zu erinnern, er hat dann den connman deinstalliert und dann war Ruhe.

[whiizy]

Also wie bereits gesagt, bei mir ist der systemd-networkd gezielt disabled. Ich hatte den nur angeschaltet und als DHCP client eingerichtet, weil ich den wicd noch vor dem dist-upgrade auf bullseye entfernt hatte. Der systemd-networkd hat mir also nur gewährleistet, daß ich vor, während und nach dem dist-upgrade immer ein intaktes Netzwerk hatte (und nicht der wicd unter den Füßen weggerissen wurde).

Etwas überrascht worden war ich ja nur, als mir lxde anscheinend über seine Recommends den connman-gtk reingeholt hatte. Ich hatte also kurzzeitig zwei DHCP clients aktiv, was mir über gleich zwei geleaste IPs schnell aufgefallen war:

Code: Alles auswählen

  
# apt-cache show lxde 
Package: lxde
Source: lxde-metapackages
Version: 11
Installed-Size: 10
Maintainer: Debian LXDE Maintainers <pkg-lxde-maintainers@lists.alioth.debian.org>
Architecture: all
Depends: galculator | gnome-calculator, gpicview, mousepad | leafpad, lxappearance, lxappearance-obconf, lxde-core, lxde-icon-theme, lxhotkey-gtk, lxinput, lxrandr, lxsession-edit, lxterminal, xarchiver
Recommends: connman-gtk | network-manager-gnome | wicd, deluge | transmission-gtk, evince | pdf-viewer, gnome-disk-utility, smplayer | vlc | mplayer-gui, gnome-colors, gnome-system-tools, gucharmap, firefox-esr | firefox | www-browser, lightdm | x-display-manager, lxmusic | audacious, lxpolkit, menu-xdg, parcellite | clipit | copyq, numlockx, usermode, xserver-xorg
[...]

Wie beschrieben habe ich deshalb seitdem den systemd-networkd wieder bewusst abgeschaltet und weiter nur den connman-gtk vom desktop aus benutzt:

Code: Alles auswählen

# systemctl status systemd-networkd
● systemd-networkd.service - Network Service
     Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
TriggeredBy: ● systemd-networkd.socket
       Docs: man:systemd-networkd.service(8)


# systemctl status connman.service 
● connman.service - Connection service
     Loaded: loaded (/lib/systemd/system/connman.service; enabled; vendor preset: enabled)
    Drop-In: /lib/systemd/system/connman.service.d
             └─disable_dns_proxy.conf
     Active: active (running) since Wed 2021-12-29 20:39:03 CET; 13min ago
   Main PID: 404 (connmand)
      Tasks: 1 (limit: 9337)
     Memory: 7.5M
        CPU: 132ms
     CGroup: /system.slice/connman.service
             └─404 /usr/sbin/connmand -n --nodnsproxy
[...]

Seitdem kämpfe ich ja eigentlich nur ein wenig mit dem Reifungszustand von connman-gtk unter bullseye - kommt mir zumindest so vor

[whiizy]

... die Umstellung auf "Predictable Network Interface Names" macht connman übrigens keine Probleme. Habe jetzt anlässlich Bullseye manuell darauf umgestellt (nun enp4s0 und wlp1s0) und connman-gtk verwendet die automatisch.

Zusammengefasst läßt sich wohl Folgendes sagen:

Wenn man vor bullseye wicd mit DHCP laufen hatte, wird nach dem dist-upgrade connman dessen DHCP-Verbindung automatisch übernommen haben. In diesem Szenario wären meine Bedenken und der temporäre Umweg über systemd-networkd wohl unnötig gewesen.

Anders sieht es wahrscheinlich aber bei einer statisch konfigurierten Netzverbindung aus. Ich glaube kaum, daß connman automatisch die statischen IP-settings von wicd importiert hätte. Aber vielleicht liege ich da falsch und irgendein postinst-script hätte dafür gesorgt. Vielleicht hat jemand hier diese Erfahrung schonmal gemacht und kann das noch verifizieren.