Subversion Repositories svn LFS-FR

Compare Revisions

Ignore whitespace Rev 5999 → Rev 6000

/branches/LFS_7.5_Systemd/chapter07/udev.xml
16,7 → 16,7
</indexterm>
 
<para>Au <xref linkend="chapter-building-system"/>, nous avons
installé le paquet Udev. Avant d'entrer dans les détails concernant son
installé Udev depuis le paquet source de Systemd. Avant d'entrer dans les détails concernant son
fonctionnement, un bref historique des méthodes précédentes de gestion
des périphériques est nécessaire.</para>
 
133,48 → 133,6
</sect3>
 
<sect3>
<title>Les scripts de démarrage d'Udev</title>
 
<para>Le premier script de démarrage de LFS,
<filename>/etc/init.d/mountvirtfs</filename>, va copier les périphériques de
<filename class="directory">/lib/udev/devices</filename> vers
<filename class="directory">/dev</filename>. C'est nécessaire car certains
périphériques, certains répertoires et certains liens symboliques sont
requis avant que les processus de gestion dynamique des périphériques ne soient
disponibles au tout début du démarrage d'un système ou car ils sont exigés
par <command>udevd</command> lui-même. La création de n&oelig;uds de
périphériques statiques dans <filename
class="directory">/lib/udev/devices</filename> offre aussi un contournement
facile pour les périphériques qui ne sont pas supportés par l'infrastructure
de gestion dynamique des périphériques.</para>
 
<para>Le script de démarrage <filename>/etc/rc.d/init.d/udev</filename>
démarre <command>udevd</command>, récupère tous les périphériques "montés à
froid" ayant déjà été créés par le noyau et attend les règles pour
se terminer. Le script défait aussi le gestionnaire d'uevent de son
paramétrage par défaut <filename>/sbin/hotplug </filename>. Cela se fait
car le noyau n'a plus besoin d'appeler de binaires externes. À la place,
<command>udevd</command> listera sur une socket netlink les uevents que
le noyau détecte.</para>
 
<para>Le script de démarrage <command>/etc/rc.d/init.d/udev_retry</command>
prend soin de ratraper les événements pour les sous-systèmes dont les règles
peuvent s'appuyer sur des systèmes de fichiers non montés jusqu'à ce que
le script <command>mountfs</command> ne s'exécute (en particulier,
<filename class="directory">/usr</filename>
et <filename class="directory">/var</filename> peut causer cela). Ce
script se lance après le script <command>mountfs</command>, afin
que les règles (si récupérées), réussissent la deuxième fois. Il est
configuré à partir du fichier <filename>/etc/sysconfig/udev_retry</filename>&nbsp;;
tous les mots de ce fichier différents de commentaires sont considérés comme
des noms de sous-systèmes pour les récupérer lors de la nouvelle tentative.
Pour trouver le sous-système d'un périphérique, utilisez
<command>udevadm info --attribute-walk &lt;périphérique&gt;</command> où
&lt;périphérique&gt; est un chemin absolu dans /dev ou /sys tel que /dev/sr0 ou
/sys/class/rtc.</para>
</sect3>
 
<sect3>
<title>Chargement d'un module</title>
 
<para>Il se peut que les pilotes des périphériques compilés en
398,12 → 356,6
(NdT&nbsp;: Le système de fichiers <systemitem class="filesystem">sysfs</systemitem>)</para>
</listitem>
 
<!-- <listitem>
<para>Pointers to further reading
<ulink url="http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html"/>
(NdT&nbsp;: Pointeurs vers de plus amples lectures)</para>
</listitem>-->
 
</itemizedlist>
 
</sect2>
/branches/LFS_7.5_Systemd/chapter07/network.xml
17,113 → 17,6
<para>Cette section s'applique seulement si une carte réseau doit être
configurée.</para>
 
<para>Si aucune carte réseau ne sera utilisée, il n'est pas nécessaire
de créer des fichiers de configuration relatifs aux cartes réseau. Si
c'est le cas, supprimez les liens symboliques
<filename class="symlink">network</filename> de tous les répertoires
des niveaux d'exécution (<filename
class="directory">/etc/rc.d/rc*.d</filename>) après avoir installé les scripts de démarrage
de la <xref linkend="ch-scripts-bootscripts"/>.</para>
 
<sect2 id='stable-net-names'>
<title>Création de noms stables pour les interfaces réseaux</title>
 
