Erstmalige Einrichtung von Diensten

Viele Systemdienste erfordern eine gewisse Erstkonfiguration, bevor sie zum ersten Mal ordnungsgemäß funktionieren. Gängige Beispiele sind die Generierung von privaten Schlüsseln und Zertifikaten oder einer eindeutigen, systemspezifischen Kennung.

Traditionell geschah dies mithilfe von RPM-Skripten im Rahmen der Installation oder Aktualisierung eines Pakets. Dies war zu einer Zeit sinnvoll, als die meisten Installationen durch beaufsichtigte oder unbeaufsichtigte Installationsprogramme (wie Anaconda und Kickstart) durchgeführt wurden.

Heutzutage ist die Nutzung von Abbildern virtueller Maschinen für traditionelle und Cloud-Computing-Umgebungen stark im Trend. Dabei ist es problematisch, wenn bei der Paketinstallation systemspezifische Daten erstellt werden. Daher muss bei der Erstellung solcher Abbilder besonders sorgfältig vorgegangen werden, um alle systemspezifischen Informationen zu entfernen. Anschließend müssen zusätzliche Werkzeuge entwickelt werden, die die korrigierten Informationen nach der Bereitstellung anwenden. Diese Richtlinie soll sicherstellen, dass nach dem Ausführen eines Systembereinigungsdienstes wie virt-sysprep und einem anschließenden Neustart des Systems alle Dienste, die eine Erstkonfiguration benötigen, diese erneut ausführen. Dies erreichen wir, indem wir die Erstkonfiguration aus den RPM-Skripten (z.B. %post) entfernen und sie stattdessen beim Start des Dienstes mit systemd ausführen.

Diese Richtlinie beschreibt einen Mechanismus, der sowohl für traditionelle als auch für Cloud-basierte Bereitstellungsstile verwendet werden kann.

Hinweis: Diese Anforderung kann entfallen, wenn die entsprechende Funktionalität in den Standardstart des Dienstes integriert ist. Diese Richtlinien beziehen sich auf Dienste, die vor dem Start eingerichtet werden müssen.

Systemspezifische Konfiguration definieren

Eine bestimmte Setup-Aufgabe ist wie folgt definiert: „Jede Aktion, die auf dem System durchgeführt werden muss, auf dem der Dienst ausgeführt wird, und deren Ergebnis nicht für alle Systeme identisch ist, auf denen dieser Dienst ausgeführt wird.“

Eine (unvollständige) Liste beispielhafter Systemkonfigurationen:

  • Der SSH-Daemon generiert einen öffentlichen/privaten Hostschlüssel

  • Das httpd-Modul mod_ssl erstellt ein selbstsigniertes Zertifikat für den Hostnamen des Rechners

  • Ein ferner Protokollierungsdienst erstellt eine UUID, die diese Maschine repräsentiert

Einige Beispiele, die nicht als systemspezifische Konfiguration betrachtet werden sollten:

  • Erstellen eines Dienstbenutzers und/oder einer Gruppe. Dies kann gefahrlos auf Systemklone kopiert werden.

  • Inhalte, die vom Dienst nach dem Löschen automatisch neu generiert werden.

Erstellen selbstsignierter Zertifkate

Das Werkzeug sscg (Self-Signed Certificate Generator) dient zur sicheren Erstellung selbstsignierter Zertifikate. Es ist in allen Fedora-Versionen enthalten; die Online-Dokumentation finden Sie unter 1.

Mehr zu selbstsignierten Zertifikaten

Wenn Ihr Dienst das SSL/TLS-Protokoll zur Transportsicherheit nutzt, benötigt er ein Dienstzertifikat. Idealerweise sollte der Administrator, der einen neuen Dienst bereitstellt, ein X.509-Zertifikat von einer geeigneten Zertifizierungsstelle (CA) beziehen. Dies sollte eine global tätige CA (z.B. ein kommerzieller SSL-Zertifikatsanbieter) sein, wenn Ihr Dienst im öffentlichen Internet verfügbar sein soll, oder eine private CA (z.B. eine Domänencontroller-CA), wenn Ihr Dienst in einem Intranet ausgeführt wird.

Es ist jedoch oft ratsam, zunächst ein selbstsigniertes Zertifikat zu verwenden, das sofort erstellt werden kann und dem Administrator ermöglicht, umgehend mit den Installationsaufgaben fortzufahren. Dieses Dokument erklärt, wie Sie ein selbstsigniertes Zertifikat erhalten. Es wird jedoch empfohlen, dieses vor der öffentlichen Bereitstellung zu ersetzen.

