Gentoo Logo

[ << ] [ < ] [ Sommaire ] [ > ] [ >> ]


4. Les scripts d'initialisation

Table des matières :

4.a. Les niveaux d'exécution

Démarrer votre système

Quand vous démarrez votre système, vous voyez beaucoup de texte défiler à l'écran. Vous remarquerez sans doute que ce texte est le même à chaque démarrage. La séquence d'actions qui se déroule devant vos yeux s'appelle la séquence de démarrage et elle est définie de façon plus ou moins statique.

D'abord, votre chargeur de démarrage charge en ménoire l'image du noyau que vous avez définie dans son fichier de configuration. Ensuite, il demande au processeur d'exécuter ce noyau. Ce dernier initialise alors ses propres structures et tâches puis lance le processus d'initialisation (init).

Ce processus monte les systèmes de fichiers définis dans /etc/fstab et exécute quelques scripts placés dans le répertoire /etc/init.d qui, à leur tour, démarrent les services nécessaires au bon fonctionnement du système.

Finalement, quand tous les scripts ont été exécutés, init active les terminaux (en général, les consoles virtuelles que vous obtenez avec les touches Alt-F1, Alt-F2, etc.) et attache un processus appelé agetty à chacun. Ce processus vous permet de vous identifier sur ces terminaux avec login.

Les scripts d'initialisation

En fait, init n'exécute pas les scripts du répertoire /etc/init.d dans n'importe quel ordre. De plus, il n'exécute pas non plus tous les scripts, mais seulement ceux qui doivent l'être. Les scripts à exécuter sont définis dans /etc/runlevels.

Le processus init exécute d'abord les scripts de /etc/init.d vers lesquels un lien symbolique existe dans /etc/runlevels/boot. Les scripts sont généralement exécutés par ordre alphabétique, mais certains contiennent des dépendances qui indiquent que d'autres scripts doivent être exécutés avant eux.

Quand tous les scripts liés dans /etc/runlevels/boot ont été exécutés, init poursuit avec ceux vers lesquels un lien symbolique existe dans /etc/runlevels/default. Ici aussi, les scripts sont généralement exécutés par ordre alphabétique, sauf quand ils contiennent des informations sur des dépendances qui spécifient une séquence d'exécution particulière.

Comment init fonctionne-t-il ?

Évidemment, init ne décide pas tout seul de ce qu'il doit faire. Il a besoin d'un fichier de configuration qui lui indique quelles actions il doit effectuer. Ce fichier est /etc/inittab.

Dans la séquence de démarrage que nous venons d'expliquer, nous avons dit que la première action de init était de monter les systèmes de fichiers. La ligne du fichier /etc/inittab qui provoque cela est la suivante :

Exemple de code 1.1 : la ligne d'initialisation du système dans /etc/inittab

si::sysinit:/sbin/rc sysinit

En fait, cette ligne indique à init qu'il doit exécuter /sbin/rc sysinit pour initialiser le système. C'est le script /sbin/rc qui fait vraiment le travail d'initialisation et pas init qui ne fait que déléguer les tâches.

Ensuite, init exécute tous les scripts vers lesquels un lien symbolique est défini dans /etc/runlevels/boot. La ligne suivante provoque cela :

Exemple de code 1.2 : l'initialisation du système, suite

rc::bootwait:/sbin/rc boot

Encore une fois, le script rc fait le travail. Remarquez que l'option boot passée au script rc correspond au nom du sous-répertoire qui se trouve dans /etc/runlevels.

Ensuite, init lit son fichier de configuration pour savoir quel runlevel (voir cette notion plus-bas) il doit exécuter . La ligne suivante définit le niveau d'exécution :

Exemple de code 1.3 : la ligne initdefault

id:3:initdefault:

Dans ce cas (qui est celui de la majorité des utilisateurs de Gentoo), le niveau d'exécution est le numéro 3. Avec ce numéro, init trouve ce qu'il doit exécuter pour lancer le niveau d'exécution 3 :

Exemple de code 1.4 : les définitions des niveaux d'exécution

l0:0:wait:/sbin/rc shutdown
l1:S1:wait:/sbin/rc single
l2:2:wait:/sbin/rc nonetwork
l3:3:wait:/sbin/rc default
l4:4:wait:/sbin/rc default
l5:5:wait:/sbin/rc default
l6:6:wait:/sbin/rc reboot

