F-Init Doku

Klaus Franken (finit@klaus.franken.de)

März 1999


F-Init ist ein Service-Verwaltungs-System, Services (Dienste) können in Abhängigkeit voneinander gestartet und gestoppt werden. Von besonderer Bedeutung sind die Diagnosefreundlichkeit und flexible Administration. Als spezieller Einsatz sind die Unix-Initscripts vorgesehen.

1. Lizenz

Die Lizenzbestimmungen sind noch nicht festgelegt.

Das Programm darf momentan frei getestet werden, aber ohne Rücksprache nicht eingesetzt und nicht auf CD oder anderen Datenträgern verbreitet werden.

Copyright by Klaus Franken 1999.

Es wird keinlerlei Garantie gewährt.

2. Motivation

2.1 Kurzbeschreibung System-V-Init

Das Bootkonzept eines Unix-Systems (mit System-V Init) kennt Services (eigentlich nur Programmaufrufe), die in einer festgelegten Reihenfolge gestartet oder gestoppt werden. Die Services werden in Runlevels zusammengefasst, um schnell von einer Konfiguration zur nächsten zu wechseln.

Die Reihenfolge wird dabei durch Nummerierung festgelegt; eine Abhängigkeit zwischen den Diensten ist damit nicht explizit vorhanden.

Die Runlevels werden dabei (typerweise) durch setzen von Links in einem speziellen Verzeichnis definiert, bei der auch die Start- und Stop-Nummer vergeben wird.

Beim Wechsel des Runlevels werden dann einfach alle Scripte in diesem Verzeichnis der Reihe nach (entsprechend ihrer Nummer) gestartet, wenn sie im alten Runlevelverzeichnis nicht vorhanden waren - genauso werden nicht mehr vorhandene Scripte gestoppt.

2.2 Unzulänglichkeiten des System-V-Init

Siehe auch Features von F-Init

3. Features von F-Init

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

5. Besonderheiten

5.1 No-Services

Manche Dinge kann man nicht zurücknehmen, das Beispiel in der Testumgebung krankt z.B. daran, daß beim Wechsel von Runlevel 3 nach 2 der Service serial gestoppt wird, aber das ist nicht wirklich möglich, die seriellen Schnittstellen sind und bleiben konfiguriert. serial ist ein Dienst, der nur einmal gestartet werden braucht. Hierfür ist das Schlüsselwort once vorgesehen (Siehe: Kewords für Services, noch nicht implementiert)

Ein anderes Fall ist, daß ein Dienst immer wieder gestartet, aber nie gestoppt werden soll. Ein Beispiel hierfür ist route, daß nach jeder Änderung an den Netzinterfaces gestartet werden soll (z.B. von network und i4l). Dafür wird route als postprg für network und i4l eingetragen und als noservice markiert (siehe Kewords für Services).

6. Syntax der Konfigurationsdateien

6.1 Keywords

globale Kewords

verbose

Verbose-Level

backuplog

Anzahl Backup-Files der Logfiles. Siehe /var/log/finit

varlog

Directory für die Logfiles. Siehe /var/log/finit

varrun

Directory für die Runfiles. Siehe /var/run/finit

scripts

Directory für die Initscripts. Siehe /etc/rc.d

localconf

Dateiname für die lokale Konfigurationsdatei.

Kewords für Services

Identifier ist der Name des Services (z.B. network:)

clear

Löscht alles bisherige über Service

needs list-of-services

Trägt alle alle Service aus list-of-services (durch Komma getrennt) als Server für diesen Service ein.

poststart Service

Nach dem Start soll Service gestartet werden. Siehe No-Services.

noservice

Service wird immer wieder gestartet und niemals gestoppt. Siehe No-Services.

Geplante Keywords (Implementierung nur wenn gebraucht)

prestart Service

Vor dem Start soll Service gestartet werden.

poststop Service

Nach dem Stop soll Service gestartet werden.

prestop Service

Vor dem Stop soll Service gestartet werden.

script

Programm zum Starten anstatt Script aus /etc/rc.d

wish Service

Abschwächung von needs: Abhängigkeit nur wenn Service vorhanden.

before Service

Umkehrung zu needs: statt X needs Y schreibt man Y before X. Dadurch kann die Abhängigkeit Server anstatt beim Client definiert werden.

provides Alias

Bietet Service Alias an.

once

Service wird nur einmal (höchtens gestartet).

Kewords für Runlevels

Identifier ist der Name des Runlevels (z.B. 2:). Dahinter werden getrennt durch Komma oder Newline die Services aufgeführt.

Besonderheiten:

-

Ein vorangestelltes Minuszeichen besagt, daß diser Service nicht im Runlevel gestartet werden soll.

()

Ein mit runden Klammern umschlossener Runlevel wird importiert. Das Importieren geschieht zur Zeit der Auswertung; nicht zum Zeitpunkt des Lesens.

7. Kommandoreferenz

Die Kommandozeile wird ein zwei Durchläufen abgearbeitet. Im ersten Durchlauf werden allgemeine Einstellungen gesucht, hierfür ist die Reihenfolge egal, z.B. -test kann vor oder nach einem Kommando stehen, es wird in beiden Fällen beim Ausführen eines Kommandos beachtet.

Im zweiten Durchlauf werden die Kommandos in der Reihenfolge ihrer Auftretens abgearbeitet.

7.1 allgemeine Einstellungen

-V

