Système d'initialisation Gentoo Linux 1.0

1.Introduction

Gentoo Linux utilise un système d'initialisation qui est largement controlé par les dépendances entre services (par exemple: un démon "x" ne peut etre lancé que si un autre est lancé). Il doit etre facile a maintenir, et cependant assez puissant et fléxible pour tout type d'installation. Ce document doit plutot etre considéré comme une introduction au fonctionnement interne, plutot qu'un rapide guide de démarrage et d'utilisation du système d'initialisation de la Gentoo. Pour les plus curieux concernant ce fonctionnement... lisez les sources ;-)

2.Niveau d'exécutions

Contrairement aux autres systèmes de démarrage, les niveaux d'exécutions Gentoo n'ont pas de noms fixes ou de numéros. Mais des noms personnalisés/personnalisables copiés sur les niveaux d'exécution standards sont préférés et utilisés.

Note: Par défaut, il y a 3 niveaux d'exécutions, nommés:"boot", "default" et "nonetwork".

Le niveau d'exécution "boot" devrait etre utilisé pour des configurations standards du système. Ce niveau d'exécution est le premier niveau d'exécution qui est exécuté. Ensuite, le niveau d'exécution "default"(niveau d'exécution par défaut) est exécuté. Finalement, "nonetwork" est exécuté.

Les scripts(liens symboliques sur les véritables scripts) formant ces niveaux d'exécution se trouvent dans /etc/runlevels. Chaque runlevel possède un répertoire dans /etc/runlevels à son nom. On peut trouver dans ce répertoire des liens symboliques vers les services qui doivent etre démarré dans ce niveau.

Note: Une façon commune d'ajouter ou de retirer un service d'un runlevel est expliqué dans la section "About rc-update".

Comme il a été énoncé précédemment, l'utilisateur peut changer le nom du runlvel comme bon lui semble, en sachant que la règle est la suivante: l'entrée dans /etc/inittab doit correspondre au nouveau nom du runlevel.

Important: Une exception a cette règle doit néanmoins etre remarquée, qui est le "boot" runlevel.

Mise en Garde : Ne changez pas le nom du "boot" runlevel, sinon votre système pourrait devenir inopérationnel !

Le script nommé /sbin/rc fait tout le travail, et peut etre appelé pour changer de runlevel a la volée.

Niveau d'exécution virtuel 

Du au fait que les runlevels ne sont pas fixés sur ceux d'init, il peut y en avoir plus que le nombre que init supporte. Ceci permet a l'utilisateur du système de créé des profiles ou des runlevels virtuels qui lui conviennent.

Par exemple, un utilisateur d'un portable peut avoir deux runlevels par défaut, appelé "online" et "offline". Ceci permettrait d'avoir un runlevel actif lorsque la carte PCMCIA NIC est braché et un autre runlevel inactif quand elle ne l'est pas. Les scripts PCMCIA peuvent ensuite etre configurés pour appeler "/sbin/rc online" ou "/sbin/rc offline" lorsque le PCMCIA est actif ou non, et donc appeler le service correspondant avec le bon argument.

Les niveaux d'exécutions et XFree86 

Dans la manière de faire de Gentoo, il n'y a pas de niveaux d'exécutions dédié à X, mais plutot un script de démarrage. Il est appelé "xdm" et peut etre ajouté aux autres runlevels si l'utilisateur le souhaite.

Note: Il devrait etre dans le runlevel principal, si l'utilisateur le souhaite.

Mise en Garde : Ajouter le script de démarrage au runlevel de démarrage peut engendré des effets de bord.

Par défaut, si vous exécutez xdm, gdm or kdm avant que vos terminaux(gettys) soient démarrés, X sera démarré sur la prochaine console libre. Sur les machines assez lentes ce n'est pas un problème si le service du gestionnaire de fenetres est démarré avant la fin du runlevel d'init. Les terminaux seront démarrés avant X et donc il se retrouvera sur la console 7 comme il devrait. Cependant sur les machines plus rapides ce n'est pas le cas. X est démarré le plus souvent sur la console numéro 2 en lieu et place de l'habituel terminal. Lorsque le terminal démarre ensuite, il prend le controle du clavier, et le gestionnaire de fenetre perd donc le support du clavier.

Ce problème est résolu en utilisant le script de démarrage DM sur l'un des niveaux d'exécution supplémentaires d'init, nommé 'a'. Le niveau 'a' n'est pas un réel niveau d'exécution, notre script "xdm" ne fait simplement qu'appelé "telinit a". Ce qui ordonnance tous les services dans le niveau d'exécution 'a' pour lancer ensuite le niveau d'exécution courant, ainsi ensuite les terminaux sont démarrés.

Note: Plus d'informations au sujet du niveau d'exécution 'a' peuvent etre acquises en lisant la page de manuel d'init.

3.Les rc-scripts

Les rc-scripts sont des scripts qui définissent les fonctions communes pour chaque service, comme les dépendances lors de lancement de démon/script. Ils se trouvent dans /etc/init.d/.

un rc-script type 

 #!/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"
 }
 

