<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
  "http://www.docbook.org/xml/4.3/docbookx.dtd" [
   
<!ENTITY bbpmail "bbp@via.ecp.fr">

<!ENTITY logilab "Logilab">
<!ENTITY logilaburl "http://www.logilab.org">

<!ENTITY etb "etherboot">
<!ENTITY etburl "http://etherboot.sourceforge.net">

<!ENTITY ltsp "linux terminal server project">
<!ENTITY ltspurl "http://www.ltsp.org">

<!ENTITY vmware "VMWare">
<!ENTITY vmwareurl "http://www.vmware.com">

<!ENTITY plex86 "plex86">
<!ENTITY plex86url "http://www.plex86.org">

<!ENTITY imggenurl "http://www.ltsp.org/contrib/">

<!ENTITY disklesshowtourl "http://www.linuxdoc.org/HOWTO/Diskless-HOWTO.html">

<!ENTITY disklessrootnfshowtourl "http://www.linuxdoc.org/HOWTO/Diskless-root-NFS-HOWTO.html">

<!ENTITY bootdiskhowtourl "http://www.traduc.org/docs/HOWTO/vf/Bootdisk-HOWTO.html">

<!ENTITY powerup2bashurl "http://www.traduc.org/docs/HOWTO/vf/From-PowerUp-to-bash-prompt-HOWTO.html">

<!ENTITY thinclienturl "http://www.linuxdoc.org/HOWTO/Thin-Client-HOWTO.html">

<!ENTITY cdwritingurl "http://www.traduc.org/docs/HOWTO/vf/CD-Writing-HOWTO.html">

<!ENTITY ntb "netboot">
<!ENTITY ntburl "http://netboot.sourceforge.net">

<!ENTITY clusternfs "clusternfs">
<!ENTITY clusternfsurl "http://clusternfs.sourceforge.net">

<!ENTITY grub "GRUB">
<!ENTITY gruburl "http://www.gnu.org/software/grub/">

<!ENTITY clientsrootbuilding "Configuration des clients, construction du système de fichiers racine">

<!ENTITY plume "plume">
<!ENTITY plumeurl "http://plume.sourceforge.net">

]>

<article lang="fr">

<articleinfo>
    
    <title>Guide pratique de l'amorçage sur réseau et des systèmes de
    fichiers racine exotiques</title>
    <subtitle>Version française du
    <foreignphrase>Network-boot-HOWTO</foreignphrase></subtitle>

    
    <authorgroup>
      <author>
        <firstname>Brieuc</firstname>
        <surname>Jeunhomme</surname>
        <email>bbp@via.ecp.fr</email>
      </author>
      
      <corpauthor>Logilab S.A.</corpauthor>

      <othercredit role="traduction">
        <firstname>Nicolas</firstname>
        <surname>Jadot</surname>
        <contrib>Adaptation française</contrib>
      </othercredit>

    </authorgroup>    
    
    <abstract><para>
      
      Ce document explique comment mettre rapidement en &oelig;uvre un 
      serveur sous linux pouvant fournir tout ce qui est nécessaire à un 
      client linux pour démarrer sur un réseau IP. Il inclut des 
      éléments extraits du Diskless-HOWTO, du Diskless-root-NFS-HOWTO, 
      de la documentation du noyau linux, des pages du projet &etb; et 
      de &ltsp;, ainsi que de l'expérience personnelle de l'auteur, 
      acquise lorsqu'il travaillait pour &logilab;. Eventuellement, ce 
      document peut rendre obsolètes le Diskless-HOWTO et le 
      Diskless-root-NFS-HOWTO. Veuillez noter également que vous 
      trouverez d'autres informations utiles dans le guide pratique "De 
      la mise sous tension à la ligne de commande bash" et dans le 
      Thin-Client-HOWTO, ainsi que sur la page écrite par Claus-Justus 
      Heine sur le basculement entre pages NFS. <!-- NDT : mal dit -->
    
    </para></abstract>

    <releaseinfo>Version&nbsp;: 0.3.fr.1.0</releaseinfo>
    <pubdate>2004-09-09</pubdate>

    <revhistory>

    <revision>
      <revnumber>0.3.fr.1.0</revnumber>
      <date>2004-09-09</date>
      <authorinitials>NJ</authorinitials>
      <revremark>Première version française</revremark>
    </revision>

    <revision>
      <revnumber>0.3</revnumber>
      <date>2002-04-28</date>
      <authorinitials>bej</authorinitials>
      <revremark>Insertion de retours d'expérience, ainsi que des
      liens vers différents projets</revremark>
    </revision>

    <revision>
      <revnumber>0.2.2</revnumber>
      <date>2001-12-08</date>
      <authorinitials>dcm</authorinitials>
      <revremark>Placé sous licence GFDL</revremark>
    </revision>

    <revision>
      <revnumber>0.2.1</revnumber>
      <date>2001-05-21</date>
      <authorinitials>logilab</authorinitials>
      <revremark>Bibliographie terminée</revremark>
    </revision>

    <revision>
      <revnumber>0.2</revnumber>
      <date>2001-05-19</date>
      <authorinitials>bej</authorinitials>
      <revremark>Plusieurs amélioration et ajout des retours
      d'expérience de Ken Yap</revremark>
    </revision>

    <revision>
      <revnumber>0.1.1</revnumber>
      <date>2001-04-09</date>
      <authorinitials>logilab</authorinitials>
      <revremark>Premier brouillon public</revremark>
    </revision>

    <revision>
      <revnumber>0.1</revnumber>
      <date>2000-12-09</date>
      <authorinitials>bej</authorinitials>
      <revremark>Brouillon initial</revremark>
    </revision>
    </revhistory>

</articleinfo>

<sect1>

    <title>Introduction</title>

    <sect2>

      <title>De quoi parlons-nous ?</title>

      <para>
      
      Les noyaux linux récents permettent de démarrer une machine sous 
      linux entièrement depuis le réseau, en chargeant le noyau et le 
      système de fichiers racine depuis un serveur. Pour ce faire, le 
      poste client peut utiliser diverses méthodes de démarrage : 
      eeproms spécialement configurées, cartes réseaux implantant les 
      protocoles RARP, BOOTP ou DHCP, CD-ROM, lanceurs chargés depuis 
      une disquette ou un disque dur local.
      
      </para>

    </sect2>

    <sect2>

      <title>Remerciements</title>

      <para>
      
      &logilab; a soutenu la rédaction de ce guide. Reportez-vous à 
      <ulink url="&logilaburl;">son site</ulink> pour les nouvelles 
      versions de ce document. Je remercie également les administrateurs 
      et les développeurs de &etb;, &ntb;, &plume; et &ltsp;, qui ont 
      réellement rendu possible le démarrage sur réseau d'une station 
      linux.
      
      </para>

      <para>J'adresse des remerciements particuliers à Ken Yap, membre
      du projet &etb;, dont les commentaires ont beaucoup aidé à la
      qualité de ce guide</para>

      <para>Je remercie également Jerome Warnier, développeur
      principal du projet &plume;, Pierre Mondi&eacute;, Kyle Bateman,
      Peter T. Breuer, Charles Howes et Thomas Marteau pour leurs
      commentaires et leurs contributions.</para>

    </sect2>

    <sect2>
      <title>Plaidoyer <!-- NDT : advovacy, est-ce celà ? --> pour les stations
      sans disque</title>

      <sect3>

        <title>Acheter est plus rentable que construire</title>

        <para>Parfois, acheter une station linux sans disque sera
        moins co&ucirc;teux que de la construire. Consultez les sites dont
        les adresses figurent en annexe, qui sont ceux de sociétés
        vendant des cartes réseau ou des machines sans disque pour
        linux. Ces sociétés vendent des millions d'unités de machines
        produites en grande série, ce qui en réduit le co&ucirc;t
        unitaire.</para>

      </sect3>

      <sect3>
        <title>Avantages des stations sans disque</title>

        <para>Les ordinateurs sans disque deviendront de plus en plus
        populaires d'ici quelques années. Leur succès ira de paire
        avec l'arrivée sur le marché de cartes réseau haut débit à bas
        prix. Une carte offrant un débit de 100&nbsp;Mégabit (taux de
        transfert de 12,5&nbsp;Mo par seconde) est aujourd'hui
        répandue et, dans un ou deux ans, des cartes offrant des
        débits de 1000&nbsp;MBit (125&nbsp;Mo par seconde) deviendront
        accessibles et s'imposeront comme le standard.</para>

        <para>Dans un futur proche, les fabricants d'écrans y
        incluront le processeur, la carte réseau 
        et la mémoire afin d'en faire des ordinateurs sans disque. Ce
        qui permettra d'éliminer le boitier et d'économiser de la
        place. L'écran sera muni des prises pour clavier, souris,
        réseau et alimentation électrique.</para>

        <para>Les bénéfices à attendre d'une machine sans disque sont
        les suivants :</para>

        <itemizedlist mark="opencircle">

          <listitem>
            <para>Le co&ucirc;t total de possession d'une station sans
            disque est très bas. Le co&ucirc; de possession étant la
            somme des co&ucirc;t d'achat et de maintenance. Le
            co&ucirc;t de la maintenance est en généralement égal à
            trois à cinq fois celui de l'achat de l'ordinateur et
            augmente d'année en année. Dans le cas d'une solution sans
            disque, le co&ucirc;t de maintenance est éliminé.</para>
          </listitem>

          <listitem>
            <para>Toutes les sauvegardes sont centralisées sur un
            unique serveur central.</para>
          </listitem>

          <listitem>
            <para>Les onduleurs, conditionnements d'air, protections
            contre la poussière sont inutiles pour ces machines ;
            seuls les serveurs en ont la nécessité.</para>
          </listitem>

          <listitem>
            <para>Une meilleure résistance aux virus&nbsp;- certains
            virus informatiques ne peuvent s'attaquer à des machines
            dépourvues de disque. Seul le serveur central a besoin
            d'&ecirc;tre protégé contre ces attaques. Ainsi peut-on
            économiser plusieurs millions d'Euros en évitant
            l'installation des anti-virus et le nettoyage des
            disques.</para>
          </listitem>

          <listitem>
            <para>Les serveurs peuvent disposer de disques performants
            de grande capacité, l'utilisation de l'espace de stockage
            peut &ecirc;tre optimisée en le partageant entre les
            utilisateurs. La tolérance de panne peut &ecirc;tre mise
            en &oelig;uvre en utilisant des disques RAID sur le
            serveur.</para>
          </listitem>

          <listitem>
            <para>Sur certaines installations, il est possible de
            partager la mémoire vive du serveur entre les utilisateurs
            de plusieurs machines sans disque. Si un navigateur web
            est utilisé par plusieurs personnes, une seule copie de ce
            programme sera chargée en mémoire.</para>
          </listitem>

          <listitem>
            <para>Le nombre d'administrateurs système nécessaire à la
            maintenance d'un unique serveur est très réduit.</para>
          </listitem>

          <listitem>
            <para>Aucune administration du poste client. Les stations
            sans disque sont sans maintenance et sans soucis.</para>
          </listitem>

          <listitem>
            <para>La durée de vie d'une station sans disque est plus
            élevée.</para>
          </listitem>

          <listitem>
            <para>Les opérations d'installation et de mise à jour du
            matériel et du logiciel sont inutiles sur une machine sans
            disque.</para>
            </listitem>

          <listitem>
            <para>Les co&ucirc;t inhérents aux CD-ROM, disquettes,
            bandes, modem, onduleurs, imprimantes, etc, sont
            éliminés.</para>
          </listitem>

          <listitem>
            <para>Une machine sans disque peut &ecirc;tre utilisée
            dans des endroits comme des usines, où un disque dur
            serait trop fragile.</para>
          </listitem>

        </itemizedlist>

      </sect3>

    </sect2>

    <sect2>

      <title>Exigences</title>

      <sect3>

        <title>Exigences matérielles</title>

        <para>La chose la plus importante dont il faut disposer pour
        pouvoir amorçer un ordinateur par le réseau est d'avoir un
        équipement permettant à la station d'exécuter un gestionnaire
        d'amorçage , qui chargera le noyau
        sur le serveur et lançera son exécution. Une autre solution
        est d'utiliser un noyau local, sur un périphérique quelconque,
        qui montera un système de fichier racine situé sur le
        serveur. Il existe de multiples solutions : inscrire les
        instructions de démarrage sur une EPROM, utiliser une carte
        réseau supportant BOOTP/DHCP, utiliser une disquette, un
        disque dur de petite taille ou un CD-ROM pour charger le
        noyau. Notez que quelques fabricants vendent des ordinateurs
        en mesure de démarrer sur le réseau : certaines stations Sun
        implantent le protocole BOOTP.</para>

        <para>Les autres caractéristiques matérielles dépendent de
        l'usage que vous envisagez : sur certains sites, toutes les
        application s'exécutent du c&ocirc;té serveur, qui doit alors
        &ecirc;tre performant, mais les stations peuvent &ecirc;tre
        très légères : selon l'utilisation, un 80486 d&ocirc;té de
        16&nbsp;Mo de mémoire vive peut suffire. A l'opposé, si les
        applications s'exécutent sur le client, les exigences
        matérielles dépendent totalement de la nature de ces
        applications. Dans ce cas, un serveur léger peut suffire. Un
        80486 avec 32&nbsp;Mo de mémoire sera suffisant pour un nombre
        réduit de postes clients, mais davantage de mémoire sera
        nécessaire pour des installations plus vastes, comptant
        plusieurs centaines ou milliers de stations. Notez que le
        processeur du serveur n'est pas crucial pour de telles
        installations.</para>

        </sect3>

      <sect3>

        <title>Exigences logicielles</title>

        <para>Les sources de la version 2.0 ou plus récente du noyau
        Linux sont requises. Les outils indispensables à la
        compilation du noyau sont également nécessaires (reportez-vous
        à la documentation du noyau Linux pour plus d'information à
        ce sujet).</para>

        <para>Le démon BOOTP (DHCP serait bien, mais je n'expliquerai
        pas comment le configurer), un serveur NFS (si vous désirez
        monter le système de fichiers racine par le réseau), sont
        requis. Nous aurons besoin également du démon TFTP pour
        pouvoir charger le noyau à distance. Enfin, l'utilitaire
        mknbi, fourni avec la distribution <ulink
        url="&etburl;">&etb;</ulink> et, si vous utilisez une EPROM
        LanWorks, comme celles des cartes 3Com 3C905, vous aurez
        besoin du programme imggen, disponible à <ulink url="&imggenurl;">&imggenurl;</ulink>.</para>

        </sect3>

      </sect2>

    <sect2>

      <title>Références et documentation associée</title>

      <para>Cette documentation a été écrite à l'intention
      d'administrateurs systèmes expérimentés, rompus à la pratique de
      linux, comme l'utilisation de grep, sed et awk, la programmation
      shell, les processus et les scripts de démarrage, la compilation
      du noyau et la configuration d'un serveur NFS. Avoir
      l'expérience du passage d'arguments au noyau aidera. Des
      informations sur ces sujets peuvent &ecirc;tre trouvées dans les
      pages de manuel de grep, sed, awk, dans les pages de manuel et
      d'info du shell bash, dans les guides pratiques "Disquettes
      d'amorçage", "De la mise sous tension à la ligne de commande
      bash", "Noyau linux", "BootParam-HOWTO" 
