Weiter Zurück Inhalt

4. Tour de finit

In diesem Abschnitt wird eine Tour durch die Grundzuege von F-Init gemacht. Wichtige Begriffe und die wichtigten Funktionsweisen werden in einer nachvollziehbaren Test-Umgebung durchgespielt.

4.1 Begriffe

Service

Ein Service (auch Dienst) hat folgende Eigenschaften:

  1. Ein Dienst wird durch einen Programmaufruf gestartet und gestoppt.
  2. Der Programmaufruf kann fehlschlagen (Exit-Code).
  3. Er kann Abhängigkeiten haben, indem er andere Dienste voraussetzt oder selbst für andere Dienste Voraussetzung ist.

Beispiele für Services:

  1. Konfiguration der Ethernet-Karten (/etc/rc.d/network)
  2. Start des Yellow-Page-Clienten (/etc/rc.d/ypclient)

Dienst

Wird synonym zu Service verwendet.

Server

Ein Service, der für einen anderen Service Vorausetzung ist.

Client

Ein Service, der von einen anderen Service abhängig ist.

Abhängigkeit

Ein Service benötigt einen anderen Service, um arbeiten zu können.

Beispiel: ypclient kann erst arbeiten, wenn die Netzwerkumgebung network gestartet ist. Man sagt:

Runlevel

Zusammenfassung von Diensten.

Wird benutzt, um verschiedene mögliche Konfigurationen eines Systems einfacher ansprechen zu können. Z.B. Runlevel 1: Multiuserbetrieb; Runlevel 2: Multiuserbetrieb mit Netzwerkanbindung.

Spezielle Runlevel: Runlevel 0: System-Stopp; Runlevel 6: System-Neustart.

finit

Das endgültige Werkzeug, das alles verwaltet ;-)

4.2 Beispiel-Ablauf für F-Init

Hier wird eine nachvollziehbare Testungebung durchgespielt. Man kann dies direkt in Sourceverzeichnis ohne installation und ohne Root-Rechte nachvollziehen, die Pfade werden in der Test-Konfigurationsdatei entsprechend umgebogen (siehe finit.conf.example). Beim Aufruf von finit.pl muß dazu immer der Schalter -f finit.conf.example angeben werden.

Die vereinfachte und idealisierte Testumgebung besteht aus:

Folgende Runlevelkonfiguration wird gewünscht:

Der gpm wird im Runlevel 3 nicht gestartet, da es bei PS2-Mäusen oft Probleme mit dem parallelen Zugriff von GPM und X gibt. Da dem aber nicht wirklich immer so ist, siehe lokale Anpassung.

Zuerst werden die Abhängigkeiten in der Datei /etc/finit.conf in der Section services eingetragen:

[services]
network:
    needs kerneld 
ypclient:
    needs network
gpm:
    needs serial
xdm:
    needs ypclient

Nicht alle Services müssen hier aufgeführt werden, hier fehlt z.B. named. Das Vorhandensein eines Dienstes wird dadurch festgestellt, daß das Initscript (normalerweise /etc/rc.d/named) existiert.

In einer zweiten Section werden die Runlevel definiert:

[runlevels]
2: network, named, gpm
3: (2), xdm, -gpm

Erklärung:

Der Aufruf von

    ./finit.pl -f finit.conf.example -gorunlevel 2 -test
zeigt uns was passieren würde, wenn wir in den Runlevel 2 wechseln, führt dies aber noch nicht aus (Schalter -test). Es wird in dieser Reihenfolge gestartet: serial, gpm, named, kerneld, network. Es wird also inbesondere serial vor gpm und kerneld vor network gestartet. Ansonsten ist die Reihenfolge unbestimmt (genaugenommen alphanumerisch sortiert).

Wir wechseln in Runlevel 2:

    ./finit.pl -f finit.conf.example -gorunlevel 2 

und testen was bei Runlevel 3 passieren würde

    ./finit.pl -f finit.conf.example -gorunlevel 3 -test

Es wird gpm und serial gestoppt (beide sind nicht in Runlevel 3, serial nicht, da gpm nicht mehr gestartet ist). Gestartet werden dagegen die Dienste ypclient und xdm.

Gibt man degegen das Kommando

./finit.pl -f finit.conf.example -startrunlevel 3 -test
werden die Dienste für Runlevel 3 zusätzlich gestartet ohne die alten Dienste für Runlevel 2 zu stoppen.

Das Kommando

./finit.pl -f finit.conf.example -list
zeigt uns alle gestarteten Dienste, z.B. (wir sind ja noch im Runlevel 2):
Service:gpm
        Starttime: Fri Mar 26 15:59:22 MET 1999
        Startreason: runlevel 2
        Servers: serial
Service:kerneld
        Starttime: Fri Mar 26 15:59:22 MET 1999
        Startreason: needed_by network
        Clients: network
Service:named
        Starttime: Fri Mar 26 15:59:22 MET 1999
        Startreason: runlevel 2
Service:network
        Starttime: Fri Mar 26 15:59:22 MET 1999
        Startreason: runlevel 2
        Servers: kerneld
        Clients: ypclient(-)
Service:serial
        Starttime: Fri Mar 26 15:59:22 MET 1999
        Startreason: needed_by gpm
        Clients: gpm
Man sieht hier neben Startzeit und Startgrund auch eventuelle Servers und Clients jedes Dientes. Mit dem Schalter listtree kann man es sich auch die Abhängigkeiten visuell darstellen lassen: (Ausschnitt, es werden immer alle bekannten Dienste gestartet)
gpm:
        serial:
named:
xdm(-):
        ypclient(-):
                network:
                        kerneld:

Ein (-) hinter dem Namen kennzeichnet jeweils, daß der Dienst momentan nicht gestartet ist.

4.3 lokale Anpassung

Wie oben angedeutet, ist diese Konfiguration nicht für alle Systeme sinnvoll, hier soll als Beispiel der GPM gestartet werden, obwohl der X-Server läuft (weil es z.B. eine serielle Maus ist).

Dazu muß nicht die globale Konfigurationsdatei /etc/finit.conf (Testumgebung: finit.conf.example) modifiziert werden, sondern die Abweichungen werden in /etc/finit.conf.local eingetragen (Testumgebung: finit.conf.local, siehe Eintrag in finit.conf.example).

/etc/finit.conf.local wird - wenn vorhanden - zusätzlich zur globale /etc/finit.conf eingelesen, wobei die Definitionen daraus nicht überschrieben werden, sondern es werden nur zusätzliche Angaben definiert. (Eine Section bzw. jede Definition von Services und Runlevels kann also beliebig oft erweitert werden.)

Um für den lokalen Rechner zu bestimmen, daß gpm doch im Runlevel 3 gestartet werden soll, reicht die finit.conf.local:

[runlevels]
3: gpm

Erklärung: Bei den Runlevels wird nach einer Plus/Minus-Rechnung entschieden. gpm ist zweimal als + eingetragen (einmal in der globalen Konfiguration im Runlevel 2 und einmal in der lokalen direkt in Runlevel 3) und einmal als - (in der globalen in Runlevel 3). Das ergibt eine Differenz von +1, also wird es gestartet.

4.4 weitere Tests


Weiter Zurück Inhalt