Zum Inhalt

Statische Konfiguration

Diese Seite beschreibt die Einrichtung der Hosts, die nicht über syslet läuft: was sie umfasst, wo sie liegt und warum sie von Hand gepflegt wird.

Eine Ausnahme

Fast alles auf den Hosts rollen wir mit syslet aus. Die Grundeinrichtung in diesem Abschnitt ist die Ausnahme: Sie liegt zwar im Repo, wird aber von Hand auf den Host gebracht.

Was dazugehört

Die Grundeinrichtung ist alles, was ein Host braucht, bevor syslet darauf Container betreiben kann, und was nicht zu einem Container gehört:

  • Betriebssystem und Pakete: Rocky Linux mit den Zusatz-Paketquellen EPEL und CRB, Podman aus der Paketquelle podman-next, dazu Werkzeuge wie WireGuard, git und htop. Die Liste steht in Neuen Host aufsetzen; die Zeitzone der Hosts ist UTC.
  • Netz: der WireGuard-Tunnel und die firewalld-Regeln auf werner (siehe Netzwerk); die Einstellungen stehen in WireGuard-Tunnel einrichten.
  • Dateien, die auf den Host kopiert werden, unter rootfs/<host>/ im selben Pfad wie auf dem Host (siehe unten).

Zu den Dateien gehören:

  • systemd-Units und Skripte, etwa der nächtliche Backup-Lauf (system-backup.timer, system-backup.service, /usr/bin/system-backup, siehe Backup) auf werner und das Einbinden des NAS (mnt-backup.mount, siehe NAS) auf containerhost
  • Einstellungen des Betriebssystems, etwa für automatische Updates (etc/dnf/) und den Arbeitsspeicher (etc/sysctl.d/)
  • Hilfen für die Arbeit auf dem Host, etwa Kurzbefehle für Discourse und Nextcloud in root/.bashrc und das Skript fix-podman-internal-networks

Sie liegen unter rootfs/, getrennt nach Host: rootfs/werner/ und rootfs/containerhost/.

Die Grundeinrichtung läuft nicht über syslet. syslet richtet Container, Volumes, Netzwerke und Secrets ein; es braucht dafür ein laufendes Betriebssystem mit Podman und eine SSH-Verbindung. Pakete, Paketquellen, WireGuard und die Firewall sind die Grundlage, auf der syslet arbeitet; sie lassen sich nicht über syslet selbst einrichten. Dasselbe gilt für das Einbinden des NAS, das der Backup-Container auf containerhost voraussetzt.

Wie sie auf den Host kommt

Die Dateien werden von Hand auf den Host kopiert, Pakete und Netz von Hand eingerichtet. Trotzdem gilt dieselbe Reihenfolge wie bei allem anderen: Eine Änderung kommt zuerst ins Repo und wird dann auf den Host übertragen, nie umgekehrt.

Wie ein neuer Host eingerichtet wird, steht in Neue VM aufsetzen.

Für die Grundeinrichtung gibt es kein eigenes Werkzeug. Für die wenigen Dateien und Einstellungen, die sich zudem selten ändern, lohnt sich kein weiteres Werkzeug, das alle verstehen und pflegen müssten (siehe Grundsätze).

Die Dateien liegen trotzdem im Repo. So sieht man, wie ein Host eingerichtet sein soll und wer was wann geändert hat, und kann einen Host danach neu aufbauen.

Kein plan

Für die Grundeinrichtung gibt es kein plan. Weicht ein Host vom Repo ab, weil jemand dort etwas geändert und nicht ins Repo übernommen hat oder umgekehrt, fällt das nicht von selbst auf.

Für den Dauerbetrieb

Ein Teil der Grundeinrichtung sorgt dafür, dass die Hosts ohne Pflege laufen.

Jeder Host spielt jeden Morgen Sicherheitsupdates ein und startet neu, wenn ein Update das verlangt, etwa ein neuer Kernel (upgrade_type = security, reboot = when-needed in etc/dnf/automatic.conf, z. B. rootfs/werner/etc/dnf/automatic.conf). werner macht das um 4 Uhr, containerhost um 5 Uhr (UTC), damit die beiden Hosts nicht gleichzeitig neu starten; der Zeitpunkt steht in etc/systemd/system/dnf-automatic-install.timer.d/override.conf, z. B. rootfs/containerhost/etc/systemd/system/dnf-automatic-install.timer.d/override.conf. Der Neustart kommt mit fünf Minuten Vorlauf; danach startet systemd alle Container von selbst wieder. Der Host startet also gelegentlich von sich aus neu, und die Apps sind dann für ein paar Minuten nicht erreichbar.

Sicherheitsupdates spielen sich automatisch ein, auch wenn dafür ein Neustart nötig ist. So muss niemand daran denken, Updates einzuspielen. Ein kurzer Neustart ab und zu ist uns lieber als eine bekannte Sicherheitslücke, die tagelang offen bleibt.

In etc/dnf/dnf.conf steht auf beiden Hosts best=False, z. B. in rootfs/werner/etc/dnf/dnf.conf. Damit spielt dnf eine ältere Version eines Pakets ein, wenn sich die neueste wegen ihrer Abhängigkeiten nicht installieren lässt, statt abzubrechen; nötig wurde das wegen Konflikten bei den Podman-Paketen.

Das Systemprotokoll (journald) ist begrenzt, auf werner auf 2 GB (rootfs/werner/etc/systemd/journald.conf), auf containerhost auf 128 MB und 24 Stunden (rootfs/containerhost/etc/systemd/journald.conf), weil es ohne Grenze über Monate wächst, bis die Platte voll ist; dann fallen alle Apps auf dem Host aus.

vm.swappiness=10 in rootfs/werner/etc/sysctl.d/10-swappiness.conf sorgt dafür, dass der Host Arbeitsspeicher erst spät auf die Platte auslagert.

Weiterlesen