Kapitel 3. Die Systeminitialisierung

# Kapitel 3. Die Systeminitialisierung

Als Systemadministrator sollten Sie grob wissen, wie das Debian-System gestartet und konfiguriert wird. Obwohl die genauen Details in den Quelldateien der installierten Pakete und deren Dokumentation zu finden sind, ist dies für die meisten von uns ein bisschen viel.

Hier ein knapper Überblick über die wichtigsten Dinge bei der Initialisierung eines Debian-Systems. Da dies ein bewegliches Ziel ist, sollten Sie die neueste Dokumentation lesen:

- Das Debian Linux Kernel Handbook ist die primäre Informationsquelle zum Debian-Kernel.

- bootup(7) beschreibt den System-Boot-Prozess basierend auf `systemd` (derzeitiges Debian-System).

- boot(7) beschreibt den System-Boot-Prozess basierend auf UNIX System V Release 4 (älteres Debian-System).

## 3.1. Ein Überblick über den Bootstrap-Prozess

Das Computer-System durchläuft verschiedene Phasen des Bootstrap-Prozesses vom Einschalten bis zur Bereitstellung des funktionalen Betriebssystems an den Benutzer.

Der Einfachheit halber beschränke ich meine Betrachtung auf die weit verbreitete PC-Plattform mit einer Standardinstallation.

Der typische Bootstrap-Prozess ist wie eine 4-stufige Rakete. Jede Stufe übergibt die Systemkontrolle an die jeweils nachfolgende Stufe:

- Abschnitt 3.1.1, „Stufe 1: das UEFI“

- Abschnitt 3.1.2, „Stufe 2: der Bootloader“

- Abschnitt 3.1.3, „Stufe 3: das Mini-Debian-System“

- Abschnitt 3.1.4, „Stufe 4: das normale Debian-System“

Natürlich können diese unterschiedlich konfiguriert werden. Wenn Sie zum Beispiel Ihren eigenen Kernel kompilieren, werden Sie unter Umständen den Schritt mit dem Mini-Debian-System überspringen. Gehen Sie daher nicht davon aus, dass dies alles in Ihrem Fall zutrifft, solange Sie es nicht selbst überprüft haben.

### 3.1.1. Stufe 1: das UEFI

Das Unified Extensible Firmware Interface (UEFI) definiert als Teil der UEFI-Spezifikation einen Boot-Manager. Wenn ein Rechner eingeschaltet wird, ist dieser Boot-Manager die erste Stufe im Boot-Prozess; er prüft die Boot-Konfiguration und führt den dort festgelegten Betriebssystem-Bootloader bzw. Betriebssystem-Kern aus (normalerweise einen Bootloader). Die Boot-Konfiguration ist über Variablen definiert, die im NVRAM gespeichert sind; dazu gehören Variablen, die den Dateisystempfad zum Betriebssystem-Bootloader oder -Kern enthalten.

Eine EFI System Partition (ESP) ist eine spezielle Partition auf einem Datenspeicher auf UEFI-konformen Computersystemen. Nach dem Einschalten des Rechners greift die UEFI-Firmware auf die ESP zu. Auf ihr sind UEFI-Applikationen abgelegt sowie weitere Dateien, die von diesen Applikationen benötigt werden. Zu diesen Applikationen gehören auch die Betriebssystem-Bootloader. (Auf älteren PC-Systemen können auch das BIOS und der MBR zum Einsatz kommen.)

### 3.1.2. Stufe 2: der Bootloader

Der Bootloader ist die zweite Stufe des Boot-Prozesses und wird durch das UEFI gestartet. Er lädt das System-Kernel-Image und das initrd-Image in den Speicher und übergibt diesen die Kontrolle. Das initrd-Image ist ein Abbild des Wurzeldateisystems und seine Funktionalitäten hängen von dem verwendeten Bootloader ab.

Das Debian-System nutzt normalerweise den Linux-Kernel als Standard-Betriebssystem-Kern. Das initrd-Image für den aktuellen Linux-Kernel der Version 5.x ist technisch gesehen ein initramfs- (initial RAM Filesystem-) Image.

Es gibt mehrere Bootloader und Konfigurationsoptionen:

Tabelle 3.1. Liste der Bootloader

Paket | Popcon | Größe | initrd | Bootloader | Beschreibung
--- | --- | --- | --- | --- | ---
grub-efi-amd64 | I:459 | 142 | Unterstützt | GRUB UEFI | Intelligenter Bootloader, der Festplattenpartitionen und Dateisysteme wie vfat, ext4 … unterstützt (UEFI).
grub-pc | V:16, I:518 | 479 | Unterstützt | GRUB 2 | Intelligenter Bootloader, der Festplattenpartitionen und Dateisysteme wie vfat, ext4 … unterstützt (BIOS).
grub-rescue-pc | V:0.06, I:0.63 | 7273 | Unterstützt | GRUB 2 | Dies ist das boot-fähige Rettungs-Image von GRUB 2 (CD und Diskette) (PC/BIOS-Version).
grml-rescueboot | V:0.1, I:1.1 | 36 | Nicht verfügbar | GRUB 2 plug-in | grml-rescueboot adds live Linux ISO images to the grub2 boot menu
syslinux | V:3, I:31 | 325 | Unterstützt | Isolinux | Unterstützt das ISO9660-Dateisystem. Dies wird von Boot-CDs verwendet.
syslinux | V:3, I:31 | 325 | Unterstützt | Syslinux | Unterstützt das MSDOS-Dateisystem FAT. Dies wird von Boot-Disketten verwendet.
loadlin | V:0.04, I:0.42 | 87 | Unterstützt | Loadlin | Das gewünschte Betriebssystem wird aus dem laufenden FreeDOS-/MSDOS-System heraus gestartet.
mbr | V:0.2, I:2.8 | 47 | Nicht unterstützt | MBR von Neil Turton | Dies ist freie Software, die den MSDOS-MBR ersetzt. Unterstützt nur Festplattenpartitionen.

