De la mise sous tension à la ligne de commande de Bash <AUTHOR>Greg O'Keefe, <tt>gcokeefe@postoffice.utas.edu.au</tt> <DATE>v0.7, April 2000 <ABSTRACT> Voici une description rapide de ce qui se passe dans un système Linux, depuis l'instant où vous mettez celui-ci sous tension, jusqu'au moment où vous vous loguez et obtenez la ligne de commande de bash (NDT : Bourne Again SHell). Ce document est organisé "par lots" pour faciliter la tâche des gens qui veulent mettre en place un système à partir du code source. Comprendre cela vous sera très utile lorsque vous aurez besoin de résoudre des problèmes ou de configurer votre système (version française par Dominique van den Broeck, Mai 2000, <tt><URL URL="mailto:dvandenbroeck@free.fr" NAME="dvandenbroeck@free.fr"></tt>). </ABSTRACT> <TOC> <SECT>Introduction Je trouve frustrant qu'il se passe dans ma machine Linux des choses que je ne comprends pas. Si, comme moi, vous souhaitez vraiment comprendre votre système plutôt que simplement savoir comment l'utiliser, ce document devrait être un bon point de départ. Ce genre de "connaissance de fond" est aussi requis si vous voulez devenir un as de la résolution de problèmes sous Linux. Je pars du principe que vous avez une machine Linux en état de marche, et que vous maîtrisez les bases d'Unix et de l'architecture matérielle des PC. Si ce n'est pas le cas, <URL URL="http://www.linuxdoc.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO.html" NAME ="The Unix and Internet Fundamentals HOWTO" > ("Les notions fondamentales d'Unix et Internet", miroirs français en <URL URL="http://www.linuxfr.org/LDP/HOWTO/Unix-and-Internet-Fundamentals-HOWTO.html" NAME="VO"> et <URL URL="http://www.freenix.org/unix/linux/HOWTO/Unix-Internet-Fundamentals-HOWTO.html" NAME="VF">) est un excellent endroit pour débuter. C'est un site concis, lisible, et qui couvre toutes les bases. Le sujet principal de ce document est la façon dont Linux démarre. Mais il se veut également être une ressource d'apprentissage plus large. J'ai inclus des exercices dans chaque section. Si vous en faites vraiment quelques uns, vous apprendrez bien plus qu'en vous contentant de lire ce document. Il y a aussi des liens vers du code source à télécharger, car j'espère que certains lecteurs s'attaqueront au meilleur exercice d'apprentissage de Linux que je connaisse : construire un système à partir du code source. Giambattista Vico, un philosophe italien (1668-1744) disait ``verum ipsum factum'' ce qui signifie "la compréhension découle de l'expérience" (NDT : Traduction libre). Merci à Alex (voir <REF ID="acknowledge" NAME="Remerciements">) pour cette citation. Si vous souhaitez vous "la rouler vous-même", je vous conseille d'aller voir <URL URL="http://www.linuxfromscratch.org" NAME="Linux From Scratch HOWTO"> (LFS soit "Linux depuis zéro"). LFS fournit des instructions détaillées pour bâtir un système complet et exploitable à partir du code source. Sur le site web de LFS, vous trouverez aussi une mailing-list (liste de diffusion) à disposition des personnes qui construisent de tels systèmes. Ce que j'ai inclus dans ce document, ce sont des instructions pour construire un système "jouet", (voir <REF ID="building" NAME="Bâtir un système Linux minimal à partir des sources">) purement pour l'exercice. Les lots (NDT : "packages" en anglais et repris ci-après) sont présentés dans l'ordre où ils apparaissent dans le processus de démarrage du système. Cela signifie que si vous installez les packages dans cet ordre vous pouvez redémarrer après chaque installation, et voir à chaque fois le système se rapprocher petit à petit de l'état où il vous donnera la ligne de commande. Il y a une notion de progression rassurante dans cela. Je vous recommande de commencer par lire le texte principal de chaque section, en ignorant les exercices et références, puis de décider du point jusqu'auquel vous souhaitez comprendre votre système. Reprenez alors depuis le début, en faisant les exercices et en relisant en détail. <SECT>Partie matérielle (Hardware) Lorsque vous allumez votre ordinateur, celui-ci se teste lui-même pour s'assurer que tous ses composants sont en état de marche. Cela s'appelle le ``Power On Self Test'' (POST ou Auto-Test à l'Allumage). Ensuite, un programme nommé Bootstrap loader (Chargeur de boot), situé dans le BIOS en ROM, recherche un secteur de boot, ou secteur d'amorce. Un secteur d'amorce est le premier secteur d'un disque et contient un petit programme capable de charger un système d'exploitation. Les secteurs d'amorce sont marqués par un ``nombre magique'' (valeur fixe caractéristique) 0xAA55 = 43603 à l'octet 0x1FE = 510. Ce sont les deux derniers octets du secteur. C'est de cette façon que l'électronique peut déterminer s'il s'agit d'un secteur d'amorce ou pas. Le bootstrap loader a une liste d'endroits où chercher un secteur d'amorce. Ma vieille machine regarde d'abord sur le lecteur de disquette, puis sur le disque dur. Les machines modernes peuvent aussi rechercher un secteur d'amorce sur un CD-ROM. S'il trouve un secteur amorçable ("bootable"), il le charge en mémoire et passe ainsi le contrôle au programme qui charge le système d'exploitation en mémoire. Sur un système Linux typique, ce programme sera la première étape du chargeur de LILO. Il existe malgré tout plusieurs manières différentes de faire démarrer ("booter") votre système. Voir le Guide de l'utilisateur de LILO pour plus de détails. Voir la section <REF ID="lilo-links" NAME="LILO"> pour l'URL. Evidement, il y a bien plus à dire sur ce que fait le hardware du PC. Mais ce n'est pas l'objet de ce document. Lisez un des nombreux livres traitant de l'architecture matérielle du PC. <SECT1>Configuration La machine stocke des informations sur son propre état dans son CMOS. Cela inclut la RAM et les types de disques installés dans le système. Le BIOS de la machine contient un programme, Setup, qui vous permet de modifier ces informations. Pour savoir comment y accéder, regardez attentivement les messages qui apparaissent sur votre écran lorsque vous mettez votre machine sous tension. Sur ma machine, il faut appuyer sur la touche DEL (Suppr) avant qu'elle ne commence à charger le système d'exploitation. <SECT1>Exercices <LABEL ID="hardware-ex"> Une bonne façon d'en apprendre plus sur le hardware d'un PC est de monter une machine à partir de composants d'occasion. Prenez au moins un 386 pour pouvoir y installer Linux facilement. Cela ne vous coûtera pas très cher. Posez la question autour de vous, quelqu'un pourrait bien vous donner une partie des pièces qu'il vous faut. Allez voir <URL URL="http://learning.taslug.org.au/resources" NAME=Unios>, (Ils avaient une page sur <URL URL="http://www.unios.org">, mais elle a disparu) et téléchargez, compilez et fabriquez votre disquette bootable. Ce n'est qu'un programme bootable affichant ``Hello World!'', contenant à peine plus de 100 lignes d'assembleur. Il serait intéressant de voir à le convertir en un format exploitable par l'assembleur GNU <TT>as</TT>. Ouvrez l'image de la disquette bootable pour unios avec un éditeur hexadécimal. Cette image fait 512 octets de long. Exactement la longueur d'un secteur. Trouvez-y le nombre magique 0xAA55. Faites la même chose pour une disquette bootable de votre propre ordinateur. Vous pouvez utiliser la commande <TT>dd</TT> pour la copier dans un fichier : <TT>dd if=/dev/fd0 of=boot.sector</TT>. Faites très attention à paramétrer <TT>if</TT> (fichier source) et <TT>of</TT> (fichier destination) comme il faut ! Essayez d'en extraire le code source du chargeur de LILO. <SECT1>Plus d'informations. <ITEMIZE> <ITEM> <URL URL="http://www.linuxdoc.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO.html" NAME="Les notions fondamentales d'Unix et d'Internet">, par Eric S. Raymond, miroirs français en <URL URL="http://www.linuxfr.org/LDP/HOWTO/Unix-and-Internet-Fundamentals-HOWTO.html" NAME="VO"> et <URL URL="http://www.freenix.org/unix/linux/HOWTO/Unix-Internet-Fundamentals-HOWTO.html" NAME="VF">, et particulièrement la section 3, Que se passe-t-il lorsque vous allumez un ordinateur ? <ITEM>Le premier chapitre du Guide de l'utilisateur de LILO donne une excellente explication des partitions de disques sur PC et de l'amorçage (booting). Voir la section <REF ID="lilo-links" NAME="LILO"> pour l'URL. <ITEM>Le NOUVEAU Peter Norton Programmer's Guide to the IBM PC & PS/2 (Guide Peter Norton du programmeur pour l'IBM PC et PS/2), par Peter Norton et Richard Wilton, Microsoft Press, 1988. Il existe un nouveau livre Norton, qui a l'air bien, mais que je ne peux m'offrir pour le moment. <ITEM>Un des nombreux ouvrages disponibles sur la manière de faire évoluer (upgrader) son PC. </ITEMIZE> <SECT>Lilo Lorsque l'ordinateur charge le secteur d'amorce d'un système sous Linux normal, ce qu'il charge est en fait un partie de LILO, appelée "first stage boot loader" (chargeur de boot de premier niveau). Il s'agit d'un mini programme dont la seule tâche est de charger et d'exécuter le ``second stage boot loader'' (chargeur de boot de deuxième niveau). Le "second stage loader" vous donne une invite de commande (s'il a été installé de cette manière) et charge le système d'exploitation de votre choix. Lorsque votre système est monté et en état de marche, et que vous exécutez <TT>lilo</TT>, ce que vous exécutez en réalité est le ``map installer''. Celui-ci lit le fichier de configuration <TT>/etc/lilo.conf</TT> et écrit le chargeur de boot sur le disque dur, avec les informations concernant les systèmes d'exploitation qu'il peut charger. Il y a de nombreuses manières de rendre votre système bootable. Celle que je viens de décrire est la manière la plus évidente et ``normale'', au moins pour une machine dont le système d'exploitation principal est Linux. Le Guide de l'Utilisateur Lilo explique plusieurs exemples de ``boot concepts''. Cela vaut la peine de les lire, et d'en essayer quelques uns. <SECT1>Configuration Le fichier de configuration de Lilo est <TT>/etc/lilo.conf</TT>. Il existe une page de manuel (man page) à son sujet : tapez <TT>man lilo.conf</TT> dans un shell pour l'afficher. La principale caractéristique de <TT>lilo.conf</TT> est qu'il existe une entrée pour chaque chose que Lilo doit booter. Pour une entrée Linux, cela inclut l'endroit où se trouve le kernel, et la partition à monter à la racine du système de fichier (``filesystem''). Pour les autres systèmes, la principale information est la partition sur laquelle booter. <SECT1>Exercices DANGER : soyez prudent avec ces exercices. Il est assez facile de faire une erreur quelque part et de bloquer votre "master boot record" (NDT : ou MBR, premier secteur du disque dur, contient le bootloader et la table des partitions) et de rendre ainsi votre système inutilisable. Assurez-vous que vous avez une disquette de réparation qui fonctionne, et que vous savez comment vous en servir pour remettre les choses en état. Voir plus bas un lien vers tomsrtbt, la disquette de réparation que j'utilise et recommande. La meilleure des précautions est d'utiliser une machine qui ne contienne pas de données sensibles. Installez Lilo sur une disquette. Peu importe s'il n'y a rien d'autre sur la disquette que le kernel - vous obtiendrez un "kernel panic" quand le kernel sera prêt a charger init, mais au moins vous saurez que Lilo fonctionne. Si vous le souhaitez, vous pouvez essayer de voir jusqu'à quel point vous pouvez faire tenir un système sur une disquette. C'est sûrement la deuxième meilleure activité pour apprendre Linux. Voir le Bootdisk HOWTO (url plus bas), et tomsrtbt (url plus bas) pour avoir des pistes. Configurez Lilo afin qu'il lance unios (voir section <REF ID="hardware-ex" NAME="exercices hardware"> pour une URL). Comme défi supplémentaire, voyez si vous pouvez le faire sur une disquette. Faites une boucle de boots. Configurez le Lilo du Master Boot Record pour qu'il boote le Lilo du secteur de boot d'une des partitions principales, puis configurez ce Lilo pour qu'il relance celui du MBR. Ou alors utilisez le MBR et vos quatre partitions principales pour faire une boucle en cinq points ! Marrant ! <SECT1>Plus d'informations <LABEL ID="lilo-links"> <ITEMIZE> <ITEM>La page de man de Lilo <ITEM>Le package Lilo (voir <REF ID="downloads" NAME="downloads">) contient le ``LILO User's Guide'' <TT>lilo-u-21.ps.gz</TT> (ou plus récent). Il se peut que vous ayez quand même déjà ce document. Regardez dans <TT>/usr/doc/lilo</TT> ou approché. La version postscript est meilleure que la version en texte brut, car elle contient des diagrammes et des tables. <ITEM><URL URL="http://www.toms.net/rb" NAME="tomsrtbt"> La disquette unique linux la plus cool ! Constitue une excellente disquette de secours. <ITEM><URL URL="http://www.linuxdoc.org/HOWTO/Bootdisk-HOWTO/" NAME="Bootdisk-HOWTO"> ("HOWTO Disquette-de-boot", miroirs français en <URL URL="http://www.linuxfr.org/LDP/HOWTO/Bootdisk-HOWTO" NAME="VO"> et <URL URL="http://www.freenix.org/unix/linux/HOWTO/Bootdisk-HOWTO.html" NAME="VF">. </ITEMIZE> <SECT>Le noyau Linux Le noyau (kernel) fait vraiment beaucoup de choses. Je pense qu'une bonne manière de résumer tout cela est de dire qu'il fait faire au hardware ce que les programmes veulent, proprement et efficacement. Le processeur ne peut exécuter qu'une seule instruction à la fois, mais Linux semble faire tourner beaucoup de choses simultanément. Le noyau accomplit cela en sautant de tâche en tâche très rapidement. Il fait le meilleur usage possible du processeur en gardant trace des processus qui sont prêts à être exécutés et de ceux qui attendent quelque chose comme un enregistrement en provenance d'un disque, ou une saisie clavier quelquonque. Cette tâche du noyau est appelée "scheduling" (planification). Si un programme ne fait rien, alors il n'a pas besoin d'être en RAM. Même un programme qui fait quelque chose peut avoir certaines parties inactives, qui donc n'ont pas besoin d'être en RAM. L'espace adressable est divisé en pages. Le noyau garde une trace des pages les plus utilisées. Les pages qui ne sont pas autant utilisées peuvent être déplacées dans la partition d'échange (swap). Lorsqu'une page est à nouveau sollicitée, une autre page inutilisée est retirée de l'espace adressable pour lui faire de la place. Cela s'appelle la gestion de la mémoire virtuelle. Si vous avez un jour compilé votre propre noyau, vous avez remarqué qu'il y a un grand nombre d'options pour des périphériques spécifiques. Le noyau contient beaucoup de code spécifique pour converser avec l'électronique de tout type, et les présente d'une façon propre et uniforme aux programmes applicatifs. Le noyau prend aussi en charge la gestion des fichiers, les communications interprocessus, et beaucoup du travail concernant le réseau. Une fois le noyau chargé, la première chose qu'il fait est de rechercher un programme appelé <TT>init</TT> et l'exécuter. <SECT1>Configuration La majorité de la configuration du noyau est effectuée quand vous le construisez, en utilisant <TT>make menuconfig</TT>, ou <TT>make xconfig</TT> dans le répertoire <TT>/usr/src/linux/</TT> (ou là ou se trouvent les sources de votre noyau Linux). Vous pouvez réinitialiser le mode vidéo par défaut, la racine du système de fichiers, le périphérique de swap et la taille du disque virtuel (RAM disk) en utilisant <TT>rdev</TT>. Ces paramètres ainsi que d'autres peuvent aussi être passés au noyau depuis Lilo. Vous pouvez indiquer à Lilo les paramètres à passer au noyau soit dans lilo.conf, soit à l'invite (prompt) de Lilo. Par exemple, si vous souhaitiez utiliser hda3 comme racine du système de fichiers plutôt que hda2, vous pourriez taper : <VERB> LILO: linux root=/dev/hda3 </VERB> Si vous mettez en place un système à partir de ses sources, vous pouvez vous simplifier la vie en créant un noyau "monolithique", c'est-à-dire sans module. Vous n'aurez donc pas à copier ceux-ci sur le système cible. NOTE : Le fichier <TT>System.map</TT> est utilisé par le logger (le journal système, qui enregistre les messages de service) du noyau pour déterminer les noms des modules générant des messages. Le programme <TT>top</TT> utilise également ces informations. Lorsque vous copiez le noyau vers un système cible, copiez aussi <TT>System.map</TT>. <SECT1>Exercices Réfléchissez à ceci : <TT>/dev/hda3</TT> est un type de fichier spécial qui décrit une partition d'un disque dur. Mais il vit sur le système de fichiers comme tous les autres fichiers. Le noyau veut savoir quelle partition monter à la racine - donc il n'a pas encore de système de fichiers. Alors comme peut-il lire <TT>/dev/hda3</TT> pour trouver la partition à monter ? Si vous ne l'avez pas encore fait, compilez votre noyau. Lisez l'aide (Help) pour chaque option. Essayez de voir jusqu'à quel point vous pouvez réduire la taille de votre noyau avant qu'il ne cesse de fonctionner. Vous pouvez apprendre beaucoup en écartant les parties qui ne sont pas nécessaires. Lisez ``The Linux Kernel'' (URL plus bas) et ce faisant, trouvez les parties du source auxquelles il se réfère. Le livre (au moment où j'écris ces lignes) se réfère au noyau version 2.0.33, qui devient franchement dépassé. Il pourrait être plus facile de suivre si vous téléchargiez cette ancienne version et y lisiez le source. Il est très excitant de trouver des morceaux de code C appelés ``process'' et ``page''. Programmez ! Faites des essais ! Voyez si vous pouvez faire cracher au noyau des messages supplémentaires ou quelque chose du même genre. <SECT1>Plus d'informations <LABEL ID="Kernel"> <ITEMIZE> <ITEM><TT>/usr/src/linux/README</TT> et le contenu de <TT>/usr/src/linux/Documentation/</TT> (Ces emplacements peuvent varier sur votre système) <ITEM> Le <URL URL="http://mirror.aarnet.edu.au/linux/LDP/HOWTO/Kernel-HOWTO.html" NAME="Kernel-HOWTO"> (miroirs français en <URL URL="http://www.linuxfr.org/LDP/HOWTO/Kernel-HOWTO.html" NAME="VO"> et <URL URL="http://www.freenix.org/unix/linux/HOWTO/Kernel-HOWTO.html" NAME="VF">). <ITEM>L'aide disponible quand vous configurez un noyau en utilisant <TT>make menuconfig</TT> ou <TT>make xconfig</TT> <ITEM> <URL URL="http://mirror.aarnet.edu.au/linux/LDP/LDP/" NAME="The Linux Kernel (et autres guides du LDP)"> (miroir français en <URL URL="http://www.linuxfr.org/LDP/LDP" NAME="VO">) <ITEM> Téléchargement des sources voir <REF ID="downloads" NAME="téléchargements"> </ITEMIZE> <SECT>La bibliothèque C de GNU L'étape suivante qui se produit au démarrage de votre ordinateur est le chargement d'init et son exécution. Cependant, init, comme la plupart des programmes, utilise des fonctions issues de bibliothèques. Vous avez peut-être déjà vu un exemple de programme C comme celui-ci : <VERB> main() { printf("Hello World!\n"); } </VERB> Le programme ne définit nullement <TT>printf</TT>, alors d'où vient-il ? Il provient des bibliothèques C standard ("standard C libraries"), sur un système GNU/Linux, glibc. Si vous les compilez sous Visual C++, alors il provient d'une implémentation Microsoft de ces mêmes fonctions standard. Il existe des milliers de ces fonctions standard, pour les mathématiques (math), la gestion des chaînes de caractères (string), l'heure et la date, l'allocation de mémoire et ainsi de suite. Tout, dans Unix (y compris Linux) est soit écrit en C, soit tente de le simuler, de sorte que tous les programmes utilisent ces fonctions. Si vous jetez un oeil dans <TT>/lib</TT> sur votre système Linux, vous verrez un grand nombre de fichiers appelés <TT>libquelquechose.so</TT> ou <TT>libquelquechose.a</TT> etc. Ce sont les bibliothèques de ces fonctions. Glibc est simplement l'implémentation GNU de ces fonctions. Les programmes peuvent utiliser ces fonctions de deux manières. si vous "linkez" (NDT : "éditez les liens", opération qui consiste à établir les relations avec les différents objets sollicités par le programme, puis à créer l'exécutable) statiquement, ces fonctions seront copiées à l'intérieur de l'exécutable généré. C'est à ça que servent les bibliothèques <TT>libquelquechose.a</TT>. Si vous linkez votre programme dynamiquement (effectué par défaut), lorsque le programme aura besoin du code d'une bibliothèque, il ira l'extraire directement du fichier <TT>libquelquechose.so</TT> La commande <TT>ldd</TT> vous apporte une aide précieuse lorsque vous cherchez à retrouver les bibliothèques utilisées par un programme particulier. Par exemple, voici les bibliothèques utilisées par <TT>bash</TT>: <VERB> [greg@Curry power2bash]$ ldd /bin/bash libtermcap.so.2 => /lib/libtermcap.so.2 (0x40019000) libc.so.6 => /lib/libc.so.6 (0x4001d000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) </VERB> <SECT1>Configuration Certaines fonctions, dans leur bibliothèque, dépendent du lieu où vous vous trouvez. Par exemple, en français, on écrit les dates sous la forme dd/mm/yy, mais les américains les écrivent mm/dd/yy. Il existe un programme livré avec <TT>glibc</TT> appelé <TT>localdef</TT> qui vous donne la possibilité de définir cela. <SECT1>Exercices Utilisez <TT>ldd</TT> pour déterminer les bibliothèques qu'utilise votre application préférée. Utilisez <TT>ldd</TT> pour déterminer les bibliothèques utilisées par <TT>init</TT>. Créez une bibliothèque gadget, avec seulement une ou deux fonctions dedans. On utilise le programme <TT>ar</TT> pour les créer. La page de manuel d'<TT>ar</TT> pourrait être un bon point de départ pour commencer à enquêter sur la manière dont cette opération est effectuée. Ecrivez, compilez, et linkez un programme utilisant cette bibliothèque. <SECT1>Plus d'informations <ITEMIZE> <ITEM>Code source, voir la section <REF ID="downloads" NAME="téléchargements"> </ITEMIZE> <SECT>Init Je ne parlerai que du style d'initialisation ``System V'' que les systèmes Linux utilisent le plus souvent. Il existe des alternatives. En fait, vous pouvez mettre n'importe quel programme dans <TT>/sbin/init</TT>, que le noyau exécutera lorsqu'il aura fini de se charger. Le travail d'<TT>init</TT> est de faire en sorte que tout se lance comme il faut. Il vérifie que les systèmes de fichier sont en bon état et les monte. Il démarre les démons (``daemons'') qui enregistrent les messages système, gèrent le réseau, distribuent les pages web, écoutent les signaux de la souris, etc. Init démarre aussi les processus <TT>getty</TT> qui vous donnent l'invite de login sur vos terminaux virtuels. Il y a un processus compliqué concernant le changement de niveau d'exécution ("run-levels"), mais je vais sauter tout ça, et ne parler que du démarrage du système. Init lit le fichier <TT>/etc/inittab</TT>, qui lui dit quoi faire. Typiquement, la première chose demandée est l'exécution d'un script d'initialisation. Le programme qui exécute (ou interprète) ce script est <TT>bash</TT>, le même programme qui vous donne la ligne de commande. Sur les systèmes Debian, le script d'initialisation est <TT>/etc/init.d/rcS</TT>, sur Red Hat, <TT>/etc/rc.d/rc.sysinit</TT>. C'est là que les systèmes de fichiers sont vérifiés puis montés, l'horloge mise à l'heure, le fichier ou la partition d'échange (swap) activés, les noms de machines définis, etc. Ensuite, un autre script est invoqué pour nous placer dans le niveau d'exécution par défaut. Cela implique simplement le démarrage d'un ensemble de sous-systèmes. Il existe un ensemble de sous-répertoires <TT>/etc/rc.d/rc0.d</TT>, <TT>/etc/rc.d/rc1.d</TT>, ..., <TT>/etc/rc.d/rc6.d</TT> sous Red Hat, ou <TT>/etc/rc0.d</TT>, <TT>/etc/rc1.d</TT>, ..., <TT>/etc/rc6.d</TT> sous Debian, correspondant aux run-levels. Si nous entrons dans le niveau d'exécution 3 sur un système Debian, le script exécute tous les scripts de <TT>/etc/rc3.d</TT> commençant par `S' (pour Start). Ces scripts sont en réalité des liens vers un autre répertoire appelé généralement <TT>init.d</TT>. Donc, le script de notre niveau d'exécution est appelé par <TT>init</TT>, et recherche dans un répertoire des scripts dont le nom débute par la lettre `S'. Il se peut qu'il tombe sur <TT>S10syslog</TT> en premier. Les chiffres indiquent au script du niveau l'ordre dans lequel il doit les lancer. En l'occurence, <TT>S10syslog</TT> est lancé en premier parce qu'il n'y pas de script commençant par S00 ... S09. Mais S10syslog est en fait un lien vers <TT>/etc/init.d/syslog</TT> qui est un script chargé du démarrage et de l'arrêt du system logger (enregistreur de messages systèmes). Parce que le lien commence par un `S', le script du run-level sait qu'il doit exécuter le script <TT>syslog</TT> avec le paramètre "start". Il y a aussi des liens dont le nom débute par `K' (pour Kill), qui spécifient ce qu'il faut arrêter, et dans quel ordre, lorsque l'on entre dans le niveau d'exécution.  Pour changer ce que le sous-système lance par défaut, vous devez configurer ces liens dans le répertoire <TT>rcN.d</TT>, ou N est le niveau d'exécution par défaut défini dans votre fichier <TT>inittab</TT>. La dernière chose importante qu'effectue init est de démarrer les <TT>getty</TT>s [NdRel :en pratique, souvent des <TT>mingetty</TT>s)]. Ceux-ci sont ressuscités (``respawned''), ce qui signifie qu'ils sont automatiquement relancés par <TT>init</TT> s'ils viennent à se terminer. La plupart des distributions fournissent six terminaux virtuels. Il se peut que vous souhaitiez en enlever pour économiser de la mémoire, ou en ajouter pour pouvoir lancer beaucoup de choses à la fois, et passer rapidement de l'un à l'autre. Vous pourriez aussi avoir besoin de lancer un <TT>getty</TT> vers un terminal texte ou vers un modem. Vous devez alors éditer <TT>inittab</TT>. <SECT1>Configuration <TT>/etc/inittab</TT>, qui est le fichier de configuration au sommet de la "hiérarchie" des fichiers de configuration. Les répertoires <TT>rcN.d</TT>, où N = 0, 1,..., 6 détermine les sous-systèmes à lancer. Quelque part dans les scripts invoqués par init, se trouve la commande <TT>mount -a</TT>. Cela signifie : "Monte tous les systèmes de fichiers censés être montés". Le fichier <TT>/etc/fstab</TT> définit ce qui est censé être monté. Si vous souhaitez changer ce qui est monté par défaut au démarrage, c'est le fichier que vous devez modifier. Il existe une page de manuel pour <TT>fstab</TT>. <SECT1>Exercices Trouvez le répertoire <TT>rcN.d</TT> du niveau d'exécution par défaut de votre système puis faites un <TT>ls -l</TT> pour voir les fichiers pointés par les liens. Changez le nombre de gettys tournant sur votre système. Retirez tous les sous-systèmes dont vous n'avez pas besoin de votre niveau d'exécution par défaut. Essayez de déterminer le minimum nécessaire pour démarrer. Fabriquez une disquette avec Lilo, un noyau et un programme statique affichant "Bonjour tout le monde !" nommé <TT>/sbin/init</TT>, puis regardez-la démarrer et dire bonjour. Regardez attentivement votre système démarrer, et notez les événements signalés. Ou imprimez une section de votre journal système <TT>/var/log/messages</TT> à partir du moment où votre système a démarré. Ensuite, en partant d'<TT>inittab</TT>, explorez tous les scripts et essayez de voir quel code fait quoi. Vous pouvez également ajouter des messages, comme <VERB> echo "Hello, moi c'est rc.sysinit" </VERB> C'est aussi un bon exercice pour apprendre le langage de script de Bash, certains scripts étant assez compliqués. Ayez un bon guide de bash à portée de main (NDT : "man bash" devrait suffire, faute de mieux). <SECT1>Plus d'informations. <ITEMIZE> <ITEM>Voir <REF ID="downloads" NAME="téléchargements"> pour télécharger le code source. <ITEM>Il y a des pages de manuel pour les fichiers <TT>inittab</TT> et <TT>fstab</TT>. Tapez (par exemple) <TT>man inittab</TT> dans un shell pour l'afficher. <ITEM>Le Guide de L'Administrateur Système Linux contient une <URL URL="http://mirror.aarnet.edu.au/linux/LDP/LDP/" NAME="section"> intéressante concernant init (miroir français en <URL URL="http://www.linuxfr.org/LDP/LDP" NAME="VO">). </ITEMIZE> <SECT>Le système de fichiers (filesystem) Dans cette section, j'emploierai l'expression ``système de fichiers'' pour deux notions différentes. Il y a les systèmes de fichiers installés sur des partitions de disque ou d'autres périphériques, et il y a le système de fichier (NdRel : la hiérarchie) tel qu'il vous est présenté par un système Linux en état de marche. Sous Linux, vous "montez" le système de fichiers d'un disque sur le système de fichiers du système. Dans la section précédente, j'ai mentionné le fait que des scripts d'initialisation vérifiaient et montaient les systèmes de fichiers. Les commandes qui effectuent ces opérations sont respectivement <TT>fsck</TT> et <TT>mount</TT>. Un disque dur n'est qu'un grand espace dans lequel vous pouvez écrire des zéros et des uns. Un système de fichiers impose une structure à tout cela, et le présente sous la forme de fichiers, à l'intérieur de sous-répertoires, à l'intérieur de répertoires... Chaque fichier est répresenté par un inode, indiquant le fichier dont il s'agit, la date de sa création, et où trouver son contenu. Les répertoires sont aussi représentés par des inodes, mais ceux-ci indiquent où trouver les inodes des fichiers que les repértoires contiennent. Si le système veut lire <TT>/home/greg/bigboobs.jpeg</TT>, il commence par lire l'inode du répertoire racine <TT>/</TT> dans le ``superblock'', puis trouve l'inode du répertoire <TT>home</TT> dans le contenu de <TT>/</TT>, puis trouve l'inode du répertoire <TT>greg</TT> dans le contenu de <TT>home</TT>, et enfin l'inode de <TT>bigboobs.jpeg</TT> qui lui dira quel bloc du disque il faut lire. Si nous ajoutons des données à la fin d'un fichier, il peut arriver que les données soient écrites avant que l'inode ne soit mis à jour (indiquant que le nouveau bloc appartient désormais au fichier), ou vice-versa. Si le courant est coupé à cet instant précis, le système de fichiers sera "cassé". C'est ce genre de chose que <TT>fsck</TT> essaie de détecter et de réparer. La commande mount prend le système de fichiers d'un périphérique, et l'ajoute à la hiérarchie de fichiers de votre système. En général le noyau monte son système de fichiers racine en lecture seule (read-only). La commande mount est ensuite utilisée pour le remonter en lecture-écriture (read-write) après que fsck ait vérifié que tout soit en ordre. Linux prend aussi en charge d'autres types de systèmes de fichiers : msdos, vfat, minix, etc. Les détails d'un système de fichiers spécifique sont masqués par le Système de Fichier Virtuel (Virtual File System ou VFS) qui est une couche d'abstraction. Je ne rentrerai pas dans ces détails. Il existe une discussion sur ce sujet dans ``Le Kernel Linux'' (voir la section <REF ID="Kernel" NAME="Le Noyau Linux"> pour l'URL) <SECT1>Configuration Il existe des paramètres à la commande <TT>mke2fs</TT>, chargée de la création d'un système de fichiers de type ext2. Ils contrôlent la taille des blocs, le nombre d'inodes, etc. Voir la man page de <TT>mke2fs</TT> pour plus de détails. Ce qui doit être monté sur votre système de fichiers est contrôlé par le fichier <TT>/etc/fstab</TT>, qui a lui aussi sa page de manuel. <SECT1>Exercices Fabriquez un tout petit système de fichiers, et visualisez-le avec un éditeur hexadécimal. Identifiez les inodes, les superblocs, et le contenu des fichiers. Je crois qu'il existe des outils qui vous donnent une vue graphique d'un système de fichiers. Trouvez-en un, essayez-le, et envoyez moi l'url par email avec vos appréciations ! Explorez le code du système de fichiers ext2 dans le noyau. <SECT1>Plus d'informations <ITEMIZE> <ITEM>Le chapitre 9 du livre ``Le noyau linux'' du LDP donne une excellente description des systèmes de fichiers. Vous pouvez le trouver sur le site LDP : miroir <URL URL="http://www.linuxfr.org/LDP/LDP/" NAME="français"> ou <URL URL="http://mirror.aarnet.edu.au/linux/LDP/LDP/" NAME="australien">). <ITEM>La commande <TT>mount</TT> fait partie du package util-linux, il y a un lien vers celui-ci dans <REF ID="downloads" NAME="téléchargements">. <ITEM>Les pages de manuel de <TT>mount</TT>, <TT>fstab</TT>, <TT>fsck</TT> et <TT>mke2fs</TT> <ITEM>La home page des EXT2 File System Utilities <URL URL="http://web.mit.edu/tytso/www/linux/e2fsprogs.html" NAME="ext2fsprogs"> et son miroir australien <URL URL="ftp://mirror.aarnet.edu.au/pub/linux/metalab/system/filesystems/ext2/" NAME="ext2fsprogs">. On y trouve aussi une vue d'ensemble d'Ext2fs, bien qu'elle ne soit plus à jour, et moins lisible que le chapitre 9 du ``Noyau Linux'' <ITEM> <LABEL ID="FHS"> <URL URL="ftp://tsx-11.mit.edu/pub/linux/docs/linux-standards/fsstnd/" NAME="Unix File System Standard"> Un autre <URL URL="http://www.pathname.com/fhs/" NAME="lien"> vers le standard des systèmes de fichiers d'Unix. Ce document décrit où doit se trouver quoi, dans un système Unix, et pourquoi. Il indique aussi le minimum nécessaire à placer dans <TT>/bin</TT>, <TT>/sbin</TT>, etc. C'est une bonne référence si votre objectif est un système minimal mais complet. </ITEMIZE> <SECT>Démons noyau Malheureusement, cette section contient plus de questions et de conjectures que de faits. Peut-être pouvez-vous apporter votre pierre ? Si vous saisissez la commande <TT>ps aux</TT>, vous verrez quelque chose ressemblant à ce qui suit : <VERB> USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND root 1 0.1 8.0 1284 536 ? S 07:37 0:04 init [2] root 2 0.0 0.0 0 0 ? SW 07:37 0:00 (kflushd) root 3 0.0 0.0 0 0 ? SW 07:37 0:00 (kupdate) root 4 0.0 0.0 0 0 ? SW 07:37 0:00 (kpiod) root 5 0.0 0.0 0 0 ? SW 07:37 0:00 (kswapd) root 52 0.0 10.7 1552 716 ? S 07:38 0:01 syslogd -m 0 root 54 0.0 7.1 1276 480 ? S 07:38 0:00 klogd root 56 0.3 17.3 2232 1156 1 S 07:38 0:13 -bash root 57 0.0 7.1 1272 480 2 S 07:38 0:01 /sbin/agetty 38400 tt root 64 0.1 7.2 1272 484 S1 S 08:16 0:01 /sbin/agetty -L ttyS1 root 70 0.0 10.6 1472 708 1 R Sep 11 0:01 ps aux </VERB> C'est une liste de processus en cours d'exécution sur le système. Remarquez que <TT>init</TT> est le processus numéro un. Les processus 2, 3,4 et 5 sont kflushd, kupdate, kpiod et kswapd. Il y a quand même quelque chose d'étrange : dans les deux colonnes de la taille virtuelle de stockage (SIZE) et la taille réelle de stockage (Real Storage Size, RSS), ces processus renvoient zéro. Comment un processus peut-il ne pas utiliser de mémoire ? En réalité, ces processus font partie du noyau. Le noyau, lui, n'apparaît pas du tout sur la liste des processus, et vous ne pouvez définir la mémoire utilisée qu'en soustrayant la mémoire disponible du total installé sur votre système. Les parenthèses autour du nom de commande pourraient signifier qu'il s'agit d'un processus noyau (?) <TT>kswapd</TT> déplace des parties d'un programme non utilisées à un instant donné de l'espace de stockage réel (c'est-à-dire la RAM) vers l'espace de swap (c'est-à-dire le disque dur). <TT>kflushd</TT> écrit les données des buffers vers le disque. Ceci permet aux choses d'aller plus vite. Ce que les programmes écrivent peut être conservé en mémoire, dans un buffer, puis écrit sur le disque par morceaux plus larges et de façon plus efficace (NDT : principe du cache). Je ne sais pas à quoi servent <TT>kupdate</TT> et <TT>kpiod</TT>. C'est ici que finissent mes connaissances. Que font ces deux derniers démons ? Pourquoi les démons noyau ont-ils des numéros de processus explicites plutôt que d'être simplement des bouts de code anonymes ? Est-ce qu'init les lance effectivement, ou tournent-ils déjà lorsque init apparaît ? J'ai mis dans <TT>/sbin/init</TT> un script pour monter <TT>/proc</TT> et faire un <TT>ps aux</TT>. Le processus 1 était le script lui-même, et les processus 2, 3, 4 et 5 étaient les démons noyau, juste au dessous du vrai init. Le noyau les a forcément mis là, car ce n'est sûrement pas mon script qui l'a fait. Les hypothèses suivantes viennent de David Leadbeater : Ces processus semblent s'occuper des accès disque, ils semblent être lancés par le noyau, mais après avoir lancé le processus init. Il semble qu'en étant lancés comme des processus noyau plutôt que comme des processus séparés, ils soient protégés et ne peuvent être tués (kill -9 ne les arrête pas), je ne sais pas vraiment pourquoi ils sont lancés en tant que threads séparés. Il semble y avoir un rapport avec les accès disque. kflushd et kupdate Ces deux processus sont démarrés pour vider les buffers "sales" (c'est-à-dire modifiés) vers le disque. kflushd est lancé quand les buffers sont pleins et kupdate se lance périodiquement (5 secondes ?) pour synchroniser les disques avec les buffers en mémoire. kpiod et kswapd Ils ont pour tâche l'exportation de pages (sections) de mémoire vers le fichier d'échange de façon à ce que la mémoire principale ne soit jamais remplie, ils ressemblent à kflushd et kupdate dans le sens où l'un est lancé en cas de besoin (kpiod) et l'autre (kswapd) est lancé périodiquement (à intervalles d'une seconde). Autres démons du noyau Sur une installation par défaut de RedHat 6, kupdate a disparu mais udpate tourne en tant que démon dans l'espace utilisateur, et il semble qu'il ait besoin d'être lancé. Il y a également un autre démon, mdrecoveryd, qui lui semble d'occuper du RAID. En regardant dans les sources du noyau, il semble que certains pilotes SCSI lancent eux aussi des processus séparés. Je ne connais toujours pas la signification des parenthèses, mais elles semblent apparaître quand la RSS d'un processus est à zéro, ce qui signifie qu'il n'utilise pas de mémoire (?). (fin de citation, merci David) <SECT1>Configuration Je n'ai pas connaissance d'une configuration de ces démons noyau. <SECT1>Exercices Trouvez à quoi servent ces processus, comment ils fonctionnent, et écrivez une nouvelle section `Démons Noyau'' pour ce document, et envoyez-la moi ! <SECT1>Plus d'informations ``Le Kernel Linux'' du Projet de Documentation Linux (LDP). (voir section <REF ID="Kernel" NAME="Le noyau Linux"> pour l'url), et les sources du noyau, c'est tout ce que je vois pour le moment. <SECT>Le journal système (System Logger) Init démarre les démons <TT>syslogd</TT> et <TT>klogd</TT>. Ils écrivent les messages à consigner dans le journal. Les messages du noyau sont pris en main par <TT>klogd</TT>, alors que <TT>syslogd</TT> gère les messages des autres processus. Le fichier journal principal est <TT>/var/log/messages</TT>. C'est un bon endroit où aller voir quand quelque chose tourne mal dans votre système. Vous y trouverez souvent de précieux indices. <SECT1>Configuration Le fichier <TT>/etc/syslog.conf</TT> indique au logger où mettre quels messages. Les messages sont identifiés par le service dont ils proviennent, et leur niveau de priorité. Ce fichier de configuration est constitué de lignes indiquant que les messages du service x avec une priorité y vont vers z, où z est un fichier, un terminal, une imprimante, une machine distante, ou autre chose encore. NOTE : Syslog a besoin que le fichier <TT>/etc/services</TT> existe. Ce fichier alloue des ports (NDT : Ports des protocoles TCP et UDP). Je ne sais pas vraiment si syslog a besoin d'un port réservé pour faire de l'enregistrement de messages à distance, ou si même l'enregistrement local se fait à travers un port, ou même s'il se contente d'utiliser <TT>/etc/services</TT> pour convertir les noms de services indiqués dans <TT>/etc/syslog.conf</TT> en numéros de port. <SECT1>Exercices Jetez un oeil à votre journal système. Prenez un message que vous ne comprenez pas, et essayez de trouver ce qu'il signifie. Redirigez tous les messages du journal vers un terminal. (Revenez à la normale une fois que c'est fait). <SECT1>Plus d'informations Le <URL URL="http://mirror.aarnet.edu.au/pub/linux/metalab/system/daemons/" NAME="miroir"> australien de sysklogd. <SECT>Getty et Login Getty est le programme qui vous permet de vous connecter à travers un périphérique série, comme une console virtuelle, un terminal en mode texte, ou un modem. Il affiche l'invite de login. Une fois que vous avez saisi votre nom d'utilisateur, getty le transmet à <TT>login</TT>, qui vous demande un mot de passe, le vérifie, puis vous donne le shell. Il existe plusieurs getty disponibles. Certaines distributions, comme Red Hat, en utilisent un très petit appelé <TT>mingetty</TT> et qui ne gère que les terminaux virtuels. Le programme <TT>login</TT> fait partie du package util-linux, qui contient aussi un getty nommé <TT>agetty</TT>, qui fonctionne bien. Ce package contient également <TT>mkswap</TT>, <TT>fdisk</TT>, <TT>passwd</TT>, <TT>kill</TT>, <TT>setterm</TT>, <TT>mount</TT>, <TT>swapon</TT>, <TT>rdev</TT>, <TT>renice</TT>, <TT>more</TT> et bien d'autres. <SECT1>Configuration Le message qui apparaît en haut de votre écran avec l'invite de login provient du fichier <TT>/etc/issue</TT>. Les getty sont en général démarrés depuis <TT>/etc/inittab</TT>. Login recherche les détails spécifiques à l'utilisateur dans <TT>/etc/passwd</TT>, et si vous avez le shadowing (une protection des mots de passe), dans <TT>/etc/shadow</TT>. <SECT1>Exercices Créez un fichier <TT>/etc/passwd</TT> à la main. Les mots de passe peuvent être nuls, puis changés avec le programme <TT>passwd</TT> une fois connecté. Voir la page de manuel de ce fichier. Utilisez <TT>man 5 passwd</TT> pour obtenir la page de manuel du fichier plutôt que celle du programme. <SECT>Bash Si vous donnez à <TT>login</TT> une combinaison valide de nom d'utilisateur et de mot de passe, il ira regarder dans <TT>/etc/passwd</TT> pour savoir quel shell vous donner. La plupart du temps, dans un système Linux, ce sera <TT>bash</TT>. Le travail de <TT>bash</TT> consiste à lire vos commandes et voir ce sur quoi elles agissent. C'est à la fois une interface utilisateur, et l'interpréteur d'un langage de programmation. Dans son rôle d'interface, il lit vos commandes, et les exécute lui-même si ces commandes sont ``internes'', comme <TT>cd</TT>, ou bien trouve et exécute un programme s'il s'agit de commandes ``externes'' comme <TT>cp</TT> ou <TT>startx</TT>. Bash propose également plusieurs options fort sympathiques comme un historique des commandes, ou le complètement automatique des noms de fichiers (avec la touche de tabulation). Nous avons déjà vu <TT>bash</TT> à l'action dans son rôle de langage de programmation. Les scripts qu'<TT>init</TT> lance pour démarrer le système sont généralement des scripts shell, et sont exécutés par <TT>bash</TT>. Avoir un langage de programmation propre, parallèlement aux utilitaires systèmes disponibles depuis la ligne de commande forme une combinaison très puissante, si vous savez ce que vous faites. Par exemple ("séquence frime" !) j'ai eu besoin l'autre jour d'appliquer une pile entière de correctifs (patches) à un répertoire de codes source. J'ai été capable de le faire en une seule commande, la suivante : <VERB> for f in /home/greg/sh-utils-1.16*.patch; do patch -p0 < $f; done; </VERB> Ceci recherche tous les fichiers de mon répertoire personnel dont les noms commencent par <TT>sh-utils-1.16</TT> et finissent par <TT>.patch</TT>, puis affecte un par un ces noms à la variable <TT>f</TT> et exécute les commandes invoquées entre <TT>do</TT> et <TT>done</TT>. Il y avait en l'occurence 11 correctifs, mais il aurait pu aussi bien y en avoir 3000. <SECT1>Configuration Le fichier <TT>/etc/profile</TT> agit sur le comportement de bash au niveau du système entier. Ce que vous mettez dans ce fichier affectera toute personne qui utilise bash sur votre système. Cela sert par exemple à ajouter des répertoires dans la variable <TT>PATH</TT>, ou à définir celui de la variable <TT>MAIL</TT>. Le comportement par défaut du clavier laisse souvent à désirer. En fait, c'est readline qui contrôle cela. Readline est un package distinct qui prend en main les interfaces de ligne de commande, en fournissant l'historique des commandes, et le complètement automatique de noms de fichiers (NDT : Touche TAB sous Bash), tout comme les facilités évoluées d'édition de ligne. Il est compilé dans bash. Par défaut, Readline est configuré à l'aide du fichier <TT>.inputrc</TT>, dans votre répertoire personnel. La variable INPUTRC peut être utilisée pour outrepasser les règles de ce fichier pour le bash. Par exemple, dans Red Hat 6, <TT>INPUTRC</TT> reçoit la valeur <TT>/etc/inputrc</TT> dans le fichier <TT>/etc/profile</TT>. Cela signifie que les touches Retour Arrière (Backspace), Suppr (Delete), Début (Home) et Fin (End) fonctionnent correctement et pour tout le monde. Une fois que bash a lu le fichier de configuration général, commun au système entier, il recherche votre fichier de configuration personnel. Il teste l'existence des fichiers <TT>.bash_profile</TT>, <TT>.bash_login</TT> et <TT>.profile</TT> dans votre répertoire personnel. Il lance le premier qu'il trouve. Si vous voulez modifier le comportement de bash à votre égard, sans le changer pour les autres, faites-le ici. Par exemple, de nombreuses applications utilisent les variables d'environnement pour contrôler leur fonctionnement. J'ai une variable <TT>EDITOR</TT> contenant la valeur <TT>vi</TT> pour pouvoir utiliser vi sous Midnight Commander (un excellent gestionnaire de fichier orienté console) au lieu de son éditeur propre. <SECT1>Exercices Les bases de bash sont faciles à apprendre. Mais ne vous y limitez pas : on peut aller incroyablement loin avec. Prenez l'habitude de rechercher de meilleures façons de faire les choses. Lisez des scripts shell, analysez les choses que vous ne comprenez pas. <SECT1>Plus d'informations <ITEMIZE> <ITEM>Téléchargement du code source, voir <REF ID="downloads" NAME="téléchargements"> <ITEM>Il existe un ``Manuel de Référence de Bash'' avec, clair, mais assez lourd. <ITEM>Il existe un livre O'Reilly sur le Bash, je ne sais pas s'il est vraiment bon. <ITEM>Je ne connais pas de tutoriel bash gratuit et à jour. Si vous en connaissez un, merci de m'envoyer l'URL. </ITEMIZE> <SECT>Les commandes Vous effectuez la plupart des choses sous bash en saisissant des commandes comme <TT>cp</TT>. La majorité de ces commandes sont des petits programmes, bien que quelques unes, comme <TT>cd</TT> soient intégrées au shell. Les commandes viennent de packages, la plupart de la Free Software Foundation (projet GNU). Plutôt que de dresser ici la liste des packages, je préfère vous renvoyer vers le <URL URL="http://www.linuxfromscratch.org" NAME="Linux From Scratch HOWTO">. Il contient une liste complète et à jour de tous les packages allant dans un système Linux, aussi bien que des indications pour les construire. <SECT>Construire un système Linux minimum à partir des sources. <LABEL ID="building"> Nous nous sommes concentrés jusqu'ici sur ce que les packages font. Je vais vous donner ici tout les indices que je peux pour fabriquer un système Linux de base à partir des sources. Si vous voulez monter un vrai système pour du vrai travail, lisez le <URL URL="http://www.linuxfromscratch.org" NAME="Linux From Scratch HOWTO">. Il est possible d'obtenir une ligne de commande bash sans installer tout ce que je mentionne ici. Ce que je décris est un système de base, sans embûche, qui peut être monté facilement. <SECT1>Ce qu'il vous faut Nous installerons une distribution de Linux comme Red Hat sur une partition, et l'utiliserons pour construire un nouveau système Linux sur une autre partition. Je nommerai par la suite ``cible'' le système que nous construisons, et ``source'' le système que nous utilisons pour construire le système cible (à ne pas confondre avec code source que nous utiliserons aussi). Vous allez donc avoir besoin d'une machine avec deux partitions libres dessus. Si vous le pouvez, utilisez une machine qui ne contienne rien d'important. Vous pouvez utiliser un système Linux déjà existant comme système source, mais je le déconseille. Si vous oubliez un des paramètres des commandes que nous allons saisir, vous pourriez accidentellement réinstaller des choses sur votre système source. Cela peut mener à des incompatibilités, et des conflits. Les anciennes architectures PC, pour la plupart 486 et plus ancien, ont une limitation ennuyeuse de leur Bios. Il ne peuvent lire les disques durs passé les 512 premiers mégaoctets. Ce n'est pas vraiment un problème pour Linux, qui gère lui-même les disques une fois lancé. Mais pour que Linux soit chargé sur ces vieilles machines, le noyau doit résider quelque part en dessous de 512 mégaoctets. Si vous utilisez une de ces machines, vous devez créer une partition distincte en dessous de 512 Mo, à monter sur <TT>/boot</TT> pour toute partition au dessus de la limite des 512 Mo. La dernière fois que je l'ai fait, j'ai utilisé Red Hat 6.1 comme système source. J'ai installé le système de base plus <ITEMIZE> <ITEM>cpp <ITEM>egcs <ITEM>egcs-c++ <ITEM>patch <ITEM>make <ITEM>dev86 <ITEM>ncurses-devel <ITEM>glibc-devel <ITEM>kernel-headers </ITEMIZE> J'ai aussi installé X-window et Mozilla (NDT : Netscape) pour pouvoir lire les documentations facilement, mais ce n'est pas nécessaire. A la fin de mon travail, cela avait pris environ 350M d'espace disque (Cela semble un peu élevé, je me demande pourquoi). Le système cible achevé prenait 650M, mais comprenait tout le code source et les fichiers intermédiaires. Si l'espace est limité, je vous conseille de faire un <TT>make clean</TT> après la construction de chaque package. Cela dit, c'est une source d'ennuis et d'hésitation. Enfin, vous allez avoir besoin du code source du système que vous allez construire. Il y a les ``packages'' dont nous avons parlé dans ce document. On peut les obtenir depuis un CD, ou par l'Internet. Je donnerai les URL pour les sites américains et miroirs australiens. <LABEL ID="downloads"> <ITEMIZE> <ITEM>MAKEDEV <URL URL="ftp://tsx-11.mit.edu/pub/linux/sources/sbin" NAME="USA"> Autre site aux <URL URL="ftp://sunsite.unc.edu/pub/Linux/system/admin" NAME="USA"> <ITEM>Lilo <URL URL="ftp://lrcftp.epfl.ch/pub/linux/local/lilo/" NAME="USA">, <URL URL="ftp://mirror.aarnet.edu.au/pub/linux/metalab/system/boot/lilo/" NAME="Australie">. <ITEM>Noyau Linux Utilisez un des miroirs listés sur <URL URL="http://www.kernel.org" NAME="home page"> plutôt que <URL URL="ftp://ftp.kernel.org/pub/linux/kernel" NAME="USA"> car ils sont toujours en surcharge. <URL URL="ftp://kernel.mirror.aarnet.edu.au/pub/linux/kernel/" NAME="Australie"> <ITEM>GNU libc La bibliothèque elle-même, ainsi que les add-on linuxthreads sont sur <URL URL="ftp://ftp.gnu.org/pub/gnu/glibc" NAME="USA"> <URL URL="ftp://mirror.aarnet.edu.au/pub/gnu/glibc" NAME="Australie"> <ITEM>Add-ons à la libc GNU Vous aurez aussi besoin des linuxthreads et des add-on libcrypt. Si libcrypt est absente à cause des lois américaines sur l'exportation, vous pouvez la récupérer sur <URL URL="ftp://ftp.gwdg.de/pub/linux/glibc" NAME="libcrypt"> les add-ons linuxthreads sont au même endroit que libc proprement dite. <ITEM>GNU ncurses <URL URL="ftp://ftp.gnu.org/gnu/ncurses" NAME="USA"> <URL URL="ftp://mirror.aarnet.edu.au/pub/gnu/ncurses" NAME="Australie"> <ITEM>SysVinit <URL URL="ftp://sunsite.unc.edu/pub/Linux/system/daemons/init" NAME="USA"> <URL URL="ftp://mirror.aarnet.edu.au/pub/linux/metalab/system/daemons/init" NAME="Australie"> <ITEM>GNU Bash <URL URL="ftp://ftp.gnu.org/gnu/bash" NAME="USA"> <URL URL="ftp://mirror.aarnet.edu.au/pub/gnu/bash" NAME="Australie"> <ITEM>GNU sh-utils <URL URL="ftp://ftp.gnu.org/gnu/sh-utils" NAME="USA"> <URL URL="ftp://mirror.aarnet.edu.au/pub/gnu/sh-utils" NAME="Australie"> <ITEM>util-linux <URL URL="ftp://ftp.win.tue.nl/pub/linux/utils/util-linux/" NAME="Ailleurs"> <URL URL="ftp://mirror.aarnet.edu.au/pub/linux/metalab/system/misc" NAME="Australie"> Ce package contient <TT>agetty</TT> et <TT>login</TT>. </ITEMIZE> Pour résumer, il vous faut : <ITEMIZE> <ITEM>Une machine avec deux partitions distinctes d'environ 400M et 700M respectivement, bien que vous puissiez sûrement vous en tirer avec un espace plus restreint. <ITEM>Une distribution de Linux (un CD de Red Hat par exemple), et de quoi l'installer (un lecteur de CD par exemple). <ITEM>Les archives (tarballs : fichier contenant plusieurs autres fichiers concaténés en un seul, puis compressé ou non ensuite) du code source, listées ci-dessus. </ITEMIZE> Je pars du principe que vous pouvez installer le système source vous-même, sans aide de ma part. A partir de maintenant, je considère que c'est fait. Les premiers pas de ce projet consistent à faire démarrer le noyau, et le laisser `paniquer' (panic) car il ne peut trouver le programme <TT>init</TT>. Cela signifie que nous allons devoir installer un noyau, et installer Lilo. Pour que Lilo fonctionne quand même correctement, nous avons besoin d'installer les fichiers spéciaux dans le <TT>/dev</TT> du système cible. Lilo en a besoin pour effectuer les accès bas niveau au disque, nécessaire pour écrire le secteur d'amorce. MAKEDEV est le script qui crée ces fichiers spéciaux (Vous pourriez bien sûr les recopier depuis le système source, mais ce serait tricher !). Mais d'abord, il nous faut un système de fichiers pour les mettre dedans. <SECT1>Le système de fichier (Filesystem) Notre nouveau système a besoin d'un système de fichiers pour vivre. Donc, il nous faut tout d'abord créer ce système de fichiers en utilisant <TT>mke2fs</TT>. Ensuite il faut le monter quelque part. Je vous suggère <TT>/mnt/target</TT> (comme `cible'). Dans ce qui va suivre, je considère que votre système se trouve à cet endroit. Vous pouvez gagner un peu de temps en ajoutant une entrée dans <TT>/etc/fstab</TT> de façon à ce que le montage de votre système destination soit automatique lorsque votre système source démarre. Lorsque nous démarrerons le système cible, ce qui se trouve dans <TT>/mnt/target</TT> se trouvera alors dans <TT>/</TT> (à la racine). Nous avons besoin d'une structure de sous-répertoires sur la cible. Jetez un oeil au Standard de la Hiérarchie des Fichiers (File Hierarchy Standard, voir section <REF ID="FHS" NAME="Système de Fichiers">). pour trouver vous même ce qu'elle devrait être, ou faites simplement un <TT>cd</TT> vers l'endroit où la cible est montée et tapez aveuglément : <VERB> mkdir bin boot dev etc home lib mnt root sbin tmp usr var cd var; mkdir lock log run spool cd ../usr; mkdir bin include lib local sbin share src cd share/; mkdir man; cd man mkdir man1 man2 man3 ... man9 </VERB> Comme le FHS et la plupart des packages se contredisent en ce qui concerne l'endroit où les man pages doivent se trouver, nous avons besoin d'un lien symbolique : <VERB> cd ..; ln -s share/man man </VERB> <SECT1>MAKEDEV Nous mettrons le code source dans le répertoire <TT>/usr/src</TT> cible. Aussi si votre système de fichiers cible est monté par exemple sur <TT>/mnt/target</TT>, et que vos archives sont dans <TT>/root</TT>, il faudra faire : <VERB> cd /mnt/target/usr/src tar -xzvf /root/MAKEDEV-2.5.tar.gz </VERB> Ne vous comportez pas en amateur fini et pensez à copier vos archives à l'endroit où vous allez les décompresser ;-) En principe, lorsque vous installez un logiciel, vous l'installez sur le système en fonctionnement. En l'occurence, ce n'est pas notre intention, nous souhaitons l'installer comme si /mnt/target était le système de fichiers racine. Les différents packages ont différentes manières de vous le laisser faire. Pour MAKEDEV, vous devez faire <VERB> ROOT=/mnt/target make install </VERB> Vous devez rechercher ces options dans les fichiers README et INSTALL ou faire un <TT>./configure --help</TT>. Explorez le <TT>Makefile</TT> de MAKEDEV pour voir l'usage qu'il fait de la variable ROOT, que nous avons définie dans cette commande. Ensuite jetez un oeil à la page de manuel en faisant un <TT>man ./MAKEDEV.man</TT> pour voir comment il fonctionne. Vous découvrirez que la méthode utilisée pour ces fichiers spéciaux consiste à faire un <TT>cd /mnt/target/dev</TT> puis un <TT>./MAKEDEV generic</TT>. Faites un <TT>ls</TT> pour découvrir tous les merveilleux fichiers spéciaux qu'il a créés pour vous ! <SECT1>Le noyau (kernel) Ensuite, nous devons fabriquer un noyau. Je considère que vous l'avez déjà fait, aussi serai-je bref. Il est plus facile d'installer Lilo si le noyau censé être monté est déjà là. Retournez dans le répertoire <TT>/usr/src</TT> de la cible, et décompressez-y les sources du noyau linux. Entrez dans l'arborescence des sources (<TT>cd linux</TT>) et configurez le noyau, en utilisant votre méthode préférée, comme par exemple <TT>make menuconfig</TT>. Vous vous faciliterez grandement la vie si vous configurez un noyau sans module. Si vous configurez des modules, vous devrez éditer <TT>Makefile</TT>, trouver <TT>INSTALL_MOD_PATH</TT>, et lui affecter la valeur <TT>/mnt/target</TT>. Vous pouvez maintenant taper <TT>make dep</TT>, <TT>make bzImage</TT>, et si vous avez configuré des modules : <TT>make modules</TT>, <TT>make modules_install</TT>. Copiez le noyau <TT>arch/i386/boot/bzImage</TT> et le plan système <TT>System.map</TT> vers le répertoire de boot de la cible <TT>/mnt/target/boot</TT>, et nous seront prêts à installer Lilo. <SECT1>Lilo Lilo est livré avec un très beau script nommé <TT>QuickInst</TT>. Décompressez les sources de Lilo dans le répertoire des sources du système cible, lancez ce script par la commande <TT>ROOT=/mnt/target ./QuickInst</TT>. Il vous posera plusieurs questions concernant la manière dont vous souhaitez que Lilo soit installé. Souvenez-vous, comme nous avons affecté à la variable <TT>ROOT</TT> la partition cible, vos noms de fichiers s'y rapportent. Donc, lorsqu'il vous demandera le nom du noyau à lancer par défaut, répondez <TT>/boot/bzImage</TT>, pas <TT>/mnt/target/boot/bzImage</TT>. J'ai trouvé un bug mineur dans le script, qui lui fait dire : <VERB> ./QuickInst: /boot/bzImage: no such file </VERB> Mais si vous vous contentez de l'ignorer, cela passe quand même. Comment doit-on s'y prendre pour expliquer à <TT>QuickInst</TT> où installer le secteur de boot ? Quand nous redémarrons, nous voulons avoir le choix de démarrer le système source ou le système cible, ou encore n'importe quel autre système présent sur la machine. Et nous souhaitons que l'instance de Lilo que nous mettons en place maintenant lance le noyau de notre nouveau système. Comment est-ce que l'on réalise ces deux choses ? Ecartons-nous un moment du sujet et étudions la façon dont Lilo démarre DOS sur un système Linux en dual-boot. Le fichier <TT>lilo.conf</TT> d'un tel système doit sûrement ressembler à çà. <VERB> prompt timeout = 50 default = linux image = /boot/bzImage label = linux root = /dev/hda1 read-only other = /dev/hda2 label = dos </VERB> Si la machine est configurée de cette façon, alors le Master Boot Record (MBR) est lu et chargé par le Bios, et lance le bootloader de Lilo, qui affiche une invite de commande. Si vous tapez <TT>dos</TT> dans cette invite, Lilo chargera le secteur de boot depuis hda2, qui lancera DOS. Ce que nous allons faire est exactement la même chose, mis à part que le secteur d'amorce d'hda2 va être un autre secteur d'amorce Lilo - celui-là même que <TT>QuickInst</TT> va installer. Donc le Lilo de la distribution de linux chargera le Lilo que nous avons construit, qui chargera le noyau que nous avons bâti. Vous verrez alors deux invites de commande Lilo au redémarrage. Pour raccourcir une longue histoire, lorsque <TT>QuickInst</TT> vous demande où placer le secteur de boot, indiquez-lui l'endroit où se trouve votre système de fichiers cible, par exemple <TT>/dev/hda2</TT>. Maintenant modifiez le fichier <TT>lilo.conf</TT> de votre système source, de façon à ce qu'il ait une ligne ressemblant à: <VERB> other = /dev/hda2 label = target </VERB> Lancez Lilo, et nous devrions être capables de faire notre premier démarrage sur le système cible. <SECT1>Glibc L'étape suivante consiste à installer <TT>init</TT>, mais comme la plupart des programmes qui tournent sous Linux, <TT>init</TT> utilise des fonctions issues de la bibliothèque C GNU, glibc. Aussi l'installerons-nous en premier. Glibc est un package très gros et très compliqué. Il faut 90 heures pour le bâtir sur mon vieux 386sx/16 avec 8M RAM. Mais cela ne prend que 33 minutes sur mon Celeron 433 avec 64M. Je pense que la quantité de mémoire est le principal critère dans notre cas. Si vous n'avez que 8Mo de RAM (ou - j'en tremble - encore moins !), préparez vous à une très longue compilation. La documentation d'installation de glibc recommande une construction dans un répertoire distinct. Cela vous permet de recommencer facilement, en supprimant simplement ce répertoire. Cela vous permet aussi d'économiser 265Mo d'espace disque. Décompressez l'archive <TT>glibc-2.1.3.tar.gz</TT> (ou n'importe quelle autre version) dans <TT>/mnt/target/usr/src</TT> comme d'habitude. A présent, nous devons décompresser les ``add-on'' dans le répertoire de la glibc. Donc, faites un <TT>cd glibc-2.1.3</TT>, puis décompressez à cet endroit les archives <TT>glibc-crypt-2.1.3.tar.gz</TT> et <TT>glibc-linuxthreads-2.1.3.tar.gz</TT>. Maintenant, nous pouvons créer le répertoire de construction, configurer, bâtir et installer glibc. Voici les commandes que j'ai utilisées, mais relisez vous-même la documentation et assurez-vous de faire ce qui est le plus approprié dans votre environnement. Toutefois, avant de faire tout cela, vous voudrez sans doute connaître l'espace disque qu'il vous reste par un <TT>df</TT>. Vous pouvez en faire un autre après avoir bâti et installé glibc pour en déduire son volume. <VERB> cd .. mkdir glibc-build ../glibc-2.1.3/configure --enable-add-ons --prefix=/usr make make install_root=/mnt/target install </VERB> Remarquez que nous avons ici encore une autre façon de dire au package l'endroit où s'installer. <SECT1>SysVinit Bâtir et installer les binaires de SysVinit est assez direct. Je me contenterai d'être paresseux et de vous donner les commandes, en considérant que vous avez décompressé son code source, et que vous êtes entré dans son répertoire. <VERB> cd src make ROOT=/mnt/target make install </VERB> Il existe aussi beaucoup de scripts associés à <TT>init</TT>. Il y a des scripts d'exemple fournis dans le package de SysVinit, qui fonctionnent bien. Mais vous devez les installer manuellement. Ils sont organisés dans une hiérarchie sous <TT>debian/etc</TT> dans l'arborescence du code source de SysVinit. Vous pouvez recopier toute cette hiérarchie dans le répertoire <TT>etc</TT> du système cible, avec une commande du style <TT>cd ../debian/etc; cp -r * /mnt/target/etc</TT>. Evidement, vous explorerez ces scripts avant de tous les recopier. Tout est désormais en place pour permettre au noyau cible de lancer <TT>init</TT> au redémarrage. Le problème, cette fois, viendra des scripts qui ne pourront être exécutés car <TT>bash</TT> ne sera pas là pour les interpréter. <TT>init</TT> tentera également de lancer des <TT>getty</TT>, qui sont inexistants eux aussi. Rebootez maintenant, et assurez-vous que tout le reste fonctionne correctement. <SECT1>Ncurses L'étape suivante consiste à mettre Bash en place, mais bash a besoin de ncurses, aussi devons-nous installer celui-ci en premier. Ncurses remplace termcap dans la manière de gérer les écrans texte, mais apporte également une compatibilité ascendante en prenant en charge les appels termcap. Dans l'objectif d'avoir un système moderne, simple et propre, je pense que le mieux est de désactiver l'ancienne méthode termcap. Vous pourriez par la suite rencontrer des problèmes avec des applications utilisant termcap, mais au moins vous connaîtrez les éléments qui l'utilisent. Si vous en avez besoin, vous pouvez recompiler ncurses avec prise en charge de termcap. Les commandes que j'ai utilisées sont : <VERB> ./configure --prefix=/usr --with-install-prefix=/mnt/target --with-shared --disable-termcap make make install </VERB> <SECT1>Bash Il m'a fallu beaucoup de lecture, de réflexion, de tests, et d'erreurs pour que Bash s'installe là où je pensais qu'il devait aller. Les options de configuration que j'ai utilisées sont : <VERB> ./configure --prefix=/mnt/target/usr/local --exec-prefix=/mnt/target --with-curses </VERB> Une fois que vous avez bâti et installé Bash, vous devez créer un lien symbolique comme ceci : <TT>cd /mnt/target/bin; ln -s bash sh</TT>. Cela est dû au fait que les scripts débutent généralement par une ligne comme celle-ci : <VERB> #!/bin/sh </VERB> Si vous n'avez ce lien symbolique, les scripts ne fonctionneront pas, car ils chercheront <TT>/bin/sh</TT> et non <TT>/bin/bash</TT>. Vous pouvez redémarrer à ce point si vous le souhaitez. Vous devriez remarquer que les scripts peuvent maintenant s'exécuter, bien que vous ne puissiez vous loguer, car il n'y pas encore de programmes <TT>getty</TT> ou <TT>login</TT>. <SECT1>Util-linux (getty et login) Le package util-linux contient <TT>agetty</TT> et <TT>login</TT>. Nous avons besoin des deux pour nous loguer et obtenir la ligne de commande de bash. Après l'avoir installé, faites un lien symbolique depuis <TT>agetty</TT> vers <TT>getty</TT> de le répertoire <TT>/sbin</TT> du système cible. <TT>getty</TT> est un des programmes censés se trouver sur tous les systèmes de type Unix, donc faire un lien est une meilleure idée que de modifier <TT>inittab</TT> pour qu'il lance <TT>agetty</TT>. Il me reste un problème avec la compilation d'util-linux. Le package contient également le programme <TT>more</TT>, et je n'ai pas été capable de persuader le processus <TT>make</TT> de placer le lien <TT>more</TT> sur la bibliothèque de ncurses 5 du système cible, plutôt que sur ncurses 4 du système source. Je regarderai cela de plus près. Vous aurez aussi besoin d'un fichier <TT>/etc/passwd</TT> sur le système cible. C'est l'endroit où le programme <TT>login</TT> ira vérifier votre accréditation. Comme il ne s'agit que d'un système gadget à ce niveau, vous pouvez vous permettre des choses scandaleuses, comme ne définir que l'utilisateur root, sans mot de passe ! Mettez le simplement dans le fichier <TT>/etc/passwd</TT> du système cible. <VERB> root::0:0:root:/root:/bin/bash </VERB> Les champs sont séparés par des deux-points, correspondent, de gauche à droite, à l'user id (nom de login), au mot de passe (crypté), au numéro d'utilisateur, au numéro de groupe, au nom de l'utlisateur, à son répertoire personnel, et à son shell par défaut. <SECT1>Sh-utils Le dernier package dont nous ayons besoin est sh-utils GNU. Le seul programme nécessaire à ce niveau est <TT>stty</TT>, qui est utilisé dans <TT>/etc/init.d/rc</TT>, lui-même utilisé pour changer de niveau d'exécution et entrer dans le niveau initial. En fait, je possède et ai utilisé un package qui ne contient que <TT>stty</TT> mais je ne peux me souvenir d'où il vient. Il vaut mieux utiliser le package GNU, car il contient d'autres choses dont vous aurez besoin si vous voulez les ajouter au système pour le rendre vraiment utilisable. Eh bien ça y est. Vous devriez maintenant avoir un système qui doit démarrer et vous donner l'invite de login. Saisissez-y ``root'', et vous devriez avoir le shell. Vous ne pourrez pas faire grand chose avec, il n'y a même pas de commande <TT>ls</TT> pour voir votre travail. Tapez deux fois la touche tab pour voir les commandes disponibles. C'est la chose la plus intéressante que j'ai trouvée à faire avec. <SECT1>Vers l'utilisabilité Il semblerait que nous ayons là un système plutôt inutilisable. Mais en réalité, nous ne sommes pas très loin de pouvoir commencer à travailler avec. L'une des premières choses à faire est de rendre le système de fichiers racine accessible et lecture et écriture. Il y a un script issu du package, dans <TT>/etc/init.d/mountall.sh</TT> qui s'occupe de cela, et effectue un <TT>mount -a</TT> pour monter automatiquement tout ce qui est spécifié dans le fichier <TT>/etc/fstab</TT>. Mettez un lien symbolique du genre <TT>S05mountall</TT> vers lui dans le répertoire <TT>etc/rc2.d</TT> du système cible. Il se peut que ce script utilise des commandes que vous n'avez pas encore installées. Si c'est le cas, trouvez le package qui contient ces commandes et installez-le. Voyez la section <REF ID="finding" NAME="Random Tips"> pour avoir des indications sur la marche à suivre pour trouver ces packages. Regardez les autres scripts dans <TT>/etc/init.d</TT>. La plupart d'entre-eux doit être incluse dans tout système sérieux. Ajoutez-les un à un, et assurez-vous que tout se lance en douceur avant d'en ajouter d'autres. Lisez le Standard de la Hiérarchie des Fichiers (voir section <REF ID="FHS" NAME="Système de Fichiers">). Il contient une liste de commandes qui devraient être dans <TT>/bin</TT> et <TT>/sbin</TT>. Assurez-vous que toutes ces commandes sont installées sur votre système. Mieux encore, trouvez la documentation Posix qui spécifie tout cela. A partir de maintenant, il n'est plus question que d'ajouter de plus en plus de packages, jusqu'à ce que tout ce que vous souhaitez avoir se trouve sur votre système. Installez les outils de construction comme <TT>make</TT> et <TT>gcc</TT> le plus tôt possible. Une fois que cela est fait, vous pouvez utiliser votre système cible pour se construire lui-même, ce qui est bien moins compliqué. <SECT1>Astuces diverses <LABEL ID="finding"> Si vous avez une commande appelée <TT>thingy</TT> sur un système Linux avec RPM, et souhaitez avoir des indications sur l'endroit où trouver les sources, vous pouvez utiliser la commande : <VERB> rpm -qif `which thingy` </VERB> Et si vous avez un CD de sources Red Hat, vous pouvez installer le code source avec <VERB> rpm -i /mnt/cdrom/SRPMS/ce.qu.il.vient.de.dire-1.2.srpm </VERB> Ceci mettra l'archive, avec les patches Redhats éventuels dans <TT>/usr/src/redhat/SOURCES</TT>. <SECT1>Plus d'informations <ITEMIZE> <ITEM> Il existe un mini-howto sur la manière de construire les logiciels à partir de leurs sources, le <URL URL="http://www.linuxdoc.org/HOWTO/Software-Building-HOWTO.html" NAME="Software Building mini-HOWTO"> (miroir français en <URL URL="http://linuxfr.org/LDP/HOWTO/Software-Building-HOWTO.html "NAME="VO">). <ITEM> Il existe aussi un HOWTO sur la manière de construire un système Linux depuis zéro. Il met l'accent sur la construction d'un système réellement utilisable, plutôt que pour le simple exercice. <URL URL="http://www.linuxfromscratch.org" NAME="The Linux From Scratch HOWTO"> </ITEMIZE> <SECT>Conclusion L'un des meilleurs côtés de Linux, à mon humble avis, est que vous pouvez entrer dedans et voir réellement comment il fonctionne. J'espère que vous apprécierez cela autant que moi. Et j'espère que ces quelques notes vous y auront aidé. <SECT>Section administrative <SECT1>Copyright Ce document est copyright (c) 1999, 2000 Greg O'Keefe. Vous êtes libre de l'utiliser, le copier, le distribuer ou le modifier, sans obligation, selon les termes de la Licence Publique Générale (GPL : <URL URL="http://www.gnu.org/copyleft/gpl.html" NAME="GNU General Public Licence">). Merci de conserver les références à l'auteur si vous utilisez tout ou partie de ce document dans un autre. <SECT1>Page principale Les mises à jour de ce document évoluent sur <URL URL="http://learning.taslug.org.au/power2bash" NAME="From Powerup To Bash Prompt">. <SECT1>Retours J'aimerais recevoir vos commentaires, critiques et suggestions. Veuillez s'il vous plaît me les envoyer à <URL URL="mailto:gcokeefe@postoffice.utas.edu.au" NAME="Greg O'Keefe"> <SECT1>Références et remerciements. <LABEL ID="acknowledge"> Les noms de produits cités sont marques déposées de leur propriétaires respectifs, et considérés par cette note comme reconnus comme tels. Il y a quelques personnes que je voudrais remercier, pour m'avoir aidé à réaliser tout ceci. <DESCRIP> <TAG>Tout les abonnés de la liste de discussion learning@TasLUG</TAG> Merci pour avoir lu tous mes mails et posé des questions intéressantes. Vous pouvez rejoindre cette liste en envoyant un message à <URL URL="mailto:majordomo@taslug.org.au" NAME="majordomo"> avec la phrase <VERB> subscribe learning </VERB> dans le corps du message. <TAG>Michael Emery</TAG> Pour m'avoir rappelé Unios. <TAG>Tim Little</TAG> Pour de bonnes indications concernant <TT>/etc/passwd</TT> <TAG>sPaKr dans #linux sur efnet</TAG> Qui a soupçonné l'utilisation de <TT>/etc/services</TT> par syslog, et m'a fait connaître la phrase ``rolling your own'' ("roulez-la vous-même") pour décrire la construction d'un système à partir des sources. <TAG>Alex Aitkin</TAG> Pour avoir porté Vico et son ``verum ipsum factum'' (La compréhension découle de l'expérience) à mon attention. <TAG>Dennis Scott</TAG> Pour avoir corrigé mon arithmétique en hexadécimal. <TAG>jdd</TAG> Pour avoir mis en évidence quelques erreurs typographiques. <TAG>David Leadbeater</TAG> Pour avoir contribué aux ``pérégrinations'' dans les démons noyau. </DESCRIP> <SECT1>Historique des changements <SECT2>0.6 -> 0.7 <ITEMIZE> <ITEM>L'accent est plus porté sur l'explication, et moins sur la façon de monter un système, ces informations ayant été regroupées dans une section distincte, et le système une fois construit a été revu à la baisse, voir directement la documentation de Gerard Beekmans ``Linux From Scratch'' pour construire un système sérieux. <ITEM>Ajout de quelques hypothèses de la part de David Leadbeater <ITEM>Correction de deux URL, ajout d'un lien vers le téléchargement d'unios sur learning.taslug.org.au/resources <ITEM>Test et correction d'url. <ITEM>Grand nettoyage et réécriture générale. </ITEMIZE> <SECT2>0.5 -> 0.6 <ITEMIZE> <ITEM>Ajout de l'historique des changements <ITEM>Ajout de quelques ``todos'' (``A faire''). </ITEMIZE> <SECT1>A faire (TODO) <ITEMIZE> <ITEM>expliquer les modules noyau, depmod, modprobe, insmod et tout (il faut d'abord que je trouve moi-même). <ITEM>mentionner le système de fichiers /proc. Exercices potentiels. <ITEM>convertir en documentation sgml <ITEM>ajouter plus d'exercices, peut-être une section entière d'exercices plus poussés, comme créer un système de fichiers minimal fichier par fichier à partir de l'installation d'une distribution. </ITEMIZE> </ARTICLE>