Druckt Versionsnummer und Beendet F-Init.

--help

Druckt Usage-Meldung und Beendet F-Init.

-f Dateiname

Liest Konfiguration von Dateiname anstatt von /etc/finit.conf

-test

Kommandos werden nicht ausgeführt, sondern nur angezeigt, was zu tun wäre.

7.2 Kommandos

-start Service

Startet den Service Service und ggf. zuvor alle Server dafür.

-restart Service

Stoppt den Service Service und ggf. zuvor alle Clienten davon. Startet danach wieder alle Services, wie vorher.

Ist Service noch nicht gestartet, wird er nomal gestartet.

-stop Service

Stoppt den Service Service wenn er keine Clienten hat.

-STOP Service

Stoppt den Service Service und ggf. zuvor alle Clienten davon.

-startrunlevel Runlevel

Startet zusätzlich zum den aktuellen Services alle Services vom Runlevel Runlevel.

-stoprunlevel Runlevel

Stoppt alle Services von Runlevel Runlevel.

-gorunlevel Runlevel

Stoppt zunächst alle aktuellen Services, die nicht zum neuen Runlevel gehören und startet danach alle Services von Runlevel.

-changerunlevel Runlevel-Neu Runlevel-Alt

Bestimmt die Unterschiede zwischen Runlevel-Neu und Runlevel-Alt. Stoppt alle nicht mehr benötigten und startet alle neuen Services.

Eventuell gestartet Services, die in keinen der Runlevels auftauchen. Bleiben unberücksichtig.

-list

Listet alle gestarteten Services.

-listall

Listet alle bekannten Services.

-listtree

Listet alle bekannten Services in einer Baumgrafik, der die Abhängigkeiten zeigt.

8. Files & Directories

8.1 Files

/etc/finit.conf

Globale Konfigurationsdatei. Kann beim Update überschrieben werden.

Syntax: siehe Syntax der Konfigurationsdateien.

Kann mit Schalter -f überschrieben werden. Siehe Kommandoreferenz

/etc/finit.conf.local

Lokale Konfigurationsdatei. Wird beim Update nicht überschrieben.

Syntax: siehe Syntax der Konfigurationsdateien.

Kann mit Keyword localconf überschrieben werden. Siehe globale Kewords

8.2 Directories

/var/run/finit

Für jeden gestarteten Service liegt dort eine Datei (Dateiname ist der Servicename), mit Logging-Informationen (Startzeit, Startgrund).

Kennzeichen dafür, daß ein Service gestartet ist, ist genau das Vorhandensein dieser Datei. Man kann F-Init also einen gestarteten Service vortäuschen, indem man hier eine Datei anlegt (darf nicht mit einen Punkt beginnen, muß lesbar sein und darf kein Directory sein).

Kann mit Keyword varrun überschrieben werden. Siehe globale Kewords.

/var/log/finit

Beinhaltet für jeden Dienst die letzten Start- und Stop-Meldungen.

Es werden jeweils Backup-Dateien mit der Extension .1, .2 u.s.w. angelegt, siehe auch backuplog in globale Kewords.

Wird in Zukunft direkt in /var/run/finit abgelegt.

Kann mit Keyword varlog überschrieben werden. Siehe globale Kewords

/etc/rc.d

Programme, die jeweils den Service starten/stoppen, werden mit dem Parameter start bzw. stop von finit aufgerufen.

Ein Dienst gilt verfügbar, wenn es in diesem Verzeichns ein ausführbares Programm (kein Directory, kein führender Punkt) gibt.

Kann mit Keyword scripts überschrieben werden. Siehe globale Kewords

/etc/rc.d/finit

Noch nicht implementiert!

In diesem Verzeichnis können einzelne Pakete ihre Konfiguration ablegen, also ihre eigenen Abhängigkeiten definieren und sich in die gewünschten Runlevels eintragen.

Diese Dateien werden zwischen der globalen und der lokalen konfigurationsdatei eingelesen.

Die Syntax dieser Dateien ist die gleiche wie für /etc/finit.conf siehe Syntax der Konfigurationsdateien.

9. Installation

9.1 Voraussetzungen

F-Init sollte auf jedem Linux/Unix-System laufen. Entwickelt und getestet unter SuSE Linux 6.0 mit perl5 (5.005_02).

9.2 Basisinstallation

Mit install.finit werden die Verzeichnisse unter var angelegt, finit.pl unter /sbin installiert und eine /etc/finit.conf angelegt. Sollte /etc/finit.conf schon existieren, wird geprüft, ob die installierte Version der neuen entspricht, falls nicht, wird die neue als /etc/finit.conf.NEW angelegt; eine bestehende Konfiguration wird nicht überschrieben.

9.3 Integration in die System-V-Init-Umgebung

Du solltest wissen was Du tust, speziell wenn Du ein laufendes System umstellt.

Man kann z.B. am besten im Singleuser-Mode (weil F-Init ja nicht weiss, was geerade gestartet ist) folgendes ausführen:

cd /etc/rc.d
for i in 1 2 3 4 5 
do
    cd rc$i.d
    rm *
    ln -s ../finit.rc S50finit
    cd ..
done

9.4 Hinweise zu SuSE 6.0

10. Bugs

hmm, siehe Features ;-)

Siehe Datei TODO.

11. Future

Siehe Datei TODO.

12. Status / News

Pre-Beta

Meine Workstations booten mit F-Init :-)