SYSTEMD.PRESET(5) systemd.preset SYSTEMD.PRESET(5) BEZEICHNUNG systemd.preset - Voreinstellungen fur Diensteaktivierung UBERSICHT /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 konnen dazu benutzt werden, Richtlinien, welche Units standardmassig aktiviert und welche standardmassig 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-Stucken von RPM-Paketen (oder anderen Betriebssystem-Paketformaten) verwandt, um eine Unit bei der Paketinstallation standardmassig 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 auszuwahlen. Fur 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 erganzt werden kann, siehe unten. Falls keine Voreinstellungsdateien existieren, werden Voreinstellungsaktionen alle Units aktivieren, die standardmassig installiert sind. Falls dies nicht gewunscht 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, ahnlich zu systemctl preset-all. Siehe auch 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. Fur die >>enable<<-Direktive konnen fur 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 mussen sich auf die >>echte<< Unit-Datei und nicht auf einen Alias beziehen. Siehe systemd.unit(5) fur eine Beschreibung von Aliasen bei Units. Es werden drei verschiedene Anweisungen verstanden: >>enable<< kann benutzt werden, um Units standardmassig zu aktivieren, >>disable<<, um Units standardmassig zu deaktivieren und >>ignore<<, um Units zu ignorieren und bestehende Konfiguration intakt zu lassen. Falls auf einen Unit-Namen mehrere Zeilen passen, erhalt die erste passende Zeile Vorrang uber alle anderen. Jede Voreinstellungsdatei muss einen Namen der Art -.preset haben. Dateien in /etc/ setzen Dateien mit dem gleichen Namen in /usr/lib/ und /run/ ausser Kraft. Dateien in /run/ setzen Dateien mit dem gleichen Namen in /usr/lib/ ausser Kraft. Pakete sollten ihre Voreinstellungsdateien in /usr/lib/ installieren. Dateien in /etc/ sind fur den lokalen Administrator reserviert, der diese Logik dazu verwenden kann, Voreinstellungsdateien des Lieferanten ausser Kraft zu setzen. Alle Voreinstellungsdateien werden nach ihrem Dateinamen in lexikographischer Reihenfolge sortiert, unabhangig 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 mochte, wird empfohlen, einen Symlink in /etc/systemd/system-preset/ auf /dev/null zu setzen, der den gleichen Dateinamen tragt. BEISPIELE Beispiel 1. Standardmassig 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 ausser 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 erwahnten Units plus alle Avahi-Daemon, unabhangig vom Unit-Typ. Eine Datei dieser Art konnte fur die Aufnahme in eine GNOME-Variante einer Distribution nutzlich sein. Sie stellt sicher, dass die fur GNOME notwendigen Units korrekt bei der Installation aktiviert werden. Es lasst alle anderen Units unberuhrt, diese konnen (spater) 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 fur Administratoren nutzlich, die genau die zu aktivierenden Units auswahlen und alle anderen deaktivieren. Aufgrund der dem Dateinamen vorangestellten >>00-<< wird sie fruh gelesen und alle anderen Voreinstellungsrichtliniendateien ausser Kraft setzen. MOTIVATION FUR DIE VOREINSTELLUNGSLOGIK Verschiedene Distributionen haben verschiedene Richtlinien bezuglich der standardmassig aktivierten Dienste, wenn ein von ihnen ausgeliefertes Paket installiert wird. Unter Fedora bleiben alle Dienste standardmassig ausgeschaltet, so dass die Installation eines Paketes nicht dazu fuhrt, dass ein Dienst aktiviert wird (mit einigen Ausnahmen). Unter Debian sind alle Dienste sofort aktiviert, so dass die Installation eines Pakets dazu fuhrt, 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 standardmassig als Display-Manager aktivieren, wahrend die Fedora-KDE-Variante stattdessen sddm aktiviert. Verschiedene Organisationen konnten auch verschiedene Richtlinien haben, was standardmassig aktiviert und was ausgeschaltet werden soll. Beispielsweise konnte ein Administrator es bevorzugen, dass >>sshd immer eingeschaltet, aber alles andere ausgeschaltet sein soll<<, wahrend ein anderer vertreten konnte, 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 muhsam, 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 konnen fur bestimmte Distributionen, fur 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: Funktionalitaten/PaketVoreinstellungen[1]. ANMERKUNGEN 1. Funktionalitaten/PaketVoreinstellungen https://fedoraproject.org/wiki/Features/PackagePresets UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . systemd 255 SYSTEMD.PRESET(5)