Debian Basics mit systemd

systemd

Mit dem (hoffentlich baldigem) Release von Jessie wird Debian um systemd erweitert, wie wohl endlich feststeht.
Vorab möchte ich drei systemd Dienste vorstellen, die meiner Meinung nach eine große Bereicherung- und jetzt schon ein Teil Debians sind.

timesyncd, resolved und networkd.

Besonders der networkd erleichtert und – vorallem – vereinheitlicht die Konfiguration komplexer Netzwerke deutlich.
Holt die Mistgabeln raus und jagt mich, aber ich finde systemd gelungen…

Bevor es losgeht, werfe ich noch kommentarlos zwei ctl’es in den Beitrag:

timedatectl set-timezone Europe/Berlin
hostnamectl set-hostname meinhostname

systemd-timesyncd

Mit dem timesyncd bringt systemd ein einfaches Werkzeug zu Synchronisation der Zeit mit.
In der Konfigurationsdatei einige Zeitserver nach Bedarf ändern, hinzufügen oder entfernen:

nano /etc/systemd/timesyncd.conf

[Time]
Servers=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org

Der Dienst wird im Anschluss aktiviert und gestartet:

systemctl enable systemd-timesyncd
systemctl start systemd-timesyncd
„systemctl enable“ entspricht etwa dem bekannten „update-rc.d xyz defaults“

Admins virtualisierte Computer überschreiben den Parameter „ConditionVirtualization“ des Dienstes, falls wirklich gewünscht, mit einer Konfigurationsdatei:

mkdir /etc/systemd/system/systemd-timesyncd.service.d
echo -e "[Unit]\nConditionVirtualization=" > /etc/systemd/system/systemd-timesyncd.service.d/virt.conf
systemctl daemon-reload
systemctl restart systemd-timesyncd.service
Das Delta aller überschriebenen Parametern wird im Diff-Format durch „systemd-delta“ ausgegeben.

Mit dem Befehl timedatectl nach Bedarf die Gültigkeit der Einstellungen überprüfen.

systemd-resolved

Bevor ich zur eigentlichen Konfiguration des Netzwerks komme, ein paar Worte zur Besonderheit des networkd.

Die Datei „/etc/resolv.conf“ wird vom networkd nicht berührt. Stattdessen kommt der Dienst resolved zum Einsatz, der eine dynamische „resolv.conf“-Datei generiert und unter „/run/systemd/resolve/resolv.conf“ bereitstellt. Für Kenner des Paketes „resolveconf“ nichts neues.
Diese Datei wird im Anschluss nach „/etc/resolv.conf“ verlinkt.

Vielleicht doch noch ein paar Worte dazu… Ich denke, dass sich viele User schwer mit dem Gedanken tun, dass Nameserver nicht Bestandteil einer TCP/IP-Konfiguration sind, auch wenn es die Windows-Netzwerkkonfiguration suggeriert.
DNS ist ein eigener Dienst, „nice to have“, aber für den Transport nicht notwendig. Im Gegensatz zu TCP und IP (Vermittlung und Transport), baut DNS als Anwendung (!) auf diese auf. Ein Mailserver hätte hier einen ähnlichen Stellenwert.

Zuerst aktiviere und starte ich den Dienst:

systemctl enable systemd-resolved.service
systemctl start systemd-resolved.service

Nun zur Konfiguration.

nano /etc/systemd/resolved.conf

[Resolve]
DNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844

Alle hier definierten DNS-Server unterliegen in ihrer Priorität denen, die ich in einer network-Datei im Verlauf festlege.
Die hier definierten Einträge werden jedoch als alternative Server hinter die primären DNS-Server angestellt.

Beispiel: Ich konfiguriere einen statischen DNS „192.168.1.1“ in einer Datei „my.network“, habe in der Datei „/etc/systemd/resolved.conf“ zusätzlich die DNS-Server „8.8.8.8 8.8.4.4“ eingetragen, so erhalte ich:

192.168.1.1
8.8.8.8
8.8.4.4