<para>S'il n'y a qu'une interface réseau à configurer sur le système,
cette section est facultative, bien que cela ne fera pas de mal de l'appliquer.
Dans de nombreux cas (comme un portable avec deux interfaces l'une sans, l'autre avec fil),
l'application de la configuration de cette section est nécessaire.</para>
 
<para>Avec Udev et les pilotes réseau modulaires, la numérotation
des interfaces réseau n'est pas constante entre deux redémarrages,
car les pilotes sont chargés en parallèle, et du coup, dans un ordre
aléatoire. Par exemple, sur un ordinateur ayant deux cartes réseau
fabriquées par Intel et Realtek, la carte réseau produite par Intel
peut devenir <filename class="devicefile">eth0</filename> et celle
de Realtek <filename class="devicefile">eth1</filename>.
Dans certains cas, après un redémarrage, les cartes sont
renumérotées d'une autre façon. Pour éviter cela, Udev est fourni
avec un script et des règles pour affecter des noms stables aux
cartes réseau basés sur leur adresse MAC.</para>
 
<para>Les règles ont été pré-générées dans les instructions de construction
d'<application>udev (systemd)</application> au chapitre précédent. Regardez
le fichier <filename>/etc/udev/rules.d/70-persistent-net.rules</filename>
pour trouver les noms affectés à vos périphériques réseaux&nbsp;:</para>
 
<screen role="nodump"><userinput>cat /etc/udev/rules.d/70-persistent-net.rules</userinput></screen>
 
<note><para>Dans certains cas comme lorsque des adresses MAC ont été affectées
à la main à une carte réseau, ou dans un environnement virtuel tel que Xen,
il se peut que le fichier de règles réseau n'ait pas été généré car les
adresses ne sont pas affectées de manière cohérente. Dans ce cas,
passez simplement à la section suivante.</para></note>
 
<para>Le fichier commence par un bloc de commentaire suivi de deux
lignes pour chaque NIC. La première ligne de chaque NIC est une
description commentée des IDs matériels (IDs de
fabricant PCI et de périphérique, si c'est une carte PCI), puis de
ses pilotes entre parenthèses, si le pilote peut être trouvé. Ni
l'ID du périphérique ni le pilote ne sont utilisés pour déterminer
quel nom donner à une interface&nbsp;; Ces informations sont
là pour référence seulement. La seconde ligne est la règle Udev
qui correspond à ce NIC et qui lui affecte au final un nom.</para>
 
<para>Toutes les règles Udev sont constituées de plusieurs mots,
séparés d'une virgule et optionnellement d'un espace. Ces clés de
règle ainsi qu'une explication de chacune d'entre elles sont les
suivantes&nbsp;:</para>
 
<itemizedlist>
<listitem>
<para><literal>SUBSYSTEM=="net"</literal> - Demande à Udev d'ignorer
les périphériques qui ne sont pas des cartes réseau&nbsp;;</para>
</listitem>
<listitem>
<para><literal>ACTION=="add"</literal> - Demande à Udev d'ignorer cette
règle pour un uevent qui n'est pas un ajout (les uevents "retrait" et
"changement" se produisent aussi mais ils n'ont pas besoin de renommer
les interfaces réseau)&nbsp;;</para>
</listitem>
<listitem>
<para><literal>DRIVERS=="?*"</literal> - Ceci existe afin qu'Udev ignore
les VLAN ou les sous-interfaces bridge (car les sous-interfaces
n'ont pas de pilotes). Ces sous-interfaces sont ignorées car le nom
qui pourrait leur être affecté entrerait en conflit avec leur périphériques parents&nbsp;;</para>
</listitem>
<listitem>
<para><literal>ATTR{adresse}</literal> - La valeur de cette
clé est l'adresse MAC du NIC&nbsp;;</para>
</listitem>
<listitem>
<para><literal>ATTR{type}=="1"</literal> - Assure que la règle ne
correspond qu'à l'interface primaire dans le cas de certains pilotes
sans fil, qui créent plusieurs interfaces virtuelles. Les interfaces
secondaires sont ignorées pour la même raison que le sont les VLAN et les
sous-interfaces bridge&nbsp;: il y aurait en ce cas un conflit de nom&nbsp;;</para>
</listitem>
<listitem>
<para><literal>KERNEL=="eth*"</literal> - Cette clé a été ajoutée au
générateur de règles d'Udev pour gérer les machines ayant plusieurs
interfaces réseau, toutes ayant la même adresse MAC (la PS3 en
fait partie). Si les interfaces indépendantes ont des noms de base
différents, cette clé permettra à Udev de leur parler en aparté. Ce
n'est normalement pas nécessaire pour la plupart des utilisateurs de
Linux From Scratch, mais ça ne fait pas de mal&nbsp;;</para>
</listitem>
<listitem>
<para><literal>NAME</literal> - La valeur de cette clé est le nom qu'Udev
affectera à l'interface.</para>
</listitem>
</itemizedlist>
 
<para>La valeur de <literal>NAME</literal> est la partie importante.
Assurez-vous de connaître quel nom a été affecté à chacune de vos
cartes réseau avant de continuer, et assurez-vous d'utiliser cette
valeur <literal>NAME</literal> lorsque vous créerez les fichiers de
configuration ci-dessous.</para>
 
</sect2>
 
<sect2>
<title>Créer les fichiers de configuration des interfaces réseau</title>
 
130,19 → 23,29
<para>Les interfaces activées et désactivées par le script réseau
dépendent des fichiers du répertoire <filename class="directory">/etc/sysconfig/</filename>.
Ce répertoire devrait contenir un fichier par interface à configurer, tel
que <filename>ifconfig.xyz</filename>, où <quote>xyz</quote> signifie,
pour l'administrateur, quelque chose comme le nom du périphérique (par
exemple eth0). Dans ce fichier, il y a les attributs de cette interface, tels
que son ou ses adresses IP, ses masques de sous-réseau, et ainsi de suite.
Il faut que la fin du nom de fichier soit <emphasis>ifconfig</emphasis>.</para>
que <filename>ifconfig.xyz</filename>, où <quote>xyz</quote> est
requis pour être le nom de la carte reseau (par
exemple eth0). Dans ce fichier, il y a les attributs de cette interface,
tels que son ou ses adresses IP, ses masques de sous-réseau, et
ainsi de suite. Il faut que la fin du nom de fichier
soit <emphasis>ifconfig</emphasis>.</para>
 