<!-- NDT : rajouter les références des guides -->
, dans les pages de manuel
      de bootparam et de rdev, dans le guide pratique de NFS et sur la
      page de manuel d'exports. </para>

      <para>Il existe de multiples sources d'information concernant le
      démarrage sur réseau mais, et c'est pourquoi j'ai écrit ce
      guide, aucune ne décrit toutes les possibilités existantes, et
      la plupart sont spécifiques à une méthode. Celle qui m'a été la
      plus utile est la documentation fournie par <ulink
      url="&ltspurl;">&ltsp;</ulink>, bien que je n'ai pas utilisé le
      paquetage qu'elle recommande et que j'ai choisi de décrire ici
      comment procéder sans ces paquetages, car ils font le choix
      d'exécuter toutes les applications à distance sur le
      serveur. Des informations utiles sont également disponible sur
      la page du <ulink url="&etburl;">projet &etb;</ulink>.</para>

      <para>Enfin, vous pouvez trouver des informations utiles mais
      succintes dans l'arborescence des sources du noyau, dans le
      répertoire <filename class="directory">/usr/src/linux/Documentation</filename>,
      <filename class="directory">/usr/src/linux</filename> étant le
      répertoire où résident les sources du noyau.</para>

      </sect2>

    <sect2>

      <title>Retour d'expérience</title>

      <para>J'apprécierai particulièrement les retours d'expérience concernant ce
      document. N'hésitez pas à m'écrire à <email>&bbpmail;</email>
      pour me faire part de vos comentaires, corrections ou
      suggestions. Vous pouvez également utiliser l'adresse
      <email>contact@logilab.fr</email>.</para>

      </sect2>

    <sect2 id="copyright">

      <title>Mentions légales</title>

      <para>Ce document est protégé et distribué sous les termes de la
      licence de documentation libre GNU. Une copie de cette licence
      devrait &ecirc;tre fournie avec le document. Dans le cas
      contraire, celle-ci est disponible à <ulink
      url="http://www.fsf.org/licenses/fdl.html">http://www.fsf.org/licenses/fdl.html</ulink>.</para>

      </sect2>

  </sect1>

  <sect1>

    <title>Panorama du démarrage sans disque</title>

    <para>Vous pensez qu'il est temps de passer aux choses
    sérieuses ? C'est parti.</para>

    <sect2>

      <title>Récupérer les paramètres IP</title>

      <para>On peut se demander comment une station peut démarrer sur un
      réseau IP sans conna&icirc;tre son adresse IP. En pratique,
      trois protocoles permettent au client d'obtenir cette
      information, ainsi que certains paramètres supplémentaires de
      configuration :
      <itemizedlist mark="opencircle">

          <listitem>
            <para>RARP : le plus simple de ces protocoles. Cependant, je pense
qu'il ne permet pas au serveur de spécifier au client comment charger
le noyau aussi ne l'utiliserons-nous pas. Dans les faits, il existe
une convention utilisant l'adresse IP de la station comme nom de
fichier ; un client récupérant l'adresse 192.168.42.12 par RARP
téléchargerait le fichier <filename>/tftpboot/192.168.42.12</filename>
par tftp, comme le ferait le noyau linux. Le nom du fichier pourrait
aussi &ecirc;tre la forme hexadécimale de l'adresse IP, mais cette
solution est très dépendante de l'implémentation.</para>
          </listitem>
          
          <listitem>
            <para>BOOTP : ce protocole autorise un serveur à fournir davantage
d'informations à un client (identifié par son adresse MAC), en
particulier son adresse IP, le masque de sous-réseau, l'adresse de
diffusion, l'adresse réseau, celle de la passerelle, le nom
d'h&ocirc;te et le chemin d'accès au noyau. C'est la solution que nous
utiliserons.</para>
          </listitem>
          
          <listitem>
            <para>DHCP : une extension de BOOTP.</para>
          </listitem>
          
        </itemizedlist>

</para>

    </sect2>
    
    <sect2>
      <title>Charger le noyau</title>
      <para>Une fois que le client à récupéré son paramétrage IP, si le
noyau n'est pas disponible sur un support local quelconque (disquette,
CD-ROM, disque dur), le client le chargera par le protocole TFTP. Son
emplacement est fourni par le server BOOTP/DHCP. Un serveur (pas
nécessairement le serveur BOOTP/DHCP) devra exécuter le démon TFTP
pour les noyaux non locaux. Le noyau obtenu après compilation ne peut
pas &ecirc;tre utilisé en l'état avec BOOTP/DHCP ; l'image du noyau
doit &ecirc;tre modifiée gr&acirc;ce à l'utilitaire
<command>mknbi</command> (et modifiée de nouveau avec l'utilitaire
<command>imggen</command> si vous utilisez une EPROM
LanWorks). L'utilitaire <command>mknbi</command> devra également
&ecirc;tre utilisé pour modifier les noyaux qui seront inscrits sur
une ROM.</para>

    </sect2>
    
    <sect2>
      <title>Monter le système de fichiers racine</title>
      
      <para>Une fois le noyau lancé, il va tenter de monter son système de
fichiers racine. Sa localisation est obtenue par BOOTP/DHCP et il est
monté gr&acirc;ce à NFS. Cela signifie qu'un client utilisera deux
fois BOOTP pour démarrer : la première fois pour charger son noyau, la
seconde pour conna&icirc;tre l'emplacement de la racine (qui peut se
trouver sur un troisième serveur).</para>

      <para>Une autre solution consiste à utiliser un disque virtuel  comme racine. Dans ce cas, l'image du disque virtuel est chargée par TFTP.</para>

    </sect2>
    
    <sect2>
      <title>Terminer la procédure de démarrage</title>
      
      <para>Une fois le système de fichiers racine monté, vous pouvez
      commencer à respirer : vous pouvez au moins utiliser les lames
      sh, sed et awk de votre couteau suisse. Vous allez devoir
      modifier les scripts d'initialisation du système de fichier de
      vos clients : par exemple, vous devrez retirer tous les disques durs,
      disquettes ou CD-ROM qui apparaissent dans le fichier
      <filename>/etc/fstab</filename> (pour vos stations qui en sont
      dépourvues), il vous faudra inhiber l'activation des partitions
      de swap (notez qu'il existe une méthode permettant de monter une
      partition swap par NFS ou sur un périphérique réseau). Si
      plusieurs clients utilisent la m&ecirc;me racine distante, vous
      devrez aussi générer automagiquement tous les fichiers de
      configuration réseau au démarrage.</para>
      
    </sect2>

  </sect1>

  <sect1>

    <title>Construire le noyau</title>

    <para>En premier lieu, construire le noyau pour les clients. Je
    vous suggère d'effectuer cette opération sur le serveur, ce qui
    sera bien pratique pour l'installation des modules. Utilisez
    zImage pour réduire la taille du noyau. Incluez tout ce qui est
    nécessaire mais essayez d'utiliser autant de modules que possible
    car de nombreuses implantations clientes de BOOTP sont incapables
    de charger des noyaux volumineux (au moins sur les architectures
    Intel x86). Incluez le support d'iramdisk, du protocole NFS, de la
    racine sur NFS, le support de votre adaptateur réseau et celui de
    l'autoconfiguration IP par BOOTP ; <emphasis>n'utilisez pas de
    module pour ces fonctionnalités !</emphasis> Enfin, si vous avez
    l'intention d'utiliser la m&ecirc;me racine pour plusieurs
    clients, ajoutez le support du système de fichier ext2 ou autre,
    ainsi que le support des disques virtuels (un disque virtuel de
    16&nbsp;Mo conviendra sur la plupart des systèmes). Vous pouvez 
    modifier les arguments du noyau comme à l'habitude (voir le guide
    pratique "BootPrompt-HOWTO" à ce sujet), mais vous pourrez toujours
    le faire plus tard.</para>

    <para>Là, si vous envisagez de faire usage de BOOTP, copiez le
    noyau zImage sur le serveur. Nous supposerons qu'il réside dans le
    répertoire <filename class="directory">/tftpboot</filename>, que
    son nom est zImage, que le nom de l'image créée pour BOOTP à
    partir de zImage est kernel, et que la racine NFS est sous
    <filename class="directory">/nfsroot</filename>.</para>

    <para>Saisissez les commandes suivantes sur le serveur (le
    paquetage mknbi doit &ecirc;tre installé) :

    <programlisting>