In späteren Systemd-Versionen wird resolved noch zwischen „DNS“ und „FallbackDNS“ unterscheiden können. Ein FallbackDNS käme nur zum Einsatz, wenn ansonsten keine Server definiert werden. Für das obige Beispiel würde das bedeuten, dass nur der DNS-Server 192.168.1.1 verwendet wird.

Im Anschluss erstelle ich den erwähnten Symlink und überschreibe eine evtl. vorhandene Datei „resolv.conf“:

ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

Den Dienst noch einmal neu starten:

systemctl restart systemd-resolved.service

Abschließend noch ein Hinweis zum Caching: Interessant wird es erst mit Systemd v216 (aktuell in Jessie: v215). Zudem stellte man Mitte November fest, dass das Caching des resolved angreifbar ist und daher vorert nicht eingesetzt werden sollte…

systemd-networkd

Die Netzwerk-Konfiguration findet in „/etc/systemd/network/“ statt.
Hier reicht eine network-Datei für ein funktionierendes Netzwerk aus.

Angenommen mein Device „eth0“ möchte ans Netz:

nano /etc/systemd/network/einbeliebigername.network

# Was muss zutreffen, damit die Konfiguration vorgenommen wird?
[Match]
# Wildcards sind möglich! "Name=eth*" für die gleichzeitige Konfiguration vieler Interfaces ist denkbar, aber nur selten sinnvoll (Beispiel: DHCP)
Name=eth0

# Die Netzwerkkonfiguration
[Network]
# Wenn ich kein DHCP verwende...
#DHCP=v4
# ...lege ich statische Einträge fest.
Address=192.168.1.2/24
Gateway=192.168.1.254
DNS=192.168.1.1

Als Debian-User entferne ich die gesamte vorherige Konfiguration und Konfigurations-Methodik des Adapters…

ifdown eth0
cp /etc/network/{interfaces,interfaces_bak}
cat /dev/null > /etc/network/interfaces
update-rc.d networking remove

…um networkd zu aktivieren und zu starten:

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

Im Verzeichnis „/etc/systemd/network/“ sind außer network-Dateien noch netdev- und link-Dateien möglich.
netdev-Dateien erstellen virtuelle Geräte. Etwa Bridges, VLANs etc. link-Dateien
Eine link-Datei beschreibt Eigenschaften eines Netzwerkgerätes, etwa MACAddress, Duplex Modus etc.

Ein Blick in die Hilfe lohnt sich unbedingt: http://www.freedesktop.org/software/systemd/man/
Es gibt sehr viele Einstellungsmöglichkeiten, die ich nicht erwähnt habe, welche aber ausführlich in obigen Manpages beschrieben sind. Da Systemd sich in aktiver Entwicklung befindet, können durchaus Parameter auftauchen, die im eigenen System noch nicht erkannt werden.