Auf UEFI-Systemen liest GRUB2 zuerst die ESP-Partition und verwendet die für `search.fs_uuid` in "`/boot/efi/EFI/debian/grub.cfg`" angegebene UUID, um die Partition von GRUB2's Menükonfigurations-Datei "`/boot/grub/grub.cfg`" zu bestimmen.

Der wichtigste Teil von GRUB2's Menükonfigurations-Datei sieht wie folgt aus:

    menuentry 'Debian GNU/Linux' ... {
            load_video
            insmod gzio
            insmod part_gpt
            insmod ext2
            search --no-floppy --fs-uuid --set=root fe3e1db5-6454-46d6-a14c-071208ebe4b1
            echo    'Loading Linux 5.10.0-6-amd64 ...'
            linux   /boot/vmlinuz-5.10.0-6-amd64 root=UUID=fe3e1db5-6454-46d6-a14c-071208ebe4b1 ro quiet
            echo    'Loading initial ramdisk ...'
            initrd  /boot/initrd.img-5.10.0-6-amd64
    }

Dieser Teil von `/boot/grub/grub.cfg` hat folgende Bedeutung:

Tabelle 3.2. Bedeutung der Bestandteile eines Menüeintrags in `/boot/grub/grub.cfg`

Einstellung | Wert
--- | ---
Geladene GRUB2-Module | `gzio`, `part_gpt`, `ext2`
verwendete Partition für das root-Dateisystem | Partition, die über `UUID=fe3e1db5-6454-46d6-a14c-071208ebe4b1` identifiziert wird
Pfad zum Kernel-Image im root-Dateisystem | `/boot/vmlinuz-5.10.0-6-amd64`
verwendete Kernel-Boot-Parameter | "`root=UUID=fe3e1db5-6454-46d6-a14c-071208ebe4b1 ro quiet`"
Pfad zum initrd-Image im root-Dateisystem | `/boot/initrd.img-5.10.0-6-amd64`

On Debian system, "`/boot/grub/grub.cfg`" is managed by the installed GRUB package (e.g. `grub-efi-amd64`) and direct user modification to this file is deprecated. You should customize configuration files in "`/etc/grub.d/`" and "`/etc/default/grub`", instead. Then configure the GRUB configuration files and update NVRAM variables to automatically boot into Debian by:

    # dpkg-reconfigure grub-efi-amd64

| Tipp
You can show kernel boot log messages by removing "`quiet`" from the "`GRUB_CMDLINE_LINUX_DEFAULT`" value in "`/etc/default/grub`".

| Tipp
You can add GRUB splash background by placing its image file in "`/boot/grub/`".

See "`info grub`", grub-install(8), grub-mkconfig(8).

### 3.1.3. Stufe 3: das Mini-Debian-System

Das Mini-Debian-System ist die dritte Stufe des Boot-Prozesses und wird durch den Bootloader gestartet. Es lässt den System-Kernel mit seinem eigenen Wurzeldateisystem im Speicher laufen. Dies ist ein optionaler, vorbereitender Schritt des Boot-Prozesses.

| Anmerkung
Der Begriff "Mini-Debian-System" wurde von dem Autor erfunden, um diese dritte Stufe des Boot-Prozesses in diesem Dokument zu beschreiben. Dieses System wird normalerweise initrd- oder initramfs-System genannt. Ein ähnliches System wird im Speicher auch durch den Debian Installer verwendet.

"`/init`" wird als erstes Programm aus diesem Wurzeldateisystem im Speicher ausgeführt. Es ist ein Programm, das den Kernel im Userspace initialisiert und die Kontrolle an die nächste Stufe übergibt. Dieses Mini-Debian-System bietet Flexibilität für den Boot-Prozess, um zum Beispiel Kernel-Module vor dem Hauptteil des Boot-Prozesses hinzuzufügen oder um das Wurzeldateisystem als verschlüsseltes Dateisystem einzubinden.

- "`/init`" ist ein Shell-Skript, wenn das initfamfs durch `initramfs-tools` erstellt wurde.

  - Sie können diesen Teil des Boot-Prozesses unterbrechen, um eine root-Shell zu bekommen, indem Sie "`break=init`" usw. zu den Kernel-Boot-Parametern hinzufügen. Informationen zu weiteren Unterbrechungsmöglichkeiten finden Sie im "`/init`"-Skript. Diese Shell-Umgebung ist ausgeklügelt genug, um eine gute Überprüfung der Hardware Ihrer Maschine zu ermöglichen.

  - Die verfügbaren Befehle in diesem Mini-Debian-System gehen auf ein GNU-Werkzeug namens busybox(1) zurück und werden auch hauptsächlich von diesem bereitgestellt.

