Paketbau/SUSE-Paketkonventionen/Sysconfig

aus openSUSE, der freien Wissensdatenbank

5. Sysconfig

Dieses Kapitel beschreibt eine spezielle, unterhalb von /etc/sysconfig gespeicherte Konfiguration. Nach einer Einführung und einem Abschnitt über das grundlegende Dateiformat folgen einige Abschnitte, die SUSE-spezifische Metadaten beschreiben. Am Ende steht ein Abschnitt, in dem beschrieben wird, wie Pakete ihre eigene Konfiguration installieren können.

/etc/sysconfig/ ist der zentrale Ort für Konfigurationsdateien für SUSE Linux und openSUSE. Im allgemeinen enthält er Einstellungen, die konfigurierbar sein sollen, aber nicht von nativen Konfigurationsdateien unterhalb von /etc verändert werden können. Hier werden nicht die nativen Konfigurationsdateien oder doppelte Informationen aus diesen Dateien bereitgestellt.

Die Sysconfig-Dateien werden vor allem zur Konfiguration von SuSEconfig-Modulen, Init-Skripten und verschiedenen Startern genutzt. /etc/sysconfig/security definiert beispielsweise die Sicherheitsebene des Systems und ob die Zugriffsrechte für bestimme kritische Dateien von SuSEconfig geprüft werden. /etc/sysconfig/xntp definiert wiederum Optionen zum Start des xntpd-Daemons und ob dieser in einer chroot-Umgebung gestartet werden muss.

Vorteile von /etc/sysconfig:

• Das Datenformat ist einfach und einheitlich.
• Alles befindet sich an einem zentralen Platz.
• Die Konfiguration ist sowohl durch Shell-Skripte als auch durch Nutzer einfach lesbar.
• Die Einstellungen können von Nutzern selber einfach mit Hilfe des YaST Sysconfig-Editors geändert werden.

5.1. Grundlegendes Dateiformat

Die sysconfig-Dateien sind einfache Textdateien. Die Einstellungen werden durch Paare {VARIABLE,Wert}, wie Shell-Variablen definiert:

VARIABLE=”Wert”

Oberhalb einer jeden Variablen kann ein spezieller Kommentar stehen, der weitere Informationen zu dieser enthält; beispielsweise eine Beschreibung, den Typ des Werts und einen Standardwert. Diese Metadaten werden dann vom YaST-Editor für /etc/sysconfig-Dateien genutzt. Kommentare beginnen wie normale Shell-Kommentare mit einem '#'. Zusätzlich muss eine spezielle Syntax folgen, um verschiedene Arten von Metadaten unterscheiden zu können. Weitere Informationen dazu erhalten Sie im zweiten Abschnitt dieses Kapitels.

Dieses Beispiel stammt aus /etc/sysconfig/boot. Es wird die Variable PROMPT_FOR_CONFIRM definiert:

## Path:        System/Boot
 ## Description: Boot configuration
 ## Type:        yesno
 ## Default:     no
 #
 # For interactive debugging of the startup process. If set
 # to "yes" the system will ask whether to confirm every
 # step of the boot process.
 #
 PROMPT_FOR_CONFIRM="no"

5.2. Metadatendateiformat

Die Informationen in diesem Abschnitt stammen aus der Datei /usr/share/doc/packages/yast2-sysconfig/metadata.txt, welche mit dem Paket yast2-sysconfig installiert wird. Weitere Details erhalten Sie direkt in der Datei.

Metadaten sind wichtig, da sie Nutzern dabei helfen, die Einstellungen unter /etc/sysconfig einfach mit dem YaST-Editor für /etc/sysconfig-Dateien ändern zu können. Der Editor benötigt weitere Daten (Metadaten) um die sysconfig-Variablen anzeigen und ändern zu können. Diese Metadaten waren ursprünglich in der Datei meta_sys.config aus dem Paket yast2-sysconfig gespeichert. Dies war allerdings absolut nicht ideal, da diese Datei vom Betreuer des Pakets yast2-sysconfig verwaltet wurde, während die Variablen durch die Betreuer der jeweiligen Pakete verwaltet wurden. Deshalb sind die Metadaten seit SL 8.2 Teil der sysconfig-Dateien.

Metadaten sind Teil des Beschreibungskommentars einer Variablen. Die Metadatenzeile beginnt mit einem doppelten Balkenkreuz "##" und wird folgendermaßen durch ein Paar aus {Tag und Wert} definiert:

## Tag:     Wert

