Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
Bezieht sich auf SUSE Linux Enterprise Server 11 SP4

10 Booten und Konfigurieren eines Linux-Systems

Das Booten eines Linux-Systems umfasst verschiedene Komponenten. Die Hardware selbst wird vom BIOS initialisiert, das den Kernel mithilfe eines Bootloaders startet. Jetzt wird der Bootvorgang mit init und den Runlevels vollständig vom Betriebssystem gesteuert. Mithilfe des Runlevel-Konzepts können Sie Setups für die tägliche Verwendung einrichten und Wartungsaufgaben am System ausführen.

10.1 Der Linux-Bootvorgang

Der Linux-Bootvorgang besteht aus mehreren Phasen, von denen jede einer anderen Komponente entspricht. In der folgenden Liste werden der Bootvorgang und die daran beteiligten Komponenten kurz zusammengefasst.

  1. BIOS.  Nach dem Einschalten des Computers initialisiert das BIOS den Bildschirm und die Tastatur und testet den Hauptspeicher. Bis zu dieser Phase greift der Computer nicht auf Massenspeichergeräte zu. Anschließend werden Informationen zum aktuellen Datum, zur aktuellen Uhrzeit und zu den wichtigsten Peripheriegeräten aus den CMOS-Werten geladen. Wenn die erste Festplatte und deren Geometrie erkannt wurden, geht die Systemkontrolle vom BIOS an den Bootloader über. Wenn das BIOS Netzwerk-Booting unterstützt, ist es auch möglich, einen Boot-Server zu konfigurieren, der den Bootloader bereitstellt. Auf x86-Systemen ist PXE-Boot erforderlich. Andere Architekturen verwenden meist das BOOTP-Protokoll, um den Bootloader abzurufen.

  2. Bootloader.  Der erste physische 512 Byte große Datensektor der ersten Festplatte wird in den Arbeitsspeicher geladen und der Bootloader, der sich am Anfang dieses Sektors befindet, übernimmt die Steuerung. Die vom Bootloader ausgegebenen Befehle bestimmen den verbleibenden Teil des Bootvorgangs. Aus diesem Grund werden die ersten 512 Byte auf der ersten Festplatte als Master Boot Record (MBR) bezeichnet. Der Bootloader übergibt die Steuerung anschließend an das eigentliche Betriebssystem, in diesem Fall an den Linux-Kernel. Weitere Informationen zu GRUB, dem Linux-Bootloader, finden Sie unter Kapitel 11, Der Bootloader GRUB. Bei einem Netzwerk-Boot fungiert das BIOS als Bootloader. Es erhält das Image für den Start vom Boot-Server und startet das System. Dieser Vorgang ist vollständig unabhängig von den lokalen Festplatten.

  3. Kernel und initramfs Um die Systemsteuerung zu übergeben, lädt der Bootloader sowohl den Kernel als auch ein initiales RAM-basiertes Dateisystem (initramfs) in den Arbeitsspeicher. Die Inhalte der Datei initramfs können direkt vom Kernel verwendet werden. initramfs enthält eine kleine ausführbare Datei namens init, die das Einhängen des Root-Dateisystems übernimmt. Spezielle Hardware-Treiber für den Zugriff auf den Massenspeicher müssen in initramfs vorhanden sein. Weitere Informationen zu initramfs finden Sie unter Abschnitt 10.1.1, „initramfs. Wenn das System über keine lokale Festplatte verfügt, muss initramfs das Root-Dateisystem für den Kernel bereitstellen. Dies kann mithilfe eines Netzwerkblockgeräts, wie iSCSI oder SAN, bewerkstelligt werden, es kann aber auch NFS als Root-Gerät eingesetzt werden.

  4. init unter initramfs Dieses Programm führt alle für das Einhängen des entsprechenden Root-Dateisystems erforderlichen Aktionen aus, z. B. das Bereitstellen der Kernel-Funktionalität für die erforderlichen Dateisystem- und Gerätetreiber der Massenspeicher-Controller mit udev. Nachdem das Root-Dateisystem gefunden wurde, wird es auf Fehler geprüft und eingehängt. Wenn dieser Vorgang erfolgreich ist, wird das initramfs bereinigt und das init-Programm wird für das Root-Dateisystem ausgeführt. Weitere Informationen zum init-Programm finden Sie in Abschnitt 10.1.2, „init unter initramfs. Weitere Informationen zu udev finden Sie in Kapitel 15, Gerätemanagement über dynamischen Kernel mithilfe von udev.

  5. init Das init-Programm führt den eigentlichen Boot-Vorgang des Systems über mehrere unterschiedliche Ebenen aus und stellt dabei die unterschiedlichen Funktionalitäten zur Verfügung. Eine Beschreibung des init-Programms finden Sie in Abschnitt 10.2, „Der init-Vorgang“.

10.1.1 initramfs