Note: L'interpréteur est: "/sbin/runscript".

Note: La fonction "depend" est optionnelle.

Note: Tous rc-scripts possèdent au moins une fonction "start".

Contrèle du démarrage 

L'ordre général de démarrage des scripts est réalisé dans l'ordre alphabétique. Ceci est du à la sortie de /bin/ls qui est générée.

La première méthode pour contourner l'ordre par défaut de démarrage est d'utiliser les dépendances. En revanche, s'il n'y a pas de relation entre les services, alors l'ordre type est utilisé.

4.Les types de dépendances

De nombreux services sont en relation ou dépendent d'autres services.

Par exemple Postfix, a besoin que le service gérant le réseau fonctionne auparavant, ainsi que le "system logger".

D'un autre coté samba nécessite lui aussi le que service réseau soit en fonctionnement. Cependant, si CUPS était utilisé pour l'impression de documents, cupsd devrait être démarré avant samba. il faut observer que cups n'est pas indispensable au démarrage de samba.

Nous avons donc deux moyens d'exprimer les relations de dépendances entre différents services. Les dépendances entre les services sont toujours valides quelque soit le niveaux d'exécution dans lequel vous vous trouvez, ou bien si un service est démarré ou arreté à la main.

La dépendance NEED 

Ceci est utilisé si un service est indispensable pour le démarrage du service courant.

 depend() {
     need net logger
 }
 

Note: Les services mentionnés ci-après NEED sont indispensables dans l'ordre pour le service courant afin de démarrer. Ce service ne pourra pas démarrer si l'une de ces dépendances n'est pas démarrée.

Important: Tout service dans une ligne NEED sera démarrée meme s'il NE se trouve PAS dans le niveau d'exécution ou niveau "boot".

NEED est par conséquent une dépendance "forte".

La dépendance USE 

Ce service n'est pas indispensable au démarrage du service courante, mais il devrait etre démarré avant le service courant pour une utilisation correcte du service. Mais un échec d'un service dans une ligne USE n'implique pas un échec au démarrage du service en question.

 depend() {
     use portmap
 }
 

Netmount peut par défaut gérer les points de montage NFS, mais cela dépendra du fait si oui ou non portmap est ajouté au runlevel courant ou à boot. Tout utilisateur/administrateur utilisant les points de montage NFS devrait par défaut ajouté portmap au runlevel par défaut. Ainsi netmount voit pormap comme une dépendance USE et démarre donc pormap avant.

Important: Tout service dans une ligne USE *doit* etre ajouté au runlevel courant ou boot afin d'etre considéré comme une dépendance USE valide.

USE est donc par conséquent une dépendance "faible".

Note: Si un service dans une ligne USE échoue au démarrage, le service démarrera quand meme, car les services dans la ligne USE n'est pas critique.

5.Controler l'ordre de démarrage sans dépendances

Si il n'existe pas de relation de dépendance entre deux services, mais il est nécessaire et/ou désirable de démarrer un service l'un avant l'autre, les relations AFTER et BEFORE peuvent etre utilisées.

Note: Ces deux types de relations ne sont valides que durant un changement de runlevel.

De plus, ces deux relations peuvent supporter l'étoile "*" signifiant d'inclure tous les autres services:

 depend() {
     after *
 }
 

Ce qui va invoqué local *après* tous les autres services.

l'ordre de démarrage BEFORE 

Le service courant sera démarré *avant* ceux qui sont listés sur la ligne BEFORE.

 depend() {
    before bar
 }
 

L'ordre de démarrage AFTER 

Le service courant démarrera *après* ceux listés sur la ligne AFTER.

 depend() {
     after foo
 }
 

6.Services vituels

Les services sont comme beaucoup des choses dans le monde unix, ils se présentent sous diverses formes et accomodations. C'est donc à l'utilisateur/administrateur de faire le choix des quels il utilise et sous quelle forme.

Le système de journalisation des évènements système (system logger) est un exemple. Dans cette manière de garder trace des évènements système, les utilisateurs de Gentoo Linux ont le choix parmi quatre possibilités. Tous les services qui nécessitent que le journal système fonctionne avant leur démarrage ne peuvent etre de type NEED tous les quatre.Pour USE(utiliser) , ce serait trop facile. As of this writing, Gentoo Linux users have a choice of four different ones. All services that need a system logger running before startup, cannot now NEED all four of them. To USE them is also too weak.