Mehrere Werte können durch eine durch Kommata eingeteilte Liste angegeben werden. Werte, die Kommata oder Leerzeichen enthalten, müssen in Anführungsstriche gesetzt werden. Lange Werte können mit einem umgekehrten Schrägstrich (engl. backslash) '\' als letztem Zeichen in der Zeile auf mehrere Zeilen aufgeteilt werden.

Ein normaler Kommentar (nach einem einzelnen Balkenkreuz “#”) wird als Hilfe-Text angezeigt.

Dieses Beispiel entstammt dem Paket acpid. Es definiert die Variable ACPI_MODULES, welche mit Hilfe der Vorlage /var/adm/fillup-templates/sysconfig.powermanagement-acpid in /etc/sysconfig/powermanagement eingetragen wird:

## Path:                System/Powermanagement/acpid/General
 ## Type:                string(ac,battery,button,fan,processor,\
 ##                             thermal,asus_acpi,toshiba_acpi)
 ## Default:             "ac battery button fan processor thermal"
 ## ServiceRestart:      acpid
 # The acipd startscript will load all necessary modules for acpi.
 # If some of these modules cause trouble, you may remove it
 # from this variable.  You may add the modules asus_acpi or
 # toshiba_acpi if your computer is an Asus or a Toshiba.
 # Seperate several modules by space.
 ACPI_MODULES="ac battery button fan processor thermal"

Kommentare nach drei aufeinanderfolgenden Balkenkreuzen “###” werden ignoriert. Sie können genutzt werden, um nicht benötigte Teile zu deaktivieren oder um Kommentare zu erstellen, die für die YaST-Nutzer nicht sichtbar sind. Zum Beispiel:

### I don't want thermal module in the default, Admin
 ### Default:             "ac battery button fan processor thermal"
 ## Default:             "ac battery button fan processor"

Metadatenblöcke müssen sich am Anfang von Kommentarblöcken befinden. Im Metadatenblock können Metadaten eine beliebige Reihenfolge einnehmen.

Zeilen wie die folgenden sollten nicht Teil der Metadaten sein:

#
 # This is /etc/sysconfig/foo
 #

#
 # Here ends /etc/sysconfig/foo
 #      

oder:

#####
 # start of section xyz
 #

#
 # end of section xyz
 #####

Nach einer Aktualisierung oder nachdem ein zweites Paket Variablen hinzugefügt hat, könnten solche Markierungen mehr schaden als nützen.

5.3. Metadaten-Tags

Alle Tags sind optional und können in zwei Sets einsortiert werden: Beschreibungen und Aktionen. Die ersten Tags beschreiben die Variable selbst: ihren Typ, Standardwert und Position in der Baumansicht von YaST. Die zweiten Tags beschreiben benötigte Aktionen um die Änderungen zu aktivieren, wie das Aufrufen eines SuSEconfig-Moduls oder Neustart eines Dienstes.

Beschreibende Tags:

• Path definiert, an welcher Stelle sich die Variable in der Baumansicht des YaST-Editors für /etc/sysconfig-Dateien befinden soll. Das Schrägstrichzeichen '/' wird als Trenner genutzt. Falls es Teil eines Namens ist, kann seine Funktion durch einen umgekehrten Schrägstrich '\' aufgehoben werden. Die Variablen befinden sich normalerweise auf der zweiten oder dritten Ebene, wobei die Tiefe allerdings nicht limitiert ist.
  Das erste Zeichen eines Unterzweigs sollte ein Großbuchstabe sein. Es gibt die folgenden Basiskategorien (auf der ersten Ebene des Pfads):
  • Hardware ist der Unterbaum für alle Hardware-relevanten Einstellungen. Er wird beispielsweise in den sysconfig-Dateien sound und keyboard genutzt.
  • System ist der Unterbaum für grundlegende Systemkonfiguration. Er wird beispielsweise in den sysconfig-Dateien boot, suseconfig, cron, console und security genutzt.
  • Desktop ist der Unterbaum für Einstellungen zur Arbeitsfläche. Er wird beispielsweise in den sysconfig-Dateien kde, gnome und xdm genutzt.
  • Applications ist der Unterbaum für anwendungsbezogene Einstellungen. Er wird beispielsweise in den sysconfig-Dateien java, ispell und man genutzt.
  • Network ist der Unterbaum für Netzwerkdiensteinstellungen. Er wird beispielsweise in den sysconfig-Dateien apache, mail und nfs genutzt.
  • Other ist der Unterbaum für Einstellungen, die in keine der obigen Kategorien passen. Dieser Unterbaum wird auch als Rückfallmöglichkeit genutzt, wenn kein Pfad angegeben ist. Der sysconfig-Dateiname wird dann auf der zweiten Ebene des Pfadnamens genutzt. Eine Variable aus /etc/sysconfig/test würde so beispielsweise unter Other/test auftauchen, falls kein anderer Pfad angegeben ist.

Alle Variablen sollten sich in einem Unterzweig der Basiskategorien befinden, wie es beispielsweise bei path:Hardware/Joystick oder path:System/Console der Fall ist. Die Pfadlänge kann dabei auch größer als zwei sein, wie beispielsweise bei path:System/Filesystem/Fam.

• Description ist ein sehr spezielles Tag, da es mit der folgenden Variable nicht verbunden ist, jedoch mit dem vorausgehenden Pfad. Es definiert eine Beschreibung für den Pfad, der durch das vorhergehende Path-Tag gesetzt wurde. Es sollte der gesamte Unterbaum beschrieben werden, da diese Beschreibung angezeigt wird, wenn der Nutzer in YaST an Stelle einer Variablen einen Pfad im Baum auswählt.
  Jede Pfadangabe kann eine Beschreibung haben. Falls ein Pfad über mehr als eine Beschreibung verfügt, wird die zuletzt gefundene genutzt. Falls mehrere Pakete das gleiche Basispaket benötigen, sollte sich die Beschreibung nur im Basispaket befinden. Falls Pakete unabhängig sind, sollte sich die Beschreibung in einer Extradatei befinden, die Teil des Pakets yast2-sysconfig ist.

• Type gibt den Typ der Variablen an und wird genutzt, um den eingegebenen Wert zu prüfen. Die folgenden Typen werden unterstützt:
  • string — Jeder Wert ist erlaubt. Dies ist der Standardtyp.
  • string(v1,v2,...) — Es werden die aufgelisteten Werte angeboten. Jeder Wert ist erlaubt.
  • list(v1,v2,...) — Es werden die aufgelisteten Werte angeboten, wobei kein anderer Wert erlaubt ist.
  • integer — Jeder Integer-Wert ist erlaubt.
  • integer(min:max) — Jeder Integer-Wert innerhalb des angegebenen Bereichs ist erlaubt. Eine Grenze kann auch ausgelassen werden, so erlaubt integer(0:) beispielsweise Werte größer als 0.
  • boolean — Die Werte "true" und "false" werden angeboten und es sind keine anderen Werte erlaubt.
  • yesno — Die Werte "yes" und "no" werden angeboten und es sind keine anderen Werte erlaubt.
  • ip — Eine IPv4- oder IPv6-Adresse ist als Wert erlaubt, beispielsweise 10.20.0.1.
  • ip4 — Nur eine IPv4-Adresse ist als Wert erlaubt.
  • ip6 — Nur eine IPv6-Adresse ist als Wert erlaubt.
  • regexp(exp) — Es sind nur Zeichenketten erlaubt, die auf den regulären Ausdruck exp passen. Der Ausdruck muss der POSIX Extended Regular Expression Syntax folgen. Zum Beispiel: regexp(^0[0-7]*$) erlaubt nur oktale Werte.

• Default gibt den Standardwert der Variablen an. Dieser wird genutzt, wenn der Nutzer im YaST-Editor für /etc/sysconfig-Dateien den Knopf [Standard] drückt.

Aktivierungs-Tags:

• PreSaveCommand definiert ein Bash-Kommando, dass vor der Speicherung eines neuen Werts in eine sysconfig-Datei ausgeführt. Es kann beispielsweise dafür genutzt werden, einen Daemon zu stoppen, falls dies geschehen muss, bevor ein Wert verändert wird.
  Der Wert ist eine Zeichenkette die dann mit bash -c ausgeführt wird. Alle Bash-Fähigkeiten wie bedingte Ausführung (&&,||) oder Ausgabeumleitung (<,>,>>) sind erlaubt.
  Die Zeichenkette wird von YaST2 nicht verarbeitet oder geändert, es werden lediglich Leerstellen am Anfang und am Ende beseitigt und Zeichenketten über mehrere Zeilen werden in eine Zeile zusammengelegt.
• Config definiert eine durch Kommata eingeteilte Liste von SuSEconfig-Modulen, die nach der Änderung eines Werts ausgeführt werden sollen, zum Beispiel Config: profiles,kde,susewm.
• ServiceReload definiert eine durch Kommata eingeteilte Liste von Init-Skriptnamen, die aufgerufen werden sollen, um Dienste die Konfiguration neu laden zu lassen, nachdem der Wert verändert wurde. Zum Beispiel: ServiceReload: sendmail,postfix.
• ServiceRestart definiert eine durch Kommata eingeteilte Liste von Init-Skriptnamen, die aufgerufen werden sollen, um Dienste neu zu starten, nachdem der Wert geändert wurde. Zum Beispiel: ServiceRestart: tomcat,jonas.
• Command definiert ein Bash-Kommando, dass nach dem Ändern einer Variablen ausgeführt werden soll. Es kann für jede Aktion genutzt werden, die nicht durch die obigen Tags möglich ist. Der Typ des Werts ist der gleiche wie beim PreSaveCommand und wird auch wie bei diesem verarbeitet (siehe oben).

Die Kommandos sollten keine gefährlichen Aktionen ausführen, da sie wahrscheinlich automatisch von Anfängern gestartet werden. Die Änderung der Variable DISPLAYMANAGER benötigt beispielsweise einen Neustart von xdm, was allerdings die aktuelle X-Sitzung abbricht. In diesem Fall sollte die nötige Aktion lediglich im Kommentar beschrieben werden.
Falls das Aktivierungskommando zu komplex ist (zu viele Abhängigkeiten oder Prüfungen), sollten die notwendigen Schritte ebenfalls lediglich kommentiert werden.

Der YaST-Editor für /etc/sysconfig-Dateien führt die gleiche Aktion nicht für jede veränderte Variable aus. Nachdem der Nutzer den Knopf [Beenden] gedrückt hat, beginnt der folgende Prozess:

1. Starten der Kommandos aus den PreSaveCommmand Tags für jede veränderte Variable. Falls ein Beendungsstatus ungleich 0 zurückgegeben wird, wird davon ausgegangen, dass ein Fehler aufgetreten ist und andere Aktivierungskommandos werden für diese Variable ignoriert.
2. Speichern aller geänderter Variablen.
3. Starten aller angegebener SuSEconfig-Module für jede gespeicherte Variable.
4. Neu Starten und neu Laden aller angegebener Dienste für jede veränderte Variable. Dies wird nur für laufende Dienste durchgeführt, weshalb die Init-Skripte zuvor mit dem Parameter status aufgerufen werden, um zu prüfen, ob die Dienste laufen.
5. Starten der Kommandos aus den Command Tags für jede geänderte Variable.

Wenn mehrere Variablen das gleiche Aktivierungskommando benötigen, wird das Kommando nur einmal gestartet, um die Aktivierung zu beschleunigen. Die Kommandos werden ohne Syntaxanalyse und semantische Prüfung verglichen, um festzustellen, ob ein Kommando schon ausgeführt wurde. Aus diesem Grund sollten die Kommandos zumindest innerhalb einer Datei konsistent sein. Der Nutzer ändert in der Regel nur einige Variablen in einer Datei.

Falls Aktivierungskommandos im der kompletten sysconfig-Datei fehlen, wird SuSEconfig zur Rückwärtskompatibilät mit alten sysconfig-Dateien gestartet. Einige Variablen benötigen keine Aktivierung, beispielsweise die in /etc/sysconfig/boot, die nur während des Boot-Vorgangs genutzt werden. In diesem Fall kann das leere Config Tag genutzt werden, um den Start des SuSEconfig-Skripts nach dem Ändern einer Variablen zu verhindern.

5.4. Metadatenvererbung

Die Metadaten müssen nicht für jeden Wert neu angegeben werden. Alle Metadaten, auch Hilfe-Kommentare, werden auch für nachfolgende Variablen genutzt, so lange sie zuvor schon definiert sind. Einzige Ausnahme davon ist das Description Tag, welches mit dem vorhergehenden Path Tag verknüpft ist. Weitere Details dazu erhalten Sie bei seiner Spezifikation weiter oben.

Die Vererbung wird oft genutzt, um sysconfig-Dateien einfach und übersichtlich zu halten, was allerdings auch zur Gefahr werden kann. Die Variablen werden vom Dienstprogramm fillup in die sysconfig-Dateien eingetragen, beschrieben in Kapitel 5.5, “Installation”. fillup aktualisiert Metadaten bereits vorhandener Variablen und fügt neue Variablen am Ende der sysconfig-Datei hinzu. Es fügt Metadaten nur unmittelbar über den neuen Variablen ein und garantiert nicht, dass diese andere Metadaten korrekt erben. Verschiedene Pakete können Variablen in der gleichen sysconfig-Datei hinzufügen, so dass die Variablen nach einigen Aktualisierungen vermischt sein können. Deshalb ist es ein gutes Vorgehen, alle Metadaten vor neuen Variablen in späteren Versionen eines Pakets zu wiederholen. Es ist auch immer eine gute Idee, einige potentiell ungewollte Aktionen durch das Setzen eines leeren Werts zurückzusetzen, falls diese nicht verlangt werden.

Dieses Beispiel entstammt /etc/sysconfig/fam. Für beide Variablen werden die gleichen Werte für <class="systemitem">Path</code> und ServiceRestart definiert:

## Path:                System/File systems/Fam
 ## Description:         File Access Monitoring Daemon
 ## Type:                integer
 ## ServiceRestart:      fam
 ## Default:             4
 # Polling interval. check for local files each
 # $FAM_POLLING_INTERVAL second
 # (default is 4)
 FAM_POLLING_INTERVAL="4"
 
 ## Type:        integer
 ## Default:     0
 # Close connections after $FAM_INACTIVE_TIMEOUT seconds.
 # (default is 0 -> do not close connections)
 FAM_INACTIVE_TIMEOUT="0"
 [...]

Dieses Beispiel entstammt /etc/sysconfig/joystick. Alle Metadaten, einschließlich der Beschreibung, werden für alle vier Variablen auf einmal definiert:

## Path:        Hardware/Joystick
 ## Description: Joystick cofigurations
 ## Type:        string
 ## Default:     ""
 ## ServiceRestart: joystick
 # Gameport module names
 # (typically "ns558" for legacy gameport support)GAMEPORT_MODULE_0=""
 GAMEPORT_MODULE_1=""
 GAMEPORT_MODULE_2=""
 GAMEPORT_MODULE_3=""

5.5. Installation

Jedes Paket kann seine eigenen Variablen in jede bereits existierende sysconfig-Datei oder in eine neue eintragen. Da mehrere Pakete Variablen in der gleichen sysconfig-Datei hinzufügen können, enthalten sie die Dateien nicht direkt. Stattdessen installieren die Pakete lediglich Vorlagen unter /var/adm/fillup-templates/ und rufen in ihren %post-Skripten das Dienstprogramm fillup auf, um die Variablen aus den Vorlagen in die sysconfig-Dateien einzutragen.

Die Variablen sollten wie in der alten /etc/rc.config eine Vorsilbe enthalten, um Namenskollisionen zu vermeiden und die Suche zu vereinfachen. Das Paket postfix nutzt beispielsweise Variablen mit der Vorsilbe POSTFIX_. Existierende Variablen sollten nich umbenannt werden, um Probleme nach einer Aktualisierung zu vermeiden.

Falls ein Paket mehrere Variablen mitbringt, ist es besser, diese auf mehrere sysconfig-Dateien aufzuteilen.

Die Vorlagen werden dem Paket in der Regel als Extradateien hinzugefügt. Sie werden im %install-Abschnitt installiert, in der Dateiliste erwähnt und im %post-Skript in die Vorlagen gefüllt. Für diesen Zweck existieren die Makros %fillup_and_insserv und %fillup_only. Dieses Beispiel entstammt dem Paket man:

PreReq:       %fillup_prereq
[...]
Source1:      sysconfig.cron-man
[...]

%install
[...]
mkdir -p ${RPM_BUILD_ROOT}/var/adm/fillup-templates
install -m 700 %{SOURCE1} ${RPM_BUILD_ROOT}/var/adm/fillup-templates
[...]

%post
%{fillup_only -an cron}

%files
[...]
/var/adm/fillup-templates/sysconfig.cron-man

Es fügt die folgenden Variablen aus der Vorlage /var/adm/fillup-templates/sysconfig.cron-man in /etc/sysconfig/cron ein. Die Variablen werden genutzt, um Cron-Skripte zu konfigurieren, die vom gleichen Paket /etc/cron.daily/ installiert werden.

## Path:        System/Cron/Man
 ## Description: cron configuration for man utility
 ## Type:        yesno
 ## Default:     yes
 # Should mandb and whatis be recreated by cron.daily ("yes" or "no")
 REINIT_MANDB=yes
 
 ## Type:        yesno
 ## Default:     yes
 # Should old preformatted man pages (in /var/catman) be deleted? (yes/no)
 DELETE_OLD_CATMAN=yes
 
 ## Type:        integer
 ## Default:     7
 # How long should old preformatted man pages be kept before deletion? (days)
 CATMAN_ATIME=7

Weitere Informationen und Beispiele erhalten Sie in Kapitel 3.6, “%fillup_and_insserv” und in Kapitel 3.7, “%fillup_only”.

Es ist nicht möglich, festzustellen welche Konfigurationsdatei oder Variable zu welchem Paket gehört, da die Dateien unter /etc/sysconfig/ nicht zu RPM-Paketen gehören. Stattdessen müssen die Vorlagen unter /var/adm/fillup-templates/ abgefragt werden.