Systemd

Der Systemd ist eine SysVinit-Alternative.

• SysVinit- und Upstart-Alternative Systemd vorgestellt - 03.05.2010 10:53 Uhr

In dem sehr ausführlichen Blog-Eintrag erläutert Poettering Probleme aktueller Init-Systeme und erklärt, wie das noch sehr experimentelle und bislang lediglich via Git erhältliche Systemd es besser machen will. Damit der Systemstart möglichst schnell erfolge, dürfe das Init-System nur das unbedingt Nötigste ausführen und müsse so viele Aufgaben wie möglich parallel erledigen, um die Ressourcen effizient zu nutzen. Dienste sollten zudem erst starten, wenn sie benötigt werden – ähnlich wie beim (x)inetd, das Server-Dienste wie SSH, Telnet oder Webmin automatisch startet, wenn auf einem bestimmten Port zugriffen wird. Auch seien die vielen beim Start aktueller Linux-Distributionen ausgeführten Shell-Skripte ein Problem, denn die seien vergleichsweise langsam. Poettering erläutert ferner, warum ihm der Ansatz des derzeit von Fedora, OpenSuse und Ubuntu eingesetzte Upstart nicht gefällt; mehrfach positiv erwähnt er hingegen einige Eigenschaften des bei MacOS eingesetzten launchd.

…

Der bei Red Hat beschäftigte Poettering stellt in der FAQ am Ende der Ankündigung klar, dass Systemd sein Freizeitprojekt sei. Er hat sich aber mit Entwicklern verschiedener Firmen abgesprochen – darunter auch dem bei Novell beschäftigten Kay Sievers, der durch seine Arbeit als Udev-Maintainer bekannt ist. Poettering und Sievers scheinen auf eine Aufnahme in Fedora und OpenSuse hinarbeiten zu wollen, wenn weitere Experimente mit Systemd zeigen, dass das Konzept tragfähig ist.

…

Der Hauptentwickler von Upstart, Scott James Remnant, kommentierte Systemd kurz nach dessen Vorstellung in seinem Blog. Dort räumt er ein, dass Upstart keineswegs perfekt sei und dass er einigen von Poettering aufgebrachten Kritikpunkten nicht widersprechen kann. Nun, da Ubuntu 10.04 freigegeben sei, will er sich Upstart wieder mehr widmen und einige der kritisierten Eigenschaften angehen. Es sei viel zu früh, um abschätzen zu können, welche der beiden Ansätze langfristig der bessere sei.

Linux von systemd befreien: Alternativen für den init-Prozess - 08.06.2017 14:12 Uhr iX Magazin

Hier liegen die Unit-Dateien des systemd: /etc/systemd/system/

Oft liegen in etc die Symlinks und hier die richtigen Unit-Dateien: /usr/lib/systemd/system/