initramfs ist ein kleines cpio-Archiv, das der Kernel auf einen RAM-Datenträger laden kann. Es stellt eine minimale Linux-Umgebung bereit, die das Ausführen von Programmen ermöglicht, bevor das eigentliche Root-Dateisystem eingehängt wird. Diese minimale Linux-Umgebung wird von BIOS-Routinen in den Arbeitsspeicher geladen und hat, abgesehen von ausreichend Arbeitsspeicher, keine spezifischen Hardware-Anforderungen. initramfs muss immer eine Programmdatei namens init zur Verfügung stellen, die das eigentliche init-Programm für das Root-Dateisystem ausführt, damit der Boot-Vorgang fortgesetzt werden kann.

Bevor das Root-Dateisystem eingehängt und das Betriebssystem gestartet werden kann, ist es für den Kernel erforderlich, dass die entsprechenden Treiber auf das Gerät zugreifen, auf dem sich das Root-Dateisystem befindet. Diese Treiber können spezielle Treiber für bestimmte Arten von Festplatten oder sogar Netzwerktreiber für den Zugriff auf ein Netzwerk-Dateisystem umfassen. Die erforderlichen Module für das Root-Dateisystem können mithilfe von init oder initramfs geladen werden. Nachdem die Module geladen wurden, stellt udev das initramfs mit den erforderlichen Geräten bereit. Später im Boot-Vorgang, nach dem Ändern des Root-Dateisystems, müssen die Geräte regeneriert werden. Dies erfolgt durch boot.udev mit dem Kommando udevtrigger.

Wenn in einem installierten System Hardwarekomponenten (z. B. Festplatten) ausgetauscht werden müssen und diese Hardware zur Boot-Zeit andere Treiber im Kernel erfordert, müssen Sie das initramfs aktualisieren. Sie gehen hierbei genauso vor wie bei der Aktualisierung des Vorgängers init: Rufen Sie mkinitrd auf. Durch das Aufrufen von mkinitrd ohne Argumente wird ein initramfs erstellt. Durch das Aufrufen von mkinitrd -R wird ein init erstellt. In SUSE® Linux Enterprise Server werden die zu ladenden Module durch die Variable INITRD_MODULES in /etc/sysconfig/kernel angegeben. Nach der Installation wird diese Variable automatisch auf den korrekten Wert eingestellt. Die Module werden genau in der Reihenfolge geladen, in der sie in INITRD_MODULES angezeigt werden. Dies ist nur wichtig, wenn Sie sich auf die korrekte Einstellung der Gerätedateien /dev/sd? verlassen. In bestehenden Systemen können Sie jedoch auch die Gerätedateien unter /dev/disk/ verwenden, die in mehreren Unterverzeichnissen angeordnet sind ( by-id, by-path und by-uuid) und stets dieselbe Festplatte darstellen. Dies ist auch während der Installation durch Angabe der entsprechenden Einhängeoption möglich.

Wichtig
Wichtig: Aktualisieren von initramfs oder init

Der Bootloader lädt initramfs oder init auf dieselbe Weise wie den Kernel. Es ist nicht erforderlich, GRUB nach der Aktualisierung von initramfs oder init neu zu installieren, da GRUB beim Booten das Verzeichnis nach der richtigen Datei durchsucht.

10.1.2 init unter initramfs

Der Hauptzweck von init unter initramfs ist es, das Einhängen des eigentlichen Root-Dateisystems sowie die Vorbereitung des Zugriffs darauf. Je nach aktueller Systemkonfiguration ist init für die folgenden Tasks verantwortlich.

Laden der Kernelmodule

Je nach Hardwarekonfiguration sind für den Zugriff auf die Hardwarekomponenten des Computers (vor allem auf die Festplatte) spezielle Treiber erforderlich. Für den Zugriff auf das eigentliche Root-Dateisystem muss der Kernel die entsprechenden Dateisystemtreiber laden.

Bereitstellen von speziellen Blockdateien

Der Kernel generiert Geräteereignisse für alle geladenen Module. udev verarbeitet diese Ereignisse und generiert die erforderlichen blockspezifischen Dateien auf einem RAM-Dateisystem im Verzeichnis /dev. Ohne diese speziellen Dateien wäre ein Zugriff auf das Dateisystem und andere Geräte nicht möglich.

Verwalten von RAID- und LVM-Setups

Wenn Ihr System so konfiguriert ist, dass das Root-Dateisystem sich unter RAID oder LVM befindet, richtet init LVM oder RAID so ein, dass der Zugriff auf das Root-Dateisystem zu einem späteren Zeitpunkt erfolgt. Informationen über RAID und LVM finden Sie in Kapitel 15, Fortgeschrittene Festplattenkonfiguration.

Verwalten von Netzwerkkonfigurationen

Wenn Ihr System für die Verwendung eines Netzwerk-eingehängten Root-Dateisystems (über NFS eingehängt) konfiguriert ist, muss init sicherstellen, dass die entsprechenden Netzwerktreiber geladen und für den Zugriff auf das Root-Dateisystem eingerichtet werden.

