© iofoto, 123RF

Das Systemd-Projekt hilft dem Admin dabei, seine Aufgaben auf einer relativ abstrakten Ebene zu erledigen. Auch der neue Bestandteil Networkd führt weg vom spezifischen Klein-Klein. Trotz des frühen Entwicklungsstadiums zeigt sich: Der Daemon hat Köpfchen.

Fedora seit Version 15, das neue RHEL 7, Open Suse seit 12.1, Mandriva 2011, Debian 8, Mageia 2, Gentoo, Arch Linux oder Tizen – sie alle setzen auf Systemd ([1], [2]). Sogar Ubuntu wird vom eignen Upstart zum Systemd schwenken. So viele können nicht irren – und dies, obwohl sich Systemd radikal am System zu schaffen macht. Die Systemd-Erfinder Lennart Poettering und Kay Sievers machen sich damit nicht nur Freunde.

Ein oft gehörtes Argument in dieser Diskussion ist die Aussage, Systemd würde eines der wesentlichen Prinzipien von Unix verletzen: “Make each program do one thing well” [3]. Lennart Poettering (Abbildung 1) widerspricht dieser Ansicht natürlich [4]. Währenddessen wachsen der Funktionsumfang und der Anspruch von Systemd weiter.

In diesem Zuge fügte der norwegische Entwickler Tom Gundersen am 17. Oktober 2013 dem Projekt eine passende Netzwerk-Basisfunktionalität hinzu. Der naheliegend auf Systemd-Networkd [5] getaufte Daemon ist seit Release 210 Teil des Systemd-Projekts. Das Projekt zielt darauf ab, vornehmlich die Netzwerkeinstellungen von Linux-Servern und virtuellen Linux-Maschinen vorzunehmen, weniger die von mobilen Geräten oder Desktops. Deshalb besitzt Systemd-Networkd bislang zum Beispiel noch keinen Wifi-Support.

Die besondere Stärke liegt auf statisch konfigurierten Netzwerken. Mit einer recht mächtigen Syntax können Admins das Netzwerk abhängig von vorliegenden Umgebungsbedingungen konfigurieren, beispielsweise anhand von Eigenschaften der physischen Netzwerkgeräte, der Architektur des Servers oder der Art der Virtualisierung.

Aktuell unterstützt Networkd statische IPv4- und IPv6-Adressen sowie dynamische IPs per DHCPv4 und IPv4LL. Auch mit Bridging, Bonding und VLANs kommt der Daemon zurecht, mit IPIP- (IP-in-IP) und SIT-Tunnel (Simple Internet Transition) ebenso. Bei der zum Redaktionsschluss letzten Version 214 fügten die Entwickler Support für Virtual Ethernet Devices (»veth« ) sowie GRE-Tunnel (Generic Routing Encapsulation) und VTI (Virtual Tunnel Interface) hinzu. All dies leistet Networkd mit eigenen Libraries, die in Zukunft auch für Third-Party-Programme nutzbar werden sollen [6].

Abbildung 1: Systemd-Entwickler Lennart Poettering (im Jahre 2012). Auf den in Guatemala geborenen Deutschen gehen auch Pulseaudio und Avahi zurück.

Weniger Aufwand

Networkd überwacht das Networking sowohl auf der administrativen als auch auf operationaler Ebene:

• Administrativ detektiert der Daemon, wer das Gerät managt (Systemd-Networkd oder ein anderes Framework?) und ob die Konfiguration noch im Gange oder bereits abgeschlossen ist.
• Operational stellt die Software fest, ob Udev die Low-Level-Einstellungen getroffen hat, ob das Gerät eingeschaltet ist, das Kabel eingesteckt, ob eine und – wenn ja – welche IP gesetzt ist.

Um einem Server eine statische IP zu geben, braucht dieser keine extra Pakete mehr, denn ein sowieso vorhandener Systemd erledigt die Netzwerk-Initialisierung und -Konfiguration selbst. Ein Vorteil gegenüber größeren Konfigurationstools wie dem Gnome Networkmanager, Wicd oder Conn Man ist die geringere Komplexität: Weniger Pakete sind zu installieren, zu warten oder zu patchen. Auch benötigt der Betrieb weniger Ressourcen.

Der Logik von Systemd folgend ist der Daemon als Service namens »systemd-networkd.service« ausgeführt, Systemctl aktiviert und startet ihn:

systemctl enable systemd-networkd.service
systemctl start systemd-networkd.service

Analog zu den Systemd-Servicefiles existieren auch für Networkd vorbereitete Konfigurationsdateien in »/usr/lib/systemd/network« , die der Admin mit lokal in »/etc/systemd/network« anlegten Dateien ergänzen kann, die zudem eine höhere Priorität innehaben. Derzeit gibt es drei Typen von Konfigurationsdateien: ».link« , ».network« und ».netdev« .

».link« -Dateien