<prompt># </prompt>cd /tftpboot
<prompt># </prompt>chmod 0555 zImage
<prompt># </prompt>chown root:root zImage
<prompt># </prompt>mknbi-linux zImage --output=kernel
--rootdir=/nfsroot
</programlisting>
</para>

    <para>Si vous utilisez des EPROM LanWorks, saisissez également les
    commandes suivantes (l'utilitaire imggen est nécessaire) :
<programlisting>
<prompt># </prompt>mv -f kernel tmpkernel
<prompt># </prompt>imggen -a tmpkernle kernel
<prompt># </prompt>rm -f tmpkernel
</programlisting>
</para>

    <para>Le noyau est près à &ecirc;tre utilisé avec BOOTP, DHCP ou
    sur une ROM. Ces opérations ne sont bien entendu pas nécessaires
    si vous comptez vous servir d'un support local au client.</para>

    <sect2>
      
      <title>Racine sur un disque virtuel</title>

      <para>Il est possible d'utiliser un disque virtuel pour le
      système de fichiers racine. Dans ce cas, la commande permettant
      de modifier l'image binaire du noyau quelque peu différente. Si
      vous choisissez cette option, il vous faudra permettre le
      support du disque virtuel initial (initrd), et vous pourrez
      peut-&ecirc;tre vous passer du support de NFS, ou le compiler en
      tant que module.</para>

      <para>Il est temps de s'intéresser à ce qui se passe quand vous
      utilisez initrd. La documentation complète est disponible dans
      les sources du noyau dans le fichier
      <filename>Documentation/initrd.txt</filename>. Je dois vous
      prévenir que je n'ai jamais essayé&nbsp;:).</para>

      <para>Quand initrd est activé, le gestionnaire de démarrage
      charge en premier le noyau et le disque virtuel initial en
      mémoire. Le disque virtuel est monté en lecture-écriture comme
      système de fichiers racine. Le noyau recherche un fichier nommé
      <filename>/linuxrc</filename> (un exécutable binaire ou un
      script commençant par #!). Quand <filename>/linuxrc</filename>
      se termine, la racine traditionnelle est montée sous
      <filename>/</filename>, et la séquence de démarrage normale est
      exécutée. Donc, pour permettre à la station de travailler
      entièrement sur le disque virtuel, il vous suffit de créer un
      lien de <filename>/linuxrc</filename> vers
      <filename>/sbin/init</filename>, ou d'écrire là  un script exécutant toutes les actions que vous désirez, et
      d'arr&ecirc;ter l'ordinateur.</para>

      <para>Une fois le noyau compilé, vous devez construire un
      système de fichiers racine pour votre installation. La méthode
      est expliquée dans la section "&clientsrootbuilding;". Je
      supposerai que cela est déjà fait et que la racine des clients
      est, temporairement, dans le répertoire <filename
      class="directory">/tmp/rootfs</filename>. Il faut maintenant
      créer l'image du disque virtuel. Une méthode simple est :

<itemizedlist mark="opencircle">

          <listitem>
            <para>Assurez-vous que l'ordinateur que vous utilisez
            dispose du support des disques virtuels et d'un tel
            périphérique (<filename>/dev/ram0</filename>).</para>
          </listitem>

          <listitem>
            <para>Créez un système de fichiers vide de la taille
            appropriée sur ce périphérique :
<programlisting>
<prompt># </prompt>mke2fs -m0 /dev/ram0 300
</programlisting>
</para>
            </listitem>

          <listitem>
            <para>Montez ce périphérique quelque part :
<programlisting>
<prompt># </prompt>mount -t ext2 /dev/ram0 /mnt
</programlisting>
</para>
            </listitem>

          <listitem>
            <para>Copiez tout ce qui est nécessaire dans votre
            nouvelle racine, et créez le futur
            <filename>/linuxrc</filename> si vous ne l'avez pas fait
            dans <filename>/tmp/rootfs/linuxrc</filename> :
<programlisting>
<prompt># </prompt>cp -a /tmp/rootfs/* /mnt
</programlisting>
</para>
            </listitem>

            <listitem>
            <para>Démontez le disque virtuel :
<programlisting>
<prompt># </prompt>umount /mnt
</programlisting>
</para>
            </listitem>
          
          <listitem>
            <para>Sauvegardez l'image du disque virtuel dans un
            fichier et libérez la :
<programlisting>
<prompt># </prompt>dd if=/dev/ram0 of=initrd bs=1024 count=300
<prompt># </prompt>freeramdisk /dev/ram0
</programlisting>
</para>
          </listitem>

        </itemizedlist>
Ce qui a été noté plus haut concernant les EPROM LanWorks est
également valable si vous utilisez initrd.
</para>
    
      <para>Maintenant, vous devez modifier l'image du noyau, comme
      expliqué plus haut, avec l'utilitaire
      <command>mknbi-linux</command>. La suite de commandes diffère 
      peu (je suppose que l'image du noyau est
      <filename>/tftpboot/zImage</filename> et que l'image du disque
      virtuel est <filename>/tmp/initrd</filename>) :

<programlisting>
<prompt># </prompt>cd /tftpboot
<prompt># </prompt>chmod 0555 zImage
<prompt># </prompt>chown root:root zImage
<prompt># </prompt>rdev zImage /dev/ram0
<prompt># </prompt>mknbi-linux zImage --output=kernel
--rootdir=/dev/ram0 /tmp/initrd
</programlisting>

</para>

      </sect2>

    </sect1>
  
  <sect1>
    <title>Configuration des démons</title>

    <sect2>
      <title>Démon NFS</title>

      <para>Contentez-vous d'exporter le répertoire dans lequel réside
      le système de fichiers racine du client (réferrez-vous à la page
      de manuel d'export pour plus d'information sur cet aspect). Le
      plus simple est d'exporter avec les attributs no_root_squash et
      rw, mais une configuration idéale exporterait la plus grande
      part de la racine avec les attributs root_squash et ro, et
      listerait, dans le fichier <filename>/etc/exports</filename>,
      tous les répertoires qui nécessitent réellement les attributs
      no_root_squash et/ou rw. Commencez avec les attributs
      rw et no_root_squash pour tout, le réglage fin sera fait plus
      tard.</para>

      <para>Bien s&ucirc;r, le serveur NFS est inutile si vous
      envisagez d'utiliser un disque virtuel sur vos clients.</para>

    </sect2>

    <sect2>
      <title>Démon BOOTP</title>

      <para>Je supposerai que le paquetage bootpd est installé. Le
      fichier de configuration par défaut est
      <filename>/etc/bootptab</filename>, et sa syntaxe est décrite
      dans la page de manuel de bootptab. Créons ce fichier.</para>

      <para>Lancez, en tant que root, votre éditeur favori. Vim. Si,
      si, c'est celui-là. Si ce n'est pas le cas, il doit le devenir. Maintenant, tapez les
      lignes suivantes (ce sont les attributs par défaut). Tous les
      attributs que vous définissez ici, et qui ne sont redéfinis dans
      aucune liste d'attributs spécifique à une machine, seront
      valables pour tous les clients :
<programlisting>
       .default\
                :sm=votre masque de sous-réseau\
                :ds=adresse IP du serveur de noms \
                :ht=ethernet\
                :dn=nom de domaine\
                :gw=adresse IP de la passerelle\
                :sa=adresse IP du serveur TFTP\
                :bf=chemin d'accès à l'image du noyau\
                :rp=chemin d'accès à la racine\
                :hn
      </programlisting>

Bien entendu, tous ces paramètres ne sont pas indispensables, et
dépendent de la configuration du réseau et de l'implémentation de
BOOTP utilisée, mais cela fonctionnera dans la plupart des cas.</para>

      <para>Maintenant, ajoutez une entrée pour chacun des clients de
      votre réseau. Une entrée se présente sous la forme :

<programlisting>
        nom du client\
                :ha=adresse MAC du client\
                :ip=adresse IP du client
      </programlisting>

L'adresse MAC est l'adresse matérielle du client en hexadécimal, sans
les ':'.</para>

      <para>Voici un exemple de fichier
      <filename>/etc/bootptab</filename> :

      <programlisting>
              .default\
                      :sm=255.255.0.0\
                      :ds=192.168.0.2\
                      :ht=ethernet\
                      :dn=frtest.org\
                      :gw=192.168.0.1\
                      :sa=192.168.0.2\
                      :bf=/tftpboot/kernel\
                      :rp=/nfsroot\
                      :hn

              foo\
                      :ha=001122334455\
                      :ip=192.168.2.12

              bar\
                      :ha=00FFEEDDCCBB\
                      :ip=192.168.12.42\
                      :ds=192.168.2.42
      </programlisting>

</para>

      <para>Enfin, lancez le démon bootpd avec la commande
      bootpd&nbsp;-s (il est judicieux d'ajouter cette commande dans
      vos scripts de démarrage), ou ajoutez la ligne suivante à votre
      fichier <filename>/etc/inetd.conf</filename> :

      <programlisting>
        bootps dgram udp wait root /usr/sbin/tcpd&nbsp;bootpd -i -t 120
      </programlisting>

    </para>

      <para>Si vous désirez tester le serveur BOOTP, ajoutez une
      entrée dans le fichier <filename>/etc/bootptab</filename> et
      utilisez le programme bootptest.</para>

    </sect2>

    <sect2>
      <title>TFTP</title>

      <para>Configurer le serveur TFTP n'est pas la partie difficile :
      installez le paquetage tftpd si vous l'avez, et ajoutez la ligne
      suivante à votre fichier <filename>/etc/inetd.conf</filename>
      (de nouveau, je suppose que <filename
      class="directory">/tftpboot</filename> est le répertoire
      contenant l'image du noyau) :

      <programlisting>
        tftp dgram udp wait root /usr/sbin/tcpd in.tftpd /tftpboot
      </programlisting>

N'oubliez pas de modifier les droits sur le répertoire 
<filename class="directory">/tftpboot</filename> (chmod&nbsp;555) le
serveur TFTP n'enverra pas les fichiers s'ils ne sont pas lisible par
tout le monde.</para>

      <para>Vous devez &ecirc;tre conscient des limitations imposées
      par l'utilisation du démon TFTP à partir d'inetd. La plupart des
      implémentations arr&ecirc;terons un service s'il est appelé trop
      souvent <!-- NDT : if it is spawned to frequently ? -->. Aussi,
      si vos clients sont nombreux, cherchez plut&ocirc;t du
      c&ocirc;té d'xinetd, ou lancez le démon TFTP isolément.</para>

      <para>Maintenant que tous les démons sont correctement
      configurés, vous pouvez relancer inetd et boire un
      café. N'oubliez pas de dire à tout le monde que la configuration
      du serveur est finie, pour pouvoir passer pour un héros avant
      d'entamer la construction du système de fichiers racine de vos
      clients.</para>

    </sect2>

  </sect1>

  <sect1>
    <title>&clientsrootbuilding;</title>

    <para>Fatigué ? Non, vous ne l'&ecirc;tes pas. Souvenez-vous que
    vous &ecirc;tes un héros. Ici commence la partie délicate. Nous
    allons (err... <emphasis>vous</emphasis> allez) construire la
    racine des clients. Ce ne devrait pas &ecirc;tres très difficile,
    mais préparez vous à de nombreux essais et erreurs.</para>

    <para>La méthode la plus simple pour créer le système de fichiers
    racine est d'utiliser un système de fichiers existant et de
    l'adapter aux besoins. Bien s&ucirc;r, vous pouvez le construire à
    la main (comme au bon vieux temps) si cela vous dit :=), mais je
    n'expliquerai pas cela ici.</para>

    <sect2>
      <title>Créer les premiers fichiers et répertoires</title>

      <para>Tout d'abord, déplacez vous dans le futur répertoire
      racine de vos stations. Vous pouvez facilement créer le
      répertoire <filename class="directory">/home</filename> par la
      commande <command>mkdir</command>, ou en le copiant à partir
      d'où vous voulez (utilisez la commande
      <command>cp&nbsp;-a</command> pour effectuer une copie récursive
      préservant les propriétaires, groupes, liens symboliques et
      permissions). M&ecirc;me chose pour les répertoires <filename
      class="directory">/mnt</filename>, <filename
      class="directory">/root</filename>, <filename class="directory">/tmp</filename> (n'oubliez pas
      <command>chmod&nbsp;0</command> sur ce dernier, puisqu'il n'est
      qu'un point de montage du <filename
      class="directory">/tmp</filename> réel que nous utiliserons, car
      chaque station a besoin de son propre répertoire <filename
      class="directory">/tmp</filename>). Copiez les répertoires
      <filename class="directory">/bin</filename>, <filename class="directory">/sbin</filename>, <filename
      class="directory">/boot</filename> et <filename
      class="directory">/usr</filename> existant dans le futur
      répertoire racine (commande
      <command>cp&nbsp;-a</command>). Vous pouvez créer le répertoire
      <filename class="directory">/proc</filename> avec mkdir, et
      utiliser <command>chmod&nbsp;0</command> dessus. Notez que
      certaines applications ont besoin d'un accès en écriture sur le
      répertoire de leur utilisateur.</para>

      <para>Le répertoire <filename class="directory">/lib</filename>
      peut &ecirc;tre copié sans danger de n'importe où, mais vous
      devrez y installer les modules qui conviennent. Pour ce faire,
      utilisez les commandes suivantes (considérant que le noyau
      compilé pour les clients réside sur le serveur dans <filename
      class="directory">/usr/src/linux</filename>, et que la racine
      est dans <filename class="directory">/nfsroot</filename>) :

<programlisting>
<prompt># </prompt>cd /usr/src/linux
<prompt># </prompt>make modules_install INSTALL_MOD_PATH=/nfsroot
</programlisting>

</para>

      <para>N'oubliez pas de placer le fichier
      <filename>System.map</filename> dans le répertoire <filename
      class="directory">/nfsroot/boot</filename>. Un premier problème
      que nous aurons à résoudre est que, en fonction de votre
      configuration, le système peut essayer de lancer fsck sur la
      racine au démarrage. Impossible sans disque dur. La plupart des
      distributions omettrons fsck si un fichier
      <filename>fastboot</filename> est présent dans le répertoire
      racine. Aussi, tapez les commandes suivantes si vous ne comptez
      pas monter de disque dur :

<programlisting>
<prompt># </prompt>cd /nfsroot
<prompt># </prompt>touch fastboot
<prompt># </prompt>chmod 0 fastboot
</programlisting>

Une autre méthode consiste à indiquer à <command>fsck</command> que la
vérification d'un système de fichiers NFS réussit à chaque fois :

<programlisting>
<prompt># </prompt>cd /nfsroot/sbin
<prompt># </prompt>ln -s ../bin/true fsck.nfs
</programlisting>

</para>

      <para>Le répertoire <filename class="directory">/dev</filename>
      peut &ecirc;tre copié d'un autre emplacement vers <filename
      class="directory">/nfsroot</filename>. Les permissions et les
      liens symboliques devant &ecirc;tre préservés, utilisez la
      commande <command>cp&nbsp;-a</command>. Une autre solution est
      d'utiliser la fonctionnalité devfs des noyaux 2.2.x, qui réduit
      la consommation mémoire tout en augmentant les performances,
      mais le défaut de cette méthode est que tous les liens
      symboliques existant dans <filename
      class="directory">/dev</filename> seront perdus. Le point à
      garder à l'esprit est que chaque station a besoin de son propre
      répertoire <filename class="directory">/dev</filename>, aussi
      vous devrez le copier sur un disque virtuel si vous voulez avoir
      plusieurs clients et ne pas utiliser devfs.</para>
      
    </sect2>

    <sect2>
      <title>Les répertoires <filename class="directory">/var</filename> et <filename class="directory">/etc</filename></title>
      
      <para>Nous utiliserons des disques virtuels pour ces
      répertoires, chaque client devant avoir les siens propres. Mais
      nous en avons encore besoin au début pour créer leur structure
      standard. Notez que cela n'est pas nécessaire si vous n'avez
      qu'un seul client. Copiez donc ces répertoires
      (<command>cp&nbsp;-a</command>) dans <filename
      class="directory">/nfsroot</filename>. Vous pouvez alors faire
      un peu de ménage dans <filename class="directory">/var</filename>
      : vous pouvez effacer tout le contenu de <filename class="directory">/nfsroot/var/log</filename> et de <filename class="directory">/nfsroot/var/run</filename>. Vous pouvez
      probablement effacer également le contenu de <filename class="directory">/nfsroot/var/spool/mail</filename> si vous
      comptez exporter ce répertoire via NFS. Vous devrez enfin
      supprimer les fichiers contenant des informations spécifiques à
      la machine présents dans <filename class="directory">/nfsroot/etc</filename> pour les
      construire à la volée durant le processus de démarrage.</para>

      <para>Les scripts de démarrage doivent &ecirc;tre modifiés afin de
pouvoir monter certaines parties de l'arborescence : le répertoire
<filename class="directory">/dev</filename> si vous n'utilisez pas
devfs, les répertoires <filename class="directory">/tmp</filename>,
<filename class="directory">/var</filename> et <filename class="directory">/etc</filename>. Le code suivant effectue ces modifications :

<programlisting>
        # cette partie uniquement si vous n'utilisez pas devfs
        mke2fs -q -i 1024 /dev/ram0 16384
        mount -n -t ext2 -o rw,suid,dev,exec, \
            async,nocheck /dev/ram0 /dev
        # cette partie dans tous les cas
        mke2fs -q -i 1024 /dev/ram1 16384
        mount -n -t ext2 -o rw,suid,dev,exec, \
            async,nocheck /dev/ram1 /tmp
        chmod 1777 /tmp
        cp -a /etc /tmp
        mke2fs -q -i 1024 /dev/ram2 16384
        mount -n -t ext2 -o rw,suid,dev,exec, \
            async,nocheck /dev/ram2 /etc
        find /tmp/etc -maxdepth 1 -exec cp -a '{}' /etc ';'
        mount -f -t ext2 -o rw,suid,dev,exec, \
            async,nocheck,remount /dev/ram2 /etc
        mount -f -o remount /
        cp -a /var /tmp
        mke2fs -q -i 1024 /dev/ram3 16384
        mount -t ext2 -o rw,suid,dev,exec, \
            async,nocheck /dev/ram3 /var
        find /tmp/var -maxdepth 1 -exec cp -a '{}' /var ';'
      </programlisting>

</para>

      <para>Dans le cas où vous aurez plus d'un seul client, vous
      devrez changer dynamiquement au démarrage certains fichiers
      contenus dans <filename class="directory">/etc</filename> : ceux
      contenant l'adresse IP et le nom d'h&ocirc;te du client. Ces
      fichiers dépendent des distributions mais vous les retrouverez
      aisément avec grep. Contentez-vous de retirer de ces fichiers
      toutes les informations spécifiques à un client, et ajouter le
      code permettant la génération de ces informations lors du
      démarrage, <emphasis>mais uniquement une fois que le nouveau
      <filename class="directory">/etc</filename> a été monté sur le
      disque virtuel !</emphasis> Ci-dessous une méthode permettant
      d'obtenir l'adresse IP et le nom d'h&ocirc;te lors du démarrage
      (si bootpc est installé dans l'arborescence des stations) :
      <programlisting>
        IPADDR="$(bootpc | awk '/IPADDR/ \
                                {
                                  match($0,"[A-Za-z]+")
                                  s=substr($0,RSTART+RLENGTH)
                                  match(s,"[0-9.]+")
                                  print substr(s,RSTART,RLENGTH)
                                }
                               ')"

        HOST="$(bootpc | awk '/HOSTNAME/ \
                              {
                                match($0,"[A-Za-z]+")
                                s=substr($0,RSTART+RLENGTH)
                                match(s,"[A-Za-z0-9-]+")
                                print substr(s,RSTART,RLENGTH)
                              }')"

        DOMAIN="$(bootpc | awk '/DOMAIN/ \
                                {
                                  match($0,"[A-Za-z]+")
                                  s=substr($0,RSTART+RLENGTH)
                                  match(s,"[A-Za-z0-9-.]+")
                                  print substr(s,RSTART,RLENGTH)
                                }')"
      </programlisting>