- "`/init`" ist ein binäres `systemd`-Programm, wenn das initramfs durch `dracut` erstellt wurde.

  - Befehle in diesem Mini-Debian-System sind in ihrer Funktionalität auf die systemd(1)-Umgebung reduziert.

| Achtung
Sie müssen die Option "`-n`" für den `mount`-Befehl verwenden, wenn Sie sich im Nur-Lese-Wurzeldateisystem befinden.

### 3.1.4. Stufe 4: das normale Debian-System

The normal Debian system is the 4th stage of the boot process which is started by the mini-Debian system. The system kernel for the mini-Debian system continues to run in this environment. The root filesystem is switched from the one on the memory to the one on the physical storage device.

Das Programm init wird als erstes Programm mit PID=1 ausgeführt und erledigt die eigentliche Hauptarbeit beim Booten, das Starten verschiedener Programme. Der Standardpfad zum init-Programm ist "`/usr/sbin/init`", aber er kann über einen Kernel-Boot-Parameter wie "`init=/pfad/zum/init-programm`" auch geändert werden.

"`/usr/sbin/init`" wurde nach Debian 8 Jessie (veröffentlicht in 2015) ein symbolischer Link auf "`/lib/systemd/systemd`".

| Tipp
Mittels "`ps --pid 1 -f`" können Sie überprüfen, welcher init-Befehl letztlich auf Ihrem System verwendet wird.

Tabelle 3.3. Liste von Boot-Hilfsprogrammen für das Debian-System

Paket | Popcon | Größe | Beschreibung
--- | --- | --- | ---
`systemd` | V:920, I:979 | 11013 | Ereignis-basierter init(8)-Daemon für gleichzeitige Ausführung (Alternative zu `sysvinit`)
`cloud-init` | V:3.6, I:6.7 | 3267 | Initialisierungssystem für Infrastruktur-Cloud-Instanzen
`systemd-sysv` | V:912, I:981 | 76 | die Handbuchseiten und Links, die nötig sind, um `sysvinit` durch `systemd` zu ersetzen
`init-system-helpers` | V:585, I:988 | 131 | Hilfsprogramme, um zwischen `sysvinit` und `systemd` umschalten zu können
`initscripts` | V:16, I:59 | 197 | Skripte zur Initialisierung und zum Herunterfahren des Systems
`sysvinit-core` | V:3.4, I:3.8 | 365 | System-V-ähnliche init(8)-Werkzeuge
`sysv-rc` | V:31, I:63 | 85 | System-V-ähnlicher Mechanismus zum Wechsel des Runlevels
`sysvinit-utils` | V:722, I:1000 | 100 | System-V-ähnliche Werkzeuge (startpar(8), bootlogd(8), …)
`lsb-base` | V:217, I:320 | 12 | Zur Linux Standard Base 3.2 konforme init-Skript-Funktionalität
`insserv` | V:35, I:62 | 132 | Werkzeug, um die Boot-Reihenfolge unter Verwendung von LSB-konformen init.d-Skript-Abhängigkeiten zu organisieren
`kexec-tools` | V:1.4, I:5.4 | 320 | Werkzeug für kexec(8)-Neustarts (Warmstarts)
`systemd-bootchart` | V:0.20, I:0.60 | 131 | Performance-Analyseprogramm für den Boot-Prozess
`mingetty` | V:0.1, I:2.5 | 36 | getty(8) nur für die Konsole
`mgetty` | V:0.15, I:0.50 | 318 | Intelligenter getty(8)-Ersatz für Modems

| Tipp
Im Debian Wiki unter BootProcessSpeedup finden Sie aktuelle Tipps zur Beschleunigung des Boot-Prozesses.

## 3.2. Rescue system

| Warnung
Do not perform system administration tasks around the boot strap process without having a rescue system.

Availability of a rescue system enables us to perform challenging tasks such as:

- Booting a system from a broken boot loader installation

- Fixing a broken boot loader installation

- Extracting data from a broken unbootable system

- Editing filesystems, disk partitions, and LVM volumes involving the root filesystem

Typically, a rescue system is provided as a ISO image file and written to a removable storage media such as:

- USB flash drive prepared as Abschnitt 9.7.2, „Direkt auf eine Festplatte schreiben“

- CD / DVD prepared as Abschnitt 9.7.7, „Direkt auf die CD/DVD-R/RW schreiben“

For simplicity, USB flash drive cases are mentioned as examples below but CD or DVD may be used as well.

| Tipp
You may need to change some UEFI NVRAM variables to boot arbitrary boot loaders on the removable storage media.

### 3.2.1. GRUB UEFI rescue system on USB

The GRUB UEFI rescue system with menu can be started by turning on system power with the "GRUB UEFI rescue system on USB" inserted.

This "GRUB UEFI rescue system on USB" is prepared by writing the Super Grub2 Disk ISO image to USB flash drive in advance.

In case of broken boot loader configuration by the installation of another operating system etc., you can fix this by:

- Start the GRUB UEFI rescue system to discover bootable installed systems automatically.

- Start the installed Debian system from the GRUB menu.

- At Linux root shell prompt:

      # dpkg-reconfigure grub-efi-amd64

| Anmerkung
The bootable GRUB rescue ISO image can be generated by following "`info grub-mkrescue`", too. It offers a CLI GRUB shell prompt but doesn't offer automatic discovery of bootable installed systems.

### 3.2.2. Linux live rescue system on USB