Wenn sich das Dateisystem auf einem Netzwerkblockgerät, wie iSCSI oder SAN, befindet, wird die Verbindung zum Speicherserver ebenfalls vom initramfs eingerichtet.

Wenn init im Rahmen des Installationsvorgangs während des anfänglichen Boot-Vorgangs aufgerufen wird, unterscheiden sich seine Tasks von den oben beschriebenen:

Suchen des Installationsmediums

Wenn Sie den Installationsvorgang starten, lädt Ihr Computer vom Installationsmedium einen Installationskernel und ein spezielles init mit dem YaST-Installationsprogramm. Das YaST-Installationsprogramm, das in einem RAM-Dateisystem ausgeführt wird, benötigt Daten über den Speicherort des Installationsmediums, um auf dieses zugreifen und das Betriebssystem installieren zu können.

Initiieren der Hardware-Erkennung und Laden der entsprechenden Kernelmodule

Wie unter Abschnitt 10.1.1, „initramfs beschrieben, startet der Boot-Vorgang mit einem Mindestsatz an Treibern, die für die meisten Hardwarekonfigurationen verwendet werden können. init startet einen anfänglichen Hardware-Scan-Vorgang, bei dem die für die Hardwarekonfiguration geeigneten Treiber ermittelt werden. Die für den Boot-Vorgang benötigten Namen der Module werden in INITRD_MODULES in das Verzeichnis /etc/sysconfig/kernel geschrieben. Diese Namen werden verwendet, um ein benutzerdefiniertes initramfs zu erstellen, das zum Booten des Systems benötigt wird. Wenn die Module nicht zum Booten, sondern für coldplug benötigt werden, werden die Module in /etc/sysconfig/hardware/hwconfig-* geschrieben. Alle Geräte, die durch Konfigurationsdateien in diesem Verzeichnis beschrieben werden, werden beim Boot-Vorgang initialisiert.

Laden des Installations- oder Rettungssystems

Sobald die Hardware korrekt erkannt wurde, werden die entsprechenden Treiber geladen und udev erstellt die entsprechenden Gerätedateien, init startet das Installationssystem mit dem YaST-Installationsprogramm bzw. das Rettungssystem.

Starten von YaST

init startet schließlich YaST, das wiederum die Paketinstallation und die Systemkonfiguration startet.

10.2 Der init-Vorgang

Das Programm init ist der Prozess mit der ID 1. Er ist verantwortlich für die erforderliche Initialisierung des Systems. init wird direkt durch den Kernel gestartet und ist nicht anfällig für „Signal  9“, das Prozesse normalerweise beendet. Alle anderen Programme werden entweder direkt von init oder von einem seiner untergeordneten Prozesse gestartet.

init wird zentral in der Datei /etc/inittab konfiguriert, in der auch die Runlevel definiert werden (siehe Abschnitt 10.2.1, „Runlevel“). Diese Datei legt auch fest, welche Dienste und Dämons in den einzelnen Runlevels verfügbar sind. Je nach den Einträgen in /etc/inittab werden von init mehrere Skripten ausgeführt. Standardmäßig wird nach dem Booten als erstes Skript /etc/init.d/boot gestartet. Nach Abschluss der Systeminitialisierung ändert das System den Runlevel mithilfe des Skripts /etc/init.d/rc auf seinen Standard-Runlevel. Diese Skripten, die der Deutlichkeit halber als init-Skripten bezeichnet werden, befinden sich im Verzeichnis /etc/init.d (siehe Abschnitt 10.2.2, „Init-Skripten“).

Der gesamte Vorgang des Startens und Herunterfahrens des Systems wird von init verwaltet. Vor diesem Hintergrund kann der Kernel als Hintergrundprozess betrachtet werden, der alle anderen Prozesse verwaltet und die CPU-Zeit sowie den Hardwarezugriff entsprechend den Anforderungen anderer Programme anpasst.

10.2.1 Runlevel

Unter Linux definieren Runlevel, wie das System gestartet wird und welche Dienste im laufenden System verfügbar sind. Nach dem Booten startet das System wie in /etc/inittab in der Zeile initdefault definiert. Dies ist in der Regel die Einstellung 3 oder 5. Weitere Informationen hierzu finden Sie unter Tabelle 10.1, „Verfügbare Runlevel“. Alternativ kann der Runlevel auch zur Boot-Zeit (beispielsweise durch Einfügen der Runlevel-Nummer an der Eingabeaufforderung) angegeben werden. Alle Parameter, die nicht direkt vom Kernel ausgewertet werden können, werden an init übergeben. Zum Booten in Runlevel 3 fügen Sie der Boot-Eingabeaufforderung einfach die Ziffer 3 hinzu.

Tabelle 10.1: Verfügbare Runlevel

Runlevel

Beschreibung

0

Systemstopp

S or 1

Einzelbenutzer-Modus

2

Lokaler Mehrbenutzer-Modus mit entferntem Netzwerk (NFS usw.)

