Dans ce cours, vous allez apprendre à installer et configurer un grand nombre de services. Ces services offriront diverses fonctionnalités à vos utilisateurs et aux autres machines de votre réseau. Avant toute chose, essayons de préciser ce que sont exactement ces services.
Pour rappel, sous Linux, chaque programme qui s’exécute prend la forme d’un processus. Vous pouvez utiliser la commande ps pour voir les processus qui tournent sur votre système. L’option -o précise les champs que vous souhaitez voir apparaître :
$ ps -o ppid,pid,tt,cmd PPID PID TT CMD 14142 14149 pts/1 bash 14149 14285 pts/1 ps -o ppid,pid,tt,cm
Vous voyez alors que le processus ps que vous lancez manuellement :
est attaché à votre terminal
pts/1;a pour parent votre shell de connexion bash (PID 14149 = PPID de ps) ;
ne mourra que s’il a terminé son exécution ou si son parent meurt.
Or, parmi tous les processus de votre système, certains :
ne sont associés à aucun terminal et tournent en “tâche de fond” indépendamment des utilisateurs qui se connectent ;
ont pour parent le processus de PID 1 qui ne meurt qu’à l’arrêt du système ;
s’exécutent “à durée indéterminée” et attendent qu’on leur donne du boulot.
Dans le monde Unix, on appelle ces processus des daemons, qu’on traduit parfois par démons, en français. Tous les logiciels serveurs que vous verrez dans ce cours s’exécutent sous forme de daemons. Dans le monde Windows, on parle de Services.
La plupart de ces daemons sont lancés au démarrage du système. On peut ensuite les arrêter, les relancer, etc. La façon dont le système gère ces daemons a évolué ces dernières années. Voyons d’un peu plus près le fonctionnement du système historique de gestion des daemons sous Linux, appelé SystemV.
SystemV : le système d’initialisation historique
Si je me lance dans un peu d’histoire, ça n’est pas juste par plaisir ou par mélancolie. Le service historique de gestion des processus est encore utilisé par d’anciennes distributions et par d’autres systèmes Unix que vous pourriez être amené à utiliser. Même les systèmes plus récents gardent généralement une forme de compatibilité. En connaissant SystemV, vous devriez pouvoir vous y retrouver un peu partout.
Avec SystemV, vous trouvez des scripts de démarrage/arrêt des daemons dans le répertoire /etc/init.d/ . Pour exécuter un script de ce répertoire, il vous suffit d’indiquer le nom du script suivi de l’action à réaliser. Par exemple, pour démarrer le serveur web apache2 :
/etc/init.d/apache2 start
Les actions possibles sont toujours start et stop pour démarrer et arrêter un processus. Vous pouvez parfois exécuter restart ( stop puis start en une seule commande), reload pour mettre à jour la configuration sans arrêter le service, ou status pour savoir si le daemon est actif et si tout fonctionne correctement.
Pour savoir quels services doivent être démarrés au lancement du système, ou à l’inverse pour tout arrêter proprement, SystemV se base sur des runlevels. Il y en a 7, numérotés de 0 à 6, et dont la fonction peut varier légèrement d’une distribution Linux à l’autre. Il y a généralement un consensus sur les niveaux :
Runlevel 0 : pour arrêter le système.
Runlevel 1 : pour le mode “single user”, qui est un mode de maintenance dans lequel seules les fonctions essentielles sont démarrées. Il n’y a pas de réseau, et seul root peut se connecter en ligne de commande.
Runlevel 6 : pour redémarrer le système.
Pour les runlevels 2 à 5, ce sont des modes multi-utilisateurs graphiques ou en mode console. C’est généralement le mode de fonctionnement normal du système. Le mode par défaut est défini dans le fichier /etc/inittab .
Pour chaque runlevel, vous trouvez ensuite un répertoire /etc/rcX.d , où X est un numéro de runlevel, par exemple /etc/rc2.d/ . Dans ce répertoire, vous trouvez des liens vers les scripts de /etc/init.d qui sont à démarrer ou à arrêter dans ce runlevel. Les liens commencent soit par la lettre S pour les daemons à démarrer, soit par la lettre K pour les daemons à arrêter. Cette lettre est suivie d’un nombre de 00 à 99 . Les scripts sont exécutés les uns après les autres dans l’ordre croissant des nombres et également par ordre alphabétique.
$ ls -og1 /etc/rc2.d | tail lrwxrwxrwx 1 22 juil. 19 2016 S03avahi-daemon -> ../init.d/avahi-daemon lrwxrwxrwx 1 19 juil. 19 2016 S03bluetooth -> ../init.d/bluetooth lrwxrwxrwx 1 17 juil. 19 2016 S03lightdm -> ../init.d/lightdm lrwxrwxrwx 1 14 juil. 19 2016 S04cups -> ../init.d/cups lrwxrwxrwx 1 22 juil. 19 2016 S04cups-browsed -> ../init.d/cups-browsed lrwxrwxrwx 1 15 juil. 19 2016 S04saned -> ../init.d/saned lrwxrwxrwx 1 21 juil. 19 2016 S05grub-common -> ../init.d/grub-common lrwxrwxrwx 1 18 juil. 19 2016 S05ondemand -> ../init.d/ondemand lrwxrwxrwx 1 18 juil. 19 2016 S05plymouth -> ../init.d/plymouth lrwxrwxrwx 1 18 juil. 19 2016 S05rc.local -> ../init.d/rc.loca
Sous les anciennes versions d’Ubuntu, le runlevel par défaut était 2, donc pour lancer Apache au démarrage du système, il suffisait de créer le lien symbolique suivant :
$ ln -s ../init.d/apache2 /etc/rc2.d/S80apache2
et pour l’arrêter à l’extinction du système :
$ ln -s ../init.d/apache2 /etc/rc0.d/K01apache2
Ce système brille par sa simplicité mais il reste assez limité. Notamment :
les différents daemons sont lancés les uns après les autres alors qu’on aurait souvent des temps de démarrage bien plus courts si on pouvait lancer plusieurs processus en même temps ;
les relations de dépendance (Apache qui a besoin du réseau, par exemple) sont gérées de manière basique par l’ordre de lancement des scripts. Si votre script dépend de plusieurs autres scripts et si plusieurs scripts dépendent du vôtre, ça devient casse-tête de trouver les bons numéros... ;
la gestion est assez statique et ne permet pas de gérer facilement des changements d’état du système (réseau coupé puis réseau qui revient, nouveau matériel, etc.).
Pour parer ces manques, de nouveaux systèmes de gestion des processus ont été développés, comme Upstart et systemd.
Upstart et systemd : évolutions récentes de systemV
Ubuntu est à l’origine d’une des initiatives les plus marquantes pour remplacer systemV, appelée Upstart. Upstart est basé sur des événements qui peuvent être tout type de changement d’état du système. Upstart peut alors réagir dynamiquement face à ces événements.
Pour les versions d’Ubuntu qui supportent ce système, vous trouverez les scripts de configuration d’Upstart dans le répertoire /etc/init/ . La commande initctl permet de gérer les processus. Par exemple, pour démarrer Apache2, il vous suffit d’indiquer :
sudo initctl start apache2
Finalement, une nouvelle évolution de la gestion des processus a vu le jour, appelée systemd. Après de vives critiques l’accusant d’être une usine à gaz ou de trop modifier les habitudes des administrateurs, c’est aujourd’hui le système qui fait consensus. Quasiment toutes les distributions Linux les plus récentes l’ont adopté, ou sont en cours de transition pour le faire.
En résumé
Sous Linux, les programmes s’exécutent sous forme de processus.
Certains processus tournent en tâche de fond, et sont appelés daemons.
Tous les logiciels serveurs s’exécutent sous forme de daemons.
Le système d’initialisation historique sous Unix est systemV.
Ce système est en passe d’être remplacé par systemd sur la plupart des distributions Linux.
Dans le prochain chapitre, je vous propose donc d’apprendre à utiliser les principales fonctions de ce système qui est, de fait, le nouveau standard.