The Linux live rescue system can be started by turning on system power with the "Linux live rescue system on USB" inserted.

This "Linux live rescue system on USB" can be prepared by writing one of Linux live ISO images based on Debian to a USB flash drive in advance. Here are some examples of such Linux live images.

- Debian Live images

- Kali Linux Live

- Grml Live Linux

Here are some use cases of this Linux live rescue system:

- Fix the broken boot loader configuration caused by the installation of another operating system etc.:

  - Start the Linux live rescue system.

  - Mount the partition containing the root filesystem of the unbootable installed Debian system to "`/mnt`".

  - At Linux root shell prompt:

        # chroot /mnt; dpkg-reconfigure grub-efi-amd64

- Fix the broken `dpkg` package:

  - Start the Linux live rescue system.

  - Mount the partition containing the root filesystem of the installed Debian system with the broken `dpkg` package to "`/mnt`".

  - At Linux root shell prompt:

        # dpkg --root /mnt -i /mnt/var/cache/apt/archives/dpkg_old_version_amd64.deb

- Perform normally prohibited changes such as filesystem operations to the installed system (see Abschnitt 9.6, „Tipps zur Speicherung von Daten“).

| Warnung
Your GUI screen of the Linux live system may be locked after the inactivity.

| Tipp

- It's a good idea to set your password as soon as you start a Linux live system.

- You may set your password for example by "`sudo passwd user`" from the user's shell prompt on the Linux virtual consoles (see Abschnitt 1.1.6, „Virtuelle Konsolen“).

- Some Linux live systems may set their default "user/password": "Debian Live" = "user/live", "Kali Linux Live" = "kali/kali"

### 3.2.3. Linux live rescue system from GRUB

The Linux live rescue system can be started from the GRUB menu entry. The GRUB configuration for this is prepared by the following:

- Install the `grml-rescueboot` package

- Find a Linux live ISO image which has "`/boot/grub/loopback.cfg`" in its image.

  - ISO images mentioned in Abschnitt 3.2.2, „Linux live rescue system on USB“ have "`/boot/grub/loopback.cfg`" in their image.

- Copy some of these Linux live ISO images to the "`/boot/grml/`" directory.

- Update GRUB menu by:

      # dpkg-reconfigure grub-efi-amd64

Upon turning on system power, the GRUB displays menu with candidates for Linux live rescue systems.

## 3.3. Systemd

### 3.3.1. Systemd-Init

Wenn das Debian-System startet, wird `/usr/sbin/init` (ein symbolischer Link auf `/usr/lib/systemd`) gestartet als Init-System-Prozess mit der `PID=1`, Eigentümer ist root (`UID=0`). Lesen Sie dazu systemd(1).

Der `systemd`-Init-Prozess wird - basierend auf den Unit-Konfigurationsdateien (siehe systemd.unit(5)) - in mehrere parallele Prozesse aufgespalten; diese Konfigurationsdateien sind in deklarativem Stil geschrieben, im Unterschied zu dem prozeduralen Stil von SysV.

Die abgespalteten Prozesse werden in individuellen Linux control groups abgelegt, die nach der Unit benannt werden, zu der sie in der privaten systemd-Hierarchie gehören (siehe cgroups und Abschnitt 4.7.5, „Linux Sicherheits-Funktionalitäten“).

Units für den System-Modus werden aus dem in systemd.unit(5) beschriebenen "System Unit Search Path" geladen. Die wichtigsten sind hier in der Reihenfolge ihrer Priorität aufgelistet:

- "`/etc/systemd/system/*`": System-Units, erstellt vom Administrator

- "`/run/systemd/system/*`": Runtime-Units

- "`/lib/systemd/system/*`": System-Units, erstellt vom Distributions-Paketmanager

Deren Abhängigkeiten untereinander sind durch die Regeln "`Wants=`", "`Requires=`", "`Before=`", "`After=`", … (siehe "MAPPING OF UNIT PROPERTIES TO THEIR INVERSES" in systemd.unit(5)) definiert. Die Ressourcen-Steuerung ist ebenfalls festgelegt (siehe systemd.resource-control(5)).

Die Endung der Unit-Konfigurationsdateien definiert ihren Typ wie folgt:

- *.service beschreibt einen Prozess (Dienst), der von `systemd` gesteuert und überwacht wird. Siehe systemd.service(5).

- *.device beschreibt ein Gerät, das im sysfs(5) als udev(7)-Gerätedatei abgebildet ist. Siehe systemd.device(5).

- *.mount beschreibt einen Einbindungspunkt im System, der von `systemd` gesteuert und überwacht wird. Siehe systemd.mount(5).

- *.automount beschreibt einen automatischen Einbindungspunkt im System, der von `systemd` gesteuert und überwacht wird. Siehe systemd.automount(5).

- *.swap beschreibt ein Swap-Device oder eine Swap-Datei (zum Auslagern von Arbeitsspeicher auf eine Festplatte), die von `systemd` gesteuert und überwacht wird. Siehe systemd.swap(5).

- *.path beschreibt einen Pfad im Dateisystem, der von `systemd` zum Zwecke der pfad-basierten Aktivierung überwacht wird. Siehe systemd.path(5).

- *.socket beschreibt einen Socket, der von `systemd` zum Zwecke der socket-basierten Aktivierung gesteuert und überwacht wird. Siehe systemd.socket(5).

