finit@klaus.franken.de
)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.
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.
init 3
startet xdm erneut.Siehe auch Features von F-Init
-test
.startrunlevel
, gorunlevel
und changerunlevel
.finit
könnte als Modul in andere
Applikationen eingebunden werden.
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.
Ein Service (auch Dienst) hat folgende Eigenschaften:
Beispiele für Services:
/etc/rc.d/network
)/etc/rc.d/ypclient
)
Wird synonym zu Service verwendet.
Ein Service, der für einen anderen Service Vorausetzung ist.
Ein Service, der von einen anderen Service abhängig ist.
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:
ypclient
ist abhängig von network
.ypclient
ist Client von network
.network
ist Server von ypclient
.
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.
Das endgültige Werkzeug, das alles verwaltet ;-)
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:
kerneld
: Startet den Kernel-Daemon zum automatischen Laden von
Modulen.network
: Konfiguriert das lokale Ethernet. Braucht: kerneld
.ypclient
: Startet den YP-Client, damit sich lokale Benutzer anmelden
können. Braucht: network
.serial
: Konfiguriert die seriellen Schnitstellen.gpm
: lädt die Mausunterstützung für die Textconsole.
Braucht: serial
.xdm
: Startet grafischen Login unter X. Braucht ypclient
.named
: Startet Nameserver. Braucht: nichts (kann auch ohne
Netzwerkanbindung gestartet werden.Folgende Runlevelkonfiguration wird gewünscht:
2
: normale Netzwerkumgebung (mit gpm
).3
: normale Netzwerkumgebung und grafischen Login (ohne gpm
).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:
kerneld
, im Runlevel 3
ypclient
) werden automatisch mitgestartet, natürlich vor dem Client.(2)
wird die Definition
von Runlevel 2 wiederverwertet.gpm
im Runlevel 3 nicht gestartet werden soll obwohl er
in Runlevel 2 definiert ist, wird durch -gpm
angegeben.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.
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.
run
und log
.-start
, -stop
, -changerunlevel
,
-restart
, ... siehe
Kommandoreferenz
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).
#
beginnen (ev. führende Blanks) sind
Kommentare.[section]
begonnen.identifier:
identifier:
werden die
Parameter dem letzten Idendifier zugeordnet.
Verbose-Level
Anzahl Backup-Files der Logfiles. Siehe /var/log/finit
Directory für die Logfiles. Siehe /var/log/finit
Directory für die Runfiles. Siehe /var/run/finit
Directory für die Initscripts. Siehe /etc/rc.d
Dateiname für die lokale Konfigurationsdatei.
Identifier ist der Name des Services (z.B. network:
)
Löscht alles bisherige über Service
Trägt alle alle Service aus list-of-services (durch Komma getrennt) als Server für diesen Service ein.
Nach dem Start soll Service gestartet werden. Siehe No-Services.
Service wird immer wieder gestartet und niemals gestoppt. Siehe No-Services.
Geplante Keywords (Implementierung nur wenn gebraucht)
Vor dem Start soll Service gestartet werden.
Nach dem Stop soll Service gestartet werden.
Vor dem Stop soll Service gestartet werden.
Programm zum Starten anstatt Script aus /etc/rc.d
Abschwächung von needs
: Abhängigkeit nur wenn Service vorhanden.
Umkehrung zu needs
: statt X needs Y
schreibt man Y before X
.
Dadurch kann die Abhängigkeit Server anstatt beim Client definiert werden.
Bietet Service Alias an.
Service wird nur einmal (höchtens gestartet).
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.
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.
Druckt Versionsnummer und Beendet F-Init.
Druckt Usage-Meldung und Beendet F-Init.
Liest Konfiguration von Dateiname anstatt von /etc/finit.conf
Kommandos werden nicht ausgeführt, sondern nur angezeigt, was zu tun wäre.
Startet den Service Service und ggf. zuvor alle Server dafür.
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.
Stoppt den Service Service wenn er keine Clienten hat.
Stoppt den Service Service und ggf. zuvor alle Clienten davon.
Startet zusätzlich zum den aktuellen Services alle Services vom Runlevel Runlevel.
Stoppt alle Services von Runlevel Runlevel.
Stoppt zunächst alle aktuellen Services, die nicht zum neuen Runlevel gehören und startet danach alle Services von Runlevel.
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.
Listet alle gestarteten Services.
Listet alle bekannten Services.
Listet alle bekannten Services in einer Baumgrafik, der die Abhängigkeiten zeigt.
Globale Konfigurationsdatei. Kann beim Update überschrieben werden.
Syntax: siehe Syntax der Konfigurationsdateien.
Kann mit Schalter -f
überschrieben werden.
Siehe
Kommandoreferenz
Lokale Konfigurationsdatei. Wird beim Update nicht überschrieben.
Syntax: siehe Syntax der Konfigurationsdateien.
Kann mit Keyword localconf
überschrieben werden.
Siehe
globale Kewords
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.
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
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
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.
F-Init sollte auf jedem Linux/Unix-System laufen. Entwickelt und getestet unter SuSE Linux 6.0 mit perl5 (5.005_02).
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.
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
finit.conf
sind
noch nicht vollständig.halt
bzw. reboot
sollten nicht im Runlevel 0 und 6 über
F-Init ausgeführt werden. Problem: das umounten des Root-Filesystems (und
möglicherweise anderer)
klappt nicht, da F-Init einige Dateien zum loggen offenhält./etc/rc.config
disabled sind, siehe Datei TODO
./etc/rc.d/boot
gemacht, was
vermutlich nicht unbedingt dort passieren müsste. Z.B. das Setzen des
Hostnamens. Vision: setzen des Hostnamens in /etc/rc.config
und alle Dienste, die den Hostnamen benötigen werden neu gestartet.
hmm, siehe Features ;-)
Siehe Datei TODO
.
Siehe Datei TODO
.
Pre-Beta
Meine Workstations booten mit F-Init :-)