<note><para>Udev pout assigner des noms aléatoires pour les cartes
réseau pour certaines cartes réseau comme enp2s1. Si vous n'êtes pas sur de
quel est le nom de votre carte réseau, vous pouvez toujours lancer
<command>ip l</command> après avoir lancé votre système. Il est donc
important que <filename>ifconfig.xyz</filename> soit nomé correctement
avec le bon nom de carte réseau (par exemple
<filename>ifconfig.enp2s1</filename> ou
<filename>ifconfig.eth0</filename>) ou Systemd échouera à mettre en
place votre carte réseau.</para></note>
 
<para>La commande suivante crée un fichier modèle pour le périphérique
<emphasis>eth0</emphasis> avec une adresse IP statique&nbsp;:</para>
 
<screen><userinput>cd /etc/sysconfig/
cat &gt; ifconfig.eth0 &lt;&lt; "EOF"
<literal>ONBOOT=yes
IFACE=eth0
<literal>IFACE=eth0
SERVICE=ipv4-static
IP=192.168.1.1
GATEWAY=192.168.1.2
153,20 → 56,12
<para>Les valeurs de ces variables doivent être modifiées dans
chaque fichier pour correspondre à la bonne configuration.</para>
 
<para>Si la variable <envar>ONBOOT</envar> est configurée à <quote>yes</quote>,
le script réseau configurera le NIC pendant
le démarrage du système. S'il est configuré avec toute autre valeur
que <quote>yes</quote>, le NIC sera ignoré par le
script réseau et ne sera pas configurée automatiquement. On peut démarrer et
arrêter l'interface à la main avec les commandes <command>ifup</command> et
<command>ifdown</command>.</para>
 
<para>La variable <envar>IFACE</envar> définit le nom de l'interface,
par exemple, eth0. Elle est nécessaire dans tous les fichiers de
configuration des périphériques réseaux.</para>
 
<para>La variable <envar>SERVICE</envar> définit la méthode utilisée
pour obtenir l'adresse IP. Les scripts de démarrage LFS ont un
pour obtenir l'adresse IP. Les scripts de réseau LFS ont un
format d'affectation d'IP modulaire. Créer les fichiers supplémentaires
dans le répertoire <filename class="directory">/lib/services/</filename>
autorise d'autres méthodes d'affectation d'IP. Ceci est habituellement
182,16 → 77,39
255.255.255.0, alors il est en train d'utiliser les trois premiers
octets (24 bits) pour spécifier le numéro du réseau. Si le
masque réseau est 255.255.255.240, il utiliserait les 28 premiers
bits. Les préfixes plus longs que 24 bits sont habituellement
utilisés par les fournisseurs d'accès Internet ADSL et câble.
Dans cet exemple (PREFIX=24), le masque réseau est 255.255.255.0. Ajustez
la variable <envar>PREFIX</envar> en concordance avec votre
sous-réseau spécifique. Si vous ne le mettez pas, PREFIX vaut 24 par défaut.</para>
bits. Les préfixes plus longs que 24 bits sont habituellement utilisés par les
fournisseurs d'accès Internet ADSL et câble. Dans cet exemple (PREFIX=24), le masque
réseau est 255.255.255.0. Ajustez la variable <envar>PREFIX</envar> en concordance
avec votre sous-réseau spécifique. Si vous ne le mettez pas, PREFIX vaut 24 par défaut.</para>
 