3

Mehrbenutzer-Vollmodus mit Netzwerk

4

Benutzerdefiniert. Diese Option wird nicht verwendet, es sei denn, der Administrator konfiguriert diesen Runlevel.

5

Mehrbenutzer-Vollmodus mit Netzwerk und X-Display-Manager - KDM, GDM oder XDM

6

Systemneustart

Wichtig
Wichtig: Runlevel 2 mit einer über NFS eingehängten Partition ist zu vermeiden

Sie sollten Runlevel 2 nicht verwenden, wenn Ihr System eine Partition, wie /usr, über NFS einhängt. Das System zeigt möglicherweise unerwartetes Verhalten, wenn Programmdateien oder Bibliotheken fehlen, da der NFS-Dienst in Runlevel 2 nicht zur Verfügung steht (lokaler Mehrbenutzer-Modus ohne entferntes Netzwerk).

Um die Runlevel während des laufenden Systembetriebs zu ändern, geben Sie telinit und die entsprechende Zahl als Argument ein. Dies darf nur von Systemadministratoren ausgeführt werden. In der folgenden Liste sind die wichtigsten Befehle im Runlevel-Bereich aufgeführt.

telinit 1 oder shutdown now

Das System wechselt in den Einzelbenutzer-Modus. Dieser Modus wird für die Systemwartung und administrative Aufgaben verwendet.

telinit 3

Alle wichtigen Programme und Dienste (einschließlich Netzwerkprogramme und -dienste) werden gestartet und reguläre Benutzer können sich anmelden und mit dem System ohne grafische Umgebung arbeiten.

telinit 5

Die grafische Umgebung wird aktiviert. Normalerweise wird ein Display-Manager, wie XDM, GDM oder KDM, gestartet. Wenn Autologin aktiviert ist, wird der lokale Benutzer beim vorausgewählten Fenster-Manager (GNOME, KDE oder einem anderem Fenster-Manager) angemeldet.

telinit 0 oder shutdown -h now

Das System wird gestoppt.

telinit 6 oder shutdown -r now

Das System wird gestoppt und anschließend neu gestartet.

Runlevel 5 ist der standardmäßige Runlevel bei allen Standardinstallationen von SUSE Linux Enterprise Server. Die Benutzer werden aufgefordert, sich mit einer grafischen Oberfläche anzumelden, oder der Standardbenutzer wird automatisch angemeldet.

Warnung
Warnung: Fehler in /etc/inittab können zu einem fehlerhaften Systemstart führen

Wenn /etc/inittab beschädigt ist, kann das System möglicherweise nicht ordnungsgemäß gebootet werden. Daher müssen Sie bei der Bearbeitung von /etc/inittab extrem vorsichtig sein. Lassen Sie init stets /etc/inittab mit dem Kommando telinit q neu lesen, bevor Sie den Computer neu starten.

Beim Ändern der Runlevel geschehen in der Regel zwei Dinge. Zunächst werden Stopp-Skripten des aktuellen Runlevel gestartet, die einige der für den aktuellen Runlevel wichtigen Programme schließen. Anschließend werden die Start-Skripten des neuen Runlevel gestartet. Dabei werden in den meisten Fällen mehrere Programme gestartet. Beim Wechsel von Runlevel 3 zu 5 wird beispielsweise Folgendes ausgeführt:

  1. Der Administrator (root) fordert init durch die Eingabe des Befehls telinit 5 auf, zu einem anderen Runlevel zu wechseln.

  2. init prüft den aktuellen Runlevel (Runlevel) und stellt fest, dass /etc/init.d/rc mit dem neuen Runlevel als Parameter gestartet werden soll.

  3. Jetzt ruft rc die Stopp-Skripten des aktuellen Runlevel auf, für die es im neuen Runlevel keine Start-Skripten gibt. In diesem Beispiel sind dies alle Skripten, die sich in /etc/init.d/rc3.d (alter Runlevel war 3) befinden und mit einem K beginnen. Die Zahl nach K gibt die Reihenfolge an, in der die Skripten mit dem Parameter stop ausgeführt werden sollen, da einige Abhängigkeiten berücksichtigt werden müssen.

  4. Die Start-Skripten des neuen Runlevel werden zuletzt gestartet. In diesem Beispiel befinden sie sich im Verzeichnis /etc/init.d/rc5.d und beginnen mit einem S. Auch hier legt die nach dem S angegebene Zahl die Reihenfolge fest, in der die Skripten gestartet werden sollen.

Bei dem Wechsel in denselben Runlevel wie der aktuelle Runlevel prüft init nur /etc/inittab auf Änderungen und startet die entsprechenden Schritte, z. B. für das Starten von getty auf einer anderen Schnittstelle. Dieselbe Funktion kann durch den Befehl telinit q erreicht werden.

10.2.2 Init-Skripten

Im Verzeichnis /etc/init.d gibt es zwei Skripttypen:

Skripte, die direkt von init ausgeführt werden