- *.timer beschreibt einen Timer (Zeitgeber), der von `systemd` zum Zwecker der timer-basierten Aktivierung gesteuert und überwacht wird. Siehe systemd.timer(5).

- *.slice verwaltet Ressourcen über cgroups(7). Siehe systemd.slice(5).

- *.scope wird programmgesteuert über die Busschnittstellen von `systemd` erzeugt, um Systemprozesse zu verwalten. Siehe systemd.scope(5).

- *.target fasst andere Unit-Konfigurationsdateien zu Gruppen zusammen, um Synchronisierungspunkte für den Startprozess zu erstellen. Siehe systemd.target(5).

Während des Systemstarts versucht der `systemd`-Prozess, das Target "`/lib/systemd/system/default.target` (normalerweise ein symbolischer Link auf "`graphical.target`") zu starten. Als erstes werden dabei einige spezielle Target-Units (siehe systemd.special(7)) wie "`local-fs.target`", "`swap.target`" und "`cryptsetup.target`" aktiviert, um die Dateisysteme einzubinden. Dann werden über die Abhängigkeiten weitere Target-Units aktiviert. Details finden Sie in bootup(7).

`systemd` enthält Funktionalitäten, um die Rückwärtskompatibilität zu SysV zu gewährleisten. Boot-Skripte im SysV-Stil in "`/etc/init.d/rc[0123456S].d/[KS]name`" werden immer noch abgearbeitet, und telinit(8)-Befehle werden in Aktivierungsanforderungen für systemd-Units übersetzt.

| Achtung
Die emulierten Runlevel 2 bis 4 verweisen über symbolische Links alle auf des gleiche "`multi-user.target`".

### 3.3.2. Systemd-Login

Wenn sich ein Benutzer über gdm3(8), sshd(8) usw. am Debian-System anmeldet, wird `/lib/systemd/system --user` als User-Service-Manager-Prozess gestartet, Eigentümer ist der entsprechende Benutzer. Lesen Sie dazu systemd(1).

Der `systemd` User-Service-Manager-Prozess wird basierend auf den deklarativen Unit-Konfigurationsdateien (siehe systemd.unit(5) und `user@.service`(5)) in mehrere parallele Prozesse aufgespalten.

Units für den Benutzer-Modus werden aus dem in systemd.unit(5) beschriebenen "User Unit Search Path" geladen. Die wichtigsten sind hier in der Reihenfolge ihrer Priorität aufgelistet:

- "`~/.config/systemd/user/*`": Benutzer-Konfigurations-Units

- "`/etc/systemd/user/*`": Benutzer-Units, erstellt vom Administrator

- "`/run/systemd/user/*`": Runtime-Units

- "`/lib/systemd/user/*`": Benutzer-Units, installiert vom Distributions-Paketmanager

Diese werden auf die gleiche Art verwaltet wie Abschnitt 3.3.1, „Systemd-Init“.

## 3.4. Die Kernel-Meldungen

Die angezeigten Fehlermeldungen des Kernels auf der Konsole können über einen Schwellwert gefiltert werden:

    # dmesg -n3

Tabelle 3.4. Liste der Schwellwerte zur Filterung von Kernel-Fehler-Meldungen

Wert | Name | Bedeutung
--- | --- | ---
0 | KERN_EMERG | System ist unbenutzbar
1 | KERN_ALERT | es ist unverzüglich eine Aktion erforderlich
2 | KERN_CRIT | Zustände mit kritischen Fehlern
3 | KERN_ERR | Zustände mit Fehlern
4 | KERN_WARNING | Zustände mit Warnungen
5 | KERN_NOTICE | normale, aber erwähnenswerte Zustände
6 | KERN_INFO | rein informativ
7 | KERN_DEBUG | Nachrichten zur Fehlersuche/-eingrenzung

## 3.5. Die Systemmeldungen

Unter `systemd` werden sowohl Kernel- wie auch Systemmeldungen durch den Journal-Dienst `systemd-journald.service` (a.k.a `journald`) protokolliert, entweder in Form von Binärdaten unterhalb von "`/var/log/journal`" oder in flüchtigen Binärdaten in "`/run/log/journal/`". Diese binären Protokolldaten können mit dem Befehl journalctl(1) abgefragt werden. Zum Beispiel erhalten Sie das Protokoll vom letzten Boot-Vorgang mit:

    $ journalctl -b

Tabelle 3.5. Liste typischer `journalctl`-Befehle

Tätigkeit | Befehl
--- | ---
Protokoll für Systemdienste und Kernel vom letzten Boot-Vorgang anzeigen | "`journalctl -b --system`"
Protokoll für Dienste des aktuellen Benutzers vom letzten Boot-Vorgang anzeigen | "`journalctl -b --user`"
Protokollinformationen von "`$unit`" vom letzten Boot-Vorgang anzeigen | "`journalctl -b -u $unit`"
Protokollinformationen von "`$unit`" vom letzten Boot-Vorgang anzeigen (im Stil von "`tail -f`") | "`journalctl -b -u $unit -f`"