La ligne qui définit le niveau 3 utilise à nouveau le script rc pour démarrer les services, cette fois avec le paramètre default. Remarquez que, encore une fois, le paramètre correspond au nom du sous-répertoire dans /etc/runlevels.

Quand le script rc a terminé, init trouve la liste des consoles virtuelles à activer et quelles commandes il doit utiliser dans son fichier de configuration :

Exemple de code 1.5 : la définition des consoles virtuelles

c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

Qu'est-ce qu'un niveau d'exécution ?

Vous avez constaté qu'init numérote les niveaux d'exécution qu'il doit activer. Un niveau d'exécution définit un état dans lequel votre système se trouve et contient les scripts nécessaires pour entrer dans ou quitter cet état.

Dans Gentoo, sept niveaux d'exécution sont définis : trois internes et quatre définis par l'utilisateur. Les niveaux d'exécution internes sont sysinit, shutdown et reboot et sont utilisés respectivement pour initialiser, éteindre et redémarrer le système.

Les niveaux d'exécution définis par l'utilisateur sont ceux qui correspondent à un sous-répertoire dans /etc/runlevels : boot, default, nonetwork et single. Le niveau d'exécution boot est utilisé pour démarrer tous les services système utilisés par les autres niveaux d'exécution. Les autres niveaux d'exécution se différencient par les services qu'ils activent : default est utilisé en temps normal, nonetwork est utilisé quand aucune connexion réseau n'est souhaitée et single est utilisé pour résoudre d'éventuels problèmes du système.

Utiliser les scripts d'initialisation

Les scripts que rc exécute sont appelés des scripts d'initialisation. Chaque script peut être exécuté avec les options start, stop, restart, zap, status, ineed, iuse, needsme, usesme ou broken.

Pour démarrer, arrêter ou relancer un service (et les autres services nécessaires éventuels), utilisez start, stop et restart.

Exemple de code 1.6 : démarrer postfix

# /etc/init.d/postfix start

Note : seuls les services qui ont besoin du service spécifié sont arrêtés ou redémarrés. Les autres services dépendants (ceux qui l'utilisent mais n'en ont pas un besoin impérieux) ne sont pas affectés.

Pour stopper un service sans toucher aux services qui l'utilisent, utilisez l'option --nodeps avec la commande stop  :

Exemple de code 1.7 : stopper postfix sans toucher aux services qui l'utilisent

# /etc/init.d/postfix --nodeps stop

Pour afficher le statut d'un service (démarré, arrêté,...), utilisez l'option status :

Exemple de code 1.8 : afficher le statut du service postfix

# /etc/init.d/postfix status

Si le système affirme qu'un service est actif, mais que vous savez qu'il ne l'est pas, utilisez l'option zap pour réinitialiser son statut à « arrêté ».

Exemple de code 1.9 : réinitialiser le statut de postfix

# /etc/init.d/postfix zap

Vous pouvez aussi afficher les services dont un service a besoin avec les options iuse ou ineed. Avec l'option ineed, les services réellement nécessaires sont affichés. Avec iuse, ce sont les services qui peuvent être utilisés sans être indispensables qui sont affichés.

Exemple de code 1.10 : afficher la liste des services dont Postfix a besoin

# /etc/init.d/postfix ineed

De la même façon, vous pouvez afficher la liste des services qui ont besoin (needsme), ou qui peuvent simplement utiliser (usesme), un service particulier :

Exemple de code 1.11 : afficher la liste des services qui ont besoin de Postfix

# /etc/init.d/postfix needsme

Enfin, vous pouvez aussi demander la liste des services requis qui manquent :

Exemple de code 1.12 : afficher la liste des services manquants dont Postfix a besoin

# /etc/init.d/postfix broken

4.b. Utiliser rc-update

Qu'est-ce que rc-update ?

Gentoo construit un arbre de dépendances pour déterminer l'ordre d'exécution des services. Cela est loin d'être trivial et nous avons donc créé des outils qui facilitent l'administration des niveaux d'exécution et des scripts d'initialisation.

La commande rc-update permet d'ajouter ou d'enlever un script d'un niveau d'exécution. Cette commande utilise automatiquement le script depscan.sh qui reconstruit l'arbre des dépendances.

Ajouter et enlever des services

Vous avez déjà ajouté des scripts d'initialisation au niveau d'exécution « default » pendant l'installation de Gentoo. Vous ignoriez alors la signification de « default », mais maintenant, vous la connaissez. Le script rc-update a besoin d'un second argument qui spécifie l'action à effectuer : add, del ou show pour respectivement ajouter, supprimer ou afficher.