C'est une solution compliquée mais je pense qu'elle fonctionne sur la
plupart des sites. On peut trouver l'adresse IP gr&acirc;ce à la
commande <command>ifconfig</command> et le nom d'h&ocirc;te par la
commande <command>host</command> mais cela n'est pas portable, car les
sorties diffèrent entre les systèmes, en fonction de la distribution
utilisée et du paramétrage local.</para>

      <para>Là, le nom d'h&ocirc;te pourra &ecirc;tre déterminé avec
      la commande <command>hostname&nbsp;$HOSTNAME</command>. Une fois
      ceci fait, il est temps de générer à la volée les fichiers de
      configuration contenant l'adresse IP ou le nom d'h&ocirc;te du
      client.</para>

      </sect2>

    <sect2>
      <title>Derniers détails</title>

      <para>On peut maintenant passer aux réglages fins. Comme
      <filename class="directory">/var</filename> sera monté sur un
      disque virtuel (suaf si vous n'avez qu'un seul client), vous
      devrez sauvegarder les logs sur un serveur, si vous voulez les
      conserver. Une méthode pour ce faire consiste à supprimer le
      fichier <filename>/nfsroot/etc/syslog.conf</filename> et à le
      remplacer par le fichier suivant (man syslog.conf pour plus de
      détails) :

      <programlisting>
        *.*     /dev/tty12
        *.*     nom ou adresse IP du serveur contenant les logs
      </programlisting>

Avec cette méthode, le serveur de logs devra faire tourner
<command>syslogd</command> avec l'option -r (reportez-vous à la page
de manuel de syslogd).</para>

      <para>Si vous utilisez <command>logrotate</command> et avez
      effectué les opérations précédentes, vous devrez remplacer le
      fichier de configuration de <command>logrotate</command>
      (<filename>/etc/logrotate.conf</filename> sur la plupart des
      machines) par un fichier vide :

      <programlisting>
        <prompt># </prompt>rm -f /etc/logrotate.conf
        <prompt># </prompt>touch /etc/logrotate.conf
      </programlisting>