Dies ist nur während des Boot-Vorgangs der Fall oder wenn das sofortige Herunterfahren des Systems initiiert wird (Stromausfall oder Drücken der Tastenkombination StrgAltEntf). Bei IBM-System z-Systemen ist dies nur während des Boot-Vorgangs der Fall oder wenn das sofortige Herunterfahren des Systems initiiert wird (Stromausfall oder Signalstilllegung). Die Ausführung dieser Skripten ist in /etc/inittab definiert.

Skripte, die indirekt von init ausgeführt werden

Diese werden beim Wechsel des Runlevels ausgeführt und rufen immer das Master-Skript /etc/init.d/rc auf, das die richtige Reihenfolge der relevanten Skripten gewährleistet.

Sämtliche Skripten befinden sich im Verzeichnis /etc/init.d. Skripten, die während des Bootens ausgeführt werden, werden über symbolische Links aus /etc/init.d/boot.d aufgerufen. Skripten zum Ändern des Runlevels werden jedoch über symbolische Links aus einem der Unterverzeichnisse (/etc/init.d/rc0.d bis /etc/init.d/rc6.d) aufgerufen. Dies dient lediglich der Übersichtlichkeit und der Vermeidung doppelter Skripten, wenn diese in unterschiedlichen Runlevels verwendet werden. Da jedes Skript sowohl als Start- als auch als Stopp-Skript ausgeführt werden kann, müssen sie die Parameter start und stop erkennen. Die Skripten erkennen außerdem die Optionen restart, reload, force-reload und status. Diese verschiedenen Optionen werden in Tabelle 10.2, „Mögliche init-Skript-Optionen“ erläutert. Die von init direkt ausgeführten Skripte verfügen nicht über diese Links. Sie werden unabhängig vom Runlevel bei Bedarf ausgeführt.

Tabelle 10.2: Mögliche init-Skript-Optionen

Option

Beschreibung

start

Startet den Dienst.

stop

Stoppt den Dienst.

restart

Wenn der Dienst läuft, wird er gestoppt und anschließend neu gestartet. Wenn der Dienst nicht läuft, wird er gestartet.

reload

Die Konfiguration wird ohne Stoppen und Neustarten des Dienstes neu geladen.

force-reload

Die Konfiguration wird neu geladen, sofern der Dienst dies unterstützt. Anderenfalls erfolgt dieselbe Aktion wie bei dem Befehl restart.

status

Zeigt den aktuellen Status des Dienstes an.

Mithilfe von Links in den einzelnen Runlevel-spezifischen Unterverzeichnissen können Skripten mit unterschiedlichen Runleveln verknüpft werden. Bei der Installation oder Deinstallation von Paketen werden diese Links mithilfe des Programms „insserv“ hinzugefügt oder entfernt (oder mithilfe von /usr/lib/lsb/install_initd, ein Skript, das dieses Programm aufruft). Unter man 8 insserv finden Sie weitere Einzelheiten.

All diese Einstellungen können auch mithilfe des YaST-Moduls geändert werden. Wenn Sie den Status über die Kommandozeile prüfen, verwenden Sie das Werkzeug chkconfig, das auf der man-Seite man 8 chkconfig beschrieben ist.

Im Folgenden finden Sie eine kurze Einführung in die zuerst bzw. zuletzt gestarteten Boot- und Stopp-Skripten sowie eine Erläuterung des Steuerskripten.

boot

Werden ausgeführt, wenn das System direkt mit init gestartet wird. Es wird unabhängig vom gewählten Runlevel und nur einmalig ausgeführt. Dabei werden die Dateisysteme /proc und /dev/pts eingehängt und blogd (Boot Logging Daemon) wird aktiviert. Wenn das System nach einer Aktualisierung oder einer Installation das erste Mal gebootet wird, wird die anfängliche Systemkonfiguration gestartet.

Der blogd-Dämon ist ein Dienst, der von boot und rc vor allen anderen Diensten gestartet wird. Er wird beendet, sobald die von diesen Skripten (die eine Reihe von Unterskripte ausführen, beispielsweise um spezielle Blockdateien verfügbar zu machen) ausgelösten Aktionen abgeschlossen sind. blogd schreibt alle Bildschirmausgaben in die Protokolldatei /var/log/boot.msg, jedoch nur wenn /var mit Schreib-/Lesezugriff eingehängt ist. Anderenfalls puffert blogd alle Bildschirmdaten, bis /var zur Verfügung steht. Info man(-Kommando)

Das Skript boot ist zudem für das Starten aller Skripten in /etc/init.d/boot.d verantwortlich, deren Name mit S beginnt. Dort werden die Dateisysteme überprüft und bei Bedarf Loop-Devices konfiguriert. Außerdem wird die Systemzeit festgelegt. Wenn bei der automatischen Prüfung und Reparatur des Dateisystems ein Fehler auftritt, kann der Systemadministrator nach Eingabe des Root-Passworts eingreifen. Das zuletzt ausgeführte Skript ist boot.local.