<para>Pour plus d'informations, voir la page de manuel de <command>ifup</command>.</para>
 
</sect2>
 
<sect2>
<title>Configuration de la carte d'interface réseau au démarage</title>
 
<para>L'activation de la configuration de la carte réseau est
est réalisée par interface. Pour activer la configuration de la carte réseau
au démarage, executer&nsbp;:</para>
 
<screen><userinput>systemctl enable ifupdown@eth0</userinput></screen>
 
<para>Pour désactiver une configuration de carte réseau pécédemment activée
au démarage, exécutez&nsbp;</para>
 
<screen><userinput>systemctl disable ifupdown@eth0</userinput></screen>
 
<para>Pour lancer la configuration de la carte réseau
exécutez&nsbp;:</para>
 
<screen><userinput>systemctl start ifupdown@eth0</userinput></screen>
 
<para>remplacez eth0 par le bon nom de la carte réseau,
comme c'est décrit au début de cette page.</para>
 
</sect2>
 
<sect2 id="resolv.conf">
<title>Créer le fichier /etc/resolv.conf</title>
 
199,12 → 117,13
<primary sortas="e-/etc/resolv.conf">/etc/resolv.conf</primary>
</indexterm>
 
<para>Si le système a besoin d'être connecté à Internet, il aura
besoin d'un DNS pour résoudre les noms de domaines Internet en adresse IP, et vice-versa.
Ceci se fait en plaçant les adresses IP du serveur DNS, disponibles
auprès du FAI ou de l'administrateur système, dans
<filename>/etc/resolv.conf</filename>. Créez le fichier en lançant
ce qui suit&nbsp;:</para>
<para>Si le système a besoin d'être connecté à Internet,
il aura besoin d'un DNS pour résoudre les noms de domaines
Internet en adresse IP, et vice-versa. Ceci se fait en
plaçant les adresses IP du serveur DNS, disponibles auprès
du FAI ou de l'administrateur système, dans
<filename>/etc/resolv.conf</filename>. Créez le fichier en
lançant ce qui suit&nbsp;:</para>
 
<screen><userinput>cat &gt; /etc/resolv.conf &lt;&lt; "EOF"
<literal># Début de /etc/resolv.conf
231,4 → 150,4
 
</sect2>
 
</sect1>
</sect1>
/branches/LFS_7.5_Systemd/chapter07/symlinks.xml
12,107 → 12,6
 
<sect2>
 
<title>Liens symboliques pour le CD-ROM</title>
 
<para>Certains logiciels que vous pourriez vouloir installer plus
tard (comme divers lecteurs multimédias) s'attendent à ce que les
liens symboliques <filename class="symlink">/dev/cdrom</filename> et
<filename class="symlink">/dev/dvd</filename> existent et pointent
vers le lecteur CD-ROM ou DVD-ROM. De plus, il peut être pratique de
mettre des références à ces liens symboliques dans <filename>/etc/fstab</filename>. Udev
est fourni avec un script qui génèrera des fichiers de règles pour créer ces liens symboliques
pour vous, selon les possibilités de chaque périphérique, mais vous devez
décider lequel des deux modes opératoires vous souhaitez que le script utilise.</para>
 
<para>Tout d'abord, le script peut opérer en mode <quote>chemin</quote> (utilisé par
défaut pour les périphériques USB et FireWire), où les règles qu'il crée dépendent
du chemin physique vers le lecteur CD ou DVD. Ensuite, il peut
opérer en mode <quote>id</quote> (par défaut pour les
périphériques IDE et SCSI), où les règles qu'il crée dépendent des
chaînes d'identification contenues dans le lecteur CD ou DVD
lui-même. Le chemin est déterminé par le script
<command>path_id</command> d'Udev, et les chaînes d'identification
sont lues à partir du matériel par ses programmes
<command>ata_id</command> ou <command>scsi_id</command>, selon le
type de périphérique que vous avez.</para>
 
