Provided by: manpages-de_4.23.1-1_all 
BEZEICHNUNG
systemd.preset - Voreinstellungen für Diensteaktivierung
ÜBERSICHT
/etc/systemd/system-preset/*.preset
/run/systemd/system-preset/*.preset
/usr/lib/systemd/system-preset/*.preset
/etc/systemd/user-preset/*.preset
/run/systemd/user-preset/*.preset
/usr/lib/systemd/user-preset/*.preset
BESCHREIBUNG
Voreinstellungsdateien können dazu benutzt werden, Richtlinien, welche Units standardmäßig
aktiviert und welche standardmäßig deaktiviert werden sollen, zu kodieren. Sie werden von
systemctl preset gelesen, das diese Informationen verwendet, um eine Unit zu aktivieren
oder zu deaktivieren. systemctl preset wird von den »post install«-Skript-Stücken von
RPM-Paketen (oder anderen Betriebssystem-Paketformaten) verwandt, um eine Unit bei der
Paketinstallation standardmäßig zu aktivieren oder zu deaktivieren und damit die
Voreinstellungsrichtlinie der Distribution, der Variante oder des Administrators
durchzusetzen. Dies erlaubt es, die Aktivierung/Deaktivierung einer bestimmten Gruppe von
Units sogar vor deren Installation auszuwählen. Für weitere Informationen siehe
systemctl(1).
Es wird nicht empfohlen, die Voreinstellungsdateien mit dem betreffenden Softwarepaket,
das die Unit implementiert, auszuliefern. Stattdessen sollte sie in einer Richtlinie der
Distribution oder der Variante zentralisiert werden, die dann von der
Administratorrichtlinie ergänzt werden kann, siehe unten.
Falls keine Voreinstellungsdateien existieren, werden Voreinstellungsaktionen alle Units
aktivieren, die standardmäßig installiert sind. Falls dies nicht gewünscht ist und
stattdessen alle Units deaktiviert sein sollen, ist es notwendig, dass eine
Voreinstellungsdatei mit einer einzelnen, alles auffangenden Zeile »disable *«
ausgeliefert wird. (Siehe Beispiel 1 unten.)
Wenn die Maschine erstmalig gestartet wird, wird systemd(1) alle Units entsprechend der
Voreinstellungsrichtlinie aktivieren/deaktivieren, ähnlich zu systemctl preset-all. Siehe
auch ConditionFirstBoot= in systemd.unit(5) und die »Semantik beim ersten Systemstart« in
machine-id(5).
VOREINSTELLUNGSDATEIFORMAT
Die Voreinstellungsdateien enthalten eine Liste von Direktiven, eine pro Zeile. Leere
Zeilen und Zeilen deren erstes, von Leerraum verschiedenes Zeichen »#« oder »;« ist,
werden ignoriert. Jede Direktive besteht aus einem der Worte »enable«, »disable« oder
»ignore«, gefolgt von Leerraum und einem Unit-Namen. Der Unit-Name darf Shell-artige
Platzhalterzeichen enthalten.
Für die »enable«-Direktive können für Vorlagen-Units eine oder mehrere Instanzennamen als
durch Leerzeichen-getrennte Liste nach dem Unit-Namen festgelegt werden. In diesem Fall
werden diese Instanzen aktiviert, anstelle der mittels DefaultInstance= in der Unit
festgelegten Instanzen.
Voreinstellungen müssen sich auf die »echte« Unit-Datei und nicht auf einen Alias
beziehen. Siehe systemd.unit(5) für eine Beschreibung von Aliasen bei Units.
Es werden drei verschiedene Anweisungen verstanden: »enable« kann benutzt werden, um Units
standardmäßig zu aktivieren, »disable«, um Units standardmäßig zu deaktivieren und
»ignore«, um Units zu ignorieren und bestehende Konfiguration intakt zu lassen.
Falls auf einen Unit-Namen mehrere Zeilen passen, erhält die erste passende Zeile Vorrang
über alle anderen.
Jede Voreinstellungsdatei muss einen Namen der Art <Priorität>-<Richtlinienname>.preset
haben. Dateien in /etc/ setzen Dateien mit dem gleichen Namen in /usr/lib/ und /run/ außer
Kraft. Dateien in /run/ setzen Dateien mit dem gleichen Namen in /usr/lib/ außer Kraft.
Pakete sollten ihre Voreinstellungsdateien in /usr/lib/ installieren. Dateien in /etc/
sind für den lokalen Administrator reserviert, der diese Logik dazu verwenden kann,
Voreinstellungsdateien des Lieferanten außer Kraft zu setzen. Alle Voreinstellungsdateien
werden nach ihrem Dateinamen in lexikographischer Reihenfolge sortiert, unabhängig davon,
in welchem Verzeichnis sie sich befinden. Falls mehrere Dateien den gleichen Unit-Namen
festlegen, wird der Eintrag in der Datei mit dem lexikographisch niedrigsten Namen
angewandt. Es wird empfohlen, allen Dateinamen eine zweistellige Zahl und einen
Bindestrich voranzustellen, um die Ordnung der Dateien zu vereinfachen.
Falls der Administrator eine vom Lieferanten bereitgestellte Voreinstellungsdatei
deaktivieren möchte, wird empfohlen, einen Symlink in /etc/systemd/system-preset/ auf
/dev/null zu setzen, der den gleichen Dateinamen trägt.
BEISPIELE
Beispiel 1. Standardmäßig aus
# /usr/lib/systemd/system-preset/99-default.preset
disable *
Dies deaktiviert alle Units. Aufgrund des vorangestellten »99-« des Dateinamens wird dies
zuletzt eingelesen und kann daher leicht durch eine Varianten- oder
Administratorenvoreinstellungsrichtlinie außer Kraft gesetzt werden.
Beispiel 2. Aktiviert mehrfache Vorlageninstanzen
# /usr/lib/systemd/system-preset/80-dirsrv.preset
enable dirsrv@.service foo bar baz
Dies aktiviert alle drei Dienste: dirsrv@foo.service, dirsrv@bar.service und
dirsrv@baz.service.
Beispiel 3. A GNOME-Variante
# /usr/lib/systemd/system-preset/50-gnome.preset
enable gdm.service
enable colord.service
enable accounts-daemon.service
enable avahi-daemon.*
Dies aktiviert die drei erwähnten Units plus alle Avahi-Daemon, unabhängig vom Unit-Typ.
Eine Datei dieser Art könnte für die Aufnahme in eine GNOME-Variante einer Distribution
nützlich sein. Sie stellt sicher, dass die für GNOME notwendigen Units korrekt bei der
Installation aktiviert werden. Es lässt alle anderen Units unberührt, diese können
(später) durch andere Voreinstellungsdateien beeinflusst werden, beispielsweise von der
aus dem ersten Beispiel.
Beispiel 4. Administrator-Richtlinie
# /etc/systemd/system-preset/00-lennart.preset
enable httpd.service
enable sshd.service
enable postfix.service
disable *
Dies aktiviert drei spezielle Dienste und deaktiviert alle anderen. Dies ist für
Administratoren nützlich, die genau die zu aktivierenden Units auswählen und alle anderen
deaktivieren. Aufgrund der dem Dateinamen vorangestellten »00-« wird sie früh gelesen und
alle anderen Voreinstellungsrichtliniendateien außer Kraft setzen.
MOTIVATION FÜR DIE VOREINSTELLUNGSLOGIK
Verschiedene Distributionen haben verschiedene Richtlinien bezüglich der standardmäßig
aktivierten Dienste, wenn ein von ihnen ausgeliefertes Paket installiert wird. Unter
Fedora bleiben alle Dienste standardmäßig ausgeschaltet, so dass die Installation eines
Paketes nicht dazu führt, dass ein Dienst aktiviert wird (mit einigen Ausnahmen). Unter
Debian sind alle Dienste sofort aktiviert, so dass die Installation eines Pakets dazu
führt, dass der Dienst direkt aktiviert ist.
Selbst innerhalb einer Distribution haben verschieden Varianten (oder wie auch immer
Variationen benannt sind) einer Distribution verschiedene Richtlinien, welche Dienste
aktiviert und welche Dienste ausgeschaltet bleiben sollen. Beispielsweise wird die Fedora
Workstation gdm standardmäßig als Display-Manager aktivieren, während die
Fedora-KDE-Variante stattdessen sddm aktiviert.
Verschiedene Organisationen könnten auch verschiedene Richtlinien haben, was standardmäßig
aktiviert und was ausgeschaltet werden soll. Beispielsweise könnte ein Administrator es
bevorzugen, dass »sshd immer eingeschaltet, aber alles andere ausgeschaltet sein soll«,
während ein anderer vertreten könnte, dass »snmpd immer eingeschaltet sein soll, und bei
allem anderen die Standardrichtlinien der Distribution verwandt werden sollen«.
Traditionell wurde die Richtlinie, welche Dienste aktiviert werden sollen, in jedem Paket
individuell implementiert. Dadurch wurde es mühsam, andere Richtlinien pro Variante zu
implementieren oder Software-Pakete zu erzeugen, die das richtige auf mehr als einer
Distribution machen. Dieser Aktivierungsmechanismus kodierte auch die
Aktivierungsrichtlinie.
Dieser Voreinstellungsmechanismus erlaubt eine saubere Trennung des
Aktivierungsmechanismus (innerhalb der Paket-Skripte, durch Aufrufen von systemctl preset)
und der Aktivierungsrichtlinie (zentralisiert in den Voreinstellungsdateien) und hebt die
Konfiguration aus den einzelnen Paketen. Voreinstellungsdateien können für bestimmte
Distributionen, für bestimmte Varianten oder bestimmte Organisationen geschrieben werden,
um je nach Bedarf verschiedene Richtlinien durchzusetzen. Es wird empfohlen, die in den
Voreinstellungsdateien kodierten Richtlinien in den Paketinstallationsskripten anzuwenden.
SIEHE AUCH
systemd(1), systemctl(1), systemd-delta(1)
In daemon(7) finden Sie eine Diskussion der Paketierungsskripte.
Fedora-Seite, die die Verwendung von Voreinstellungen vorstellt:
Funktionalitäten/PaketVoreinstellungen[1].
ANMERKUNGEN
1. Funktionalitäten/PaketVoreinstellungen
https://fedoraproject.org/wiki/Features/PackagePresets
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann
<debian@helgefjell.de> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License
Version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der Copyright-
Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-
Mail an die Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.