C'est où les services virtuels et le type PROVIDE entrent en action.

Le tyze PROVIDE 

Le type PROVIDE définit un service virtuel qui pour les autres services peut etre NEED ou USE.

 depend() {
     provide logger
 }
 

Le service virtuel LOGGER 

LOGGER est un service virtuel prédéfini, qui est fournis par tous les loggers. Il peut etre utilisé indifféremment avec les types de dépendances NEED ou USE.

Le service virtuel NET 

Le service NET est un autre service virtuel , mais contraiement à LOGGER, il n'est pas explicitement un service de type PROVIDE.

Important: Pour fournir le service virtuel NET, un service doit : Etre ajouté au service courant ou au runlevel de démarrage. Avoir ;net." pre-pended. La partie arpès "net." doit etre le nom de l'actuel interface réseau (net.eth0 ou net.ppp1 par exemple).

Pour tous les services net.*, la variable d'environnement $IFACE prendra pour valeur le nom de l'interface réseau ("eth0" pour net.eth0 par exemple).

7.Les options par défaut de la ligne de commande

Tout service peut etre appelé avec les options par défaut. Toutes celles mentionnées sont déjà définies sauf, START et STOP, que l'utilisateur devrait définir comme fonction dans son script rc.

Important: The start() function must be defined.

Note: The stop() function is less important, and can be left out.

Note: En général, l'utilisateur définira seulement start(),stop() et restart(). Le reste est interne et devrait etre laissé de coté.

 # /etc/init.d/httpd start
 

Note: Les options de la ligne de commande peuvent etre cumulées.

 # /etc/init.d/net.eth0 pause start
 

L'option START/STOP 

START (démarrer) le service en incluant tous les services qui en dépendent.

STOP (arreter) le service et tous les services qui en dépendent.

L'option RESTART 

Le service doit etre démarré pour que RESTART fonctionne. Il redemarrera ce service tout comme ceux qui en dépendent.

Important: Si une fonction restart personnalisée par l'utilisateur est définie, l'utilisateur devrait utiliser "svc_start()" et "svc_stop()" pour démarrer et arreter le service.

Note: Ceci est réalisé pour gérer correctement toutes les dépendances entre les services.

L'option PAUSE 

Cela stoppera le service, mais en revanche STOP, n'arretera pas les services dépendants.

L'option ZAP 

Réinitialise le status du service à arreter.

Note: Notez qu'aucune commande dans la fonction stop() ne sont exécutées. L'utilisateur devra par conséquent réalisé lui-meme les opérations nécessaires à l'arret ou autre s'il le souhaite.

L'option INEED/NEEDSME 

INEED liste les services nécessaires à ce service.

NEEDSME liste les services qui ont besoin du service courant.

L'option IUSE/USESME 

IUSE liste les services qu'utilise ce service.

USESME liste les services qui utilisent ce service.

L'option BROKEN 

Cela liste les services manquants s'il y en a, qui sont nécessaires au bon usage du service.

8.Ajouter soi-meme une option à la ligne de commande

Il est relativement facile d'ajouter une option de ligne de commande. La fonction décrivant l'option devra etre définie dans le script-rc, et son nom devra etre ajouter à la variable d'environnement $opts, comme décrit ci-dessous.

 opts="${opts} foo"
  
 foo() {
     ............
 }
 

9.Configuration

La configuration se fera généralement en utilisant les variables d'environment. Celles-ci, cependant, ne doivent pas etre ajouter directement dans le script-rc, mais plutot ans l'un des trois fichiers de configuration suivant:

L'un est spécifique au script-rc, et les deux autres sont des fichiers de configurations globaux:

 /etc/conf.d/<name of rc-script>
 /etc/conf.d/basic
 /etc/rc.conf
 

Note: Ces trois fichiers forment le source dans cet ordre, faites donc attention dans à cet ordre et placer donc vos variables et fonction au bon endroit.

Important: Tous les services NET prennent leur informations dans /etc/conf.d/net

10.Scripts: utilitaires/système d'aide

L'utilitaire: rc-update 

rc-update est l'outil principal pour ajouter ou supprimer des services d'un runlevel. Il appelera "depscan.sh" pour mettre à jour le cache des dépendances.

 # rc-update add metalog default
 

 # rc-update del metalog default
 

Note: Utiliser rc-update sans argument vous fournira de l'aide sur son utilisation.

Le script d'aide depscan.sh 

Il est utilisé pour créé un cache des dépendances, c'est d'un manière assez basique: une carte de dépendances inter-services.

Il devrait etre exécuter lorsque un nouveau script est ajouté à /etc/init.d/, mais rc-update l'appelle automatiquement, de nombreux utilisateurs ne devraient donc pas avoir besoin de l'utiliser directement.