Der Nachteil selbstsignierter Zertifikate besteht darin, dass die meisten Client-Programme (wie Webbrowser) sie als nicht vertrauenswürdig ablehnen und gegebenenfalls eine explizite Bestätigung durch den Benutzer erfordern. Die Vorgehensweise hierfür variiert je nach Client-Software. Es ist einfacher, ein CA-Zertifikat im Systemspeicher hinzuzufügen und es als vertrauenswürdig zu kennzeichnen.

Anstatt ein selbstsigniertes Zertifikat zu erstellen, generieren wir ein temporäres CA-Zertifikat und signieren damit das vom Dienst verwendete Zertifikat. Anschließend löschen wir den privaten Schlüssel des CA-Zertifikats, wodurch die Möglichkeit entfällt, damit weitere Zertifikate zu erstellen. Danach importieren wir das CA-Zertifikat als vertrauenswürdig in den lokalen Systemzertifikatspeicher. Folglich akzeptiert jede lokale Client-Software, die den Systemzertifikatspeicher berücksichtigt, das Dienstzertifikat als vertrauenswürdig. Das Werkzeug sscg übernimmt all dies für Sie.

Allgemeine Richtlinien

Für alle systemspezifischen Fälle nutzen wir die Dienst-Funktionalität von systemd. Paketierer erstellen für jede Dienst-Unit ihres Pakets, die eine systemspezifische Konfiguration erfordert, eine neue Dienst-Unit-Datei. Diese Dienst-Unit wird -init.service genannt und in /usr/lib/systemd/system installiert. Beispielsweise wäre /usr/lib/systemd/tog-pegasus-init.service die Konfigurationseinheit für tog-pegasus.service.

Der Inhalt dieser Dienst-Unit ist wie folgt:

[Unit]
Description=One-time configuration for <servicename>

ConditionPathExists=|!/path/to/generated/config
ConditionPathExists=|!/path/to/other/generated/config (one or more lines optional)

[Service]
Type=oneshot
RemainAfterExit=no

ExecStart=/Pfad/zum/Konfigurationsskript

Die Syntax für ConditionPathExists= verwendet das Ausrufezeichen (!) zur Negation (die Datei ist nicht vorhanden). Das Pipe-Zeichen (|) dient zur logischen ODER-Verknüpfung (fehlt eine dieser Dateien, wird die Konfiguration ausgeführt). Diese Bedingungen werden als „Auslösebedingungen“ bezeichnet. Eine ausführliche Erklärung finden Sie unter systemd.unit(5). /Pfad/zum/Konfigurationsskript kann ein beliebiges ausführbares Skript oder eine Binärdatei sein, die die für diesen Dienst benötigte Initialkonfiguration generiert. Sie muss die von ConditionPathExists geprüften Dateien generieren. Besteht das Skript aus einem einzelnen Befehl, kann es direkt von dieser Dienst-Unit ausgeführt werden. Müssen mehrere Befehle ausgeführt werden, empfiehlt es sich, eine Skriptdatei im Verzeichnis /usr/libexec/ des Pakets zu erstellen und diese auszuführen.

Hier tog-pegasus.service als Beispiel:

[Unit]
Description=One-time configuration for tog-pegasus

ConditionPathExists=|!/etc/Pegasus/server.pem
ConditionPathExists=|!/etc/Pegasus/file.pem
ConditionPathExists=|!/etc/Pegasus/client.pem

[Service]
Type=oneshot
RemainAfterExit=no

ExecStart=/usr/bin/sscg --package tog-pegasus --ca-file /etc/Pegasus/client.pem --cert-file /etc/Pegasus/server.pem --cert-key-file /etc/Pegasus/file.pem

Der Befehl ExecStart kann beliebige Aktionen ausführen, solange er im Erfolgsfall 0 zurückgibt. In diesem Fall generieren wir ein selbstsigniertes Zertifikat, das der Dienst verwenden kann.

Paketierer müssen außerdem ihre primäre Dienst-Unit aktualisieren, sodass diese benötigt wird und anschließend ausgeführt wird:

[Unit]
...
Requires=<service>-init.service
After=<service>-init.service

Wir setzen mit dem Beispiel für tog-pegasus.service fort:

[Unit]
Description=OpenPegasus CIM Server
After=slpd.service

Requires=tog-pegasus-init.service
After=tog-pegasus-init.service

[Service]
Type=forking
ExecStart=/usr/sbin/cimserver
PIDFile=/var/run/tog-pegasus/cimserver.pid

[Install]
WantedBy=multi-user.target

Want to help? Learn how to contribute to Fedora Docs ›