Systemd bei LPIC-1 und LPIC-2 ############################# LPI thematisiert den neuen Init-Daemon an mehreren Stellen. Dazu möchte dieses Dokument Hinweise geben. LPI 101 ======= Allgemeines Handout: https://pemmann.de/doc/LPI-101-Handout/lpi-101-vorbereitung.html 101.2 Boot the system --------------------- Hier geht es im Wesentlichen um technisches Vorwissen und darum, Systemd als Alternative zu init einzuordnen. Siehe dazu: * https://pemmann.de/doc/LPI-101-Handout/lpi-101-vorbereitung.html#_typischer_ablauf_eines_linux_bootvorganges * https://www.ordix.de/48-ordix-news/ordix-news-titelthema/313-booten-unter-linux-systemd.html * https://www.debian.org/doc/manuals/debian-reference/ch03.de.html 101.3 Change runlevels / boot targets and shutdown or reboot system ------------------------------------------------------------------- Vorteile: - Bootvorgang ist schneller - Abhängigkeiten können sehr gut aufgelöst werden - Anwendungsüberwachung ist auf einfache Art möglich (nach Absturz autom. neu starten) - Bringt viele eigenständige Daemons mit: Netzwerkkonfiguration, Namensauflösung, Zeitserver, Zeitplanung, Superserver, ... - Erleichterte Realisierung zustandsloser Systeme Nachteile: - Nicht transparent (Fehlersuche!) - Viele einzelne Kommandos mit komplexer, langer Syntax - Ein einziger, großer Daemon beherrscht alles (widerspricht alten Unix-Konzepten) Kommen wir nun zu wichtigen Merkmalen des neuen Init-Systems. Es gibt einen zentralen Ort, wo alle Infos zusammenfließen: :: tux@tux-pc:~$ file /var/lib/systemd/catalog/database /var/lib/systemd/catalog/database: data tux@tux-pc:~$ Im nächsten Schritt sehen wir den Elternprozess Nr. 1 mit seinem eigenen Log-Dienst "systemd-journal", außerdem steht hier *udev* voll unter der Kontrolle von systemd mittels des Daemons "systemd-udevd": :: tux@tux-pc:~$ pstree -pn | head -3 systemd(1)-+-systemd-journal(245) |-systemd-udevd(258) |-alsactl(362) tux@tux-pc:~$ Es gibt zwar noch 'init' und 'runlevel', aber eigentlich nur noch aus Gründen der Kompatibilität: :: root@tux-pc:~# which init /usr/sbin/init root@tux-pc:~# root@tux-pc:~# ls -l `which init` lrwxrwxrwx 1 root root 20 Aug 20 13:50 /usr/sbin/init -> /lib/systemd/systemd root@tux-pc:~# root@tux-pc:~# ls -l `which telinit` lrwxrwxrwx 1 root root 14 Aug 20 13:50 /usr/sbin/telinit -> /bin/systemctl root@tux-pc:~# root@tux-pc:~# ls -l `which runlevel` lrwxrwxrwx 1 root root 14 Aug 20 13:50 /usr/sbin/runlevel -> /bin/systemctl root@tux-pc:~# Targets/Runlevel ^^^^^^^^^^^^^^^^ Anstelle der alten grob unterteilten Runlevel gibt es hier "Targets": :: root@tux-pc:~# systemctl isolate runlevel5.target root@tux-pc:~# root@tux-pc:~# # >> Dies entspricht "systemctl isolate graphical.target" Das vorkonfigurierte Standard-Target ausgeben: :: root@tux-pc:~# systemctl get-default graphical.target root@tux-pc:~# Das vorkonfigurierte Standard-Target auf multi-user.target ändern: :: root@tux-pc:~# systemctl set-default multi-user.target Created symlink /etc/systemd/system/default.target → /lib/systemd/system/multi-user.target. root@tux-pc:~# So sieht es aus, wenn wir vorher im Runlevel 3 waren und nunmehr in Level 5 sind: :: root@tux-pc:~# runlevel 3 5 root@tux-pc:~# root@tux-pc:~# systemctl isolate runlevel2.target root@tux-pc:~# root@tux-pc:~# # >> Damit wechseln wir wieder... HINWEIS: Mit ``systemctl default`` kann auf einfache Art der voreingestelle "Runlevel" erneut angesteuert werden. Services und Daemons ^^^^^^^^^^^^^^^^^^^^ Kommen wir nun zu den Services und wie wir sie konfigurieren können. Zuerst wollen wir uns den Status ausgeben: :: root@tux-pc:~# systemctl status ssh ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2019-10-16 14:53:33 CEST; 4 days ago Docs: man:sshd(8) man:sshd_config(5) Main PID: 490 (sshd) Tasks: 1 (limit: 2346) Memory: 4.7M CGroup: /system.slice/ssh.service └─490 /usr/sbin/sshd -D Okt 16 14:54:28 tux-pc sshd[748]: Accepted password for tux from 10.44.27.234 port 37438 ssh2 Okt 16 14:54:28 tux-pc sshd[748]: pam_unix(sshd:session): session opened for user tux by (uid=0) Okt 16 15:01:50 tux-pc sshd[871]: Accepted password for tux from 10.44.27.234 port 37716 ssh2 Okt 16 15:01:50 tux-pc sshd[871]: pam_unix(sshd:session): session opened for user tux by (uid=0) Okt 17 08:03:52 tux-pc sshd[2556]: Accepted password for tux from 10.44.27.234 port 40396 ssh2 Okt 17 08:03:52 tux-pc sshd[2556]: pam_unix(sshd:session): session opened for user tux by (uid=0) Okt 21 11:41:58 tux-pc sshd[17652]: Accepted password for tux from 10.44.27.234 port 44448 ssh2 Okt 21 11:41:58 tux-pc sshd[17652]: pam_unix(sshd:session): session opened for user tux by (uid=0) root@tux-pc:~# root@tux-pc:~# systemctl stop ssh root@tux-pc:~# root@tux-pc:~# systemctl start ssh root@tux-pc:~# Anstelle von Init-Skripten gibt es Unit-Files: :: root@tux-pc:~# systemctl status ssh ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2019-10-21 12:18:30 CEST; 19h ago Docs: man:sshd(8) man:sshd_config(5) Process: 18452 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS) Main PID: 18453 (sshd) Tasks: 1 (limit: 2346) Memory: 2.4M CGroup: /system.slice/ssh.service └─18453 /usr/sbin/sshd -D Okt 21 12:18:30 tux-pc systemd[1]: Starting OpenBSD Secure Shell server... Okt 21 12:18:30 tux-pc sshd[18453]: Server listening on 0.0.0.0 port 22. Okt 21 12:18:30 tux-pc sshd[18453]: Server listening on :: port 22. Okt 21 12:18:30 tux-pc systemd[1]: Started OpenBSD Secure Shell server. Okt 22 07:52:46 tux-pc sshd[22095]: Accepted password for tux from 10.44.27.234 port 57894 ssh2 Okt 22 07:52:46 tux-pc sshd[22095]: pam_unix(sshd:session): session opened for user tux by (uid=0) root@tux-pc:~# root@tux-pc:~# systemctl status ssh | grep loaded Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled) root@tux-pc:~# root@tux-pc:~# cat /lib/systemd/system/ssh.service [Unit] Description=OpenBSD Secure Shell server Documentation=man:sshd(8) man:sshd_config(5) After=network.target auditd.service ConditionPathExists=!/etc/ssh/sshd_not_to_be_run [Service] EnvironmentFile=-/etc/default/ssh ExecStartPre=/usr/sbin/sshd -t ExecStart=/usr/sbin/sshd -D $SSHD_OPTS ExecReload=/usr/sbin/sshd -t ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=on-failure RestartPreventExitStatus=255 Type=notify RuntimeDirectory=sshd RuntimeDirectoryMode=0755 [Install] WantedBy=multi-user.target Alias=sshd.service root@tux-pc:~# ACHTUNG: Debian-/Ubuntu-Distributionen verwöhnen uns regelrecht: mit der Installation starten sie den Dienst und aktivieren ihn zugleich. Das muss bei RedHat und SuSE manuell getan werden: :: root@tux-pc:~# systemctl start sshd root@tux-pc:~# systemctl enable sshd TIPP: Weil ``systemctl status sshd`` ziemlich viel ausgibt, ist es oft sinnvoll, ``systemctl is-active sshd`` und ``systemctl is-enabled sshd`` zu benutzen. Dabei sieht man sehr deutlich, ob der Daemon läuft und automatisch beim Booten gestartet wird. Siehe dazu auch: * https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units-de * https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#sec-boot-systemd-boot 104.3 Control mounting and unmounting of filesystems ---------------------------------------------------- (Awareness of systemd mount units) Siehe dazu: * :ref:`systemd-mount` * https://opensource.com/article/20/5/systemd-units (unter "Creating a mount unit") HINWEIS: Mit ``systemd-mount /dev/sr0`` kann sogar ein einfacher User eine CD/DVD mounten, ohne dass dies in der /etc/fstab extra erlaubt werden müsste. Dazu muss er via PolicyKit sein Passwort eingeben; der Mountpunkt erscheint dann unter */run/media/system*. LPI 102 ======= - 107.2 Automate system administration tasks by scheduling jobs - 108.2 System logging - 109.2 Persistent network configuration (Awareness of systemd-networkd) * Siehe dazu :ref:`networkd` - 109.4 Configure client side DNS (Awareness of systemd-resolved) * Siehe dazu :ref:`resolved` - 110.2 Setup host security (systemd.socket) * Siehe dazu :ref:`systemdsocket` LPI 201 ======= Hier eine Auflistung der Systemd-relevanten Themen: - 202.1 Customizing SysV-init system startup (/usr/lib/systemd/, /etc/systemd/, /run/systemd/, delta-systemd) - 202.2 System Recovery (Use systemd rescue and emergency modes) - 202.3 Alternate Bootloaders (Awareness of systemd-boot and U-Boot) - 203.1 Operating the Linux filesystem (Understanding of systemd mount units) - 205.3 Troubleshooting Network Issues (systemd journal) LPI 202 ======= In LPI 202 gibt es nur ein Systemd-relevantes Thema: - 210.1 DHCP configuration (DHCP Log messages in syslog or systemd journal)