<para>Il y a des avantages dans chaque approche&nbsp;; la bonne
approche à utiliser dépendra des types de changements de périphérique
qui peuvent se produire. Si vous vous attendez à ce que le chemin
physique vers le périphérique (c'est-à-dire, les ports et/ou les
slots par lesquels ils sont branchés) changent, par exemple parce que
vous envisagez de déplacer le lecteur sur un port IDE différent ou
un connecteur USB différent, alors vous devriez utiliser le mode
<quote>id</quote>. D'un autre côté, si vous vous attendez à ce
que l'identification du périphérique change, par exemple parce qu'il
peut mourir et que vous le remplaceriez par un périphérique différent
avec les mêmes possibilités et qui serait monté sur les mêmes
connecteurs, vous devriez utiliser le mode
<quote>chemin</quote>.</para>
 
<para>Si les deux types de changement sont possibles avec votre
lecteur, choisissez un mode basé sur le type de changement que vous
pensez rencontrer le plus fréquemment.</para>
 
<!-- If you use by-id mode, the symlinks will survive even the transition
to libata for IDE drives, but that is not for the book. -->
 
<important><para>Les périphériques externes (par exemple un lecteur
CD connecté en USB) ne devraient pas utiliser la méthode des chemins,
car chaque fois que le périphérique est monté sur un nouveau port,
son chemin physique changera. Tous les périphériques connectés en
externe auront ce problème si vous écrivez des règles Udev pour les
reconnaître par leur chemin physique&nbsp;; le problème ne concerne
pas que les lecteurs CD et DVD.</para></important>
 
<para>Si vous souhaitez voir les valeurs que les scripts Udev
utiliseront, et celles appropriées au périphérique CD-ROM, trouvez le
répertoire correspondant sous
<filename class="directory">/sys</filename> (cela peut être par exemple
<filename class="directory">/sys/block/hdd</filename>) et
lancez une commande ressemblant à ce qui suit&nbsp;:</para>
 
<screen role="nodump"><userinput>udevadm test /sys/block/hdd</userinput></screen>
 
<para>Regardez les lignes contenant la sortie des divers programmes
*_id. Le mode <quote>id</quote> utilisera la valeur ID_SERIAL
si elle existe et n'est pas vide, sinon il utilisera une combinaison
de ID_MODEL et de ID_REVISION. Le mode <quote>chemin</quote> utilisera la valeur de ID_PATH.</para>
 
<para>Si le mode par défaut ne convient pas à votre situation, vous
pouvez faire la modification suivante du fichier
<filename>/etc/udev/rules.d/83-cdrom-symlinks.rules</filename>,
comme suit, (où <replaceable>mode</replaceable> est soit
<quote>by-id</quote> soit <quote>by-path</quote>)&nbsp;:</para>
 
<screen role="nodump"><userinput>sed -i -e 's/"write_cd_rules"/"write_cd_rules <replaceable>mode</replaceable>"/' \
 
/etc/udev/rules.d/83-cdrom-symlinks.rules</userinput></screen>
 
<para>Remarquez qu'il n'est pas nécessaire de créer les fichiers de règle ou les
liens symboliques à ce moment puisque vous avez monté en bind le répertoire
<filename class="directory">/dev</filename> du système hôte dans le système LFS,
et nous supposons que les liens symboliques existent sur l'hôte. Les
règles et les liens symboliques seront créés la première fois que vous
démarrerez votre système LFS.</para>
 
<para>Cependant, si vous avez plusieurs lecteurs CD-ROM, les liens
symboliques générés à ce moment peuvent pointer vers des
périphériques différents de ceux vers lesquels ils pointent sur
votre hôte, car les périphériques ne sont pas découverts dans un
ordre prévisible. Les affectations créées quand vous démarrerez pour
la première fois le système LFS seront stables, donc cela n'est un
problème que si vous avez besoin que les liens symboliques sur les
deux systèmes pointent vers le même périphérique. Si tel est le cas,
inspectez (et éditez peut-être) le fichier
<filename>/etc/udev/rules.d/70-persistent-cd.rules</filename> généré
après le démarrage pour vous assurer que les liens symboliques
affectés correspondent à ce dont vous avez besoin.</para>
 
</sect2>
 
<sect2>
 
<title>Gestion des périphériques dupliqués</title>
 
<para>Comme expliqué à la <xref linkend="ch-scripts-udev"/>, l'ordre