Unter `systemd` könnte das System-Log-Werkzeug rsyslogd(8) deinstalliert sein. Falls es installiert ist, ändert sich sein Verhalten, so dass die volatilen binären Logdaten gelesen werden (statt "`/dev/log`", was vor systemd der Standard war) und traditionelle permanente ASCII-Logdaten erstellt werden. Dies kann über "`/etc/default/rsyslog`" und "`/etc/rsyslog.conf`" sowohl für die Protokolldateien wie auch für die Bildschirmanzeige angepasst werden. Lesen Sie dazu rsyslogd(8) und rsyslog.conf(5) sowie auch Abschnitt 9.3.2, „Analyseprogramme für Logdateien“.

## 3.6. Systemmanagement

`systemd` enthält nicht nur das eigentliche init-System zum Starten des Systems, sondern auch Funktionalitäten zum Systemmanagement mittels dem systemctl(1)-Befehl.

Tabelle 3.6. Liste typischer `systemctl`-Befehle

Tätigkeit | Befehl
--- | ---
Alle verfügbaren Unit-Typen auflisten | "`systemctl list-units --type=help`"
Alle Target-Units im Arbeitsspeicher auflisten | "`systemctl list-units --type=target`"
Alle Service-Units im Arbeitsspeicher auflisten | "`systemctl list-units --type=service`"
Alle Device-Units im Arbeitsspeicher auflisten | "`systemctl list-units --type=device`"
Alle Mount-Units im Arbeitsspeicher auflisten | "`systemctl list-units --type=mount`"
Alle Socket-Units im Arbeitsspeicher auflisten | "`systemctl list-sockets`"
Alle Timer-Units im Arbeitsspeicher auflisten | "`systemctl list-timers`"
"`$unit`" starten | "`systemctl start $unit`"
"`$unit`" stoppen | "`systemctl stop $unit`"
Dienst-spezifische Konfiguration neu laden | "`systemctl reload $unit`"
"`$unit`" stoppen und neu starten | "`systemctl restart $unit`"
"`$unit`" starten und alle anderen stoppen | "`systemctl isolate $unit`"
Zur grafischen Oberfläche wechseln (GUI-System) | "`systemctl isolate graphical`"
Zur Konsolenoberfläche wechseln (Mehrbenutzer-CLI-System) | "`systemctl isolate multi-user`"
Zur Rettungssystem-Oberfläche wechseln (Einzelbenutzer-CLI-System) | "`systemctl isolate rescue`"
Kill-Signal an "`$unit`" senden | "`systemctl kill $unit`"
Prüfen, ob "`$unit`" aktiv ist | "`systemctl is-active $unit`"
Prüfen, ob "`$unit`" fehlgeschlagen ist | "`systemctl is-failed $unit`"
Status von "`$unit|$PID|device`" prüfen | "`systemctl status $unit|$PID|$device`"
Eigenschaften von "`$unit|$job`" anzeigen | "`systemctl show $unit|$job`"
Fehlgeschlagene "`$unit`" zurücksetzen (Reset) | "`systemctl reset-failed $unit"`
Abhängigkeiten aller Unit-Dienste auflisten | "`systemctl list-dependencies --all`"
Auf dem System installierte Unit-Dateien auflisten | "`systemctl list-unit-files`"
"`$unit`" aktivieren (symbolischen Link hinzufügen) | "`systemctl enable $unit`"
"`$unit`" deaktivieren (symbolischen Link entfernen) | "`systemctl disable $unit`"
"`$unit`" zum Starten bereit machen (symbolischen Link auf "`/dev/null`" entfernen) | "`systemctl unmask $unit`"
"`$unit`" am Starten hindern (symbolischen Link auf "`/dev/null`" hinzufügen) | "`systemctl mask $unit`"
Aktuelles default-Target abrufen | "`systemctl get-default`"
default-Target auf "`graphical`" setzen (grafische Oberfläche, GUI) | "`systemctl set-default graphical`"
default-Target auf "`multi-user`" setzen (Konsolenoberfläche, CLI) | "`systemctl set-default multi-user`"
Job-Umgebungseinstellungen anzeigen | "`systemctl show-environment`"
Job-Umgebungseinstellung "`variable`" auf "`wert`" setzen | "`systemctl set-environment variable=wert`"
Job-Umgebungseinstellung "`variable`" löschen | "`systemctl unset-environment variable`"
Alle Unit-Dateien und Daemons neu laden | "`systemctl daemon-reload`"
System herunterfahren | "`systemctl poweroff`"
System herunterfahren und neu starten (Reboot) | "`systemctl reboot`"
System in Standby setzen (Suspend) | "`systemctl suspend`"
System in Ruhezustand setzen (Hibernate) | "`systemctl hibernate`"

In obigen Beispielen kann "`$unit`" für einen einzelnen Unit-Namen stehen (ein Anhang wie `.service` oder `.target` ist dabei optional), oder auch für die Angabe mehrerer Units (über Suchmuster im Shell-Stil wie "`*`", "`?`" oder "`[]`", die fnmatch(3) verwenden; diese werden auf die primären Namen aller Units angewandt, die derzeit in den Arbeitsspeicher geladen sind).

Befehlen zum Ändern des Systemstatus wird typischerweise ein "`sudo`" vorangestellt, um die nötigen administrativen Rechte anzufordern.

Die Ausgabe von "`systemctl status $unit|$PID|$device`" nutzt farbige Punkte ("●"), um den Unit-Status kompakt zusammenzufassen.

- Ein weisser "●" steht für "inaktiv" oder "deaktiviert".

- Ein roter "●" steht für "fehlgeschlagen" oder "Fehler".

- Ein grüner "●" steht für "aktiv", "wird neu geladen" oder "wird aktiviert".

## 3.7. Weitere Systemüberwachungs-Werkzeuge

Hier eine Liste von weiteren Befehlsschnipseln zur Systemüberwachung unter `systemd`. Bitte lesen Sie die zugehörigen Handbuchseiten inklusive cgroups(7).

Tabelle 3.7. Liste weiterer Überwachungsbefehle unter `systemd`

Tätigkeit | Befehl
--- | ---
Dauer der einzelnen Initialisierungsschritte anzeigen | "`systemd-analyze time`"
Alle Units auflisten, sortiert nach der Dauer ihrer Initialisierung | "`systemd-analyze blame`"
"`$unit`"-Datei laden und auf Fehler prüfen | "`systemd-analyze verify $unit`"
Kurze Statusinformationen zum Benutzer der Sitzung vom Aufrufer | "`loginctl user-status`"
Kurze Statusinformationen zur Sitzung vom Aufrufer | "`loginctl session-status`"
Boot-Prozess nachverfolgen über cgroups | "`systemd-cgls`"
Boot-Prozess nachverfolgen über cgroups | "`ps xawf -eo pid,user,cgroup,args`"
Boot-Prozess nachverfolgen über cgroups | sysfs unter "`/sys/fs/cgroup/`" auslesen

## 3.8. Systemkonfiguration

### 3.8.1. Der Rechnername

Der Kernel verwaltet den Rechnernamen (hostname) des Systems. Die durch `systemd-hostnamed.service` gestartete System-Unit setzt beim Systemstart den Rechnernamen auf den in "`/etc/hostname`" festgelegten Wert. Diese Datei sollte nur den Rechnernamen des Systems enthalten, nicht einen vollqualifizierten Domänennamen.

Um den derzeitigen Rechnernamen auszugeben, führen Sie hostname(1) ohne ein Argument aus.

### 3.8.2. Das Dateisystem

Die Optionen zum Einbinden normaler Festplatten- und Netzwerkdateisysteme werden in "`/etc/fstab`" festgelegt. See fstab(5) und Abschnitt 9.6.7, „Optimierung von Dateisystemen über mount-Optionen“.

Die Konfiguration verschlüsselter Dateisysteme ist in "`/etc/crypttab`" abgelegt. Siehe crypttab(5).

Software-RAID mit mdadm(8) wird in "`/etc/mdadm/mdadm.conf`" konfiguriert. Siehe mdadm.conf(5).

| Warnung
Bei jedem Systemstart werden nach dem Einbinden aller Dateisysteme temporäre Dateien in "`/tmp`", "`/var/lock`" und "`/var/run`" gelöscht.

### 3.8.3. Initialisierung der Netzwerkschnittstellen

Auf modernen Debian-Desktop-Systemen mit `systemd` erfolgt die Initialisierung von Netzwerkschnittstellen für die Loopback-Schnittstelle `lo` typischerweise durch "`networking.service`" und für andere Schnittstellen durch "`NetworkManager.service`".

Details zur Konfiguration finden Sie in Kapitel 5, Netzwerkkonfiguration.

### 3.8.4. Initialisierung eines Cloud-Systems

Die Cloud-System-Instanz kann als Klon der "Debian Official Cloud Images" oder ähnlicher Images ausgeführt werden. Für solche Systeminstanzen können persönliche Anpassungen wie Rechnername, Dateisystem, Netzwerk, Locale, SSH-Schlüssel, Benutzer und Gruppen über Funktionalitäten aus den Paketen `cloud-init` und `netplan.io` konfiguriert werden. Dabei werden mehrere Datenquellen genutzt, wie Dateien, die im Original-System-Image liegen, und externe Daten, die beim Start der Instanz bereitgestellt werden. Diese Pakete verwenden eine deklarative Systemkonfiguration mittels YAML-Daten.

Näheres finden Sie unter "Cloud Computing with Debian and its descendants", "Cloud-init-Dokumentation" und Abschnitt 5.4, „Moderne Netzwerkkonfiguration für Cloud-Systeme“.

### 3.8.5. Anpassungsbeispiel zur Optimierung des sshd-Dienstes

Bei einer Standardinstallation werden viele Netzwerkdienste (siehe Kapitel 6, Netzwerkapplikationen) von `systemd` durch `network.target` als Daemon-Prozess gestartet. "`sshd`" ist hier keine Ausnahme. Als Beispiel dafür, wie man so etwas anpassen kann, wollen wir zeigen, wie Sie "`sshd`" so ändern, dass er nur auf Anfrage (on-demand) startet.

Als erstes deaktivieren Sie die entsprechende Dienst-Unit:

     $ sudo systemctl stop sshd.service
     $ sudo systemctl mask sshd.service

Der klassische Weg zur on-demand-Aktivierung von Sockets führte früher über den `inetd`- (oder `xinetd`)-Superserver. Unter `systemd` kann dies über das Hinzufügen von *.socket und *.service Unit-Konfigurationsdateien erreicht werden.

Eine `sshd.socket` anlegen zur Spezifizierung eines Sockets, der auf Anfragen überwacht wird:

    [Unit]
    Description=SSH Socket for Per-Connection Servers

    [Socket]
    ListenStream=22
    Accept=yes

    [Install]
    WantedBy=sockets.target

Und eine `sshd@.service` als Dienste-Datei passend zu `sshd.socket`:

    [Unit]
    Description=SSH Per-Connection Server

    [Service]
    ExecStart=-/usr/sbin/sshd -i
    StandardInput=socket

Dann muss der Dienst neu geladen werden:

     $ sudo systemctl daemon-reload

## 3.9. Das udev-System

Das udev-System bietet seit dem Linux-Kernel 2.6 Mechanismen zur automatischen Hardware-Erkennung und -initialisierung (lesen Sie dazu udev(7)). Nach der Erkennung eines Gerätes durch den Kernel startet das udev-System einen User-Prozess. Dieser verwendet Informationen aus dem sysfs-Dateisystem (Näheres in Abschnitt 1.2.12, „procfs und sysfs“), lädt über den Befehl modprobe(8) benötigte Kernel-Module, die die Hardware unterstützen (Details in Abschnitt 3.10, „Die Kernel-Modul-Initialisierung“), und erstellt die zugehörigen Geräteknoten (device nodes).

| Tipp

Falls "`/lib/modules/kernel-version/modules.dep`" mittels depmod(8) aus irgendeinem Grund nicht korrekt erstellt wurde, könnte es beim Laden der Module durch das udev-System Probleme geben. Führen Sie "`depmod -a`" aus, um dies zu beheben.

Für die Regeln zum Einbinden von Dateisystemen in "`/etc/fstab`" müssen Geräteknoten nicht fest zugeordnet sein. Sie können auch UUIDs verwenden, um Geräte einzubinden, statt der Gerätenamen wie "`/dev/sda`". Lesen Sie dazu Abschnitt 9.6.3, „Zugriff auf Partitionen über die UUID-Kennung“.

Da das udev-System immer ein wenig im Wandel ist, überlasse ich die Details anderen Dokumenten und beschränke mich hier auf das Nötigste.

| Warnung
Versuchen Sie nicht, lange laufende Programme wie Backup-Skripte mit `RUN` in udev-Regeln zu starten, wie in udev(7) erwähnt. Erstellen Sie stattdessen eine saubere systemd.service(5)-Datei und aktivieren Sie diesen Service. Lesen Sie dazu Abschnitt 10.2.3.2, „Automatisches Backup, durch ein mount-Ereignis ausgelöst“.

## 3.10. Die Kernel-Modul-Initialisierung

Das modprobe(8)-Programm erlaubt es, einen laufenden Linux-Kernel über einen User-Prozess zu konfigurieren, indem Kernel-Module hinzugefügt und entfernt werden. Das udev-System (Näheres in Abschnitt 3.9, „Das udev-System“) automatisiert dessen Aufruf, um bei der Initialisierung des Kernel-Moduls zu helfen.

Es gibt Module, die nicht zu bestimmter Hardware gehören, sowie spezielle Hardware-Treibermodule wie die folgenden, die im Voraus geladen werden müssen, indem Sie in die Datei "`/etc/modules`" eingetragen werden (Details in modules(5)):

- TUN/TAP-Module, die ein virtuelles Point-to-Point Netzwerkgerät (TUN) und ein virtuelles Ethernet-Netzwerkgerät (TAP) bereitstellen;

- netfilter-Module, die Netfilter-Firewall-Funktionalitäten bereitstellen (lesen Sie dazu iptables(8) und Abschnitt 5.7, „Die Netfilter-Infrastruktur“);

- watchdog timer-Treibermodule.

Die Konfigurationsdateien für das modprobe(8)-Programm sind unterhalb des "`/etc/modprobes.d/`"-Verzeichnisses abgelegt, wie in modprobe.conf(5) beschrieben. (Falls Sie vermeiden möchten, dass einige Kernel-Module automatisch geladen werden, sollten Sie erwägen, diese in die Datei "`/etc/modprobes.d/blacklist`" einzutragen.)

Die Datei "`/lib/modules/version/modules.dep`" (erzeugt durch das Programm depmod(8)) beschreibt Abhängigkeiten zwischen den Modulen; diese Abhängigkeiten werden von modprobe(8) genutzt.

| Anmerkung
Wenn Sie Probleme beim Laden von Modulen feststellen, entweder während des Systemstarts oder beim Nachladen mit modprobe(8), kann "`depmod -a`" diese Probleme möglicherweise durch Neuerstellung der "`modules.dep`"-Datei beheben.

Der Befehl modinfo(8) zeigt Informationen über ein Linux-Kernel-Modul an.

Das lsmod(8)-Programm formatiert den Inhalt von "`/proc/modules`" zu einer hübschen Ausgabe, um anzuzeigen, welche Kernel-Module gerade geladen sind.

| Tipp

Sie können die Hardware in Ihrem System exakt identifizieren. Lesen Sie dazu Abschnitt 9.5.3, „Hardware-Identifikation“.

Möglicherweise wollen Sie Hardware während des Systemstarts konfigurieren, um bestimmte erwartete Hardware-Funktionalitäten zu aktivieren. Näheres finden Sie in Abschnitt 9.5.4, „Hardware-Konfiguration“.

Unterstützung für spezielle Geräte können Sie unter Umständen durch Neukompilieren des Kernels hinzufügen. Details finden Sie in Abschnitt 9.10, „Der Kernel“.

Kapitel 2. Debian-Paketmanagement |  | Kapitel 4. Authentifizierung und Zugriffskontrolle