Si vous n'en faites pas usage, contentez-vous de retirer les scripts
de rotation des logs de la crontab et, tant que vous n'aurez pas de
fichiers de log dans <filename>/var/log</filename>, placez
<command>exit&nbsp;0</command> au début de vos scripts de
rotation.</para>

      <para>Retirez du fichier <filename>/nfsroot/etc/fstab</filename>
      toutes les références à des disques durs, lecteurs de disquettes
      ou CD-ROM qui sont absents de vos stations clientes. Ajoutez une
      entrée pour le répertoire <filename
      class="directory">/var/spool/mail</filename>, qui pourrait
      &ecirc;tre exporté par le serveur par NFS ou par tout autre système de fichiers
      réseau. Vous pourrez vouloir également ajouter une entrée pour
      <filename class="directory">/home</filename> dans ce fichier.</para>
      <para>Vous pouvez également mettre en commentaire les lignes
      exécutant newaliases, activant le swap, et exécutant
      depmod&nbsp;-a et également supprimer le fichier
      <filename>/nfsroot/etc/mtab</filename>. Retirez les commentaires
      <!-- Comment out ? --> des lignes de vos fichiers de démarrage
      concernant <filename>/fastboot</filename>,
      <filename>/fsckoptions</filename>, et
      <filename>/forecfsck</filename>. Retirez également ou mettez en
      commentaires toutes les lignes des scripts de démarrage qui
      tenteraient d'écrire sur le système de fichiers racine, à
      l'exception des accès en écriture réellement nécessaires, qui
      devraient tous &ecirc;tre redirigés vers l'emplacement d'un
      ramdisk si vous utilisez plusieurs clients.</para>

    </sect2>

    <sect2>

      <title>Essais...</title><!-- Trial -->

      <para>Le temps est venu d'un petit essai. SAUVEGARDEZ TOUS LES
      <filename>/nfsroot</filename> NOUVELLEMENT
      CREES. tar&nbsp;-cvvIf devrait faire cela à merveille. Prenez
      également le temps de vérifier que vous n'avez rien oublié. Et
      tentez de démarrer un client.</para>

    </sect2>

    <sect2>

      <title>Une erreur !</title>

      <para>Regardez attentivement l'écran de la station cliente
      pendant la phase de démarrage. Excusez-moi ! j'ai omis de vous
      dire de connecter un écran... Cours, Forest ! Cours et
      rapportes-en un. Des messages d'erreur vont probablement
      s'afficher. Résolvez les problèmes et effectuez de fréquentes
      sauvegardes du répertoire <filename
      class="directory">/nfsroot</filename>. Un jour, le client
      démarrera proprement. Pour l'heure, vous allez devoir résoudre
      les problèmes apparaissant pendant la séquence d'arr&ecirc;t
      ;=P.</para>

    </sect2>

  </sect1>
    
  <sect1>

    <title>Différentes manières de récupérer le noyau</title>

    <para>Nous avons parlé plus haut de la configuration du client et
    du serveur en vue des opérations s'exécutant une fois que le
    client a terminé la requ&ecirc;te bootp, mais le premier soucis
    est que la plupart des ordinateur est incapable de fonctionner par
    défaut comme client bootp. Nous allons voir dans cette section
    comment résoudre ce problème.</para>

    <sect2>

      <title>Interfaces réseaux à capacités bootp ou DHCP</title>

      <para>C'est le cas le plus simple : certaines cartes réseau
      fournissent une extension du BIOS contenant un client bootp ou
      DHCP, aussi il suffit de configurer les opérations bootp ou DHCP
      dans le BIOS, et tout est dit.</para>

    </sect2>

    <sect2>

      <title>Noyau sur disquette ou disque dur local</title>

      <para>Ces deux cas de figure sont assez simples : le noyau est
      chargé depuis le support local, et tout ce qu'il doit faire est
      de récupérer ses paramètres réseau par bootp et de monter le
      système de fichiers racine par NFS ; cela ne devrait poser aucun
      problème. D'autre part, un disque dur local est un excellent
      endroit pour loger les répertoire <filename
      class="directory">/var</filename>, <filename
      class="directory">/tmp</filename>, et <filename
      class="directory">/dev</filename>...</para>

      <para>Si vous disposez d'un disque dur local, tout ce que vous
      avez à faire est d'utiliser lilo ou votre chargeur de démarrage
      préféré, comme d'habitude. Si vous utilisez une disquette, vous
      pouvez utilisez le chargeur, ou simplement y écrire le noyau :
      un noyau est directement chargeable. Vous pouvez utiliser une
      commande comme :

<programlisting>
<prompt># </prompt>dd if=zImage of=/dev/fd0 bs=8192
</programlisting>

</para>

      <para>Cependant, Alan Cox a écrit dans une discussion au sujet
      du noyau linux que cette fonctionnalité sera retirée t&ocirc;t
      ou tard, aussi devrait vous un jour utiliser un chargeur de
      démarrage également sur les disquettes. Je sais que cela
      fonctionne toujours avec un noyau 2.4.11, mais le support semble
      en avoir été retiré dans la version 2.4.13. Voyez le chapitre
      six du <ulink url="&bootdiskhowtourl;">boot-disk-HOWTO</ulink> à
      ce sujet.</para>

    </sect2>

    <sect2>

      <title>Chargeur de démarrage sans noyau sur un support
      local</title>

      <para>Certains chargeurs de démarrage ont des capacités réseau,
      aussi devriez vous utilisez ceux là pour chargeur l'image du
      noyau par le réseau. Quelques-un sont listés ci-dessous :</para>

      <itemizedlist mark="opencircle">

        <listitem>
          <para><ulink url="&ntburl;">&ntb;</ulink>, chargeur dédié au
          démarrage réseau.</para>
        </listitem>
        
        <listitem>
          <para><ulink url="&gruburl;">&grub;</ulink>, le chargeur du
          projet GNU (GRand Unified Bootloader), de portée
          vaste.</para>
        </listitem>

      </itemizedlist>

    </sect2>

    <sect2>

      <title>Créer les ROM des clients</title>

      <para>De nombreuses cartes réseau comportent un slot permettant
      l'insertion d'une EPROM contenant du code BIOS additionnel. Cela
      permet d'ajouter, par exemple, des fonctionnalités bootp au
      BIOS. Pour ce faire, il convient tout d'abord de trouver comment
      activer la prise supportant l'EPROM. Il peut &ecirc;tre
      nécessaire d'agir sur un cavalier ou d'utiliser un logiciel
      spécifique. Quelques cartes, telles la 905B de 3Com, disposent
      de branchements pour EEPROM, ce qui permet de modifier le
      logiciel embarqué dans l'EEPROM. En annexe, vous trouverez des
      informations sur les EPROM et sur les différents types de
      composant de mémoire.</para>

      <para>Pour obtenir la liste des fabricants de br&ucirc;leurs
      d'EPROM, reportez-vous au site Yahoo, dans le répertoire <ulink
      url="http://dir.yahoo.com/Business_and_Economy/Companies/Computers/Hardware/Peripherals/Device_Programmers/">Economie->Entreprises->Matériel->Périphériques->Programmateurs</ulink>
      <!-- lien à vérifier en français --> ou reportez-vous au guide
      pratique Diskless-HOWTO, section <emphasis>Liste des fabricants
      de br&ucirc;leurs d'EPROM</emphasis>.</para>

      <para>Si vous choisissez de créer vos propres ROM, vous devrez y
      charger un logiciel bootp ou DHCP et alors, vous vous
      retrouverez dans la configuration d'une carte réseau possédant
      ces caractéristiques, tel que décrit plus haut.</para>

      <para>Vous devrez également trouver la taille et la vitesse
      d'EPROM appropriés à votre adaptateur réseau. Des méthodes pour
      ce faire sont fournies en annexe, car les fabricants de cartes
      fournissent rarement ces informations.</para>

      <sect3>

        <title>EPROM LanWorks</title>

        <para>Cette précision peut vous sauver. Pour permettre à une
        EPROM LanWorks BootWare (tm) de démarrer correctement une
        image du noyau linux, la partie "bootsector" de l'image doit
        &ecirc;tre modifiée pour permettre à la PROM de "sauter"
        directement à l'adresse de démarrage de l'image. L'image créée
        par l'utilitaire `mknbi-linux` est différente et ne
        fonctionnera pas avec une PROM BootWare.</para>

        <para>Vous pouvez trouver le bootsector modifié ainsi qu'un
        Makefile permettant la création d'une image compatible
        BootWare aux adresses :

<itemizedlist mark="opencircle">

          <listitem>
            <para>Paquetage Bwimage : <ulink url="ftp://ftp.ipp.mpg.de/pub/ipp/wls/linux/bwimage-0.1.tgz">ftp://ftp.ipp.mpg.de/pub/ipp/wls/linux/bwimage-0.1.tgz</ulink></para>
          </listitem>

          <listitem>
            <para>Voir aussi <ulink url="http://www.patoche.org/LTT/net/00000096.html">http://www.patoche.org/LTT/net/00000096.html</ulink></para>
          </listitem>

          <listitem>
            <para>ROM de démarrage LanWorks BootWare : <ulink url="http://www.3com.com/lanworks">http://www.3com.com/lanworks</ulink></para>
          </listitem>

        </itemizedlist>

</para>

        <para>Reportez-vous au fichier README pour les détails
        concernant l'installation. Le plus souvent, seules les images
        du type "zImage" sont supportées. Malheureusement, les
        paramètres noyau sont ignorés.</para>

        <para>Cette section a été initialement écrite par Jochen
        Kmietsch pour le guide pratique "Machines sans disque" ; posez
        vos questions par courrier électronique à
        <email>jochen.kmietsch@tu-clausthal.de</email>.</para>

      </sect3>

    </sect2>

    <sect2>

      <title>CD-ROM local</title>

      <para>Cette section a originellement été écrite par Hans de
      Goede (<email>j.w.r.degoede@et.tudelft.nl</email>) pour le guide
      pratique "Système de fichiers racine sur NFS". Je l'ai juste
      modifié dans la mesure nécessaire pour rendre compte des
      différences entre le présent document et le guide pratique
      "Système de fichiers racine sur NFS".</para>

      <para>La majeure partie de ce qui est écrit ci-dessus est
      également valable pour le démarrage par CD-ROM. Pourquoi vouloir
      démarrer une machine depuis le lecteur de CD-ROM ? Le démarrage
      sur un CD-ROM est surtout intéressant pour des applications très
      spécifiques, comme un kiosque, une base de données de
      bibliothèque, un net-café, ou pour celui qui n'a pas de réseau
      ou de serveur pour permettre l'usage d'un système de fichiers
      racine sur réseau.</para>

      <sect3>

        <title>Créer une configuration test</title>

        <para>Maintenant que nous savons ce que nous voulons faire et
        comment, il est temps de réaliser une configuration test.</para>

        <itemizedlist mark="opencircle">

          <listitem>
            <para>Au début, premez seulement l'une des machines que
            vous désirez utiliser et branchez dessus un gros disque
            dur et un graveur de CD.</para>
          </listitem>

          <listitem>
            <para>Installez le linux de votre choix sur cette machine,
            en veillant à conserver une partition libre de
            650&nbsp;Mo. Cette installation servira à la création
            d'une image ISO et au gravage d'un CD-ROM, aussi prévoyez
            les logiciels nécessaires. Elle servira également à
            réparer les défauts qui emp&ecirc;cheraient le démarrage
            de la configuration test.</para>
          </listitem>

          <listitem>
            <para>Sur la partition de 650Mo, installez linux avec la
            configuration que vous désirez obtenir sur le CD ; ce sera
            la configuration de test.</para>
          </listitem>

          <listitem>
            <para>Démarrez la configuration test.</para>
          </listitem>
          
          <listitem>
            <para>Compilez un noyau avec les supports isofs et cdrom
            inclus (pas en modules).</para>
          </listitem>

          <listitem>
            <para>Configurez l'installation de test comme décrit plus
            haut, avec le système de fichiers racine en lecture
            seule.</para>
          </listitem>

          <listitem>
            <para>Vérifiez que la configuration de test démarre
            automagiquement et que tout fonctionne.</para>
          </listitem>

          <listitem>
            <para>Démarrez votre installation principale (la première,
            voir ci-dessus) et montez la partition de 650Mo dans le
            répertoire <filename class="directory">/test</filename> de
            l'installation principale.</para>
          </listitem>

          <listitem>
            <para>Insérez les lignes suivantes dans un fichier nommé
            <filename>/test/etc/rc.d/rc.iso</filename> qui sera exécuté
            au démarrage de <filename>rc.sysinit</filename> pour créer
            le répertoire <filename class="directory">/var</filename>
            :
