< zurück >

Warum Selnic?

Selnic ist als Bash-Script mit dem Ziel entstanden, eine grundlegende Unterstützung beim Öffnen und Schließen eines Netzwerk-Adapters sowie beim Herstellen einer Netzwerkverbindung zu erhalten. In gewisser Weise übernimmt Selnic damit einen Teil der Aufgaben eines traditionellen Netzwerk-Managers, ohne aber selber ein Netzwerk-Manager sein zu wollen. Selnic ist kein Daemon, sondern ein immer im Vordergrund laufendes Terminalprogramm, es kann aber trotzdem auch via Desktopstarter im Dialog-Modus gestartet werden. Insbesondere im Dialog-Modus ist das, was selnic tut, durch den aktivierbaren Tracemode hoch transparent. Weil selnic wegen dem Öffnen und Schließen von Netzwerkadaptern root-Rechte benötigt, ist hier jedoch eine Polkit-Policy plus einer Berechtigungsregel notwendig und auch sinnvoll. Es sind die folgenden Ziele, die ich mit selnic erreichen wollte:

1.

Verhinderung von laufenden Diensten wie dhcpd und networkmanager, die ich generell für unsere Systeme für unerwünscht erachte und die mit selnic jetzt auch überflüssig sind.

2.

Beseitigung altbekannter Fehler und Probleme

 

-

Verhindern, dass die herkömmlichen Networkmanager beim Shutdown WLAN-Verbindungen trennen, bevor die Netzwerk-Mounts 'umount'ed sind, was im Regelfall in diesen unschönen 120-Sekunden-Stobjobs endet, die den Shutdown blockieren.

 

-

Die fehlende Abstimmung zwischen Netzwerk-Verbindung und Netzwerk-Mounts beseitigen, weil eine vorhandene Netzwerkverbindung auf meinem Laptop nicht bedeutet, dass auch meine Server-Platten erreichbar sind. Das bedeutet, wenn sich mein Laptop zuhause via WLAN verbindet, sollen die Server-Platten gemountet werden, unterwegs und bei Anmeldung an fremden WISP jedoch nicht. Wenn ich jedoch unterwegs via OpenVPN verbunden bin, will ich die Mounts übers Menü aber ggf. doch ermöglichen.

3.

Eine reine Vordergrundanwendung zu haben, die mir nicht im Hintergrund irgendwie ins Handwerk pfuscht und mit der ich notfalls auch gleichzeitig eth0 und wlan0 verbinden kann, was z.B. der Networkmanager gar nicht zulässt. Genau das brauche ich aber, wenn ich beispielsweise unterwegs via Kabel über meinen WLAN-Router den AccessPoint auf dem Dach einstellen will und gleichzeitig dabei die WLAN-Netze sehen muss.

4.

Eine optimale Unterstützung auf der Reise bei täglichen wechselnden WLAN-Anbietern zu haben. Das heißt, fremde WISP werden nur bei Bedarf ad hoc und manuell verbunden, aber beim nächsten Einschalten wird nicht dauerhaft versucht, den letzten WISP erneut zu verbinden. Eine automatische Verbindung, die im Hintergrund erfolgt, darf auf gar keinen Fall durchgeführt werden, nur weil der NWM meint "Ach, den kenn ich ja noch vom letzten Mal".

5.

Völlig flexibel den Laptop auf Reisen mit und ohne Netzwerk zu betreiben. Es wird nichts automatisch verbunden, aber eine Verbindung zum vorhanden WLAN-Netz kann jederzeit mit einem Klick hergestellt werden, sofern bereits eine SSID.conf besteht.

6.

Die Möglichkeit, völlig transparent in den von selnic erstellten SSID-eigenen /etc/wpa_supplicant/*.conf's manuell optimale Anpassungen durchführen zu können, falls selnic Probleme hat, einen WISP und dessen Einstellungen sauber zu identifizieren.

7.

Die Einbindung meiner Unit "mountctl.service", mit der ich über selnic's Menü meine Netzwerk-Mounts verbinden kann. selnic sorgt beim Trennen vom WISP dafür, dass die Mounts vorher ordentlich geschlossen werden.

8.

Flexibel bei Verbindung in fremden Netzwerken eine OpenVPN-Verbindung zum heimischen Router herstellen zu können, um entweder sicher zu surfen oder Zugang ins Heimnetz zu erhalten, z.B. für Mailserver, Festplatten

 

!

selnic kann nicht konfliktfrei gleichzeitig mit dem dhcpd-Daemon und dem networkmanager-Daemon betrieben werden. Ich persönlich halte dhcpd und NWM sowieso für überflüssig, insofern beachte ich das auch nicht weiter.

 

Überblick:       

 
 
 

Selnic-Menü ohne die Service-Units:

-  /etc/systemd/system/mountctl.service

-  /etc/systemd/system/openvpn@.service

 
 

Selnic-Menü mit Service-Unit

-  /etc/systemd/system/mountctl.service

 
 

Selnic-Menü mit Service-Units:

-  /etc/systemd/system/mountctl.service

-  /etc/systemd/system/openvpn@.service

 
 

Selnic-Menü mit Service-Units:

-  /etc/systemd/system/mountctl.service

-  /etc/systemd/system/openvpn@.service

 
 
 

Wenn die folgenden Service-Units installiert sind,

-  /etc/systemd/system/mountctl.service

-  /etc/systemd/system/openvpn@.service

ist  Voraussetzung, dass auch die (bzw. eine alternative) mountctl-Infrastruktur installiert ist. Ebenso ist Voraussetzung, dass OpenVPN installiert ist. Zur interaktiven Anzeige der OpenVPN-Verbindung ist es darüber hinaus notwendig, in den OpenVPN-Client-Conf-Files das Log in der Datei /var/run/openvpn/client.log zu aktivieren. Die  OpenVPN-Client-Conf-Files werden im Verzeichnis /etc/openvpn erwartet und nur dort gesucht.

Wenn Selnic bereits im Boot-Prozess über eine Service-Unit gestartet werden und sofort auch Netzwerk-Mounts über die mountctl-Infrastruktur durchführen soll, so ist zwingend die Angabe des Usernamens erforderlich, unter dem die Mounts durchgeführt werden sollen. Das reguläre Verfahren ist, dass mountctl erst nach dem Login eines Users aktiv wird und zum Mount den Namen und die Credentials dieses Users verwendet. In der Boot-Phase ist jedoch kein Sambaberechtigter User bekannt. In dem Fall muss der User in der Service-Unit explizit angegeben werden, z.B.:

ExecStart=/usr/local/bin/mountctl start thomas

Wenn mountctl.service jedoch planmäßig von sessionctl oder von selnic im Vordergrund-Dialog gestartet wird, ist das nicht notwendig, weil in beiden Fällen durch sessionctl der angemeldete User bekannt ist.

Wenn die Funktionen mountctl und openvpn nicht verwendet werden und die entsprechenden Service-Units nicht vorhanden sind, findet im Programm auch keine weitere Berücksichtigung statt.

Und eine Wiederholung, damit es nicht übersehen wird:

selnic kann nicht konfliktfrei gleichzeitig mit dem dhcpd-Daemon und dem networkmanager-Daemon betrieben werden!

< zurück >