Pour ajouter ou supprimer un service, ajoutez simplement add ou del à la commande rc-update et spécifiez ensuite le nom du script d'initialisation et le niveau d'exécution. Par exemple :

Exemple de code 2.1 : supprimer Postfix du niveau d'exécution « default »

# rc-update del postfix default

La commande rc-update -v show affiche la liste des scripts d'initialisation disponibles et les niveaux d'exécution dans lesquels ils ont été ajoutés :

Exemple de code 2.2 : afficher la liste des scripts d'initialisation

# rc-update -v show

Vous pouvez aussi lancer rc-update show (sans l'option -v) pour simplement voir les scripts d'initialisation activés et leurs niveaux d'exécution.

4.c. Configurer les services

Pourquoi encore configurer ?

Les scripts d'initialisation peuvent être complexes. Il vaut donc mieux éviter que les utilisateurs n'aient à les modifier directement; cela évite bien des problèmes. Cependant, les services ont parfois besoin d'être configurés ou de recevoir certaines options.

Il importe donc de bien séparer les scripts de leur configuration car cela permet de mettre à jour les scripts sans que leur configuration ne soit perdue.

Le répertoire /etc/conf.d

Gentoo offre un système facile pour configurer les services. Chaque script d'initialisation qui peut être configuré a un fichier de configuration dans le répertoire /etc/conf.d. Par exemple, le script d'initialisation d'apache2 (/etc/init.d/apache2) a un fichier de configuration /etc/conf.d/apache2 qui contient les options à passer au serveur Apache 2 quand ce dernier est lancé.

Exemple de code 3.1 : variables définies dans /etc/conf.d/apache2

APACHE2_OPTS="-D PHP5"

Un tel fichier de configuration ne contient que des définitions de variables (tout comme /etc/portage/make.conf), ce qui permet de configurer facilement un service. Cela permet aussi de fournir des explications sur ces options sous forme de commentaires.

4.d. Écrire un script d'initialisation

Dois-je faire cela ?

Non. Rédiger un script d'initialisation n'est généralement pas nécessaire puisque Gentoo fournit des scripts complets pour tous les services supportés. Cependant, si vous avez installé un service sans l'aide de Portage, vous devrez sans doute écrire un tel script.

N'utilisez pas le script fourni avec le logiciel à moins qu'il ne soit écrit spécifiquement pour Gentoo, car les scripts d'initialisation de Gentoo ne sont pas compatibles avec ceux des autres distributions.

Structure

La structure de base d'un script d'initialisation est décrite ci-dessous.

Exemple de code 4.1 : structure de base d'un script d'initialisation

#!/sbin/runscript

depend() {
  (Information sur les dépendances)
}

start() {
  (Commandes à exécuter pour démarrer le service)
}

stop() {
  (Commandes à exécuter pour arrêter le service)
}

La partie start() est indispensable, les autres sont facultatives.

Dépendances

Il y a deux paramètres de dépendances que vous pouvez définir, et qui influencent l'ordre d'exécution des scripts d'initialisation : use and need. À coté de ces paramètres, il y a aussi deux autres paramètres pour influencer cet ordre d'exécution : before et after. Ces derniers ne créent pas de dépendance en eux-mêmes; il ne font pas échouer le script initial si le script mentionné n'est pas programmé pour démarrer ( où ne parvient pas à démarrer).

  • Le paramètre use informe le système que le script utilise (use-s) la fonctionnalité offerte par le script mentionné, mais n'en dépend pas directement. Un bon exemple serait use logger or use dns. Si ces deux services sont disponibles, ils seront utilisés. Néanmoins, si aucun logger ou service DNS n'est disponible, le service continuera à fonctionner sans eux. Si ces services existent, ils seront démarrés avant le script qui les utilise ( use-s).
  • Le paramètre need implique une dépendance absolue. Il indique que le script a besoin d' (need-s) un autre script et ne démarrera pas avant que cet autre script ne soit exécuté avec succès. Ainsi, si cet autre script est redémarré, il en sera de même pour le script requérant.
  • Un script qui utilise le paramètre before (avant) , est lancé avant le script auquel ce before fait référence, si ce dernier fait partie du niveau d'exécution. Ainsi, par exemple, un script xdm qui fait usage de before alsasound démarre avant le script alsasound , mais seulement si alsasound fait également partie du même niveau d'éxécution. Si ce n'est pas le cas, ce paramètre n'a aucune influence et xdm est démarré quand le système d'initialisation le juge opportun.
  • De la même manière, un script qui utilise le paramètre after (après), est lancé après le script auquel ce after fait référence, si ce dernier fait partie du niveau d'exécution. Dans le cas contraire, ce paramètre n'a aucune influence et ce script est démarré quand le système d'initialisation le juge opportun.

D'après ce qui précède, seul le paramètre need implique une véritable dépendance, en ce sens qu'il peut remettre en question, où pas, le démarrage du script. Les autres paramètres ne font qu'influer sur l'ordre de démarrage des scripts.

Par ailleurs, si vous regardez attentivement beaucoup de scripts d'initialisation de Gentoo, vous verrez que certains d'entre-eux indiquent des dépendances sur des choses qui ne sont pas des scripts d'initialisation. Ces choses sont appelées services virtuels (virtuals).

Une dépendance d'un service virtuel (virtual) est une dépendance qui se rapporte, non pas à un sevice unique, mais à un service disponible parmi un groupe de services plus ou moins équvalents et interchangeables. Votre script d'initialisation peut très bien dépendre d'un système de journalisation, mais il existe plusieurs tels systèmes disponibles (metalogd, syslog-ng, sysklogd, ...). Comme vous ne pouvez exprimer le besoin (need ) de chacun d'entre-eux (aucun système raisonnable ne possède tous ces systèmes de journalisation installés et opérationnels), nous faisons en sorte que ces services fournissent, solidairement, un service virtuel qui pourra être utilisé comme dépendance.

Jetons un coup d'œil aux dépendances du service postfix.

Exemple de code 4.2 : dépendances de Postfix

depend() {
  need net
  use logger dns
  provide mta
}

Comme vous pouvez le voir, postfix :

  • a besoin du service virtuel net qui est fourni par /etc/init.d/net.eth0, par exemple ;
  • utilise un système de journalisation (service virtuel logger) qui est fourni par /etc/init.d/syslog-ng, par exemple ;
  • utilise le service (virtuel) dns qui est fourni par /etc/init.d/named, par exemple ;
  • fournit le service virtuel mta qui indique qu'un serveur de courrier est disponible.

Ordonner la séquence d'exécution

Comme expliqué précédemment, vous pouvez dire au système d'initialisation dans quel ordre démarrer (ou arrêter) les scripts. Cet ordonnancement est assuré par l'utilisation des paramètres de dépendance use et need, mais aussi par celle des paramètres d'ordonnancement before et after. Comme nous en avons déjà parlé, considérons maintenant un exemple de script d'initialisation, ici pour le service Portmap.

Exemple de code 4.3 : la fonction depend() du service Portmap

depend() {
  need net
  before inetd
  before xinetd
}

Vous pouvez aussi remplacer le nom de service par une étoile ("*") pour spécifier tous les services d'un niveau d'exécution, mais cela n'est pas recommandé.

Exemple de code 4.4 : lancer un script avant tous les autres dans un niveau d'exécution

depend() {
  before *
}

Si votre service doit écrire sur des disques locaux, il aura besoin du localmount. S'il place quelque chose dans /var/run, tel un fichier .pid, alors il devra démarrer après bootmisc :

Exemple de code 4.5 : exemple de fonction depend()

depend() {
  need localmount
  after bootmisc
}

Fonctions standard

En plus de la fonction depend(), vous devez définir la fonction start() qui doit contenir les commandes nécessaires pour activer le service. Il est conseillé d'utiliser les fonctions ebegin et eend pour afficher des messages à l'écran et ainsi informer l'utilisateur de ce qu'il advient de la tentative de démarrage d'un service.

Exemple de code 4.6 : exemple de fonction start()

start() {
  if [ "${RC_CMD}" = "restart" ];
  then
    # Faire quelque chose dans le cas où un redémarrege nécessite plus qu'un simple arrêt, redémarrage. t
  fi

  ebegin "Starting my_service"
  start-stop-daemon --start --exec /path/to/my_service \
    --pidfile /path/to/my_pidfile
  eend $?
}

Les options --exec et --pidfile devraient être utilisées dans les fonctions start et stop. Si le service ne crée pas de fichier .pid, alors utilisez --make-pidfile, si possible, bien que vous devriez le tester pour en être sûr. Dans le cas contraire, n'utilisez pas de fichier .pid. Vous pouvez aussi ajouter --quiet aux options start-stop-daemon, bien que cela soit déconseillé à moins que le service soit extrêmement verbeux. En effet, utiliser --quiet peut cacher des informations de débogage utiles si le démarrage du service échoue.

Un autre réglage notable utilisé dans l'exemple précédent est de vérifier le contenu de la variable RC_CMD. Contrairement aux précédents scripts d'initialisation, le nouveau système openrc ne prend pas en charge les fonctions de redémarrage spécifique à un script. Au lieu de cela, le script doit vérifier le contenu de la variable RC_CMD pour savoir si une fonction (qu'elle soit start() ou stop()) est appelée à l'intérieur d'un restart ou pas.

Note : assurez-vous que --exec appelle effectivement un service et pas simplement un script shell qui lance des services (c'est ce que le script init est censé faire).

Vous trouverez plus d'exemples de fonctions start() dans les sources des scripts d'initialisation, localisés dans le répertoire /etc/init.d.

Vous pouvez aussi définir la fonction facultative stop() pour arrêter un service, mais Gentoo est capable de s'en passer si vous avez utilisé la commande start-stop-daemon.

En voici quand même un exemple :

Exemple de code 4.7 : exemple de fonction stop()

stop() {
  ebegin "Arrêt de mon_service"
  start-stop-daemon --stop --exec /chemin/vers/mon_service \
    --pidfile /chemin/vers/mon_fichier_pid
  eend $?
}

Si votre service exécute un script (Bash, Python ou Perl par exemple) dont le nom change par la suite (par exemple, toto.py devient toto), il faut alors ajouter l'option --name à la commande start-stop-daemon. Vous devez y spécifier le nom du script après changement. Dans cet exemple, un service démarre toto.py dont le nom devient toto :

Exemple de code 4.8 : un service qui lance le script toto

start() {
  ebegin "Démarrage de mon_script"
  start-stop-daemon --start --exec /chemin/vers/mon_script \
  --pidfile /chemin/vers/mon_fichier_pid --name toto 
  eend $?
}

Pour de plus amples informations, une excellente page de manuel (man page) est disponible pour la commande start-stop-daemon :

Exemple de code 4.9 : consulter le manuel de start-stop-daemon

$ man start-stop-daemon

La syntaxe des scripts d'initialisation est basée sur le Shell POSIX. Vous pouvez donc utiliser toutes les fonctionnalités de bash (ou compatibles sh) dans vos scripts.

Ajouter une option personnalisée

Si vous voulez utiliser une option non prévue par nos scripts, vous devez l'ajouter à la variable extra_commands et créer une fonction qui a le même nom que l'option. Par exemple, pour ajouter une option restartdelay :

Exemple de code 4.10 : ajouter une option restartdelay

extra_commands="restartdelay"

restartdelay() {
  stop
  sleep 3    # Temporisation de 3 secondes
  start
}

Important : la fonction restart() ne peut pas être ré-écrite (overriden) dans openrc!

Variables de configuration d'un service

Vous ne devez rien faire de particulier pour utiliser un fichier de configuration dans /etc/conf.d : avant que votre script d'initalisation ne soit exécuté, les variables des fichiers suivants sont initialisées dans cet ordre :

  • /etc/conf.d/<votre_script>
  • /etc/conf.d/basic
  • /etc/rc.conf

De plus, si votre script contribue à un service virtuel (comme net), le fichier de configuration correspondant (comme /etc/conf.d/net) sera également lu.

4.e. Modifier le comportement des niveaux d'exécution

Quel intérêt et pour qui ?

Les utilisateurs d'ordinateurs portables connaissent bien le problème : vous devez démarrer net.eth0 à la maison, mais pas lorsque vous êtes en vadrouille puisque vous n'êtes alors plus connecté à votre réseau. Vous pouvez adapter le comportement de Gentoo.

Par exemple, vous pouvez créer un second niveau d'exécution similaire au niveau « default », mais sans les options réseau. Vous pourrez ensuite sélectionner le niveau d'exécution au démarrage de votre machine.

Utiliser « softlevel »

Créez votre second niveau d'exécution similaire à « default ». Dans notre exemple, nous créons un niveau « offline ».

Exemple de code 5.1 : créer le répertoire du nouveau niveau d'exécution

# mkdir /etc/runlevels/offline

Ajoutez les scripts d'initialisation à votre nouveau niveau d'exécution. Par exemple, pour copier le niveau « default » sauf le script net.eth0 :

Exemple de code 5.2 : recopier les scripts d'initialisation

(Copier tous les services du niveau d'exécution default vers offline.)
# cd /etc/runlevels/default
# for service in *; do rc-update add $service offline; done
(Supprimer les services superflus du niveau d'exécution offline.)
# rc-update del net.eth0 offline
(Afficher les services du niveau d'exécution offline.)
# rc-update show offline
(Affichage partiel :)
               acpid | offline
          domainname | offline
               local | offline
            net.eth0 |

Même si net.eth0 a été retiré du niveau d'exécution offline, udev va quand même essayer de démarrer les interfaces qu'il détecte et lancer les services associés, une fonctionnalité appelée démarrage à chaud. Par défaut, Gentoo n'active pas le démarrage à chaud.

Si vous voulez activer le démarrage à chaud, mais uniquement pour un choix de scripts, utilisez la variable rc_hotplug dans /etc/rc.conf:

Exemple de code 5.3 : désactiver un service démarré par une interface dans /etc/conf.d/rc

# Autoriser net.wlan comme les autres services, sauf ceux dont le nom commence par net. (y compris le point). 
# démarrage à chaud autorisé
rc_hotplug="net.wlan !net.*"

Note : vous trouverez plus d'informations sur les services démarrés par les interfaces en consultant les commentaires du fichier /etc/rc.conf.

Ensuite, modifiez la configuration de votre chargeur de démarrage pour y ajouter une nouvelle option pour le niveau offline. Par exemple, pour grub, modifiez /boot/grub/grub.conf :

Exemple de code 5.4 : ajouter une entrée dans le menu de démarrage

title Gentoo Linux Offline
  root (hd0,0)
  kernel (hd0,0)/kernel-2.4.25 root=/dev/hda3 softlevel=offline

Voilà, c'est terminé. Si vous redémarrez votre machine et que vous choisissez la nouvelle entrée, le niveau d'exécution offline sera utilisé au lieu du niveau default.

Utiliser « bootlevel »

L'utilisation de l'option bootlevel est tout à fait analogue à celle de softlevel. La seule différence ici, c'est que vous définissez un deuxième niveau d'exécution "boot" au lieu de définir un deuxième niveau d'exécution "défaut".


[ << ] [ < ] [ Sommaire ] [ > ] [ >> ]


Imprimer

Voir tout

Dernière mise à jour le 1er août 2013

Une version originale plus récente datée du 18 décembre 2013 existe.

Résumé : Gentoo fait appel à un format particulier de scripts de démarrage qui, entre autres, permet la gestion des dépendances et le support des services virtuels. Ce chapitre explique ces aspects et comment utiliser de tels scripts.

Sven Vermeulen
Auteur

Grant Goodyear
Auteur

Roy Marples
Auteur

Daniel Robbins
Auteur

Chris Houser
Auteur

Jerry Alexandratos
Auteur

Seemant Kulleen
Développeur Gentoo x86

Tavis Ormandy
Développeur Gentoo Alpha

Jason Huebel
Développeur Gentoo AMD64

Guy Martin
Développeur Gentoo HPPA

Pieter Van den Abeele
Développeur Gentoo PPC

Joe Kallar
Développeur Gentoo SPARC

John P. Davis
Correcteur

Pierre-Henri Jondot
Correcteur

Eric Stockbridge
Correcteur

Rajiv Manglani
Correcteur

Jungmin Seo
Correcteur

Stoyan Zhekov
Correcteur

livecd-i686-installer-2008.0_beta1.iso Jared Hudson
Correcteur

Colin Morey
Correcteur

Jorge Paulo
Correcteur

Carl Anderson
Correcteur

Jon Portnoy
Correcteur

Zack Gilburd
Correcteur

Jack Morgan
Correcteur

Benny Chuang
Correcteur

Erwin
Correcteur

Joshua Kinard
Correcteur

Tobias Scherbaum
Correcteur

Joshua Saddler
Correcteur

Gerald J. Normandin Jr.
Relecteur

Donnie Berkholz
Relecteur

Ken Nowack
Relecteur

Lars Weiler
Contributeur

Xavier Neys
Correcteur, traducteur

José Fournier
Traducteur

Camille Huot
Traducteur

Benjamin Girault
Traducteur

Olivier Fisette
Traducteur

Olivier Roomans
Traducteur

Vincent Strubel
Traducteur

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.