LPI-101-2-2
Un article de RotomaLUG.
| Frontal web | Wiki accueil | Les forums | La galerie | La liste LUG | La liste INSTALL PARTY |
Site original
http://www.gentoo.org/doc/en/articles/lpi-101-administration-p2.xml
Participer à la traduction
Pour participer aux traductions vous devez tout d'abord :
- vous inscrire sur le wiki (Pour créer un compte sur ce wiki, envoyez nous un courrier en suivant ce lien [1] )
- suivre au maximum le petit guide du traducteur
- nous contacter (via l'adresse info@rotomalug) pour l'organisation du travail
Notes de version
Date de version : --JMarc 14 jan 2007 à 18:40 (CEST) (relecture)
--Aurelien 7 avr 2006 à 22:58 (CEST)
--EricDeschamps 21 août 2006 à 22:20 (CEST)
Avancement :
- traduction 100%
- relecture 40% -> Utilisation de find
Note de licence : ce document est mis sous licence Creative Commons, pour respecter la licence du document original. (Merci aux juristes de l'association de confirmer que c'est nécessaire et OK).
LPI certification 101 (version 2) préparation à l'examen, Partie 2 - traduction
Avant de commencer
A propos de ce tutoriel
Voici "Administration de base", second de quatre tutoriels destinés à vous préparer à l'examen LPI 101. Dans ce document nous vous montrerons comment utiliser les expressions rationnelles (ou régulières ) pour rechercher des fichiers à partir de chaînes de caractères. Ensuite, nous vous ferons une introduction au File System Hierarchy Standard (le standard pour la hiérarchie du système de fichiers) et nous vous montrerons comment localiser des fichiers sur votre système. Puis nous vous montrerons comment prendre le contrôle total des processus Linux en les lançant en tâche de fond, en les listant, en les détachant d'un terminal, etc. Ensuite, nous vous donnerons une brève introduction aux tubes du shell, aux redirections et aux commandes permettant de travailler sur les chaînes de caractères. Enfin, nous vous présenterons les modules du noyau Linux.
Ce tutoriel (partie 2) est idéal pour ceux qui ont de bonnes connaissances de base du bash et souhaitent recevoir une solide introduction aux tâches d'administration de base. Si vous êtes nouveau sur Linux, nous vous recommandons de suivre la partie 1 avant d'aller plus loin. Pour certains, une bonne partie de ce qui sera vu sera nouveau, mais les utilisateurs plus expérimentés de Linux pourront trouver dans ce tutoriel un bon moyen de renforcer leurs compétences d'administration de base.
Ceux qui ont suivi la première version de ce document pour une autre raison que la préparation de la certification LPI n'ont sans doute pas besoin de suivre celle-ci. Par contre, si vous prévoyez de passer les examens, vous devriez envisager de lire cette version révisée.
A propos des auteurs
Résidant à Albuquerque, au Nouveau-Mexique, Daniel Robbins est le créateur de la distribution Gentoo Linux, une distribution Linux avancée basée sur les ports (au sens BSD). Il écrit également des articles, des tutoriels ou des conseils pour IBM developerWorks Linux zone et Intel Developer Services et a également contribué à plusieurs livres comme Samba Unleashed et SuSE Linux Unleashed. Daniel apprécie de passer son temps libre avec sa femme, Mary et sa fille Hadassah. Vous pouviez contacter Daniel à drobbins _CHEZ_ gentoo _POINT_ org.
Note du traducteur : voir également le contenu actuel du Wikipedia sur l'auteur, plus à jour :
Créateur en 2002 de la distribution GNU/Linux Gentoo et fondateur de la fondation Gentoo. Le 26 avril 2004, il quitte le projet pour passer plus de temps avec sa famille. Du 13 juin 2005 au 9 janvier 2006, il rejoint Microsoft, expliquant qu'il souhaitait aider Microsoft à comprendre l'Open Source et les projets communautaires. Avant de quitter gentoo, il a transféré toute propriété intellectuelle de Gentoo vers la fondation Gentoo. Le 9 janvier 2006, il quitte Microsoft.
Chris Houser, connu par ses amis comme "Chouser", est un partisan d'UNIX depuis 1994 alors qu'il rejoint l'équipe d'administration à l'université Taylor dans l'Indiana, où il a obtenu sa licence en informatique et mathématique. Depuis, il travaille dans la programmation d'applications Web, d'interfaces homme-machine, logiciels vidéo professionnels, et maintenant dans la programmation de pilotes UNIX pour Tru64 chez Compaq. Il a aussi contribuer à divers projets libres et plus particulièrement Gentoo. Il vit avec sa femme et ses deux chats dans le New Hampshire. Vous pouvez le contacter à chouser _CHEZ_ gentoo _POINT_ org .
Aron Griffis est titulaire d'un diplôme d'informatique de l'université Taylor et d'une distinction qui le désigne : "Futur fondateur d'une communauté utopique UNIX". Il travaille dans ce but. Aron est employé par la société Compaq afin de programmer des pilotes de cartes réseau pour UNIX Tru64, et il partage son temps avec entre jouer des airs au piano et développer pour Gentoo Linux. Il vit avec sa femme Amy, qui est elle aussi ingénieur UNIX à Nashua dans le New-Hampshire
Les expressions rationnelles
Qu'est-ce qu'une expression régulière ?
Une expression rationnelle ou régulière (également nommée "regex" ou "regexp") est une syntaxe particulière décrivant des motifs de texte. Sur des systèmes Linux, les expressions régulières sont souvent utilisées pour rechercher des motifs de texte, de même que pour effectuer des opérations de recherche et de remplacement sur des flux de texte.
Comparaison avec les jokers du shell
Quand nous jetterons un œil aux expressions régulières, vous pourrez trouver que la syntaxe des expressions régulières est similaire à celle des jokers que l'on a vus dans la partie 1. Cependant, ne vous laissez pas influencer par cette impression ; ce ne sont que des ressemblances de surface.
La sous-chaîne simple (et non pas le chimple chouchen )
Après cet avertissement, découvrons la plus basique des expressions régulières, la recherche d'une sous-chaîne simple. Pour cela, nous allons utiliser grep, une commande qui recherche dans le contenu d'un fichier le résultat d'une expression régulière. grep affiche chaque ligne qui correspond à l'expression régulière et ignore toutes les autres :
$ grep bash /etc/passwd operator:x:11:0:operator:/root:/bin/bash root:x:0:0::/root:/bin/bash ftp:x:40:1::/home/ftp:/bin/bash
Ci-dessus, le premier paramètre passé à grep est une expression régulière ; le second est un nom de fichier. grep parcourt chaque ligne de /etc/passwd et lui applique l'expression régulière sous-chaîne simple 'bash', en recherchant une correspondance. Si une équivalence est trouvée, grep affiche la ligne entière ; sinon, la ligne est ignorée.
Comprendre la sous-chaîne simple
En général, si vous recherchez une sous-chaîne de caractères, vous pouvez vous contenter de spécifier uniquement le texte recherché, sans ajouter de caractère "spécial". L'unique raison pour laquelle vous devriez saisir un tel caractère serait que votre sous-chaîne contienne un +, ., *, [, ], ou un \, cas pour lesquels ces caractères devraient être entourés de guillemets et précédés par un backslash. Voici quelques exemples supplémentaires de expressions régulières simples pour rechercher une sous-chaîne de caractères :
- /tmp (recherche la chaîne /tmp)
- "\[box\]" (recherche la chaîne [box]
- "\*funny\*" (recherche la chaîne *funny*)
- "ld\.so" (recherche la chaîne ld.so)
les Métacaractères
Avec les expressions régulières, vous pouvez effectuer des recherches bien plus complexes que les exemples que nous avons vus jusqu'à présent en utilisant les métacaractères (ou jockers). L'un de ces métacaractères est le . (le point) qui correspond à n'importe quel caractère seul :
$ grep dev.hda /etc/fstab /dev/hda3 / reiserfs noatime,ro 1 1 /dev/hda1 /boot reiserfs noauto,noatime,notail 1 2 /dev/hda2 swap swap sw 0 0 #/dev/hda4 /mnt/extra reiserfs noatime,rw 1 1
Dans cette exemple, la chaîne littérale dev.hda n'apparaît dans aucune ligne de /etc/fstab. Cependant, grep ne recherchait pas la chaîne littérale dev.hda mais le motif dev.hda. Rappelez-vous que . correspond à n'importe quel caractère seul. Comme vous pouvez le voir, le métacaractère . a la même fonctionnalité que le métacaractère ? pour les jokers du shell.
Utiliser []
Si nous souhaitions obtenir un caractère de façon un peu plus précise qu'avec ., nous aurions pu utiliser [ et ] pour préciser un sous-ensemble de caractères qui devraient correspondre :
$ grep dev.hda[12] /etc/fstab /dev/hda1 /boot reiserfs noauto,noatime,notail 1 2 /dev/hda2 swap swap sw 0
Comme vous pouvez le voir, cette syntaxe fonctionne comme le jocker [] sous bash. À nouveau, c'est l'un des points délicats lorsque l'on apprend les expressions régulière : la syntaxe est similaire mais pas identique aux jockers du shell, ce qui rend la plupart du temps les regex plus difficiles à apprendre.
Utiliser [^]
Vous pouvez inverser le sens des crochets en ajoutant un ^ immédiatement après le [. Dans ce cas, les crochets correspondront à tout caractère qui n'est pas entre les crochets. Encore un fois, notez que nous utilisons [^] pour les expressions régulières mais [!] avec les jockers :
$ grep dev.hda[^12] /etc/fstab /dev/hda3 / reiserfs noatime,ro 1 1 #/dev/hda4 /mnt/extra reiserfs noatime,rw 1 1
Syntaxe différente
Il est important de noter que la syntaxe entre les crochets est fondamentalement différente de celle utilisée en dehors, dans les expressions rationnelles. Par exemple, si vous mettez un . entre les crochets, cela correspondra littéralement à un ., comme dans les deux exemples qui suivent. En comparaison, un . utilisé en dehors des crochets est interprété comme un caractère spécial à moins qu'il soit préfixé par un \. Nous pouvons utiliser cette fonction pour afficher une liste de tous les fichiers de /etc/fstab qui contiennent la chaîne dev.hda en tapant :
$ grep dev[.]hda /etc/fstab
Nous aurions également pu taper :
$ grep "dev\.hda" /etc/fstab
Logiquement aucune de ces deux expressions régulières ne devrait renvoyer une ligne de votre fichier /etc/fstab.
Le jocker « * »
Certains caractères sont des jockers qui ne correspondent à rien, seuls, mais modifient le sens du caractère précédent. Par exemple, l'astérisque * qui vaut zéro ou plusieurs occurrences du caractère précédent. Notez que cela veut dire que * n'a pas le même sens pour les regex que pour les caractères spéciaux du shell. Voici quelques exemples, faites attention à ceux où le sens est différent dans les regex et dans le shell :
- ab*c trouvera abbbbc mais pas abqc (dans un shell, les deux auraient été équivalentes – voyez-vous pourquoi ?)
- ab*c trouvera abc mais pas abbqbbc (à nouveau vous auriez les 2 correspondances dans un shell)
- ab*c trouvera ac mais pas cba (dans un shell aucune des deux n'aurait correspondu)
- b[cq]*e trouvera bqe et be (dans un shell, vous auriez bqe mais pas be)
- b[cq]*e renvoie bccqqe mais pas bccc (vous auriez le même résultat dans un shell)
- b[cq]*e renvoie bqqcce mais pas cqe (vous auriez le même résultat dans un shell)
- b[cq]*e renvoie bbbeee (ce ne serait pas le cas dans un shell)
- .* renvoie n'importe quelle chaîne (dans un shell, vous auriez n'importe quelle chaîne commençant par un .)
- foo.* renvoie n'importe quelle chaîne commençant par foo (dans un shell, vous auriez n'importe quelle chaîne de caractères commençant par les 4 caractères foo.)
Maintenant, un petit point : la ligne ac est trouvée par l'expression régulière ab*c parce que l'astérisque * autorise le caractère précédent (c) à apparaître zéro fois. A nouveau, il est crucial de noter que le jocker * est interprété d'une façon fondamentalement différente que le caractère spécial * dans un shell.
Début et fin de ligne
Les derniers jockers que nous allons détailler ici sont ^ et $, correspondant respectivement au début et à la fin de ligne. En utilisant un ^ au début de votre regex, vous pouvez imposer à votre motif d'être ancré au début de la ligne. Dans l'exemple suivant, nous utilisons la regex ^# pour renvoyer chaque ligne qui commence par le caractère # :
$ grep ^# /etc/fstab # /etc/fstab: static file system information. #
Expressions régulières sur des lignes complètes
^ et $ peuvent être combinés pour correspondre à une ligne entière. Par exemple, l'expression régulière suivante trouvera une ligne qui commence avec le caractére # et qui fini par un ., avec n'importe quel nombre de caractéres entre les deux :
$ grep '^#.*\.$' /etc/fstab # /etc/fstab: static file system information.
Dans l'exemple précédent, nous entourons notre expression régulière avec des apostrophes pour éviter que $ ne soit interprété par le shell. Sans ces apostrophes, le $ disparaîtrait de notre expression régulière avant même que grep ne puisse le chercher.
FHS et recherche de fichiers
Standard de hiérarchisation du système de fichier
Le standard de hiérarchisation du système de fichiers (ou FHS Filesystem Hierarchy Standard) est un document qui définit la disposition des répertoires dans un système Linux. Le FHS a été conçu pour donner une disposition standard afin de simplifier le développement de logiciels indépendamment de la distribution, de sorte que l'ensemble des données se trouve généralement à la même place quelle que soit la distribution Linux. Le FHS définit l'arborescence de répertoires suivante (repris directement des spécifications FHS) :
- / (le répertoire racine)
- /boot (fichiers statiques du gestionnaire d'amorce)
- /dev (fichiers de périphériques)
- /etc (fichiers de configuration du système hôte)
- /lib (principales bibliothèques partagées et modules du noyau)
- /mnt (points de montage pour monter temporairement des systèmes de fichier)
- /opt (applications supplémentaires)
- /sbin (principaux binaires du système)
- /tmp (fichiers temporaires)
- /usr (hiérarchie secondaire)
- /var (données variables)
Les deux catégories de FHS indépendantes
La spécification du FHS base son organisation sur l'idée qu'il y a deux catégories indépendantes de fichiers : partagé vs non partagé, et variable vs statique. Les données partageables peuvent l'être entre deux hôtes (machines) ; les données non partageables sont spécifiques à un hôte (comme un fichier de configuration). Les données variables peuvent être modifiées ; les données statiques ne peuvent pas l'être (sauf lors de l'installation ou la maintenance d'un système).
La grille suivante résume les quatre combinaisons possibles, avec les répertoires qui pourraient tomber dans ces catégories. Une nouvelle fois, ce tableau vient directement des spécifications FHS :
+---------+-----------------+--------------+ | | partagés | non partagés | +---------+-----------------+--------------+ |statique | /usr | /etc | | | /opt | /boot | +---------+-----------------+--------------+ |variable | /var/mail | /var/run | | | /var/spool/news | /var/lock | +---------+-----------------+--------------+
La seconde hiérarchie de /usr
Dans /usr, vous trouverez une seconde hiérarchie qui ressemble beaucoup à celle du répertoire racine du système de fichier. Il n'est pas crucial qu'/usr existe lorsque la machine est mise en route, il peut donc être partagé sur le réseau ou monté à partir d'un CD-ROM (statique). La plupart des installations Linux ne font pas usage du partage de /usr, mais il est important de comprendre l'utilité de distinguer la hiérarchie primaire du répertoire racine, et la seconde hiérarchie de /usr. C'est tout ce que nous dirons sur le standard de hiérarchisation du système de fichier. Le document en lui-même est assez lisible, vous pouvez donc jeter un œil dessus. Vous comprendrez beaucoup plus de choses sur le FHS en le lisant. Il se trouve ici.
Recherche de fichier
Les systèmes Linux contiennent souvent des centaines de milliers de fichiers. Peut-être avez vous suffisamment de mémoire pour ne jamais oublier le chemin d'aucun d'entre eux, mais il est plus vraisemblable que vous aurez occasionnellement besoin d'aide pour en trouver un. Il y a quelques outils sous Linux pour trouver des fichiers. Cette introduction vous aidera à choisir le bon outil pour ce travail.
Le PATH
Lorsque vous exécutez un programme en ligne de commande, le bash va en fait rechercher dans une liste de répertoires pour trouver le programme que vous demandez. Par exemple, quand vous tapez ls, le bash ne sait pas de façon intrinsèque que le programme ls se trouve dans /usr/bin. En fait, le bash se référe à une variable d'environnement appelée PATH, qui est une liste de répertoires séparés par deux points. Nous pouvons regarder la valeur du PATH :
$ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin
Etant donnée cette valeur du PATH (la vôtre peut être différente), le bash vérifiera d'abord dans /usr/local/bin, puis dans /usr/bin pour trouver le programme ls. Il est probable que ls soit dans /usr/bin, le bash s'arrêtera donc à ce répertoire.
Modifier le PATH
Vous pouvez augmenter le PATH en ligne de commande :
$ PATH=$PATH:~/bin $ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/home/agriffis/bin
Vous pouvez également supprimer des éléments du PATH, cependant, ce n'est pas facile dès lors que vous ne pouvez pas accéder à un $PATH. Le plus simple est de retaper le nouveau PATH que vous souhaitez :
$ PATH=/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:~/bin $ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/agriffis/bin
Pour rendre les changements de PATH disponibles pour vos futures utilisations de ce shell, vous pouvez exporter vos changements avec la commande :
$ export PATH
Tout à propos de "which"
Vous pouvez vérifier s'il y a un programme donné dans votre PATH avec la commande which. Par exemple, nous voyons ici que notre système Linux n'a pas de sense :
$ which sense which: no sense in (/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin)
Dans cet exemple, nous trouvons la commande ls :
$ which ls /usr/bin/ls
"which -a"
Finalement, vous pouvez utiliser l'option -a, qui indique à which qu'il faut montrer toutes les occurrences d'un programme dans votre PATH :
$ which -a ls /usr/bin/ls /bin/ls
whereis
Si vous voulez plus d'information que l'emplacement d'un programme, vous devriez essayer la commande whereis :
$ whereis ls ls: /bin/ls /usr/bin/ls /usr/share/man/man1/ls.1.gz
Nous voyons ici que ls se trouve dans deux répertoires de fichiers binaires, /bin et /usr/bin. En plus, nous voyons qu'il y a une page de manuel située dans /usr/share/man. C'est la page de manuel que vous pouvez voir en tapant man ls. Le programme whereis permet également de chercher des sources, de donner des chemins de recherche différents, et de chercher des entrées inhabituelles. Voyez la page de manuel pour plus d'informations.
find
La commande find est un autre outil pratique dans votre boite à outils. Avec find, vous n'êtes pas limité aux programmes; vous pouvez rechercher n'importe quel fichier, en utilisant différents critères de recherche. Par exemple, pour rechercher des fichiers du nom de README, dans /usr/share/doc :
$ find /usr/share/doc -name README /usr/share/doc/ion-20010523/README /usr/share/doc/bind-9.1.3-r6/dhcp-dynamic-dns-examples/README /usr/share/doc/sane-1.0.5/README
find et caractères spéciaux
Vous pouvez utiliser des caractères d'englobement dans l'argument de -name, sous réserve que vous les mettiez entre guillemets, ou qu'ils soient précédés d'un backslash (afin qu'ils ne soient pas interprétés par le bash). Par exemple, vous pouvez rechercher les fichiers README avec une extension :
$ find /usr/share/doc -name README\* /usr/share/doc/iproute2-2.4.7/README.gz /usr/share/doc/iproute2-2.4.7/README.iproute2+tc.gz /usr/share/doc/iproute2-2.4.7/README.decnet.gz /usr/share/doc/iproute2-2.4.7/examples/diffserv/README.gz /usr/share/doc/pilot-link-0.9.6-r2/README.gz /usr/share/doc/gnome-pilot-conduits-0.8/README.gz /usr/share/doc/gimp-1.2.2/README.i18n.gz /usr/share/doc/gimp-1.2.2/README.win32.gz /usr/share/doc/gimp-1.2.2/README.gz /usr/share/doc/gimp-1.2.2/README.perl.gz [578 lignes supplémentaire non montrées]
Ignorer la casse avec find
Vous pouvez bien sûr ignorer la casse dans votre recherche :
$ find /usr/share/doc -name '[Rr][Ee][Aa][Dd][Mm][Ee]*'
Ou plus simplement :
$ find /usr/share/doc -iname readme\*
Comme vous pouvez le voir il est possible d'utiliser -iname pour faire une recherche insensible à la casse.
find et les expressions régulières
Si vous êtes habitué aux expressions régulières, vous pouvez utiliser l'option -regexp pour limiter la sortie aux noms de fichiers qui correspondent à votre expression. Et de la même façon qu'avec l'option -iname, vous disposez d'une option -iregexp pour ignorer la casse. Par exemple :
$ find /etc -iregex '.*xt.*' /etc/X11/xkb/types/extra /etc/X11/xkb/semantics/xtest /etc/X11/xkb/compat/xtest /etc/X11/app-defaults/XTerm /etc/X11/app-defaults/XTerm-color
Notez que contrairement à de nombreux programmes, find a besoin que l'expression régulière corresponde au chemin complet, et non juste à une partie de ce dernier. Il est donc nécessaire de spécifier le .* au début et à la fin; utiliser uniquement xt comme expression régulière ne serait pas suffisant.
find et les types
L'option -type vous permet de rechercher dans le système de fichiers des objets d'un certain type. Les arguments pour -type sont b (périphérique de type bloc), c (périphérique de type caractère), d (répertoire), p (canal nommé), f (fichier), l (lien symbolique), et s (socket). Par exemple, pour chercher les liens symboliques qui contiennent l'expression vim dans /usr/bin :
$ find /usr/bin -name '*vim*' -type l /usr/bin/rvim /usr/bin/vimdiff /usr/bin/gvimdiff
find et mtime
L'option -mtime vous permet de sélectionner des fichiers en fonction de leur date de dernière modification. L'argument passé à -mtime est exprimé en terme de périodes de 24 heures et est plus utile lorsqu'il est accompagné du signe plus (qui veut dire après) ou du signe moins (qui signifie avant). Par exemple, considérez le scénario suivant :
$ ls -l ? -rw------- 1 root root 0 Jan 7 18:00 a -rw------- 1 root root 0 Jan 6 18:00 b -rw------- 1 root root 0 Jan 5 18:00 c -rw------- 1 root root 0 Jan 4 18:00 d $ date Mon May 7 18:14:52 EST 2003
Vous pourriez chercher les fichiers créés dans les dernières 24 heures :
$ find . -name \? -mtime -1 ./a
Ou vous pourriez chercher les fichiers qui ont été créés avant la période de 24 heures courante :
$ find . -name \? -mtime +0 ./b ./c ./d
L'option -daystart
Si vous spécifiez l'option -daystart, la période commence à minuit ce jour à la place d'il y a 24 heures. Par exemple, voici une liste de fichiers créée hier et le jour précédent :
$ find . -name \? -daystart -mtime +0 -mtime -3 ./b ./c $ ls -l b c -rw------- 1 root root 0 May 6 18:00 b -rw------- 1 root root 0 May 5 18:00 c
L'option -size
L'option -size vous permet de chercher des fichiers à partir de leur taille. Par défaut, l'argument à -size fonctionne en blocs de 512 octets, mais ajouter un suffixe rend les choses plus claires. Les suffixes possibles sont b (blocs de 512 octets), c (octets), k (kilo-octets), et w (mots de 2 octets). De plus vous pouvez faire précéder votre argument d'un signe plus (plus gros que) ou moins (inférieur à).
Par exemple, pour chercher les fichiers de /usr/bin inférieurs à 50 octets :
$ find /usr/bin -type f -size -50c /usr/bin/krdb /usr/bin/run-nautilus /usr/bin/sgmlwhich /usr/bin/muttbug
Agir sur les fichiers trouvés
Vous pouvez vous demander ce que vous pouvez faire avec tous ces fichiers que vous avez trouvé ! Bien, find a la possibilité d'agir sur les fichiers qu'il trouve en utilisant l'option -exec. Cette option accepte une ligne de commande à exécuter comme argument, terminé par ; , et il remplace chaque occurrence de {} par le nom du fichier.
Note du traducteur : dans l'exemple suivant les caractères {} et ; sont échappés par des guillemets simples. Vous trouverez ailleurs un certain nombre d'exemple où le ; est échappé par un \.
C'est plus facile à comprendre avec un exemple :
$ find /usr/bin -type f -size -50c -exec ls -l '{}' ';'
-rwxr-xr-x 1 root root 27 Oct 28 07:13 /usr/bin/krdb
-rwxr-xr-x 1 root root 35 Nov 28 18:26 /usr/bin/run-nautilus
-rwxr-xr-x 1 root root 25 Oct 21 17:51 /usr/bin/sgmlwhich
-rwxr-xr-x 1 root root 26 Sep 26 08:00 /usr/bin/muttbug
Comme vous pouvez le voir, find est une commande très puissante. Elle a pris de l'ampleur à travers les années du développement d'UNIX et de Linux. Il y a beaucoup d'autres options utiles à find. Vous pouvez en apprendre plus en consultant la page de manuel de find.
locate
Nous avons vu which, whereis et find. Vous aurez peut-être constaté que find prend un certain temps à s'exécuter, parce qu'il doit parcourir chaque répertoire dans lequel il effectue sa recherche. Cela nous démontre que la commande locate peut accélérer les choses en faisant appel à une base de données externe générée par updatedb (qui sera vu juste après).
La commande locate effectue sa recherche dans n'importe quelle partie du nom d'un chemin, pas simplement sur le nom du fichier lui-même. Par exemple :
$ locate bin/ls /var/ftp/bin/ls /bin/ls /sbin/lsmod /sbin/lspci /usr/bin/lsattr /usr/bin/lspgpot /usr/sbin/lsof
Utiliser updatedb
La plupart des systèmes Linux ont un travail planifié (par cron) qui met à jour la base de locate périodiquement. Si votre locate renvoie une erreur comme celle qui va suivre, alors vous aller devoir lancer updatedb en tant que root pour générer la base de recherche :
$ locate bin/ls locate: /var/spool/locate/locatedb: No such file or directory $ su - Password: # updatedb
La commande updatedb peut prendre un certain temps à s'exécuter. Si votre disque dur est bruyant, vous allez l'entendre gratter parce que l'ensemble du système de fichiers est indexé.
slocate
Sur la plupart des distributions Linux, locate a été remplacé par slocate. Il y a typiquement un lien symbolique vers locate, ainsi vous n'avez pas à vous occuper de celui que vous utilisez. slocate signifie « secure locate ». Il stocke les informations de permissions dans la base de données de façon à ce que les utilisateurs normaux ne puissent pas se balader dans des répertoires auxquels ils n'ont pas accès autrement. Les informations sur slocate sont les mêmes que pour locate, cependant la sortie peut dépendre en fonction de l'utilisateur qui lance la commande.
Contrôle de processus
Afin de comprendre le contrôle de processus, nous devons tout d'abord en lancer un. Assurez vous que votre X fonctionne, et exécutez la commande suivante :
$ xeyes -center red
Vous remarquerez que la fenêtre xeyes apparaît, et que des yeux rouges (NdT : plus gros mais moins rouges que ceux d'Aurélien) suivent la souris sur l'écran. Vous remarquerez également que vous n'avez pas de nouvelle invite de commande dans votre terminal.
Arrêter un processus
Pour retrouver votre invite de commande, vous pouvez taper Control-C (souvent écrit Ctrl-C ou ^C). Vouz avez alors une nouvelle invite de commande bash, mais la fenêtre xeyes a disparu. En fait, le processus a été tué. Au lieu de le tuer avec Control-C, nous aurions pu juste le stopper avec Control-Z :
$ xeyes -center red Control-Z [1]+ Stopped xeyes -center red $
Cette fois ci, vous avez une nouvelle invite de commande bash, et la fenêtre xeyes est restée. Cependant, si vous jouez un peu avec, vous verrez que les yeux restent figés. Si vous recouvrez la fenêtre xeyes par une autre fenêtre, et que vous la découvrez, vous verrez qu'elle ne se redessine pas. Le processus ne fait plus rien. En fait, il est "Arrêté".
fg et bg
Pour "relancer" le programme pour qu'il fonctionne de nouveau, vous pouvez le remettre en avant plan avec la commande interne du bash fg :
$ fg (test it out, then stop the process again) Control-Z [1]+ Stopped xeyes -center red $
Continuons maintenant avec l'arrière plan avec la commande interne du bash bg :
$ bg [1]+ xeyes -center red & $
Merveilleux! Le processus xeyes fonctionne maintenant à l'arrière plan, et nous avons de nouveau une invite de commande bash disponible.
Utilisation de "&"
Si nous souhaitions lancer xeyes à l'arrière plan dès le début (au lieu d'utiliser Control-Z et bg), nous aurions pu simplement ajouter un & à la fin de la ligne de commande :
$ xeyes -center blue & [2] 16224
Multiples processus en arrière plan
Maintenant, nous avons deux processus xeyes, (l'un bleu, l'autre rouge) en arrière plan. Nous pouvons lister ces tâches avec la commande interne bash "jobs" :
$ jobs -l [1]- 16217 Running xeyes -center red & [2]+ 16224 Running xeyes -center blue &
Les nombres dans la colonne de gauche sont les numèros de tâche que le bash a donné lors du démarrage. Job 2 a un + qui indique que c'est la tâche courante, ce qui signifie qu'en tapant fg, vous le mettrez en arrière plan. Vous pouvez également placer à l'arrière plan une tâche spécifique en indiquant son numéro associé; par exemple, bg 1 mettrait le xeyes rouge en tâche de fond. La colonne suivante est l'id ou pid du processus, inclue grâce à l'option -l. Finalement, les deux tâches fonctionnent, et les lignes de commandes correspondantes sont listées à droite.
Introduction au signaux
Pour tuer, arrêter ou continuer des processus, Linux utilise une forme particulière de communication appelé "signaux". En envoyant un certain signal à un processus, vous pouvez l'arrêter, le stopper, ou faire d'autres choses. C'est en fait ce que pratiquez en tapant Control-C, Control-Z, ou en utilisant les commandes internes bg ou fg -- vous utlisez bash pour envoyer un signal particulier au processus. Ces signaux peuvent aussi être envoyés en utilisant la commande kill et en indiquant le pid (ou l'id du processus) avec la ligne de commande :
$ kill -s SIGSTOP 16224 $ jobs -l [1]- 16217 Running xeyes -center red & [2]+ 16224 Stopped (signal) xeyes -center blue
Comme vous pouvez le voir, kill ne tue pas forcément un processus, bien qu'il le puisse. En utilisant l'option "-s", kill peut envoyer n'importe quel type de signal à un processus. Linux tue, stoppe ou continue des processus quand les signaux SIGINT, SIGSTOP, et SIGCONT sont respectivement envoyés. Il y a aussi d'autres signaux que vous pouvez envoyer à un processus; certains de ces processus peuvent être interprétés différement suivant l'application. Vous pouvez apprendre quels signaux particuliers sont reconnus par un processus en regardant sa page man, et en cherchant la section SIGNALS.
SIGTERM and SIGINT
Si vous voulez tuer un processus, vous avez différentes options. Par défault, kill envoie SIGTERM, qui n'est pas identique à SIGINT de Control-C, mais qui a habituellement le même résultat :
$ kill 16217 $ jobs -l [1]- 16217 Terminated xeyes -center red [2]+ 16224 Stopped (signal) xeyes -center blue
Le grand kill
Les processus peuvent ignorer SIGTERM et SIGINT, soit par choix soit parce qu'ils sont arrêtés d'une manière anormale. Dans ces cas, il peut être nécessaire d'utiliser le grand marteau, le signal SIGKILL. Un processus ne peut pas ignorer SIGKILL :
$ kill 16224 $ jobs -l [2]+ 16224 Stopped (signal) xeyes -center blue $ kill -s SIGKILL $ jobs -l [2]+ 16224 Interrupt xeyes -center blue
nohup
Le terminal dans lequel vous avez démarré un tâche est appelé le terminal de contrôle des tâches. Quelques shells (pas bash par défault), transmettrons le signal SIGHUP aux travaux en arrière plan lorsque vous vous déconnectez, entrainant leur arrêt. Pour protéger les processus de ce comportement, utilisez la commande nohup lorsque vous démarrez un processus :
$ nohup make & [1] 15632 $ exit
Utilisation de ps pour lister des processus
La commande jobs que nous avons utilisé précedemment liste simplement les processus qui ont été démarré depuis notre session bash. Pour voir tous les processus sur notre système, utilisez ps avec les options a et x ensembles :
$ ps ax
PID TTY STAT TIME COMMAND
1 ? S 0:04 init [3]
2 ? SW 0:11 [keventd]
3 ? SWN 0:13 [ksoftirqd_CPU0]
4 ? SW 2:33 [kswapd]
5 ? SW 0:00 [bdflush]
Je n'en ai listé que les premières car la liste est généralement très longue. Cela donne un aperçu de tout ce que la machine est en train de faire, mais il y a beaucoup d'informations qu'il faut trier. Si vous n'indiquez pas les options ax, vous le verrez que les processus dont vous êtes le propriétaire, et qui ont un terminal de contrôle. La commande ps x vous montrera tous vos processus, même ceux qui n'ont pas de terminal de contrôle. Si vous utilisez ps a, vous aurez la liste des processus de tout le monde, lorsqu'ils sont liés à un terminal.
Voir les forêts et les arbres
Vous pouvez également lister différentes informations à propos de chaque processus. l'option --forest permet de voir facilement la hiérarchie des procesus, ce qui vous donnera une indication sur la façon dont les différents procesus sont liés. Quand un processus démarre un nouveau processus, ce nouveau processus est appelé processus "fils". Dans une liste --forest, les parents apparaissent sur la gauche, et les enfants apparaissent comme des branches sur la droite :
$ ps x --forest PID TTY STAT TIME COMMAND 927 pts/1 S 0:00 bash 6690 pts/1 S 0:00 \_ bash 26909 pts/1 R 0:00 \_ ps x --forest 19930 pts/4 S 0:01 bash 25740 pts/4 S 0:04 \_ vi processes.txt
Les options "u" et "l" de ps
Les options u et l peuvent aussi être ajoutée à n'importe quelle combinaison de a et x afin d'avoir plus d'informations sur chaque processus :
$ ps au USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND agriffis 403 0.0 0.0 2484 72 tty1 S 2001 0:00 -bash chouser 404 0.0 0.0 2508 92 tty2 S 2001 0:00 -bash root 408 0.0 0.0 1308 248 tty6 S 2001 0:00 /sbin/agetty 3 agriffis 434 0.0 0.0 1008 4 tty1 S 2001 0:00 /bin/sh /usr/X chouser 927 0.0 0.0 2540 96 pts/1 S 2001 0:00 bash
$ ps al F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 100 1001 403 1 9 0 2484 72 wait4 S tty1 0:00 -bash 100 1000 404 1 9 0 2508 92 wait4 S tty2 0:00 -bash 000 0 408 1 9 0 1308 248 read_c S tty6 0:00 /sbin/ag 000 1001 434 403 9 0 1008 4 wait4 S tty1 0:00 /bin/sh 000 1000 927 652 9 0 2540 96 wait4 S pts/1 0:00 bash
Utilisation de top
Si vous utlisez fréquemment ps, en essayant de voir ce qui change, ce que vous voulez probablement est top. top affiche une liste des processus mise à jour en permanence, avec quelques informations importantes :
$ top 10:02pm up 19 days, 6:24, 8 users, load average: 0.04, 0.05, 0.00 75 processes: 74 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 1.3% user, 2.5% system, 0.0% nice, 96.0% idle Mem: 256020K av, 226580K used, 29440K free, 0K shrd, 3804K buff Swap: 136544K av, 80256K used, 56288K free 101760K cached PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 628 root 16 0 213M 31M 2304 S 0 1.9 12.5 91:43 X 26934 chouser 17 0 1272 1272 1076 R 0 1.1 0.4 0:00 top 652 chouser 11 0 12016 8840 1604 S 0 0.5 3.4 3:52 gnome-termin 641 chouser 9 0 2936 2808 1416 S 0 0.1 1.0 2:13 sawfish
nice
Chaque processus a une priorité que Linux utilise pour déterminer comment partager les temps d'accés CPU. Vous pouvez régler la priorité d'un processus en le démarrant avec la commande nice :
$ nice -n 10 oggenc /tmp/song.wav
Etant donné que le réglage de la priorité est appelé nice (gentil NdT), il est facile de se souvenir qu'une grande valeur rendra le processus plus "gentil" envers les autres, en leur permettant d'être prioritaire pour l'accés au CPU. Par défaut, les processus sont démarrés avec le réglage 0, ainsi le réglage 10 siginifie que oggenc laissera facilement l'accés au CPU aux autres processus. Généralement, cela signifie que oggenc autorisera les autres processus à fonctionner à une vitesse normale, malgré la gourmandise habituelle de oggenc en terme de CPU. Vous pouvez voir ces niveaux de "gentillesse" sous la colonne NI de la commande ps.
renice
La commande nice peut uniquement changer la priorité d'un processus lorsque vous le démarrez. Si vous voulez changer les paramètres de gentillesse d'un processus en cours d'exécution, utilisez renice :
$ ps l 641 F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 000 1000 641 1 9 0 5876 2808 do_sel S ? 2:14 sawfish $ renice 10 641 641: old priority 0, new priority 10 $ ps l 641 F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 000 1000 641 1 9 10 5876 2808 do_sel S ? 2:14 sawfish
Edition de texte
Revisitons les redirections
Plus tôt dans cette série de tutoriels, nous avons vu un exemple d'utilisation de l'opérateur > pour rediriger la sortie d'une commande vers un fichier comme cela :
$ echo "firstfile" > copyme
De plus, pour rediriger la sortie vers un fichier, nous pouvons également tirer partie d'un puissant composant du shell appelé tube (ou pipe). En utilisant les tubes, nous pouvons donner la sortie d'une commande comme entrée d'une autre commande. Considérant l'exemple suivant :
$ echo "hi there" | wc
1 2 9
Le caractère | est utilisé pour connecter la sortie de la commande de gauche à l'entrée de la commande de droite. Dans cet exemple, la commande echo affiche la chaine "hi there" suivie d'un saut de ligne. Cette sortie devrait normalement apparaître sur le terminal, mais le tube la redirige vers la commande wc, qui affiche le nombre de lignes, de mots, et de caractères en entrée.
Un exemple de tube
Voici un autre exemple simple :
$ ls -s | sort -n
Dans ce cas, ls -s devrait normalement afficher la liste du répertoire courant dans le terminal, chaque fichier étant précédé de sa taille. Mais en fait, nous avons fait un tube vers sort -n, qui trie numériquement la sortie. C'est un moyen très utile de trouver les gros fichier dans votre répertoire personnel !
Les exemples suivants sont plus complexes, mais ils démontrent la puissance des tubes. Nous allons découvrir quelques commandes que nous n'avons pas pas encore vu, mais sans pour autant s'y attarder. Concentrons-nous plutôt sur la compréhension des tubes afin que vous puissiez les utiliser dans vos tâches quotidiennes avec Linux.
Le tube pour décompresser
Normalement, pour décompresser et détarer un fichier, vous pourriez faire :
$ bzip2 -d linux-2.4.16.tar.bz2 $ tar xvf linux-2.4.16.tar
Le revers de cette méthode est qu'il vous faut créer un fichier décompressé intermédiaire sur votre disque. Puisque tar peut directement lire depuis l'entrée (au lieu de spécifier un fichier), nous pouvons arriver au même résultat en utilisant le tube :
$ bzip2 -dc linux-2.4.16.tar.bz2 | tar xvf -
Woo hoo ! Notre tarball compressé a été extrait, et nous n'avons pas eu besoin d'un fichier intermédiaire.
Un tube plus long
Voici un autre exemple de tube :
$ cat myfile.txt | sort | uniq | wc -l
Nous avons utilisé cat pour alimenter la commande sort avec le contenu du fichier myfile.txt. Quand la commande sort reçoit l'entrée, elle trie toutes les lignes par ordre alphabétique, et envoie ensuite la sortie à la commande uniq. uniq supprime les lignes multiples (nécessite que l'entrée soit triée cependant) envoyant la sortie à wc -l. Nous avons vu la commande wc plus tôt, mais sans options. Avec l'option -l, elle n'affiche que le nombre de lignes de l'entrée, au lieu d'afficher également les mots et caractères. Vous verrez que le tube n'affichera que le nombre de lignes uniques (non identiques) du fichier texte.
Essayer de créer une paire de fichiers tests avec votre éditeur de texte préféré et testez ce tube pour voir les résultats que vous obtenez.
Le tourbillon du traitement de texte commence
Nous allons maintenant partir dans le tourbillon des commandes Linux de traitement de texte. Etant donné que nous couvrons beaucoup de choses dans ce tutoriel, nous n'avons pas la place de donner des exemples pour chaque commande. Nous vous encourageons donc à lire les man pages (en tapant man echo par exemple) pour apprendre de quelle façon chaque commande fonctionne, et à passer un peu de temps à jouer avec chacune d'entre elles. En général, ces commandes affichent les résultats de chaque traitement de texte dans le terminal plutôt que de modifier les fichiers spécifiés. Après un tour de ces commandes de traitement de texte, nous regarderons de plus près les redirections d'entrée et de sortie. Donc oui, il y a une lumière à la sortie du tunnel :)
echo affiche ces arguments sur le terminal. L'option -e permet d'interpréter les séquences d'échappement précédées d'un backslash, par exemple, echo -e "foo\nfoo" affichera foo, suivie d'une nouvelle ligne et foo de nouveau. L'option -n indique à echo de ne pas tenir compte du retour à la ligne final qui est ajouté par défaut.
cat affichera le contenu des fichiers indiqués sur le terminal. Pratique comme première commande du tube, par exemple, cat foo.txt | blah
sort affichera le contenu du fichier dans l'ordre alphabétique. Biensûr, sort accepte aussi les les sorties d'un tube comme entrée. Tapez man sort pour vous familiariser avec les nombreuses options pour contrôler le comportement de sort.
uniq prend un fichier déjà trié, ou un flux de données (via un tube) et supprime les redondances.
wc affiche le nombre de lignes, de mots et de caractères d'un fichier ou d'un flux d'entrée. Tapez man wc pour apprendre à régler finement les totaux affichés.
head affiche les dix premières lignes d'un fichier ou d'un flux. L'option -n permet de spécifier le nombre de lignes à afficher.
tail affiche les dix dernières lignes d'un fichier ou d'un flux. L'option -n permet de spécifier le nombre de lignes à afficher
tac est comme cat mais affiche les fichiers dans l'ordre inverse; en d'autres termes, la dernière ligne est affichée en premier.
expand convertit les tabulations en espaces. Utilisez l'option -t pour spécifier la longueur des tabulations.
unexpand convertit les espaces en tabulations. Utilisez l'option -t pour spécifier la longueur des tabulations.
cut est utilisé pour extraire des champs délimités par des caractères de fichiers ou flux d'entrée.
La commande nl ajoute le numéro de ligne à chaque ligne du fichier d'entrée. Utile pour les impressions.
pr est utilisé pour séparer des fichiers sur différentes pages de sortie ; typiquement utilisé pour les impressions.
tr est un outil de traduction de caractères; c'est utilisé pour convertir certains caractères du flux d'entrée en d'autres caractères pour le flux de sortie.
sed est est un puissant éditeur de texte orienté pour les flux. Vous pouvez en apprendre plus sur sed en lisant les articles IBM (attention, articles en anglais : Sed par l'exemple 1, Sed par l'exemple 2 et Sed par l'exemple 3)
Si vous souhaitez passer la certification LPI, assurez vous d'avoir lu au moins les deux premiers articles.
awk est un langage d'édition de texte pratique, orienté ligne. Vous pouvez en apprendre plus sur awk en lisant les articles IBM (attention, articles en anglais : awk par l'exemple 1, awk par l'exemple 2 et awk par l'exemple 3)
od est conçu pour transformer le flux d'entrée en format octal ou héxadécimal.
split est une commande utilisée pour séparer de gros fichiers en plusieurs petits fichiers, plus facilement gérables.
fmt reformate les paragraphes en rognant les marges. De nos jours, cette commande est moins utile car cette fonction est disponible dans la plupart des éditeurs de texte, mais il est bon de la connaître.
paste prend au moins deux fichiers en entrée, les concatène séquentiellement sur la sortie standard. Cette commande peut être utile pour créer des tableaux ou des colonnes de texte.
join est similaire à paste, mais utilise un champ (par défaut le premier) de chaque ligne d'entrée, pour trouver ce qui doit être combiné sur une seule ligne.
tee affiche son entrée dans un fichier et à l'écran. C'est très utilie lorsque vous voulez créer un log de quelque chose, mais que vous voulez également le voir à l'écran.
Le tourbillon est fini! Les redirections
De la même façon qu'il est possible d'utiliser > dans les commandes bash, vous pouvez également utiliser < pour rediriger un fichier vers une commande. Pour beaucoup de commandes, vous pouvez simplement spécifier un nom de fichier sur la ligne de commande, cependant, quelques commandes ne fonctionnent qu'avec l'entrée standard.
Bash comme d'autres shells supporte le concept de "herefile". Cela permet de spécifier à l'entrée d'un commande dans les lignes suivant l'invocation de la commande, en terminant avec une valeur particulière. Le plus simple est de regarder un exemple :
$ sort <<END apple cranberry banana END apple banana cranberry
Dans l'exemple ci-dessus, nous avons tapé les mots apple, cranberry et banana, suivis par "END" qui signifie la fin de l'entrée. Le programme sort retourne alors les mots triès par ordre alphabétique.
Utilisation de >>
Nous pourrions nous attendre à ce que >> ait un comportement similaire à <<, mais pas vraiment. Il indique simplement d'ajouter la sortie à un fichier, et non de l'écraser comme >. Par exemple :
$ echo Hi > myfile $ echo there. > myfile $ cat myfile there.
Oops! Nous avons perdu la partie "Hi". Ce que nous voulions c'était :
$ echo Hi > myfile $ echo there. >> myfile $ cat myfile Hi there.
Nettement mieux!
Les modules du noyau
A la rencontre de uname
La commande uname vous fournit un certain nombre d'informations intéressantes sur votre système. Voici ce qu'affiche ma station de travail de développement lorsque je tape uname -a qui demande à uname de retourner toutes ses informations en un seul jet :
$ uname -a Linux inventor 2.4.20-gaming-r1 #1 Fri Apr 11 18:33:35 MDT 2003 i686 AMD Athlon(tm) XP 2100+ AuthenticAMD GNU/Linux
Un peu plus sur la folie de uname
Maintenant, regardons quelles informations uname nous fourni :
Information arg exemple kernel name -s "Linux" hostname -n "inventor" kernel release -r "2.4.20-gaming-r1" kernel version -v "#1 Fri Apr 11 18:33:35 MDT 2003" machine -m "i686" processor -p "AMD Athlon(tm) XP 2100+" hardware platform -i "AuthenticAMD" operating system -o "GNU/Linux"
Intriguant ! Qu'est-ce que la commande uname -a vous affiche ?
La version du noyau
Voilà un tour de magie. D'abord, tapez uname -r pour que uname vous renvoie la version du noyau que vous utilisez actuellement.
Maintenant, regardez dans le répertoire /lib/modules et -- presto ! -- je parie que vous trouverez un répertoire de ce nom e x a c t e m e n t ! D'accord, ce n'est pas si magique, mais maintenant il est sans doute temps de parler du sens des répertoires dans /lib/modules et d'expliquer ce que sont les modules du noyau.
Le noyau
Le noyau de Linux est le coeur de qu'on appelle communément "Linux" -- c'est une partie de code qui accède directement à votre matériel et procure des couches d'abstractions qui permettent aux bons vieux programmes de fonctionner. Grâce au noyau Linux votre éditeur de texte n'a pas à se préoccuper de savoir s'il écrit sur un disque SCSI ou IDE - ou même un disque virtuel en mémoire. Il écrit simplement sur un système de fichiers et le noyau s'occupe du reste.
Introduction aux modules du noyau
Donc c'est quoi les modules du noyau ? Eh bien, ce sont des parties du noyau qui ont été stockées dans un format spécial sur le disque. Ils peuvent être chargés dans le noyau en fonctionnement à la demande et fournir une fonctionnalité supplémentaire.
Puisque les modules sont chargés à la demande, votre noyau peut gérer beaucoup de fonctionnalités dont vous n'avez pas besoin couramment. Une fois inclus, ces modules peuvent se révéler très pratiques et être chargés - souvent automatiquement - pour gérer ce curieux système de fichiers ou encore un périphérique que vous utilisez rarement.
Les modules du noyau en résumé
En résumé, les modules permettent à votre noyau en fonctionnement d'activer des fonctionnalités à la demande. Sans les modules, vous devriez compiler un noyau tout neuf et redémarrer pour gérer quelque-chose de nouveau.
lsmod
Pour voir quels sont les modules actuellement chargés sur votre système, utilisez la commande lsmod :
# lsmod Module Size Used by Tainted: PF vmnet 20520 5 vmmon 22484 11 nvidia 1547648 10 mousedev 3860 2 hid 16772 0 (unused) usbmouse 1848 0 (unused) input 3136 0 [mousedev hid usbmouse] usb-ohci 15976 0 (unused) ehci-hcd 13288 0 (unused) emu10k1 64264 2 ac97_codec 9000 0 [emu10k1] sound 51508 0 [emu10k1] usbcore 55168 1 [hid usbmouse usb-ohci ehci-hcd]
La liste de modules
Comme vous pouvez le voir, mon système a assez peu de modules chargés. Les modules vmnet et vmmon me fournissent les fonctionnalités nécessaires pour utiliser VMWare, qui me permet de lancer un PC virtuel dans une fenêtre sur mon bureau. (NdT : il existe désormais des alternatives libres à VMWare parmi lesquelles QEMU et XEN). Le module nvidia vient de NVIDIA corporation et me permet d'utiliser ma carte vidéo 3D avec accélération graphique sous Linux tout en profitant de ses meilleures fonctionnalités.
Ensuite, j'ai une série de modules qui servent à gérer ma souris USB - "mousedev," "hid," "usbmouse," "input," "usb-ohci," "ehci-hcd" et "usbcore.". Il est souvent plus intéressant de configurer votre système Linux pour gérer l'USB à partir des modules. Pourquoi ? Parce que les périphériques USB sont "plug and play" et que lorsque vous gérez l'USB avec les modules vous pouvez acheter un nouveau périphérique USB, le brancher sur votre machine, et que votre système charge automatiquement le module approprié pour pouvoir l'utiliser. C'est un moyen pratique de faire les choses.
depmod et ses amis
Dans mon répertoire /lib/modules/2.4.20-gaming-r1/ j'ai un certain nombre de fichiers dont le nom commence par « modules » :
$ ls /lib/modules/2.4.20-gaming-r1/modules.* /lib/modules/2.4.20-gaming-r1/modules.dep /lib/modules/2.4.20-gaming-r1/modules.generic_string /lib/modules/2.4.20-gaming-r1/modules.ieee1394map /lib/modules/2.4.20-gaming-r1/modules.isapnpmap /lib/modules/2.4.20-gaming-r1/modules.parportmap /lib/modules/2.4.20-gaming-r1/modules.pcimap /lib/modules/2.4.20-gaming-r1/modules.pnpbiosmap /lib/modules/2.4.20-gaming-r1/modules.usbmap
Ces fichiers contiennent les informations sur les dépendances. En fait ils enregistrent les informations de dépendances entre les modules – car certains modules nécessitent que d'autres modules soient chargés avant eux pour fonctionner. Cette information est inscrite dans ces fichiers.
Comment trouver les modules
Certains modules du noyau gèrent certains types de matériel (NdT : ce sont les pilotes de matériel), comme mon module « emu10k1 » qui contrôle ma carte SoundBlaster Audigy. Pour ce type de module, ces fichiers contiennent aussi les identifiants PCI ou un équivalent permettant d'identifier les différents matériels qu'ils gèrent. Ces informations peuvent être utilisées par exemple par les scripts « hotplug » (que nous verrons dans un autre tutoriel) pour détecter automatiquement le matériel et charger le bon module pour ce matériel.
Utiliser depmod
Si vous installez ne serait-ce qu'un nouveau module, les informations de dépendance risquent d'être obsolètes. Pour les rafraîchir, tapez tout simplement depmod -a. La commande depmod va parcourir tous les modules de vos répertoires dans /lib/modules et mettre à jour les informations de dépendance. Cela se fait en parcourant les fichiers modules dans /lib/modules et en analysant les « symboles » à l'intérieur des modules.
Localiser les modules du noyau
Alors, ces modules, ils ressemblent à quoi ? Pour les noyaux 2.4, ce sont typiquement n'importe quel fichier dans l'arborescence /lib/modules avec une extension en « .o ». Pour voir tous les modules dans /lib/modules, tapez la commande suivante :
# find /lib/modules -name '*.o' /lib/modules/2.4.20-gaming-r1/misc/vmmon.o /lib/modules/2.4.20-gaming-r1/misc/vmnet.o /lib/modules/2.4.20-gaming-r1/video/nvidia.o /lib/modules/2.4.20-gaming-r1/kernel/fs/fat/fat.o /lib/modules/2.4.20-gaming-r1/kernel/fs/vfat/vfat.o /lib/modules/2.4.20-gaming-r1/kernel/fs/minix/minix.o [liste coupée pour faire bref]
NdT : pour les noyaux en 2.6.x, l'extension des modules est « .ko »
insmod face à modprobe
Alors, comment on charge un module dans le noyau (celui qui tourne actuellement) ? Vous pouvez utiliser la commande insmod et spécifier le chemin complet pour le module que vous souhaitez charger :
# insmod /lib/modules/2.4.20-gaming-r1/kernel/fs/fat/fat.o # lsmod | grep fat fat 29272 0 (unused)
Cependant, on utilise habituellement la commande modprobe pour charger les modules. Un des avantages de modprobe est qu'il va s'occuper de charger automatiquement les modules dont dépend le notre. De plus, on n'a plus besoin d'indiquer le chemin vers le module que nous souhaitons charger, ni de mettre l'extension « .o ».
rmmod et modprobe à l'oeuvre
Déchargeons notre module « fat.o » et rechargeons-le en utilisant modprobe :
# rmmod fat # lsmod | grep fat # modprobe fat # lsmod | grep fat fat
Comme vous pouvez le voir, la commande rmmod fonctionne comme modprobe, mais a l'effet inverse : elle décharge le module que vous lui indiquez.
Vos amis modinfo et modules.conf
Vous pouvez utiliser la commande modinfo pour apprendre plein de choses intéressantes sur vos modules préférés :
# modinfo fat filename: /lib/modules/2.4.20-gaming-r1/kernel/fs/fat/fat.o description: <none> author: <none> license: "GPL"
Regardez tout spécialement le fichier /etc/modules.conf. Ce fichier contient les informations de configuration pour modprobe. Il vous permet de modifier le fonctionnement de modprobe en lui disant de charger des modules avant ou après les uns les autres, lancer des scripts avant ou après le chargement d'un module etc.
modules.conf : à savoir
La syntaxe et le fonctionnement de modules.conf est assez compliqué et nous n'allons pas entrer dans sa syntaxe (tapez man modules.conf pour tous les détails croustillants – traduction encore une fois assez libre), mais il y a quelques points que vous devriez savoir à propos de ce fichier.
La chose la plus importante, c'est que de nombreuses distributions génèrent ce fichier à partir d'un ensemble de fichiers dans un autre répertoire, comme /etc/modules.d/. Par exemple, Gentoo Linux utilise un répertoire /etc/modules.d/, et la commande update-modules va prendre tous les fichiers de /etc/modules.d/ et les concaténer pour créer un tout nouveau /etc/modules.conf. Maintenant que vous le savez, modifiez les fichiers de /etc/modules.d/ et lancez update-modules si vous utilisez Gentoo. Si vous utilisez Debian, la procédure est équivalente à ceci près que le répertoire est nommé /etc/modutils/ (NdT : il y a aussi un /etc/modprobe.d/ depuis l'apparition du noyau 2.6).
Résumé et ressources
Résumé
Félicitations, vous avez atteint la fin de ce tutoriel sur l'administration de base sur Linux ! Nous espérons qu'il vous a aidé à asseoir vos connaissances fondamentales sur Linux. Rejoignez-nous dans notre prochain tutoriel qui couvre l'administration intermédiaire qui se basera sur ce que nous venons d'apprendre, et qui explore des thèmes comme le modèle de permissions et de propriété, la gestion des comptes utilisateurs, la création et le montage de systèmes de fichiers, etc. Rappelez-vous qu'en suivant cette série de tutoriels vous serez bientôt prêt à obtenir votre Certification LPI de niveau 1.
Ressources
Si vous souhaitez préparer la certification LPIC, nous vous recommandons d'étudier les ressource suivantes. Elles ont été sélectionnées avec soin pour vous permettre d'améliorer les connaissances acquises dans ce tutoriel.
Il y a un certain nombre de bonnes ressources sur les expressions rationnelles sur internet. En voici deux que nous avons trouvé :
Vous devriez aussi parcourir le FileSystem Hierarchy Standard : http://www.pathname.com/fhs/
Dans la série d'article sur Bash par l'exemple, je vous montre comment construire vos propres scripts Bash. Cette série (particulièrement les parties un et deux) sont une bonne préparation pour l'examen LPIC niveau 1.
Vous pouvez en apprendre plus sur sed dans ces articles sur IBM developerWorks. Si vous préparez l'examen, étudiez au moins le premier des deux articles de cette série.
Pour en apprendre plus sur awk, lisez cet article sur IBM developerWorks.
Nous recommandons vivement la FAQ technique pour les utilisateurs de Linux, une liste de 50 pages de questions fréquemment posées avec leurs réponses détaillées. La FAQ est au format PDF. Si vous êtes débutant ou d'un niveau moyen, vous devriez vraiment la consulter.
Si vous n'êtes pas tellement familier de l'éditeur vi, je vous recommande également de consulter mon tutoriel : Vi, la méthode accélérée (traduction pas bonne du tout). Cet article vous donnera une introduction rapide et en douceur à cet éditeur puissant. Considérez que vous devez le consulter si vous ne savez pas utiliser vi.