boot.local

Hier können Sie zusätzliche Kommandos eingeben, die beim Booten ausgeführt werden sollen, bevor Sie zu einem Runlevel wechseln. Dieses Skript ist mit der AUTOEXEC.BAT in DOS-Systemen vergleichbar.

halt

Dieses Skript wird nur beim Wechsel in Runlevel 0 oder 6 ausgeführt. Hier wird es entweder als init oder als init ausgeführt. Ob das System heruntergefahren oder neu gebootet wird, hängt davon ab, wie halt aufgerufen wird. Falls beim Herunterfahren Sonderkommandos benötigt werden, fügen Sie diese dem Skript init hinzu.

rc

Dieses Skript ruft die entsprechenden Stopp-Skripten des aktuellen Runlevels und die Start-Skripten des neu gewählten Runlevels auf. Wie das Skript /etc/init.d/boot wird auch dieses Skript über /etc/inittab mit dem gewünschten Runlevel als Parameter aufgerufen.

Sie können Ihre eigenen Skripten erstellen und diese problemlos in das oben beschriebene Schema integrieren. Anweisungen zum Formatieren, Benennen und Organisieren benutzerdefinierter Skripten finden Sie in den Spezifikationen von LSB und auf den man-Seiten von init, init.d, chkconfig und insserv. Weitere Informationen finden Sie zudem auf den man-Seiten zu startproc und killproc.

Warnung
Warnung: Fehlerhafte init-Skripte können das System stoppen

Bei fehlerhaften init-Skripten kann es dazu kommen, dass der Computer hängt. Diese Skripten sollten mit großer Vorsicht bearbeitet werden und, wenn möglich, gründlich in der Mehrbenutzer-Umgebung getestet werden. Hilfreiche Informationen zu init-Skripten finden Sie in Abschnitt 10.2.1, „Runlevel“.

Sie erstellen ein benutzerdefiniertes init-Skript für ein bestimmtes Programm oder einen Dienst, indem Sie die Datei /etc/init.d/skeleton als Schablone verwenden. Speichern Sie eine Kopie dieser Datei unter dem neuen Namen und bearbeiten Sie die relevanten Programm- und Dateinamen, Pfade und ggf. weitere Details. Sie können das Skript auch mit eigenen Ergänzungen erweitern, sodass die richtigen Aktionen vom init-Prozess ausgelöst werden.

Der Block INIT INFO oben ist ein erforderlicher Teil des Skripts und muss bearbeitet werden. Weitere Informationen hierzu finden Sie unter Beispiel 10.1, „Ein minimaler INIT INFO-Block“.

Beispiel 10.1: Ein minimaler INIT INFO-Block
### BEGIN INIT INFO
# Provides:          FOO
# Required-Start:    $syslog $remote_fs
# Required-Stop:     $syslog $remote_fs
# Default-Start:     3 5
# Default-Stop:      0 1 2 6
# Description:       Start FOO to allow XY and provide YZ
### END INIT INFO

Geben Sie in der ersten Zeile des INFO-Blocks nach Provides: den Namen des Programms oder des Dienstes an, das bzw. der mit diesem Skript gesteuert werden soll. Geben Sie in den Zeilen Required-Start: und Required-Stop: alle Dienste an, die weiter ausgeführt werden müssen, wenn der Dienst selbst gestoppt wird. Diese Informationen werden später zum Generieren der Nummerierung der Skriptnamen verwendet, die in den Runlevel-Verzeichnissen enthalten sind. Geben Sie nach Default-Start: und Default-Stop: die Runlevel an, in denen der Dienst automatisch gestartet oder gestoppt werden soll. Geben Sie für Description: schließlich eine kurze Beschreibung des betreffenden Dienstes ein.

Um in den Runlevel-Verzeichnissen (/etc/init.d/rc?.d/) die Links auf die entsprechenden Skripten in /etc/init.d/ zu erstellen, geben Sie den Befehl insserv neuer skriptname ein. Das Programm insserv wertet den INIT INFO-Header aus, um die erforderlichen Links für die Start- und Stopp-Skripts in den Runlevel-Verzeichnissen (/etc/init.d/rc?.d/) zu erstellen. Das Programm sorgt zudem für die richtige Start- und Stopp-Reihenfolge für die einzelnen Runlevel, indem es die erforderlichen Nummern in die Namen dieser Links aufnimmt. Wenn Sie zum Erstellen der Links ein grafisches Werkzeug bevorzugen, verwenden Sie den von YaST zur Verfügung gestellten Runlevel-Editor wie in Abschnitt 10.2.3, „Konfigurieren von Systemdiensten (Runlevel) mit YaST“ beschrieben.

Wenn ein in /etc/init.d/ bereits vorhandenes Skript in das vorhandene Runlevel-Schema integriert werden soll, erstellen Sie die Links in den Runlevel-Verzeichnissen direkt mit insserv oder indem Sie den entsprechenden Dienst im Runlevel-Editor von YaST aktivieren. Ihre Änderungen werden beim nächsten Neustart wirksam und der neue Dienst wird automatisch gestartet.