<programlisting>
                #/var
                echo Creating /var ...
                mke2fs -q -i 1024 /dev/ram1 16384
                mount /dev/ram1 /var -o defaults,rw
                cp -a /lib/var /
              </programlisting>
            </para>
          </listitem>

          <listitem>
            <para>Editez le fichier
            <filename>/test/etc/rc.sysint</filename>, mettez en
            commentaires les lignes dans lesquelles le système de
            fichier racine est remonté en lecture-écriture (rw), et
            ajoutez les deux lignes suivantes directement après la
            configuration de PATH :
              <programlisting>
                #to boot from cdrom
                . /etc/rc.d/rc.iso
              </programlisting>
            </para>
          </listitem> 

          <listitem>
            <para>Copiez les lignes suivantes dans un script et
            exécutez le afin de créer un répertoire <filename
            class="directory">/var</filename> générique et créer les
            liens vers <filename class="directory">/tmp</filename> et
            <filename>/etc/mtab</filename>.
              <programlisting>

                #!/bin/sh
                echo tmp
                rm -fR /test/tmp
                ln -s var/tmp /test/tmp

                ###
                echo mtab
                touch /test/proc/mounts
                rm /test/etc/mtab
                ln -s /proc/mounts /test/etc/mtab

                ###
                echo var
                mv /test/var/lib /test/lib/var-lib
                mv /test/var /test/lib
                mkdir /test/var
                ln -s /lib/var-lib /test/lib/var/lib
                rm -fR /test/lib/var/catman
                rm -fR /test/lib/var/log/httpd
                rm -f /test/lib/var/log/samba/*
                for i in `find /test/lib/var/log -type f`; do
                  cat /dev/null > $i;
                done
                rm `find /test/lib/var/lock -type f`
                rm `find /test/lib/var/run -type f`

              </programlisting>

            </para>
          </listitem>

          <listitem>
            <para>Retirez ce qui a trait à la création de
            <filename>/etc/issue*</filename> du fichier
            <filename>/test/etc/rc.local</filename> : ce ne peut
            qu'échouer.</para>
          </listitem>

          <listitem>
            <para>Maintenant, démarrez la partition de test de
            nouveau, elle sera lue exactement comme si elle était sur
            CD-ROM. Si quelque chose ne fonctionne pas, redémarrez
            l'installation de travail pour résoudre le problème et
            relancez l'installation de test de nouveau. Pour remonter
            la racine (<filename class="directory">/</filename>) en
            lecture-écriture (rw), tapez :

<programlisting>
<prompt># </prompt>mount -o remount,rw /
</programlisting>
</para>
            </listitem>

          </itemizedlist>


        
      </sect3>

      <sect3>

        <title>Créer le CD</title>

        <para>S'il vous faut davantage d'informations que celles
        fournies ci-dessous, référez-vous au guide pratique "Gravure
        de CD-ROM".</para>

        <sect4>

          <title>Créer une image lançable</title>

          <para>En premier lieu, démarrez l'installation de
          travail. Pour créer un CD lançable, nous avons besoin d'une
          disquette lançable. Utiliser simplement dd sur un fichier zImage ne
          fonctionne pas car le chargeur situé au début du fichier
          zImage ne semble pas apprécier le "faux lecteur de
          disquette" créé par un CD lançable. Aussi allons-nous
          utiliser syslinux à la place.</para>

          <itemizedlist mark="opencircle">

            <listitem>
              <para>Récupérez le fichier boot.img d'un CD
              RedHat</para>
            </listitem>

            <listitem>
              <para>Montez ce fichier n'importe où au travers de
              l'interface loopback :
              <programlisting>
<prompt># </prompt>mount boot.img nimporteoù -o loop -t vfat
</programlisting>
</para>
            </listitem>

            <listitem>
              <para>Retirez tout de boot.img, à l'exception de ce qui
              concerne ldlinux.sys et syslinux.cfg.</para>
            </listitem>

            <listitem>
              <para>Copiez l'image du noyau de la partition de test
              dans boot.img.</para>
            </listitem>

            <listitem>
              <para>Editez le fichier
              <filename>syslinux.cfg</filename> pour qu'il contienne
              les lignes suivantes, en remplaçant bien entendu
              <filename>zImage</filename> par le nom de votre image :
              <programlisting>

                default linux 

                label linux
                kernel zImage
                append root=/dev/&lt;le nom de périphérique de votre
                lecteur de CD-ROM&gt;

              </programlisting>

            </para>

            </listitem>

            <listitem>
              <para>Démontez boot.img :
<programlisting>
<prompt># </prompt>umount nimporteoù
</programlisting>
</para>
            </listitem>
            
            <listitem>
              <para>Si <filename>/etc/mtab</filename> est un lien vers
              <filename>/proc/mounts</filename>, umount ne libérera
              pas automagiquement <filename>/dev/loop0</filename>,
              aussi libérez le par :
<programlisting>
<prompt># </prompt>losetup -d /dev/loop0
</programlisting>
</para>
            </listitem>
          </itemizedlist>



        </sect4>
        
        <sect4>

          <title>Créer l'image ISO</title>

          <para>Maintenant que nous avons une image lançable et une
          installation capable de démarrer sur un support en lecture
          seule, il est temps de créer l'image ISO du CD :

<itemizedlist mark="opencircle">

              <listitem>
                <para>Copiez boot.img dans <filename
                class="directory">/test</filename></para>
              </listitem>
              
              <listitem>
                <para>Déplacez vous dans le répertoire où vous désirez
                créer l'image et assurez vous que la partition en
                question dispose de suffisament d'espace libre.</para>
              </listitem>

              <listitem>
                <para>Créez l'image avec :
                <programlisting>
                  <prompt># </prompt>mkisofs -R -b boot.img -c boot.catalog -o boot.iso /test
                </programlisting>
              </para>
            </listitem>

          </itemizedlist>

</para>

        </sect4>

        <sect4>
          
          <title>Vérifier l'image ISO</title>

          <para>
<itemizedlist mark="opencircle">

              <listitem>
                <para>Montez l'image par l'intermédiaire du
                périphérique loopback :
                <programlisting>
                  <prompt># </prompt>mount boot.iso quelquepart -o loop -t iso9660
                </programlisting>
              </para>
              </listitem>

              <listitem>
                <para>Démontez boot.iso :
                <programlisting>
                  <prompt># </prompt>umount somewhere
                </programlisting>
              </para>
              </listitem>

              <listitem>
                <para>Si <filename>/etc/mtab</filename> est un lien vers
              <filename>/proc/mounts</filename>, umount ne libérera
              pas automagiquement <filename>/dev/loop0</filename>,
              aussi libérez le par :
<programlisting>
<prompt># </prompt>losetup -d /dev/loop0
</programlisting>
</para>
              </listitem>
            </itemizedlist>
</para>

        </sect4>

        <sect4>

          <title>Ecrire le véritable CD</title>

          <para>Considérant que vous disposez de
          <command>cdrecord</command> installé et correctement
          configuré pour votre graveur, tapez :
          <programlisting>
            <prompt># </prompt>cdrecord -v speed=&lt;vitesse de
            gravure&gt; dev=&lt;chemin au périphérique générique scsi
            de votre graveur&gt; boot.iso
          </programlisting>
        </para>

        </sect4>

      </sect3>

      <sect3>

        <title>Démarrer et tester le CD</title>

        <para>Tout est dit dans le titre ;)</para>

      </sect3>

    </sect2>

  </sect1>

  <sect1>

    <title>Comment créer des stations MS-Windows sans disque ?</title>

    <para>Comme MS-Windows n'apporte pas de support pour le démarrage
    sans disque, un simple tour d'horizon des solutions est présenté
    ici : la solution est d'utiliser un logiciel comme <ulink
    url="&vmwareurl;">&vmware;</ulink> ou son alternative libre,
    <ulink url="&plex86url;">&plex86;</ulink>. Bien que &plex86;
    semble avoir été abandonné, on peut encore démarrer certaines
    versions de MS-Windows en utilisant ce logiciel. Cela permet
    d'exécuter de manière transparente MS-Windows sur une machine
    linux.</para>

  </sect1>

  <sect1>

    <title>Problèmes, trucs, difficultés et liens utiles</title>


    <sect2>

      <title>Traiter les fichiers spécifiques aux stations de manière
      transparente</title>

      <para>Les sections précédentes ont exposé une manière simple de
      traiter les fichiers et les répertoires comme <filename
      class="directory">/var</filename>, spécifiques aux différentes
      stations. La plupart sont simplement construits à la volée et
      stockés sur ramdisk, mais vous pouvez préférer traiter ce
      problème sur le serveur NFS. Le projet &clusternfs; fournit un
      serveur de fichiers réseau capable de délivrer des fichiers
      différents en fonctions de critères comme l'adresse IP ou le nom
      d'h&ocirc;te. L'idée de base est que, si un client d'adresse IP
      10.2.12.42 requiert le fichier, disons,
      <filename>monfichier</filename>, le serveur cherche un fichier
      nommé <filename>monfichier$$IP=10.2.12.42$$</filename> et le
      renvoi à la place du fichier <filename>monfichier</filename>
      s'il est disponible.</para>

    </sect2>

    <sect2>

      <title>Réduire l'occupation de la mémoire des stations</title>

      <para>Une manière simple de diminuer la consommation de mémoire
      est de disposer plusieurs répertoires créés de manière dynamique
      sur le m&ecirc;me disque virtuel. Par exemple, supposons que le
      premier disque virtuel contient le répertoire <filename
      class="directory">/tmp</filename>. Alors, on peut déplacer le
      répertoire <filename class="directory">/var/tmp</filename> sur
      ce disque virtuel avec la commande suivante, exécutée depuis le
      serveur :

      <programlisting>
        <prompt># </prompt>mkdir /nfsroot/tmp/var
        <prompt># </prompt>chmod 0 /nfsroot/tmp/var
        <prompt># </prompt>ln -s /tmp/var /nfsroot/var/tmp
      </programlisting>

    </para>

      <para>Une autre bonne méthode pour réduire la consommation
      mémoire si vous ne disposez pas de disque dur local et
      n'utilisez pas de partition d'échange par réseau est de
      désactiver l'option <command>Echange sur périphériques en mode
      bloc</command><!-- NDT : Swapping to block devices ?! -->
      pendant la compilation du noyau.</para>

    </sect2>

    <sect2>

      <title>Partition swap sur NFS</title>

      <para>Si vos stations ne dispose pas de suffisament de mémoire
      et n'ont pas de disques locaux, vous pouvez utiliser une
      partition d'échange sur NFS. Cependant, gardez à l'esprit que le
      code de cette fonctionnalité est encore en phase de
      développement et que son fonctionnement est généralement assez
      lent. La documentation complète de cette fonctionnalité est
      disponible à <ulink
      url="http://www.instmath.rwth-aachen.de/~heine/nfs-swap/">http://www.instmath.rwth-aachen.de/~heine/nfs-swap/</ulink>.</para>
      
      <para>La première chose à faire pour mettre en &oelig;uvre cette
      fonctionnalité est de modifier votre noyau (vous devez disposer
      de la version 2.2 ou supérieure). Téléchargez le modificatif à
      l'adresse fournie ci-dessus et déplacez vous dans le répertoire
      <filename class="directory">/usr/src/linux</filename>. On
      considère que le modificatif est dans <filename
      class="directory">/usr/src/patch</filename>. Utilisez la
      commande suivante :

      <programlisting>
        <prompt># </prompt>cat ../patch | patch -p1 -l -s
      </programlisting>

Ceci fait, compilez votre noyau de manière habituelle en activant
les options <command>Partiton d'echange sur réseau
(EXPERIMENTALE)</command> et <command>Partiton d'échange par NFS
(EXPERIMENTALE)</command>.</para>

      <para>Exportez alors un répertoire en lecture-écriture et avec
      l'option no_root_squash depuis le serveur NFS. Configurez les
      clients pour qu'ils montent ce répertoire quelque part (disons
      dans <filename class="directory">/mnt/swap</filename>). Il devra
      &ecirc;tre monté avec des paramètres rsize et wsize inférieurs à
      la taille de page utilisée par le noyau (soit 4ko sur
      architecure Intel), sans quoi la machine risque de se trouver à
      cours de mémoire, pour cause de fragmentation ; reportez vous à
      la page de manuel de nfs pour les détails concernant les
      paramètres rsize et wsize. Pour créer une partition d'échange de
      20Mo, utilisez les lignes de commande suivantes (à placer dans
      les scripts d'initialisation des stations clientes)&nbsp;:

      <programlisting>
        <prompt># </prompt>dd if=/dev/zero of=/mnt/swap/swapfile bs=1k count=20480
        <prompt># </prompt>mkswap /mnt/swap/swapfile
        <prompt># </prompt>swapon /mnt/swap/swapfile
      </programlisting>

Bien entendu, ceci n'est valable que pour une seule machine, car si
vous en disposez de plusieurs il vous faudra modifier les noms des
fichiers et des répertoires, sans quoi toutes vos stations
utiliseraient le m&ecirc;me fichier d'échange...

</para>

      <para>Un mot encore sur les caractéristiques des partitions d'échange par NFS : en
      premier lieu le
      mécanisme est généralement lent, sauf à disposer d'interfaces
      réseau spécialement rapides. Cette possibilité n'a pas encore
      été beaucoup testée. Enfin, ce n'est pas sécurisé : n'importe
      qui sur le réseau est à m&ecirc;me de lire les données
      transférées.</para>

    </sect2>

    <sect2>

      <title>Echange sur un périphérique réseau en mode bloc (NBD -
      Network Block Device)</title>

      <para>Bien que je n'ai jamais testé personnellement, j'ai eu des
      retours selon lesquels cette astuce fonctionne, du moins avec
      des noyaux récents.</para>

      <para>Le principe général est le m&ecirc;me qu'avec NFS. Le
      point positif est qu'il n'est pas nécessaire de modifier le code
      du noyau. Mais la plupart de ses caractéristiques s'appliquent
      également à cette méthode.</para>
      
      <para>Pour créer un espace de swap de 20&nbsp;Mo, vous devrez
      d'abord le créer sur le serveur, puis l'exporter vers le client,
      enfin, exécuter <command>mkswap</command> sur le fichier. Notez
      que la commande <command>mkswap</command> doit &ecirc;tre
      exécutée sur le serveur, car mkswap fait usage d'appels système
      non supportés par NBD. De plus, cette commande doit &ecirc;tre
      exécutée après que le serveur ait exporté le fichier, car les
      données contenues dans celui-ci risqueraient d'&ecirc;tre
      détruite au moment où le serveur commence l'exportation. En
      considérant un serveur nommé NBDserveur, un client nommé
      NBDclient et que le port TCP utilisé pour l'exportation est le
      port 1024, la commande à exécuter sur le serveur est :

      <programlisting>
        <prompt># </prompt>dd if=/dev/zero of=/swap/swapfile bs=1k count=20480
        <prompt># </prompt>nbd-server NBDclient 1024 /swap/swapfile
        <prompt># </prompt>mkswap /swap/swapfile
      </programlisting>


    Maintenant, le client doit utiliser la commande suivante :

      <programlisting>
        <prompt># </prompt>swapon /dev/nd0
      </programlisting>

    </para>
 
      <para>De nouveau, ce ne sont là que les principes généraux. Les
      noms de fichiers peuvent également &ecirc;tre dépendants des
      noms ou adresses IP des stations.</para>

      <para>Une autre solution de fichier d'échange est de créer un
      système de fichiers ext2 sur le NBD, d'y créer un simple fichier
      et, enfin, d'utiliser les commandes <command>mkswap</command> et
      <command>swapon</command> pour utiliser le fichier comme fichier
      d'échange. La seconde méthode est plus proche de celle du fichier
      d'échange sur NFS que la première.</para>

    </sect2>

    <sect2>
      
      <title>Se débarasser des messages d'erreur au sujet de
      <filename>/etc/mtab</filename> ou de répertoires non démontés
      lors de la séquence d'arr&ecirc;t;</title>

      <para>Les commandes suivantes, exécutées sur le serveur,
      devraient résoudre le problème :

      <programlisting>
        <prompt># </prompt>ln -s /proc/mounts /nfsroot/etc/mtab
        <prompt># </prompt>touch /nfsroot/proc/mounts
      </programlisting>
    </para>

    </sect2>

    <sect2>

      <title>Installer de nouveaux paquetages sur les stations</title>

      <para>Une méthode simple est d'utiliser, du c&ocirc;té serveur,
      un chroot et d'exécuter alors votre utilitaire d'installation
      favori. Pour changer la racine vers l'endroit approprié,
      utiliser la commande suivante :
      <programlisting>
        <prompt># </prompt>chroot /nfsroot
      </programlisting>
    </para>

      <para>Les utilisateurs de distributions Debian seront
      particulièrement intéressés par l'option --root de dpkg, qui
      indique à dpkg où est la racine du système cible.</para>

    </sect2>

  </sect1>

<appendix>

    <title>Composants mémoire persistants</title>

    <para>Cette section décrit brièvement les différents types de
    composants mémoire :</para>

    <itemizedlist mark="opencircle">

      <listitem>
        <para>PROM : prononcé prom, acronyme anglo-saxon pour
        <emphasis>programmable read-only memory</emphasis> (mémoire
        programmable à accès en lecture seule). Une PROM est un
        composant mémoire sur lequel les données peuvent &ecirc;tre
        écrites une seule fois. Une fois qu'un programme est inscrit
        sur une PROM, il y demeure. Contrairement à la RAM, les PROM
        conservent leurs contenus quand l'ordinateur est hors
        tension. La différence entre une PROM et une ROM
        (<emphasis>read-only memory</emphasis> - mémoire en lecture
        seule) est que la PROM est vide en sortie de cha&icirc;ne , alors que la ROM reçoit son contenu lors du
        processus de fabrication. Pour inscrire des données sur une
        PROM, il est nécessaire de disposer d'un équipement appelé
        programmateur, ou br&ucirc;leur, de PROM. Le processus de
        programmation d'une PROM est parfois appelé br&ucirc;ler une
        PROM. Une EPROM (<emphasis>erasable programmable read-only
        memory</emphasis> - mémoire programmable et effaçable à accès
        en lecture seule) est un type particulier de PROM dont le
        contenu peut &ecirc;tre effacé par exposition à un éclairage
        ultraviolet. Une fois effacée, elle peut &ecirc;tre
        reprogrammée. Une EEPROM est similaire à une PROM, mais son
        effacement se fait électriquement.</para>
        </listitem>

      <listitem>
        <para>EPROM : acronyme anglo-saxon de <emphasis>erasable programmable read-only
        memory</emphasis> (mémoire programmable et effaçable à accès
        en lecture seule) et prononcé e-prom ; l'EPROM est un type
        particulier de mémoire non-volatile effaçable par exposition
        aux ultraviolets. Les ultraviolets effacent le contenu du
        composant, rendant possible sa reprogrammation. Pour écrire
        sur ou pour effacer une EPROM, il faut disposer d'un
        programmateur (ou br&ucirc;leur) de PROM. L'EPROM diffère de
        la PROM par le fait qu'une PROM ne peut &ecirc;tre programmée
        qu'une fois et ne peut &ecirc;tre effacée. Les EPROM sont
        largement utilisées au sein des ordinateurs personnels car
        elles autorisent le fabricant à modifier le contenu des PROM
        avant que l'ordinateur soit réellement vendu. Cela signifie
        que les erreurs peuvent &ecirc;tre fixées et des nouvelles
        versions des programmes installées rapidement avant
        livraison. A noter concernant la technologie des EPROM : les
        différents bits d'une EPROM sont programmés en injectant des
        électrons sous un voltage élevé sur la porte  
<!-- NDT : floatting gate ?! --> d'un transistor à effet de champ là
        où un bit à 0 est voulu. Les électrons capturés rendent le
        transistor passant, se lisant comme un 0. Pour effacer
        l'EPROM, on fournit aux électrons capturés assez d'énergie
        pour quitter la porte du transistor en bombardant le composant
        d'ultraviolets, au travers d'une fen&ecirc;tre de quartz.
<!-- NDT : au secours les électroniciens !!! --> 
Pour se prémunir d'un effacement lent sous l'effet de la lumière solaire ou des tubes fluorescents, cette fen&ecirc;tre est couverte, en utilisation normale, d'un masque opaque.</para>
      </listitem>

      <listitem>
        <para>EEPROM : acronyme anglo-saxon pour
        <emphasis>electrically erasable programmable read-only
        memory</emphasis> (mémoire programmable et effaçable
        électriquement à accès en lecture seule). Prononcé
        double-e-prom ou e-e-prom, une EEPROM est un type particulier
        de PROM effaçable par exposition à une charge
        électrique. Comme les autres types de PROM, une EEPROM retient
        son contenu m&ecirc;me lorsqu'elle est hors tension. Comme les
        autres types de ROM, une EEPROM est plus lente que la
        RAM. L'EEPROM est similaire à la mémoire flash (parfois
        appelée, flash-EEPROM). La principale différence est que les
        données d'une EEPROM doivent &ecirc;tre écrites ou effacées
        octet par octet, alors que celles d'une mémoire flash le sont
        par blocs. Cela rend la mémoire flash plus rapide.</para>
      </listitem>

      <listitem>
        <para>FRAM : raccourci pour <emphasis>Ferroelectric Random
        Access Memory</emphasis> (mémoire à accès direct ferroélectrique), un
        type de mémoire non-volatile développé par Ramtron
        International Corporation. La FRAM combine les avantages de
        rapidité d'accès des DRAM et SRAM et la non-volatilité de la
        ROM. En raison de sa rapidité, elle remplace les EEPROM pour
        de nombreuses applications. Le terme FRAM lui-m&ecirc;me est
        une marque déposée de Ramtron.</para>
      </listitem>

      <listitem>
        <para>NVRAM : abréviation de <emphasis>Non-Volatile Random
        Access Memory</emphasis> (mémoire non-volatile à accès
        direct), type de mémoire qui retient son contenu m&ecirc;me
        hors tension. Un type de NVRAM est la SRAM qui est rendue
        non-volatile en la connectant sur une source électrique
        permanente comme une batterie. Un autre type de NVRAM utilise
        des EEPROM pour sauvegarder son contenu lors de la mise hors
        tension. Dans ce cas, la NVRAM est une combinaison de
        composants SRAM et EEPROM.</para>
      </listitem>

      <listitem>
        <para>Mémoire bulle : un type de mémoire non-volatile composé
        d'une fine couche d'un matériau qui peut &ecirc;tre aisément
        magnétisé dans une seule direction. Lorsqu'un champ magnétique
        est appliqué sur une surface circulaire de cette substance qui
        n'est pas magnétisée dans la m&ecirc;me direction, cette
        surface se réduit en un disque plus petit, ou bulle. On a cru
        que la mémoire bulle allait devenir la technologie phare des
        mémoires, mais elle n'a pas tenu toutes ses
        promesses. D'autres types de mémoires non-volatiles, comme les
        EEPROM, sont à la fois plus rapides et moins co&ucirc;teuses
        que la mémoire bulle.</para>
      </listitem>

      <listitem>
        <para>Mémoire flash : un type spécifique d'EEPROM qui peut
        &ecirc;tre effacé et reprogrammé par blocs. Le BIOS de
        nombreux PC récents est stocké sur une mémoire flash, et peut
        donc &ecirc;tre mis à jour si nécessaire. Un tel BIOS est
        parfois appelé flash BIOS. La mémoire flash est également
        populaire dans les modems, car elle autorise le fabricant à
        prendre en compte de nouveaux protocoles au fur et à mesure
        des normalisation.</para>
      </listitem>

      </itemizedlist>

</appendix>

<appendix>

    <title>Déterminer la capacité et la vitesse d'une EPROM à
    destination d'un adaptateur réseau</title>

    <para>Cette section provient de la version 5.0 de la documentation
    du projet &etb;. Elle expose les méthodes permettant de déterminer
    la capacité et la vitesse de l'EPROM à utiliser pour un type donné
    d'adaptateur réseau.</para>

    <para>La capacité minimale d'une EPROM, acceptée par une carte
    réseau est de 8&nbsp;Ko (2764). Des tailles de 16&nbsp;Ko (27128) ou
    32&nbsp;Ko (27256) sont la norme. Quelques cartes supportent des
    capacités de 64&nbsp;Ko (27512). On peut voir aussi des
    dénominations portant un C après le 27, comme 27C256 ; cela
    signifie que l'EPROM est de type CMOS. Equivalente à la version
    sans C, elle constitue un bon choix eu égard à sa faible
    consommation électrique. Vous utiliserez la plus petite taille
    d'EPROM possible afin de ne pas utiliser plus que de besoin
    l'espace mémoire supérieur, car des extensions du BIOS peuvent en
    avoir besoin <!-- NDT : You want to use the smallest EPROM
    you can so that you don't take up more of the upper memory area
    than needed as other extensions BIOSes may need the space. --> De
    m&ecirc;me, vous voudrez ne pas acheter une EPROM trop chère. Les
    EPROM de 32&nbsp;Ko et de 64&nbsp;Ko semblent &ecirc;tre les moins
    co&ucirc;teuses à l'unité. Les EPROM de moindre capacité semblent
    plus chères car elles ne sont pas produites sur la cha&icirc;ne
    principale de fabrication.</para>  

    <para>Si vous ne pouvez trouver dans la documentation la capacité
    de l'EPROM supportée par votre carte, pour des adaptateurs sur
    slot ISA uniquement, vous pouvez la découvrir par
    essais-erreurs. Les adaptateurs sur slot PCI n'activent pas
    l'EPROM sauf indication contraire du BIOS. Prenez une ROM
    contenant quelques données (par exemple un générateur de
    caractères) et branché là dans son emplacement. Prenez garde de ne
    pas utiliser une extension BIOS pour ce test car elle pourrait
    &ecirc;tre détectée et vous emp&ecirc;cher de démarrer votre
    machine. En utilisant le programme DOS <command>debug</command>,
    effacer divers régions de la mémoire. Supposons que que vous
    découvrez les données dans la fen&ecirc;tre mémoire située des
    adresses CC00:0 à CC00:3FFF (=&nbsp;4000 en
    hexadécimal&nbsp;=&nbsp;16384 en décimal). Cela indique qu'une
    EPROM de 16&nbsp;Ko est nécessaire. Si vous découvrez qu'une
    région mémoire est dupliquée, mettons la région CC00:0 à CC00:1FFF
    identique à CC00:2000-CC0:3FFF, cela signifie que vous avez
    introduit une EPROM de 8&nbsp;Ko dans un emplacement prévu pour
    une EPROM de 16&nbsp;Ko, et qu'il vous faut essayer une EPROM de
    plus grande capacité.</para>

    <para>Notez que parce que les EPROM à 28 broches bénéficient de la
    compatibilité ascendante, il est possible que vous utilisiez une
    EPROM de plus grande capacité dans une branchement prévu pour une
    plus petite. 
<!-- NDT PB DE TRADUCTION : The higher
    address lines will probably be held high so you will need to
    program the image in the upper half or upper quarter of the larger
    EPROM, as the case may be. However you should
    double check the voltages on the pins armed with data sheet and a
    meter because CMOS EPROMs don't like floating pins. -->.</para>

    <para>Si votre ROM est d'une capacité supérieure à la taille de
    l'image, par exemple, une ROM de 32&nbsp;Ko contenant une image de
    16&nbsp;Ko, vous pouvez stocker l'image dans n'importe quelle
    moitié de la ROM. Vous pourrez lire des conseils stipulant de
    placer deux copies de l'image sur la ROM. Cela fonctionne mais
    n'est pas recommandé car la ROM risque d'&ecirc;tre activée deux
    fois <!-- NDT : because the ROM will be activated twice if it's a legacy
    ROM --> ou ne fonctionnera pas du tout si c'est une PCI/PnP. Cela
    est toléré par Etherboot car le code vérifie s'il a déjà été
    activé, et la seconde activation avorte. La méthode recommandée
    est de combler la seconde moitiée avec des données
    inertes. Remplir avec des 1 est recommandé car il s'agit là de
    l'état <emphasis>naturel</emphasis> de l'EPROM et nécessite moins
    de travail au programmateur de PROM. La commande Unix suivante
    engendre 16384 octets à la valeur 0xFF et les combine avec le
    contenu d'une ROM de 16&nbsp;Ko pour créer une image de 32&nbsp;Ko
    à l'usage du programmateur d'EPROM.
    <programlisting>
      <prompt># </prompt>(perl -e 'print "\xFF" x 16384'; cat bin32/3c509.lzrom) > 32kbimage
    </programlisting>

  </para>

    <para>La vitesse d'EPROM nécessaire dépend de la façon dont elle
    est connectée au bus de l'ordinateur. Si l'EPROM est directement
    connectée sur le bus, cas de beaucoup de composants de type
    NE2000, il vous faudra probablement vous procurer une EPROM dont
    la vitesse est au moins égale à celle de la ROM du BIOS
    principal. Typiquement 120-150&nbsp;ns. Certaines cartes réseau
    jouent les médiateurs vers l'EPROM, introduisant des états
    d'attente qui peuvent permettre l'utilisation d'une EPROM plus
    lente. La lenteur de l'EPROM n'a pas beaucoup d'incidence sur la
    vitesse d'exécution d'Etherboot car celui se duplique en mémoire
    avant de s'exécuter. Il parait que Netboot fait de
    m&ecirc;me.</para>

    <para>Si vous disposez de votre propre équipement de programmation
    d'EPROM, il existe une jolie collection d'utilitaires de
    conversion de formats de fichiers d'EPROM à <ulink
    url="http://www.canb.auug.org.au/~millerp/srecord.html">http://www.canb.auug.org.au/~millerp/srecord.html</ulink>.
    Les fichiers produits par le procédé de construction d'Etherboot
    sont entièrement en binaire. Un convertisseur simple de format, du
    binaire vers le format hexadécimal Intel, est disponible sur le
    site web d'Etherboot à <ulink
    url="http://etherboot.sourceforge.net/bin2intelhex.c">http://etherboot.sourceforge.net/bin2intelhex.c</ulink>.
    Vous pouvez aussi utiliser l'utilitaire objcopy, inclus dans le
    paquetage binutils :

    <programlisting>
      <prompt># </prompt>objcopy --input-target binary --output-target ihex binary.file intelhex.file
      <prompt># </prompt>objcopy --input-target ihex --output-target binary intelhex.file binary.file
    </programlisting>

  </para>       

    <para>Etherboot est considéré comme capable de créer des ROM
    compatibles avec les caractéristiques PnP des adaptateurs réseau
    sur slot PCI. Une erreur résiduelle dans les ent&ecirc;tes a été
    éliminée. Cependant, certains BIOS ne prennent pas en compte cette
    modification, aussi ai-je écris le script Perl swapdevids.pl pour
    effectuer la rotation des ent&ecirc;tes en cas de besoin. Vous
    devrez expérimenter les deux méthodes et déterminer laquelle
    fonctionne. Ou vous pouvez récupérer le contenu d'une ROM qui fonctionne (RPL, ou
    ROM PXE) en utilisant le script Perl disrom.pl. Les champs à
    examiner sont ceux concernant le type du périphérique (base,
    inférieur, interface). Cela doit &ecirc;tre 02 00 00 mais certains
    BIOS demandent 00 00 02 à cause d'une ambiguité dans les
    spécifications originelles.
<!-- NDT A VERIFIER - PARA VO : Etherboot is believed to make PnP compliant ROMs
    for PCI NICs. A long-standing bug in the headers has been tracked
    down. However some faulty old BIOSes are out there so I have
    written a Perl script swapdevids.pl to switch the header around if
    necessary. You'll have to experiment with it both ways to find out
    which works. Or you could dump a ROM image that works (e.g. RPL,
    PXE ROM) using the Perl script disrom.pl. The fields to look at
    are Device (base, sub, interface) Type. It should be 02 00 00, but
    some BIOSes want 00 00 02 due to ambiguity in the original
    specification. --></para>

</appendix>

<appendix>
    
    <title>Fournisseurs de stations sans disques</title>

    <para>Le guide pratique original "Machines sans disque" mentionne
    les noms des fournisseurs suivants :</para>
   <itemizedlist mark="opencircle">

      <listitem>
        <para>Linux Systems Labs Inc., USA <ulink
        url="http://www.lsl.com">http://www.lsl.com</ulink>. Cliquez
        sur "Shop on-line", puis sur "Hardware" où tous les modèles
        sont listés. Téléphone&nbsp;: 1-888-LINUX-88.</para>
      </listitem>

      <listitem>
        <para>Diskless Workstations Corporation, USA <ulink url="http://www.disklessworkstations.com">http://www.disklessworkstations.com</ulink>.</para> </listitem>

      <listitem>
        <para>Unique Systems of Holland Inc., Ohio, USA <ulink url="http://www.uniqsys.com">http://www.uniqsys.com</ulink></para> </listitem>

    </itemizedlist>


</appendix>

<bibliography>

    <title>Références</title>

  <biblioentry xreflabel="Diskless-HOWTO">
    <title>Guide pratique "Machines sans disque"</title>
    <address>&disklesshowtourl;</address>
  </biblioentry>

  <biblioentry xreflabel="Diskless-root-NFS-HOWTO">
    <title>Guide pratique "Système de fichier racine sur NFS pour
    machines sans disque"</title>
    <address>&disklessrootnfshowtourl;</address>
  </biblioentry>

  <biblioentry xreflabel="Bootdisk-HOWTO">
    <title>Guide pratique "Disque de démarrage"</title>
    <address>&bootdiskhowtourl;</address>
  </biblioentry>  

  <biblioentry xreflabel="ltsp">
    <title>&ltsp;</title>
    <abstract>
      <simpara>Utilitaires et documentation pour les stations sans
      disque, basé sur la distribution RedHat.</simpara>
    </abstract>
    <address>&ltspurl;</address>
  </biblioentry>

  <biblioentry xreflabel="&plume;">
    <title>&plume;</title>
    <abstract>
      <simpara>Projet naissant dont le but est de fournir des
      utilitaires à destination des stations sans disque et des
      serveurs associés, basé sur la distribution Debian.</simpara>
    </abstract>
    <address>&plumeurl;</address>
  </biblioentry>

  <biblioentry xreflabel="logilab">
    <title>Le site web de Logilab.org</title>
    <address>&logilaburl;</address>
  </biblioentry>

  <biblioentry xreflabel="PowerUp2Bash">
    <title>Guide pratique "Du démarrage à la ligne de commande bash"</title>
    <address>&powerup2bashurl;</address>
  </biblioentry>

  <biblioentry xreflabel="ThinClient">
    <title>Guide pratique "Clients légers"</title>
    <address>&thinclienturl;</address>
  </biblioentry>

  <biblioentry xreflabel="cdwriting">
    <title>Guide pratique "Gravage de CD"</title>
    <address>&cdwritingurl;</address>
  </biblioentry>

  <biblioentry xreflabel="etb">
    <title>Le projet &etb;</title>
    <address>&etburl;</address>
  </biblioentry>

  <biblioentry xreflabel="&vmware;">
    <title>&vmware;</title>
    <abstract>
      <simpara>Une machine virtuelle (non libre).</simpara>
    </abstract>
    <address>&vmwareurl;</address>
  </biblioentry>

  <biblioentry xreflabel="&plex86;">
    <title>&plex86;</title>
    <abstract>
      <simpara>Une autre machine virtuelle (libre).</simpara>
    </abstract>
    <address>&plex86url;</address>
  </biblioentry>

</bibliography>


</article>