diff options
Diffstat (limited to 'xml/htdocs/doc/de/rc-scripts.xml')
| -rw-r--r-- | xml/htdocs/doc/de/rc-scripts.xml | 755 |
1 files changed, 0 insertions, 755 deletions
diff --git a/xml/htdocs/doc/de/rc-scripts.xml b/xml/htdocs/doc/de/rc-scripts.xml deleted file mode 100644 index 28ec7fdd22..0000000000 --- a/xml/htdocs/doc/de/rc-scripts.xml +++ /dev/null @@ -1,755 +0,0 @@ -<?xml version="1.0"?> -<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> - -<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/de/Attic/rc-scripts.xml,v 1.5 2003/12/11 21:56:55 dertobi123 Exp $ --> - -<!-- English CVS Version: 1.9 --> - -<guide link="/doc/de/rc-scripts.xml"> -<title>Gentoo Linux Init System</title> -<author title="Autor"> - <mail link="azarah@gentoo.org">Martin Schlemmer</mail> -</author> -<author title="Proof-Reader"> - <mail link="seemant@gentoo.org">Seemant Kulleen</mail> -</author> -<author title="Translator"> - <mail link="egber@netzraum.com">Sebastian Egbers</mail> -</author> -<author title="Translator"> - <mail link="sebastian@beneke-it.de">Sebastian Beneke</mail> -</author> -<author title="Translator"> - <mail link="dertobi123@gentoo.org">Tobias Scherbaum</mail> -</author> - -<abstract> -Dieses ist eine Einführung in das Init-System von Gentoo Linux und erklärt -ebenfalls einige Details zum Schreiben von rc-Skripten. -</abstract> - -<version>1.0.3</version> -<date>5. Dezember 2003</date> - -<chapter> -<title>Einleitung</title> -<section> -<body> - -<p> -Gentoo Linux benutzt ein Init-System das größtenteils über Abhängigkeiten -kontrolliert wird. Es sollte einfach zu warten und doch stark und flexibel -genug sein für jede Art von Konfiguration. Diesen Text sollte man nicht als -eine Einleitung in die inneren Mechanismen verstehen, sondern vielmehr als eine -einfach Anleitung um mit Gentoo's Init-System arbeiten zu können. Leute die -ernsthaft daran interessiert sind, die inneren Mechanismen zu verstehen -.... lesen Sie den Quelltext ;-) -</p> - -</body> -</section> -</chapter> - -<chapter> -<title>Runlevel</title> -<section> -<body> - -<p> -Im Gegensatz zu anderen Init-Systemen, bestehen Gentoos Runlevel nicht aus -festen Namen oder Nummern, sondern vielmehr aus eigenen Namen, die auf die -standard Runlevel von init abgebildet werden. -</p> - -<note> -Standardmäßig gibt es drei Runlevel, namentlich: <e>"boot"</e>, -<e>"default"</e> und <e>"nonetwork"</e>. -</note> - -<p> -Das "boot" Runlevel sollte der standard Typ für die meisten Setups -sein, und ist, wie der Name sagt, das erste Runlevel das nach dem booten -ausgeführt wird. Als nächstes kommt <e>"default"</e>, welches, -wie der Name schon andeutet, das Standard Runlevel ist und nach dem booten -gestartet wird. Zuletzt folgt <e>"nonetwork"</e>, welches -ausschließlich als Beispiel dient. -</p> - -<p> -Die Runlevels liegen in <path>/etc/runlevels</path>, in einem Unterverzeichnis -das nach dem Namen des Runlevels benannt wurde; dieses Unterverzeichnis enthält -symbolische Links zu den Diensten, die in diesem Runlevel geladen werden sollen. -</p> - -<note> -Der bevorzugte Weg, um einen Service hinzuzufügen oder zu löschen wird später -in dem Abschnitt "Utilities und hilfreiche Scripte" behandelt. -</note> - -<p> -Wie bereits erwähnt, kann der Name frei gewählt werden, solange die Datei -<path>/etc/inittab</path> entsprechend dem neuen Namen des Runlevels angepasst -wird. -</p> - -<impo> -Eine Ausnahme dieser Regel, die jedoch erwähnt werden sollte, stellt das Runlevel -<e>"boot"</e> dar. -</impo> - -<warn> -Bitte ändern Sie den Namen des <e>"boot"</e> Runlevels NIEMALS, da es -einige Dinge kaputt machen würde. -</warn> - -<p> -Die ganze Arbeit wird vom <path>/sbin/rc</path> Script erledigt, mit diesem können -Sie auch im laufenden Betrieb zwischen den virtuellen Runleveln wechseln. -</p> - -</body> -</section> -<section> -<title>Virtuelle Runlevel</title> -<body> - -<p> -Da Runlevel nicht statisch auf die von Init gebunden sind, kann man wesentlich -mehr haben als init unterstützt. Das ermöglicht es dem Benutzer nach seinen -Bedürfnissen Profile und Virtuelle Runlevel zu erstellen. -</p> - -<p> -Zum Beispiel könnte ein Laptop Benutzer zwei Standard Runlevel haben, -"online" und "offline". Das würde erlauben ein aktives -Runlevel zu benutzen, wenn die PCMCIA Netzwerkkarte eingesteckt ist, und ein -weiteres Runlevel, wenn sie es nicht ist. Die PCMCIA Scripts könnten dann so -konfiguriert werden, dass sie <c>"/sbin/rc online"</c> oder -<c>"/sbin/rc offline"</c> aufrufen, um die richtigen Dienste zu starten oder -zu stoppen, jeweils abhängig vom Status der PCMCIA Netzwerkkarte. -</p> - -</body> -</section> -<section> -<title>Runlevel und XFree86</title> -<body> - -<p> -Nach Gentoos Weg, Dinge zu erledigen haben wir kein Runlevel für X, sondern -stattdessen ein Startup-Script. Es hat den Namen "xdm" und kann -zu jedem Runlevel hinzugefügt werden, wenn der Benutzer dieses wünscht. -</p> - -<note> -Dies sollte das hauptsächlich genutzte Runlevel des Nutzers sein. -</note> - -<warn> -Es zum Boot Runlevel zu ergänzen kann in unerwünschten Nebeneffekten enden. -</warn> - -<p> -Wenn xdm, gdm oder kdm vor Ihren Gettys gestartet wird, startet X standardmäßig -auf der nächsten freien Konsole. Auf langsameren Rechner ist das kein Problem, -solange der Desktop Manager am Ende des Runlevel Init Vorganges startet. Die -Gettys werden vor X starten, welches dann auf Konsole 7 startet. Auf schnelleren -Rechnern ist dies nicht der Fall. X wird hier vorher auf Konsole zwei starten. -Wenn nun die Gettys starten, übernehmen diese die Kontrolle über die Tastatur, -dadurch verliert der Desktop Manager die Kontrolle der Tastatur. -</p> - -<p> -Dies wird dadurch verhindert, dass das Desktop Manager Startscript über ein -"Extra-Runlevel", hier das Runlevel "a", geführt wird. Da das Runlevel "a" kein -richtiges Runlevel ist, ruft unser "xdm" Script einfach -<c>"telinit"</c> auf. Dadurch werden alle Dienste des Runlevels "a" erst nach -dem aktuellen Runlevel gestartet, also nachdem die Gettys gestartet wurden. -</p> - -<note> -Sie können mehr Informationen über Runlevel "a" erhalten, indem Sie die Man -Pages von init lesen. -</note> - -</body> -</section> -</chapter> - -<chapter> -<title>rc-scripts</title> -<section> -<body> - -<p> -rc-scripts sind Scripte, die die grundsätzlichen Funktionen, sowie die -Abhängigkeiten von Diensten beim Start definieren. Sie liegen in -<path>/etc/init.d/</path>. -</p> - -</body> -</section> -<section> -<title>Grundlayout eines rc-scripts</title> -<body> - -<pre caption="rc-script Layout"> -#!/sbin/runscript - -depend() { - need bar -} - -start() { - ebegin "Starting foo" - /sbin/foo - eend $? "Failed to start foo" -} - -stop() { - ebegin "Stopping foo" - kill $(cat /var/run/foo.pid) - eend $? "Failed to stop foo" -} -</pre> - -<p> -<note>Der Interpreter ist "/sbin/runscript".</note> -<note>Die "depend" Funktion ist optional.</note> -<note>Jedes rc-Script braucht mindestens die "start" Funktion.</note> -</p> - -</body> -</section> - -<section> -<title>Kontrollieren des Start-up</title> -<body> - -<p> -Die generelle Startreihenfolge der Dienste innerhalb eines Runlevels ist -alphabetisch. Dies liegt an der Sortierung der Ausgabe von <path>/bin/ls</path>. -</p> - -<p> -Die erste Möglichkeit von der Startreihenfolge abzuweichen sind Abhängigkeiten. -Alternativ können auch die sogenannten "Order Types" genutzt werden. -</p> - -</body> -</section> -</chapter> - -<chapter> -<title>Abhängigkeitstypen</title> -<section> -<body> - -<p> -Die meisten Dienste sind mit anderen Diensten verbunden und hängen sogar von -ihnen ab. -</p> - -<p> -Zum Beispiel benötigt Postfix ein laufendes Netzwerk, sowie einen Systemlogger. -</p> - -<p> -Samba benötigt ebenfalls ein laufendes Netzwerk. Wenn CUPS zum Drucken benutzt -werden soll, muss cupsd auf jeden Fall vor Samba gestartet werden. Beachten Sie, -das CUPS nicht unbedingt zum Starten von Samba nötig ist. -</p> - -<p> -Wir haben zwei verschiedene Möglichkeiten, um Abhängigkeiten zwischen -verschiedenen Diensten zu definieren. Diese Abhängigkeiten sind immer gültig, -egal ob ein Runlevel als ganzes gewechselt wird oder ein Service einfach nur -manuell nach dem Booten gestartet wird. -</p> - -<p> -Wenn mehrere Initscripte einen virtuellen Dienst anbieten (wenn Sie zum Beispiel -mehrere <path>net.eth*</path> Skripte haben, die alle "net" anbieten), wird nur -ein einziges von diesen als mögliche Abhängigkeit gesehen. Wenn ein Script -<e>need net</e> beinhaltet wird nur eines der verfügbaren <path>net.eth0</path> -Scripte benutzt, nicht alle. -</p> - -</body> -</section> -<section> -<title>Der NEED Abhängigkeitstyp</title> -<body> - -<p> -Dieser Typ wird benutzt, wenn ein Dienst für das Starten des aktuellen Dienstes -dringend nötig ist. -</p> - -<pre caption="Logger und net werden als NEED Abhängigkeit definiert"> -depend() { - need net logger -} -</pre> - -<note> -Die Dienste, welche nach <e>NEED</e> genannt werden, sind dringend erforderlich, -damit der aktuelle Dienst starten kann. Der aktuelle Dienst wird also nicht -starten, wenn eine der Abhängigkeiten nicht starten sollte. -</note> - -<impo> -Jeder Dienst, der in der <e>NEED</e> Zeile steht, wird gestartet, auch wenn -dieser NICHT zum aktuellen oder <e>"boot"</e> Runlevel ergänzt wurde. -</impo> - -<p> -<e>NEED</e> ist deshalb eine "starke" Abhängigkeit. -</p> - -</body> -</section> -<section> -<title>Der USE Abhängigkeitstyp</title> -<body> - -<p> -Dieser Dienst ist nicht unbedingt zum Starten des aktuellen Dienstes nötig, -sollte jedoch vor dem aktuellen gestartet werden. -</p> - -<pre caption="Portmap wird als USE Abhängigkeit zu netmount ergänzt"> -depend() { - use portmap -} -</pre> - -<p> -Netmount kann standardmäßig mit NFS Mounts umgehen, aber wird nur von Portmap -abhängen, wenn dieses zum aktuellen oder zum Boot Runlevel ergänzt wurde. -Jeder Benutzer, der NFS Mounts nutzt, sollte portmap zum Default Runlevel -hinzufügen. Dadurch wird Portmap als USE Abhängigkeit gesehen und vor netmount -gestartet werden. -</p> - -<impo> -Jeder Dienst in der <e>USE</e> Zeile <e>*muss*</e> im aktuellen oder im Boot -Runlevel vorhanden sein, damit er als gültige <e>USE</e> Abhängigkeit -anerkannt werden kann. -</impo> - -<p> -<e>USE</e> is dadurch eine "schwache" Abhängigkeit. -</p> - -<p> -<note> -Sollte ein Dienst in der <e>USE</e> Zeile nicht starten, so wird der aktuelle Dienst trotzdem -gestartet werden, da der Dienst der <e>USE</e> Zeile nicht zwingend für den Start des -aktuellen Dienstes nötig ist. -</note> -</p> - -</body> -</section> -</chapter> - -<chapter> -<title>Kontrollieren der Reihenfolge ohne Abhängigkeiten</title> -<section> -<body> - -<p> -Sollte keine abhängige Verbindung zwischen zwei Diensten bestehen, es aber -trotzdem nötig oder gewünscht sein, einen Dienst nach einem bestimmten anderen -zu starten, können die <e>AFTER</e> und <e>BEFORE</e> Optionen genutzt werden. -</p> - -<note> -Diese beiden Typen sind nur während dem Wechseln eines Runlevels gültig. -</note> - -<p> -Optional können diese beiden Typen ein "*" Wildcard für das integrieren aller -anderen Dienste enthalten: -</p> - -<pre caption="Ein Beispiel für AFTER"> -depend() { - after * -} -</pre> - -<p> -Dies wird den Dienst <e>*nach*</e> allen anderen Diensten starten. -</p> - -</body> -</section> -<section> -<title>Die BEFORE Option</title> -<body> - -<p> -Der aktuelle Dienst wird <e>*vor*</e> den in der <e>BEFORE</e> Zeile -aufgelisteten Diensten gestartet. -</p> - -<pre caption="Lässt foo vor dem Dienst bar starten (Auszug von foo)"> -depend() { - before bar -} -</pre> - -</body> -</section> -<section> -<title>Die AFTER Option</title> -<body> - -<p> -Der aktuelle Dienst wird <e>*nach*</e> den in der <e>AFTER</e> Zeile gelisteten -Diensten gestartet. -</p> - -<pre caption="Lässt bar nach foo starten (Auszug von bar)"> -depend() { - after foo -} -</pre> - -</body> -</section> -</chapter> - -<chapter> -<title>Virtuelle Dienste</title> -<section> -<body> - -<p> -Dienste, wie die meisten Dinge in der heutigen Unix Welt, kommen in -verschiedenen Farben und Geschmäckern daher. Normalerweise hat der Nutzer -/ Administrator die Wahl zu bestimmen welche genutzt werden. -</p> - -<p> -Ein Beispiel dafür sind Systemlogger. Zum Zeitpunkt des Schreibens dieses -Dokumentes, hat der Nutzer von Gentoo Linux die Auswahl aus vier verschiedenen. -Alle Dienste, die einen Logger benötigen, können nicht alle vier mittels -<e>NEED</e> Option anfordern. Die <e>USE</e> option ist zu schwach. -</p> - -<p> -Dies ist der Punkt, an dem Virtuelle Dienste und die <e>PROVIDE</e> Option -ins Spiel kommen. -</p> - -</body> -</section> -<section> -<title>Die PROVIDE Option</title> -<body> - -<p> -Die <e>PROVIDE</e> Option definiert einen virtuellen Dienst, welche andere -Dienste mittels <e>NEED</e> und <e>USE</e> aufrufen können. -</p> - -<pre caption="Sysklogd liefert logger"> -depend() { - provide logger -} -</pre> - -</body> -</section> -<section> -<title>Der Virtuelle Dienst LOGGER</title> -<body> - -<p> -<e>LOGGER</e> ist ein vordefinierter virtueller Dienst, welcher von allen -Systemloggern geliefert wird. Er kann entweder mit <e>NEED</e> oder <e>USE</e> -genutzt werden. -</p> - -</body> -</section> -<section> -<title>Der virtuelle Dienst NET</title> -<body> - -<p> -Der NET Dienst ist ein anderer virtueller Dienst, jedoch im Gegensatz zu -<e>LOGGER</e> liefert er nicht einen eindeutigen Dienst. -</p> - -<impo> -Um den virtuellen Dienst <e>NET</e> zu unterstützen, muss ein Dienst: -<ul> - <li>zum aktuellen oder Boot Runlevel angehören.</li> - <li>ein "net" vorangestellt haben.</li> - <li> - der Teil nach "net" muss den Namen des eigentlichen Netzwerk Interfaces tragen - (z.B. net.eth0 oder net.ppp1). - </li> -</ul> -</impo> - -<p> -Für jeden gültigen net.* Dienst, wird $IFACE auf den Namen des Netzwerk -Interfaces gesetzt(z.B. "eth0" für net.eth0). -</p> - -</body> -</section> -</chapter> - -<chapter> -<title>Standard Kommandozeilen Optionen</title> -<section> -<body> - -<p> -Jeder Dienst kann mit einer der Standard Optionen aufgerufen werden. All diese -genannten sind bereits definiert, mit Ausnahme von <e>START</e> und <e>STOP</e>, -welche dem Benutzer als Funktionen in seinem rc-script definieren sollte. -</p> - -<impo> -Die <e>start()</e> Funktion <e>muss</e> definiert werden. -</impo> - -<note> -Die <e>stop()</e> Funktion ist nicht ganz so wichtig und kann weggelassen werden. -</note> - -<note> -In der Regel wird der Benutzer nur <e>start()</e>, <e>stop()</e> und -<e>restart()</e> definieren. Der Rest wird intern ablaufen und sollte in Ruhe -gelassen werden. -</note> - -<pre caption="Start des HTTPD Dienstes"> -# <c>/etc/init.d/httpd start</c> -</pre> - -<note> -Kommandozeilen Optionen können gestapelt, bzw. aufgereiht werden. -</note> - -<pre caption="Pausieren / Starten von net.eth0"> -# <c>/etc/init.d/net.eth0 pause start</c> -</pre> - -</body> -</section> -<section> -<title>Die START/STOP Option</title> -<body> - -<p> -<e>START</e>, startet den Dienst inklusive aller seiner Abhängigkeiten. -</p> - -<p> -<e>STOP</e>, stoppt den Dienst inklusive aller Dienste, welche von ihm -abhängig sind. -</p> - -</body> -</section> -<section> -<title>Die RESTART Option</title> -<body> - -<p> -Damit <e>RESTART</e> funktioniert, muss der Dienst vorher gestartet sein. -Dadurch wird der Dienst und alle Dienste, die von ihm abhängen neu gestartet. -</p> - -<impo> -Sollte eine eigene <e>restart()</e> Funktion definiert sein, sollte der Nutzer -zum Starten und Stoppen <e>"svc_start()"</e> und <e>"svc_stop()"</e> verwenden. -</impo> - -<note> -Dies ist nötig, damit alle abhängigen Dienste richtig gehandhabt werden. -</note> - -</body> -</section> -<section> -<title>Die PAUSE Option</title> -<body> - -<p> -Dies wird den Dienst stoppen, nur im Gegensatz zu <e>STOP</e> wird kein -abhängender Dienst angehalten. -</p> - -</body> -</section> -<section> -<title>Die ZAP Option</title> -<body> - -<p> -Setzt den Status eines Dienstes auf gestoppt. -</p> - -<note> -Beachten Sie, dass hier kein Kommando aus der <e>stop()</e> Funktion -ausgeführt wird. Deshalb sollte der Benutzer alle nötigen "Aufräumarbeiten" -manuell durchführen. -</note> - -</body> -</section> -<section> -<title>Die INEED/NEEDSME Optionen</title> -<body> - -<p> -<e>INEED</e> listet alle Dienste auf, die vom aktuellen Dienst gebraucht werden. -</p> - -<p> -<e>NEEDSME</e> listet alle Dienste auf, die den aktuellen Dienst brauchen. -</p> - -</body> -</section> -<section> -<title>Die IUSE/USESME Optionen</title> -<body> - -<p> -<e>IUSE</e> listet alle Dienste auf, die der aktuelle Dienst benutzt (siehe -USE Option / Typ weiter oben). -</p> - -<p><e>USESME</e> listet alle Dienste auf, die den aktuellen Dienst nutzen -(siehe USE Option / Typ weiter oben). -</p> - -</body> -</section> -<section> -<title>Die BROKEN Option</title> -<body> - -<p> -Diese listet alle fehlenden Dienste (falls es welche gibt) auf, die der -aktuelle Dienst braucht. -</p> - -</body> -</section> -</chapter> - -<chapter> -<title>Eigene Kommandozeilen Optionen ergänzen</title> -<section> -<body> - -<p> -Eigene Kommandozeilen Optionen zu ergänzen ist relativ einfach. Eine Funktion -mit dem Namen der Option muss im rc-script definiert werden und zur -<e>$opts</e> Variable ergänzt werden, siehe unten: -</p> - -<pre caption="foo als eigene Option"> -opts="${opts} foo" - -foo() { - ............ -} -</pre> - -</body> -</section> -</chapter> - -<chapter> -<title>Konfiguration</title> -<section> -<body> - -<p> -Konfiguration sollte generell durch Umgebungsvariablen erfolgen. Diese sollten -*nicht* im rc-script definiert werden, sondern in einer der drei möglichen -Konfigurations Dateien. -</p> - -<p> -Eine, die speziell für das rc-Script da ist und zwei globale Konfigurations Dateien: -</p> - -<pre caption="Konfigurations Dateien für Rc-Scripte"> -<path>/etc/conf.d/<name of rc-script></path> -<path>/etc/conf.d/basic</path> -<path>/etc/rc.conf</path> -</pre> - -<note> -Diese drei werden in der aufgelisteten Reihenfolge eingelesen. -</note> - -<impo> -Alle <e>NET</e> Dienste lesen also <path>/etc/conf.d/net</path> aus. -</impo> - -</body> -</section> -</chapter> - -<chapter> -<title>Utilities und hilfreiche Scripte</title> -<section> -<title>Das rc-update Utility</title> -<body> - -<p> -rc-update ist das Hauptwerkzeug, um Dienste zu einem bestimmten Runlevel -zu ergänzen oder von einem solchen zu entfernen. Es wird darüber hinaus auch -"depscan" aufrufen, um den Abhängigkeits Cache zu aktualisieren. -</p> - -<pre caption="Metalog zum standard Runlevel ergänzen"> -# <c>rc-update add metalog default</c> -</pre> - -<pre caption="Metalog vom standard Runlevel entfernen"> -# <c>rc-update del metalog default</c> -</pre> - -<note> -Um mehr Hilfe zu erhalten, rufen Sie einfach rc-update ohne weitere Argumente -auf. -</note> - -</body> -</section> -<section> -<title>Das depscan.sh Helfer Script</title> -<body> - -<p> -Um eine vollständige Dokumentation zu bieten, wird depscan.sh hier erwähnt. -Es wird genutzt, um einen Abhängigkeits Cache zu erstellen, dieser ist -eigentlich eine Aufzeichnung der Abhängigkeiten zwischen den Diensten. -</p> - -<p> -Es sollte immer dann gestartet werden, wenn ein neues rc-script nach -<path>/etc/init.d/</path> ergänzt wird. Da jedoch rc-update dieses Script -automatisch aufruft, wird der normale Benutzer normalerweise nicht mit -depscan in Berührung kommen. -</p> - -</body> -</section> -</chapter> -</guide> |