Mit Link-Dateien nimmt Networkd grundlegende Einstellungen der Netzwerkgeräte vor (Name der Netzwerkschnittstelle, MTU, Wake on LAN, modifizierte MAC-Adresse), ohne die Dienste von zum Beispiel Ethtool in Anspruch zu nehmen. Link-Dateien enthalten einen »[Match]« -Block, in dem der Admin mit einfachen Schlüsselwörtern definiert, auf welche Geräte er die Änderungen im ebenfalls enthaltenen »[Link]« -Block anwenden will. Das Beispiel in Listing 1 trifft auf ein Intel-E1000-Gerät mit einer bestimmten MAC-Adresse zu. Die Zeilen 4 bis 6 fragen ab, in welchem PCI-Slot das Gerät steckt, ob das System in einer virtuellen Maschine läuft und ob das Betriebssystem ein 64-Bit-System ist.

Die im Beispiel gewünschten Settings betreffen den Gerätenamen, eine MTU von 1450 Bytes und einen Durchsatz von nur 10 MBit/s. Zeile 12 ändert die MAC-Adresse ab. Technisch betrachtet führt Udev, das seit 2012 Teil des Systemd-Projekts ist, die Änderungen aus, bevor es dem Userspace Existenz und Eigenschaften des Geräts mitteilt, um eventuellen Konflikten zu begegnen.

Ein ».link« -File kann, aber muss nicht für jedes Gerät existieren, denn Networkd wendet zusätzlich ein Standard-Link-File auf alle Geräte an, das Basispolicies für den Umgang mit Namen und MAC-Adressen beinhaltet.

Streng genommen sind diese Link-Files nicht Teil des Networkd, sondern ein Udev-Aufsatz, bei dem der Admin mit einer möglichst simplen und selbsterklärenden Syntax für eine tiefere Ebene Einstellungen vornimmt, ohne sich in die komplexe Syntax und Logik von Udev-Regeln einlesen zu müssen. Hier zielt Networkd offenbar auf die Bedürfnisse von Maintainern ab, die Linux-Distributionen paketieren. Im gleichen Maße profitieren Live-Medien, die abhängig von der Umgebung das gestartete System passend konfigurieren wollen.

01 [Match]
02 MACAddress=12:34:56:78:9a:bc
03 Driver=e1000
04 Path=pci-0000:02:00.0-*
05 Virtualization=no
06 Architecture=x86-64
07
08 [Link]
09 Name=enp0s25
10 MTUBytes=1450
11 BitsPerSecond=10M
12 MACAddress=cb:a9:87:65:43:21

».network« -Dateien

Die Network-Dateien konfigurieren den Systemd-Networkd unmittelbar. Dabei kommt die gleiche Matching-Logik wie in den Link-Dateien zur Anwendung: Ein »[Match]« -Block definiert die Geräte, auf die der Daemon die Settings im Block »[Network]« anwendet:

[Match]
Name=en*
[Network]
DHCP=yes

Das Beispiel bewirkt, dass für alle Interfaces, deren Namen mit »en« beginnen, DHCP startet. Das Setzen einer statischen IP zeigen folgende Zeilen:

[Match]
Name=enp0s25
[Network]
Address=192.168.0.34/24
Gateway=192.168.0.254

Meist ist der Admin an diesem Punkt bereits fertig mit der Konfiguration, und der Server oder die VM beziehen bei aktiviertem Systemd-Networkd ihre IPs korrekt beziehungsweise bekommen sie gesetzt.

».netdev« -Dateien

Auch wer virtuelle Netzwerkgeräte anzulegen hat, wird bei Networkd fündig. Der Admin kann über »*.netdev« .-Dateien so genannte Net Devices konfigurieren, derzeit sind das Bridges, Bonded Interfaces und VLANs. Um etwa eine Bridge namens »br0« zu errichten, legt der Admin eine Datei namens »br0.netdev« an (den Dateinamen vor dem Punkt kann man nach Belieben vergeben):

[NetDev]
Name=bridge0
Kind=bridge

Zusätzlich fügt der Admin allen Network-Dateien die Eigenschaft

Bridge=bridge0

hinzu, was das Gerät als Mitglied und Teil der Bridge definiert.

Eine praktische Anwendung für eine solche Netzwerkbrücke ist der Betrieb eines Virtualisierungsservers, bei dem der Admin den VMs einen Weg ins physische Netzwerk bahnt. Ein Beispiel aus der Praxis: Auf dem Rechner des Autors läuft KVM als Virtualisierungsplattform, es existiert eine einzelne physische Gigabit-NIC namens »enp6s0« ([7], seit Udev 197). Um einer Bridge nun diese NIC hinzuzufügen, bedarf es mehrerer Schritte, beginnend mit »static.network« :

[Match]
Name=enp6s0
[Network]
Bridge=br0

Das physische Gerät »enp6s0« bekommt die Eigenschaft “Teil der Bridge namens »br0« “. Die Bridge ist ein Network Device, eine Datei vom Typ »netdev« definiert sie, im Beispiel eine »br0.netdev« :

[NetDev]
Name=br0
Kind=bridge