15 Antworten auf “Debian Basics mit systemd

  1. fine

    ich verstehe deine Argumentation zu Systemd jetzt nicht so richtig.
    Ich fand ehrlich gesagt den Hype um Upstart viel bedeutender.
    Upstart war ein Graus.
    Für mich zählt nur, daß der Manager seinen Dienst macht und die Prozesse richtig fehlerfrei laufen.
    Gegenüber Upstart sehe ich hier, daß es zu funktionieren scheint.
    Gegenüber udev habe ich eine leichte Verbesserung bei der Performance feststellen können.

    Zu Deiner Information. Sysv kann leider nur einen Dienst nach dem anderen verarbeiten, was das System eher altbacken werden lässt.
    Das Leben geht weiter die Welt dreht sich weiter.. und Sysv ist bald tot ebenso wie Slakeware und SCO Unix :D

    In dem Sinne!

  2. Michele

    Hallo, danke für den Artikel.

    Auf meinem Linux Mint Debian 201403 habe ich, nach dem ich das nachvollziehen wollte was du geschrieben hast, herausgefunden, das ein paar ausführbare systemd Dateien in /lib/system zu finden sind. Ich vermute das ich den Pfad anpassen muss :)

    Ich wüsste nicht was man an Systemd meckern kann. Das gute, und damit auch das schlechte am Linux ist doch die vielfallt, oder? Systemd wurde konzepiert damit verschiedene Systeme eine einheitliche Sprache zu Systemverwaltung haben. Ich glaube nicht, das ein Ding wie eine Software, es wert ist das sich Menschen streiten.

    Danke

  3. Stefan Betz

    Man verändert übrigens keine Dateien in /lib/systemd/system, dafür hat Systeme eigene Mechanismen die nicht mit denen der Paketverwaltung kollidieren. Sieh dir hierzu mal die Einleitung der Manpage von systemd.unit an, dazu auch noch gerne die Sektion „UNIT LOAD PATH“ ;)

    1. André P. Autor

      Hi,
      ja – systemd nimmt immer die Erweiterung .service an, wenn nichts weiter definiert wurde.
      In einem Artikel hat das aber meiner Meinung nach mit Erweiterung zu stehen, vor allem, wenn folgender Fall eintritt:

      systemctl enable xyz.path 
      systemctl enable xyz.service

      Grundsätzlich ist es natürlich gut, dass du es erwähnst, und danke dafür! :-)

      Viele Grüße

    1. André P. Autor

      Darüber lässt sich streiten. Ich finde systemd sehr gelungen und sauber geschrieben.
      Klar, es ist unglaublich aufgebläht. Es kann aber auch wirklich so vieles im gesamten Linux-Ökosystem erleichtern bzw. vereinheitlichen. Davon profitiert im Endeffekt die gesamte Community. Poetterings Egozentrik in der Thematik mal außen vor…

      1. tux.

        Du hast den ganzen systemd-Code durchgelesen?

        Was genau erleichtert es? Serveradministration schon mal nicht. Und ist Vereinheitlichung so eine gute Sache? „Haha, unter Windows hat man keine Auswahl! LOL! Oh, systemd <3"…

        1. André P. Autor

          Najo, zum Beispiel das Handling von CGroups (finde ich genial), Verwaltung von Diensten in Abhängigkeit zueinander, das Erstellen von Diensten, die gesamte Netzwerkverwaltung (! macvlan, bridges, viel einfacher geht es nicht) …
          Eigentlich kann es viel zu viel für das, was es mal werden sollte, das stimmt. Ich persönlich finde es okay und versuche das Beste aus den neuen Möglichkeiten zu machen.
          Die viel wichtigere Frage ist daher, ob es das denn alles können muss?
          Ich verstehe deine Meinung dazu. Schön wäre ja auch eine leichtere Variante, wobei es da schon genug Alternativen gibt, oder?
          Alles meine persönliche Meinung, wie gesagt…

          1. tux.

            Ja, leichtere Initsysteme, die keinen riesigen Klotz mitbringen, der einem /tmp und /var/log und /usr kaputtmacht, gibt es tatsächlich zuhauf. runit finde ich sehr schön. :)

            Dass SysVinit nicht mehr zeitgemäß ist, sehe auch ich als BSD’ler ein.

            1. André P. Autor

              Gerade BSD’ler sind eher minimalistisch, oder? :-) Da verstehe ich die Aufregung. Allerdings wird es ja wegen der fehlenden CGroups vorerst nicht portiert. Aber mal abwarten. Wobei ich nicht glaube, dass man es überhaupt versucht.
              Ich glaube, dass die Linux-Community die ganze Debatte überhaupt nicht mitbekommen hat und viele jetzt einfach überrannt werden mit systemd. Ich beschäftige mich auch noch nicht soo lange damit. Mir gefällts. Aber auch ein Stück weit deshalb, weil es mir gefallen muss…

              1. tux.

                Muss es nicht, du kannst auch Slackware nutzen, eins der letzten ernst zu nehmenden Linuxe.

                Ich weiß nicht, ob ich minimalistisch bin. Ich hab‘ nur was gegen Bloat. ;)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.