Auflisten von Services: ls -lha /etc/systemd/system/*.service

• *.service
• *.socket
• *.mount
• *.target
• und viele andere

> systemd-resolve --set-dns=192.168.1.1 --set-domain=lan --interface=eth0
> systemd-resolve --status
...

Link 2 (eth0)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 192.168.1.1
          DNS Domain: lan

• Systemd service file example
• systemd Service Unit Beispiel

/etc/systemd/system/myservice.service

[Unit]
Description=myservice
After=network.target auditd.service sshd.service
 
[Service]
### startet und läuft dauerhaft weiter ohne zu forken
Type=simple
### forkt - erzeugt weiter Prozesse (z.B. einige Webserver)
#Type=forking
### startet und arbeitet einen Auftrag ab, danach beendet es sich
#Type=oneshot
WorkingDirectory=/tmp/
EnvironmentFile=-/etc/default/myservice
ExecStartPre=/bin/echo "Dienst wird jetzt gestartet..."
ExecStart=/bin/bash -c "touch replace_this_line_with_your_binary_path"
ExecStartPost=/bin/echo "Dienst wurde gestartet."
 
[Install]
WantedBy=default.target
Alias=myservice.service

Anschliessend muss Systemd die Services neu einlesen:

> systemctl daemon-reload

Nun kann der Service gestartet werden:

> systemctl start myservice

Natürlich kann man den Service auch beim Booten automatisch starten lassen:

> systemctl enable myservice
> systemctl is-enabled myservice
enabled

https://github.com/masterflitzer/wake-on-lan

/etc/systemd/system/wol.service

[Unit]
Description=Wake on LAN
After=network.target
 
[Service]
Type=simple
ExecStart=/opt/cargo/bin/deno run --allow-net=0.0.0.0 --allow-read=/data/config --allow-run=wakeonlan /data/www/wol.masterflitzer.xyz/wake-on-lan.ts -p 8001 -c /data/config/wake-on-lan.json
Restart=on-failure
 
[Install]
WantedBy=multi-user.target

$ systemctl enable wol
$ systemctl start wol

DNS Server und Search Domains werden in dieser Konfiguration nur von DHCPv4 & RA bezogen, nicht von DHCPv6

/etc/systemd/network/default.network

# systemctl --version -> systemd 252
[Match]
Name=eth0 end0 enp0s*
 
[Network]
DHCP=true
IPv6LinkLocalAddressGenerationMode=stable-privacy
LLMNR=false
MulticastDNS=true
DNSOverTLS=opportunistic
DNSSEC=allow-downgrade
IPv6PrivacyExtensions=true
IPv6AcceptRA=true
 
[Route]
Gateway=_dhcp4
Gateway=_ipv6ra
 
[DHCPv4]
UseDNS=true
UseDomains=true
 
[DHCPv6]
RapidCommit=true
UseDNS=false
UseDomains=false
 
[IPv6AcceptRA]
# eui64
#Token=eui64
# rfc7217
Token=prefixstable
UseDNS=true
UseDomains=true

/etc/systemd/network/default.network

# systemctl --version -> systemd 252
[Match]
Name=eth0
 
[Network]
DHCP=true
IPv6LinkLocalAddressGenerationMode=stable-privacy
LLMNR=false
MulticastDNS=true
DNSOverTLS=opportunistic
DNSSEC=allow-downgrade
IPv6PrivacyExtensions=false
IPv6AcceptRA=true
DNS=::1
DNS=127.0.0.1
 
[Address]
Address=10.0.0.10/24
 
[Address]
Address=fd00::10/8
 
[Route]
Gateway=10.0.0.1/24
Gateway=fd00::1/8
 
[DHCPv4]
UseDNS=false
UseDomains=false
 
[DHCPv6]
RapidCommit=true
UseDNS=false
UseDomains=false
 
[IPv6AcceptRA]
# eui64
#Token=eui64
# rfc7217
Token=prefixstable
UseDNS=false
UseDomains=false

> networkctl list
> networkctl status
> networkctl renew eth0
> networkctl forcerenew eth0

/etc/systemd/resolved.conf

[Resolve]
#DNS=2606:4700:4700::1111#cloudflare-dns.com 1.1.1.1#cloudflare-dns.com
#FallbackDNS=2620:fe::fe#dns.quad9.net 9.9.9.9#dns.quad9.net
#Domains=
DNSSEC=allow-downgrade
DNSOverTLS=opportunistic
MulticastDNS=true
LLMNR=false
Cache=no-negative
#CacheFromLocalhost=no
#DNSStubListener=yes
#DNSStubListenerExtra=
#ReadEtcHosts=yes
#ResolveUnicastSingleLabel=no

• systemd-resolved: MulticastDNS=true und systemctl disable avahi-daemon && systemctl stop avahi-daemon
• avahi-daemon: MulticastDNS=false und systemctl enable avahi-daemon && systemctl start avahi-daemon

Beide Einstellungen für mDNS müssen aktiviert werden: systemd-resolved (global) und systemd-networkd (pro verbindung).

Wenn NetworkManager statt systemd-networkd zum Einsatz kommt, muss mDNS in der jeweiligen Konfiguration aktiviert werden (siehe NetworkManager).

Überprüfen: systemctl status systemd-resolved; systemctl status avahi-daemon; resolvectl status

siehe ArchLinux Wiki und Sektion /ETC/RESOLV.CONF in man systemd-resolved

• ln -fs /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf → stub mode (empfohlen)
• ln -fs /usr/lib/systemd/resolv.conf /etc/resolv.conf → static mode (keine search domains)
• ln -fs /run/systemd/resolve/resolv.conf /etc/resolv.conf → uplink mode
• extern verwaltete /etc/resolv.conf → foreign mode

stub und uplink mode sind die beiden die am meisten Sinn ergeben, wobei 1. ein stub resolver nutzt (127.0.0.53) und 2. einer normalen resolv.conf ähnelt

Alt (SystemD Version 247):

> systemd-resolve --status

Neu (SystemD Version 249):

> resolvectl status
> resolvectl dns
> resolvectl domain
> resolvectl default-route

DNS-Cache abschalten:

> resolvectl flush-caches

> vi /etc/systemd/resolved.conf
...
Cache=no
...