Diese Links dürfen nicht manuell festgelegt werden. Wenn der INFO-Block Fehler enthält, treten Probleme auf, wenn insserv zu einem späteren Zeitpunkt für einen anderen Dienst ausgeführt wird. Der manuell hinzugefügte Dienst wird bei der nächsten Ausführung von insserv für dieses Skript entfernt.

10.2.3 Konfigurieren von Systemdiensten (Runlevel) mit YaST

Nach dem Starten dieses YaST-Moduls mit YaST › System › Systemdienste (Runlevel) werden ein Überblick über alle verfügbaren Dienste sowie der aktuelle Status der einzelnen Dienste (deaktiviert oder aktiviert) angezeigt. Legen Sie fest, ob das Modul im einfachen Modus oder im Expertenmodus ausgeführt werden soll. Der vorgegebene einfache Modus sollte für die meisten Zwecke ausreichend sein. In der linken Spalte wird der Name des Dienstes, in der mittleren Spalte sein aktueller Status und in der rechten Spalte eine kurze Beschreibung angezeigt. Der untere Teil des Fensters enthält eine ausführlichere Beschreibung des ausgewählten Dienstes. Um einen Dienst zu aktivieren, wählen Sie ihn in der Tabelle aus und klicken Sie anschließend auf Aktivieren. Führen Sie die gleichen Schritte aus, um einen Dienst zu deaktivieren.

Die detaillierte Steuerung der Runlevel, in denen ein Dienst gestartet oder gestoppt bzw. die Änderung des vorgegebenen Runlevel erfolgt im Expertenmodus. Der aktuell vorgegebene Runlevel oder initdefault (der Runlevel, in den das System standardmäßig bootet) wird oben angezeigt. Der standardmäßige Runlevel eines SUSE Linux Enterprise Server-Systems ist in der Regel Runlevel 5 (Mehrbenutzer-Vollmodus mit Netzwerk und X). Eine geeignete Alternative kann Runlevel 3 sein (Mehrbenutzer-Vollmodus mit Netzwerk).

In diesem YaST-Dialogfeld können Sie einen Runlevel (wie unter Tabelle 10.1, „Verfügbare Runlevel“ aufgeführt) als neuen Standard wählen. Zudem können Sie mithilfe der Tabelle in diesem Fenster einzelne Dienste und Dämonen aktivieren oder deaktivieren. In dieser Tabelle sind die verfügbaren Dienste und Dämonen aufgelistet und es wird angezeigt, ob sie aktuell auf dem System aktiviert sind und wenn ja, für welche Runlevel. Nachdem Sie mit der Maus eine der Zeilen ausgewählt haben, klicken Sie auf die Kontrollkästchen, die die Runlevel (B, 0, 1, 2, 3, 5, 6 und S) darstellen, um die Runlevel festzulegen, in denen der ausgewählte Dienst oder Daemon ausgeführt werden sollte. Runlevel 4 ist nicht definiert, um das Erstellen eines benutzerdefinierten Runlevel zu ermöglichen. Unterhalb der Tabelle wird eine kurze Beschreibung des aktuell ausgewählten Dienstes oder Daemons angezeigt.

Warnung
Warnung: Fehlerhafte Runlevel-Einstellungen können das System beschädigen

Fehlerhafte Runlevel-Einstellungen können ein System unbrauchbar machen. Stellen Sie vor dem Anwenden der Änderungen sicher, dass Sie deren Auswirkungen kennen.

Systemdienste (Runlevel)
Abbildung 10.1: Systemdienste (Runlevel)

Legen Sie mit den Optionen Start, Anhalten oder Aktualisieren fest, ob ein Dienst aktiviert werden soll. Status aktualisieren prüft den aktuellen Status. Mit Übernehmen oder Zurücksetzen können Sie wählen, ob die Änderungen für das System angewendet werden sollen, oder ob die ursprünglichen Einstellungen wiederhergestellt werden sollen, die vor dem Starten des Runlevel-Editors wirksam waren. Mit OK speichern Sie die geänderten Einstellungen.

10.3 Systemkonfiguration über /etc/sysconfig

Die Hauptkonfiguration von SUSE Linux Enterprise Server wird über die Konfigurationsdateien in /etc/sysconfig gesteuert. Die einzelnen Dateien in /etc/sysconfig werden nur von den Skripten gelesen, für die sie relevant sind. Dadurch wird gewährleistet, dass Netzwerkeinstellungen beispielsweise nur von netzwerkbezogenen Skripten analysiert werden.

Sie haben zwei Möglichkeiten, die Systemkonfiguration zu bearbeiten. Entweder verwenden Sie den YaST-Editor "sysconfig" oder Sie bearbeiten die Konfigurationsdateien manuell.

