Linux Initialisierung

Linux Initialisierung

BIOS

Im BIOS sind Informationen über die eingebauten Laufwerke hinterlegt. Die wichtigste Information ist an welchem Interface das Boot-Laufwerk mit der primären Partition hängt, denn von dort wird der Master-Boot-Record gelesen, um die weitere Systeminitialisierung zu triggern.

---

Master-Boot-Record: Bootloader

• https://de.wikipedia.org/wiki/Master_Boot_Record

Auf einem Speichermedium können mehrere Betriebssysteme parallel liegen.

Ein Laufwerk (z. B. Festplatte) hat auf den ersten 512 Bytes den sog. Master-Boot-Record. Dort legt man i. a. den sog. Bootloader ab, der die weitere Systeminitialisierung triggert. Jede Partition (= Volume) kann dann weitere Boot Records haben. Der Bootloader verweist auf diese Boot Records, die jeweils für das Starten eines Betriebssystems zuständig sind.

Der Master-Boot-Record der primären Partition des Boot-Laufwerks entscheidet - evtl. durch Interaktion des Benutzers - welches Betriebsssystem gestartet wird.

GRUB Bootloader

Bei Linux-System wird häufig der GRUB Bootloader verwendet, der vor einiger Zeit LILO abgelöst hat.

Der GRUB-Bootloader ist - im Gegensatz zum LILO - in der Lage, das Filesystem des Laufwerks zu lesen und so den Kernel zu lesen, der für die weitere Initialisierung zuständig ist.

---

Linux Kernel

Linux ist der Name des Kernels ... der Kernel bildet den Kern des Betriebssystems.

---

Linux Services

systemd

• https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units

• http://fedoraproject.org/wiki/Packaging:Systemd#EnvironmentFiles_and_support_for_.2Fetc.2Fsysconfig_files

Viele Linux-Distributionen sind vom SysV-Initialisierungsprozess auf systemd umgestiegen (z. B. Ubuntu, Fedora, Suse). Ubuntu hatte zwischendurch Upstart verwendet.

Targets

Aus den Runleveln (SysV) wurden die sog. Targets (z. B. multi-user.target). Darüber werden Units gruppiert, um zu enthscheiden welche Services in welchen Situationen gestartet werden.

Jedes System hat ein Default-Target

systemctl get-default

Die vorhandenen Targets werden über

systemctl list-unit-files --type=target

angezeigt.

Units

Als Units bezeichnet man die Dinge, die von systemd gemanaged werden. Hierzu gehören folgende Kategorien

• Daemon-Prozesse

• Services

• Mounts

• Sockets

• Devices

• ...

Eine Übersicht über die Units erhält man per

sudo systemctl list-units --all

oder

sudo systemctl list-unit-files

Unit: Service

systemd erwartet für jeden Service eine Konfigurationsdatei, die folgendermaßen aussehen kann (wird per systemctl cat myapp.service angezeigt):

[vagrant@management system]$ systemctl cat sshd.service
# /usr/lib/systemd/system/sshd.service
[Unit]
Description=OpenSSH server daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target sshd-keygen.service
Wants=sshd-keygen.service

[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target

Wichtig ist, daß alle Umgebungsvariablen (z. B. JAVA_HOME) hier gesetzt werden müssen, da ein Systemd-Service auf der grünen Wiese aufsetzt.

Wenn Änderungen am Systemd-Skript vorgenommen werden, dann muß der Systemd-Daemon über diese Änderung informiert werden: systemctl daemon-reload

Über systemctl list-dependencies myapp.service werden die Services aufgelistet, von denen der Service abhängig ist:

[vagrant@management system]$ systemctl list-dependencies sshd.service
sshd.service
● ├─sshd-keygen.service
● ├─system.slice
● └─basic.target
●   ├─microcode.service
●   ├─rhel-autorelabel-mark.service
●   ├─rhel-autorelabel.service
●   ├─rhel-configure.service
●   ├─rhel-dmesg.service
●   ├─rhel-loadmodules.service
●   ├─paths.target
●   ├─slices.target

Client systemctl

• https://wiki.ubuntuusers.de/systemd/systemctl/

Systemd-basierte Linux-Systeme bieten den systemctl Client, mit dem sich einzelne Units aber auch das gesamte System beeinflussen läßt (z. B. System anhalten systemctl halt).

Per

systemctl start myapp.service

wird der Service myapp.service gestartet ... in Kurzform systemctl start myapp.

Ein paar typische Aktionen auf Services sind

• start

• status

• is-active

• stop

• reload

• reload-or-restart

• enable

  • hierüber wird konfiguriert, daß der Service beim Start des Systems automatisch gestartet wird ... per disable wird diese Konfiguration rückgängig gemacht

  • dabei wird ein symbolischer Link in /lib/systemd/ angelegt

• is-enabled

• ``disable

• list-dependencies

• mask bzw. unmask

  • verhindern, daß ein Service gestartet werden kann

• edit

  • Unit-Datei editieren

Dazu kommen noch ein paar serviceunabhängige Kommandos:

• sudo systemctl daemon-reload

  • Unit-Dateien nachladen/aktualisieren

• ``

systemctl: wichtige Konfigurationsdateien

• Konfiguration von systemd: /etc/systemd/

• symbolische Links auf die bei Systemstart zu startenden Services/Daemons (je nach Distribution unterschiedlich)

  • /lib/systemd/

  • /system

  • /etc/systemd/system