Die Bridge existiert jetzt, besitzt aber noch keine gültige IP-Adresse. Das holt eine »bridge.network« -Datei nach:

[Match]
Name=br0
[Network]
Address=172.31.98.12/24
Gateway=172.31.98.250

Mit diesen drei kleinen Dateien ist die Konfiguration vollständig und der Networkd stellt die Verbindungsdaten für Host und VMs her. Das ist im Vergleich zu bisher erforderlichen Systemd-Servicefiles erfreulich simpel und gut verständlich. Der Autor musste sich bei seinem ersten KVM-Setup mit Systemd auf Gentoo Linux noch mit einem ellenlangen Servicefile (»/etc/systemd/system/bridge.service« ) plagen.

Ergänzend konnte der Autor an dieser Stelle zwei weitere Dinge erledigen, anstatt sie unübersichtlich an verschiedenen Stellen separat zu konfigurieren: Einerseits das Erzwingen des Full-Duplex-Gigabit-Modus. Bislang erledigte man dies mit einer Zeile in einem lokalen Startskript:

ethtool -s enp6s0 speed 1000 duplex fullautoneg on

Zweitens geht es um das Aktivieren von Wake-on-LAN (WOL), um die Maschine remote einschalten zu können. Dafür war bislang eine eigene Systemd-Unit nötig, zu sehen in Listing 2. Sowohl WOL wie auch Gigabit-Konnektivität gelingt nun elegant in einem einzigen Networkd-Link-File (Listing 3).

01 [Unit]
02 Description=Wake-on-LAN for %i
03 Requires=network.target
04 After=sys-subsystem-net-devices-%i.device
05
06 [Service]
07 ExecStart=/usr/sbin/ethtool -s %i wol g
08 Type=oneshot
09
10 [Install]
11 WantedBy=multi-user.target

01 [Match]
02 MACAddress=38:60:77:33:11:22
03
04 [Link]
05 MTUBytes=1500
06 BitsPerSecond=1G
07 Duplex=full
08 WakeOnLan=magic

Ziele und Vorteile

Bei den meisten dedizierten Servern, aber auch bei Embedded-Geräten, ist die Netzwerkkonfiguration für die ganze Betriebsdauer recht statisch. Hat sich der Admin für Systemd als Initsystem entschieden, deckt Networkd gleich das Netzwerksetup mit ab, ohne dass er weitere Pakete installieren und warten müsste.

Hinzu kommt die Performance: Auf dem System des Autors bezifferte das Analysetool »systemd-analyze« die Startzeit von Systemd-Networkd mit flotten 3 Millisekunden. Auch das Beziehen von IPs per DHCP ist schnell, Messungen des Entwicklers zeigen erstaunlich kurze DHCP-Dialoge – wenn auch im Labor und ohne Check, ob die IP irgendwo im Subnetz bereits vergeben ist.

Wer im Serverraum vorrangig auf Virtualisierung setzt, dem eröffnet Systemd-Networkd weitere Möglichkeiten: Läuft eine virtuelle Maschine mal auf diesem und später auf jenem physischen Host, ist es mit den Link-Files möglich, innerhalb der VM je nach aktueller Umgebung automatisch das korrekte Netzwerksetup zu definieren.

Die Netzwerkkonfiguration darf zu einem sehr frühen Zeitpunkt, bei Bedarf bereits per Initram-FS, stattfinden. Kombiniert mit den sehr kurzen Boot- und Shutdown-Zeiten, die mit Systemd möglich sind, fällt es leichter, VMs on Demand ein- und auszuschalten. Im Speziellen sind die Container zu erwähnen, die Systemd-Nspawn betreiben kann (siehe zum Beispiel [8]).

Aktuelles und Ausblick

Der Networkd interagiert zunehmend mit anderen Subsystemen von Systemd. Die Daemons Systemd-Timesyncd und der in einem frühen Entwicklungsstadium befindliche Systemd-Resolved, die bei den letzten Releases hinzukamen, sind abhängig vom Status der Netzwerk-Konnektivität und daher eng mit Networkd assoziiert. Sie sorgen für das korrekte Synchronisieren der Systemzeit beziehungsweise setzen den DNS-Server. Hier sind weitere Features geplant, darunter DNSSEC und M-DNS-Caching.

Bei Redaktionsschluss in Vorbereitung befindlich waren ein DHCPv6-Client sowie ein DHCPv4-Server. Die Entwickler denken nicht daran, Platzhirsche wie den ISC-DHCP-Server zu ersetzen, sondern eher an den Spezialfall der Container-Virtualisierung. Hierbei könnte ein Host per Networkd IPs an die von ihm betriebenen Container vergeben. Ein anderer möglicher Anwendungsfall ist der Betrieb von Hotspots auf mobilen Geräten. Diese Ideen sind noch in der Diskussion und Entwicklung begriffen.

Die Systemd-Networkd-Entwickler sind im Dialog mit den Maintainern des Gnome-Networkmanagers oder denen von Connman, um Doppelgleisigkeiten zu vermeiden und sinnvolle Schnittstellen zu schaffen.