10.3.1 Ändern der Systemkonfiguration mithilfe des YaST-Editors "sysconfig"

Der YaST-Editor "sysconfig" bietet ein benutzerfreundliches Frontend für die Systemkonfiguration. Ohne den eigentlichen Speicherort der zu ändernden Konfigurationsvariablen zu kennen, können Sie mithilfe der integrierten Suchfunktion dieses Moduls den Wert der Konfigurationsvariablen wie erforderlich ändern. YaST wendet diese Änderungen an, aktualisiert die Konfigurationen, die von den Werten in sysconfig abhängig sind, und startet die Dienste neu.

Warnung
Warnung: Das Ändern von /etc/sysconfig/*-Dateien kann die Installation beschädigen

Sie sollten die Dateien /etc/sysconfig-Dateien nur bearbeiten, wenn Sie über ausreichende Sachkenntnisse verfügen. Das unsachgemäße Bearbeiten dieser Dateien kann zu schwerwiegenden Fehlern des Systems führen. Die Dateien in /etc/sysconfig enthalten einen kurzen Kommentar zu den einzelnen Variablen, der erklärt, welche Auswirkungen diese tatsächlich haben.

Systemkonfiguration mithilfe des sysconfig-Editors
Abbildung 10.2: Systemkonfiguration mithilfe des sysconfig-Editors

Das YaST-Dialogfeld "sysconfig" besteht aus drei Teilen. Auf der linken Seite des Dialogfelds wird eine Baumstruktur aller konfigurierbaren Variablen angezeigt. Wenn Sie eine Variable auswählen, werden auf der rechten Seite sowohl die aktuelle Auswahl als auch die aktuelle Einstellung dieser Variable angezeigt. Unten werden in einem dritten Fenster eine kurze Beschreibung des Zwecks der Variable, mögliche Werte, der Standardwert und die Konfigurationsdatei angezeigt, aus der diese Variable stammt. In diesem Dialogfeld werden zudem Informationen dazu zur Verfügung gestellt, welche Konfigurationsskripten nach dem Ändern der Variable ausgeführt und welche neuen Dienste als Folge dieser Änderung gestartet werden. YaST fordert Sie zur Bestätigung der Änderungen auf und zeigt an, welche Skripts ausgeführt werden, wenn Sie Beenden wählen. Außerdem können Sie die Dienste und Skripten auswählen, die jetzt übersprungen und zu einem späteren Zeitpunkt gestartet werden sollen. YaST wendet alle Änderungen automatisch an und startet alle von den Änderungen betroffenen Dienste neu, damit die Änderungen wirksam werden.

10.3.2 Manuelles Ändern der Systemkonfiguration

Gehen Sie wie folgt vor, um die Systemkonfiguration manuell zu ändern:

  1. Melden Sie sich als root an.

  2. Wechseln Sie mit telinit 1 in den Einzelbenutzer-Modus (Runlevel 1).

  3. Nehmen Sie die erforderlichen Änderungen an den Konfigurationsdateien in einem Editor Ihrer Wahl vor.

    Wenn Sie die Konfigurationsdateien in /etc/sysconfig nicht mit YaST ändern, müssen leere Variablenwerte durch zwei Anführungszeichen (KEYTABLE="") gekennzeichnet sein und Werte, die Leerzeichen enthalten, müssen in Anführungszeichen gesetzt werden. Werte, die nur aus einem Wort bestehen, müssen nicht in Anführungszeichen gesetzt werden.

  4. Führen Sie SuSEconfig aus, um sicherzustellen, dass die Änderungen wirksam werden.

  5. Mit einem Kommando wie telinit default_runlevel stellen Sie den vorherigen Runlevel des Systems wieder her. Ersetzen Sie default_runlevel durch den vorgegebenen Runlevel des Systems. Wählen Sie 5, wenn Sie in den Mehrbenutzer-Vollmodus mit Netzwerk und X zurückkehren möchten, oder wählen Sie 3, wenn Sie lieber im Mehrbenutzer-Vollmodus mit Netzwerk arbeiten möchten.

Dieses Verfahren ist hauptsächlich beim Ändern von systemweiten Einstellungen, z. B. der Netzwerkkonfiguration, relevant. Für kleinere Änderungen ist der Wechsel in den Einzelbenutzer-Modus nicht erforderlich. In diesem Modus können Sie jedoch sicherstellen, dass alle von den Änderungen betroffenen Programme ordnungsgemäß neu gestartet werden.

Tipp
Tipp: Konfigurieren der automatisierten Systemkonfiguration

Um die automatisierte Systemkonfiguration von SuSEconfig zu deaktivieren, setzen Sie die Variable ENABLE_SUSECONFIG in /etc/sysconfig/suseconfig auf no. Wenn Sie den SUSE-Support für die Installation nutzen möchten, darf SuSEconfig nicht deaktiviert werden. Es ist auch möglich, die automatisierte Konfiguration teilweise zu deaktivieren.

Diese Seite drucken