Table des matières :
Tout d'abord, bienvenue chez Gentoo. Vous êtes sur le point de découvrir un monde riche de flexibilité et de performances. Cela sera mis en évidence à plusieurs reprises tout au long de l'installation de Gentoo. Vous pourrez choisir la proportion du système de base que vous voulez compiler vous-même, comment installer Gentoo, quel système de journalisation des évènements (syslog) vous désirez, etc.
Gentoo est une métadistribution moderne, rapide et conçue de façon propre et flexible autour de logiciels libres. Rien n'est caché. Portage, le système de gestion de paquets utilisé par Gentoo, a été écrit en Python, ce qui signifie que vous pouvez facilement consulter et modifier son code source. Portage utilise le code source des paquets qu'il installe, bien qu'un support pour des paquets précompilés soit également présent. De plus, Gentoo se configure avec de simples fichiers texte. Autrement dit, l'ouverture règne.
Il est primordial que vous compreniez que Gentoo est avant tout une question de flexibilité. Nous ne vous imposerons jamais un choix que vous ne voudriez pas faire. Si vous considérez qu'un changement s'impose, faites-le nous savoir via un rapport de bogue.
Comment l'installation est-elle structurée ?
L'installation de Gentoo se déroule en dix étapes couvertes par les chapitre 2 à 11. Après chaque étape, votre système sera dans un état bien défini :
Lorsque vous devrez choisir parmi plusieurs possibilités, comme ce sera souvent le cas, nous nous efforcerons de vous expliquer les avantages et les inconvénients de chaque option et nous continuerons ensuite avec celle par défaut. Les choix par défaut sont identifiés par le texte « Défaut : ». Les autres possibilités sont identifiées par le texte « Alternative : ». Ne croyez pas que les choix par défaut représentent des recommandations ; ils indiquent simplement les choix que, selon nous, la plupart des utilisateurs feront.
Parfois, vous aurez la possibilité de réaliser des actions facultatives. De telles étapes sont identifiées par le texte « Facultatif » et ne sont pas essentielles pour installer Gentoo. Cependant, certaines options dépendent de choix que vous aurez faits plus tôt. Dans ce cas, nous vous en informerons au moment de faire votre choix et au début de la description de l'étape.
Quelles sont les possibilités ?
Vous pouvez installer Gentoo de différentes façons. Vous pouvez télécharger un de nos CD d'installation, vous pouvez partir d'une autre distribution précédemment installée ou d'une distribution sur un CD amorçable comme Knoppix. Vous pouvez aussi démarrer via une autre machine de votre réseau ou à partir d'une disquette de démarrage.
Ce manuel décrit l'installation à partir d'un LiveCD Gentoo ou, dans certains cas, à partir d'une autre machine de votre réseau. Ce guide décrit l'installation de la version actuelle de Gentoo et des paquets. Si vous voulez installer Gentoo sans connexion réseau, veuillez consulter les manuels de la version 2008.0.
Notez que si vous voulez faire une installation « GRP » (Gentoo Reference Platform, un ensemble de paquets binaires prêts à être installés dès la fin de l'installation de Gentoo), vous devez suivre les manuels 2008.0.
D'autres méthodes d'installation sont abordées dans notre guide des méthodes d'installation alternatives. Vous pourriez aussi trouver notre guide des trucs et astuces pour x86 utile. Si vous trouvez que notre manuel d'installation est trop complexe, peut-être devriez-vous essayer un de nos guides d'installation rapide, si un tel quide existe pour votre architecture. Veuillez consulter la liste des documents.
Vous avez aussi le choix entre plusieurs points de départs :vous pouvez compiler 100% de votre nouveau système ou installer des logiciels précompilés pour accélérer la procédure d'installation. Évidemment, il existe d'autres possibilités entre ces deux extrêmes : vous pouvez, par exemple, partir d'un système partiellement compilé.
Si vous rencontrez un problème lors de l'installation ou dans la documentation, veuillez consulter notre système de gestion des bogues. Si le problème n'est pas déjà connu, veuillez créer un rapport de bogue. Ne craignez pas les développeurs auxquels vos bogues seront attribués, ils n'ont encore mangé personne.
Veuillez noter que ce document contient des références à d'autres architectures bien que ce manuel soit destiné à celle sur laquelle vous allez installer Gentoo. Cela est dû au fait que les différents manuels ont de nombreuses sections communes à toutes les architectures pour éviter le gaspillage de ressources. Nous essayons de limiter ces références à d'autres architectures pour éviter toute confusion.
Si vous avez un doute quant à l'origine d'un problème qui est soit une erreur que vous avez commise bien que vous ayez soigneusement lu la documentation, soit une erreur dans Gentoo malgré toute l'attention portée aux tests et à la documentation, vous êtes le bienvenu sur le canal #gentoo ou #gentoofr sur irc.freenode.net pour en discuter. Évidemment, vous y êtes de toute façon toujours le bienvenu :)
Si vous avez une question relative à Gentoo, vous devriez consulter notre foire aux questions et notre centre de documentation. Vous pouvez aussi consulter la FAQ en anglais dans les forums. Si vous ne trouvez toujours pas de réponse, rejoignez-nous sur le canal #gentoo sur irc.freenode.net, vous serez surpris de voir le nombre de Gentooistes qui y sont actifs :-)
Avant de débuter, nous allons présenter le matériel requis pour installer Gentoo avec succès sur votre système.
| Processeur (Big Endian port) | MIPS3, MIPS4, MIPS5 ou MIPS64-class CPU |
| Processeur (Little Endian port) | MIPS4, MIPS5 ou MIPS64-class CPU |
| Mémoire | 64 Mo |
| Espace disque | 1.5 Go (mémoire virtuelle non comprise) |
| Mémoire virtuelle | Au moins 256 Mo |
Vous devriez consulter le document Matériels supportés par Linux Gentoo/MIPS.
Quelques mots sur les processeurs
Sur de nombreuses architectures, on peut trouver plusieurs générations de processeurs et chaque génération est construite sur les bases de la génération précédente. Les architectures MIPS ne font pas exception. Il existe plusieurs générations de processeurs pour l'architecture MIPS. Pour pouvoir choisir l'archive de stage utilisée lors du démarrage en réseau et pour bien configurer la variable CFLAGS, vous devez savoir à quelle famille le processeur de votre système appartient. Ces familles sont regroupées sous la dénomination ISA (pour Instruction Set Architecture).
| ISA MIPS | 32/64 bits | Processeurs concernés |
| MIPS 1 | 32 bits | R2000, R3000 |
| MIPS 2 | 32 bits | R6000 |
| MIPS 3 | 64 bits | R4000, R4400, R4600, R4700 |
| MIPS 4 | 64 bits | R5000, RM5000, RM7000, R8000, R9000, R10000, R12000, R14000, R16000 |
| MIPS 5 | 64 bits | N'existe pas encore. |
| MIPS32 | 32 bits | Série AMD Alchemy, 4kc, 4km, beaucoup d'autres... |
| MIPS64 | 64 bits | Broadcom SiByte SB1, 5kc etc. |
Note : La couche ISA du MIPS5 a été conçue par Silicon Graphics en 1994, mais n'a jamais été utilisée dans un processeur. Elle continue à survivre en tant que partie de l'ISA du MIPS64. |
Note : Les couches ISA du MIPS32 et du MIPS64 sont une source commune de confusion. La couche ISA du MIPS64 est en fait une surcouche de celle du MIPS5, elle inclut donc toutes les instructions ISA du MIPS5 et précédents. Le MIPS32 est la version 32 bits du MIPS64, il n'existe que parce que la plupart des applications ne nécessitent que du calcul 32 bits. |
Un autre concept important à prendre en compte est la représentation des nombres dans le système. Elle se réfère à la manière avec laquelle le processeur lit les mots dans la mémoire principale. Un mot peut être lu comme étant big endian (l'octet de poids fort en premier) ou little endian (l'octet de poids faible en premier). Les machines Intel x86 sont en général en little endian, alors que les machines Apple et SPARC sont en big endian. Sur les MIPS, on peut rencontrer les deux. Pour séparer les deux cas, nous ajoutons el au nom de l'architecture lorsqu'elle est en little endian.
| Architecture | 32/64 bits | Big/little endian | Machines concernées |
| mips | 32 bits | Big Endian | Silicon Graphics |
| mipsel | 32 bits | Little Endian | DECStations, Cobalt Servers, PlayStation 2 |
| mips64 | 64 bits | Big Endian | Silicon Graphics |
| mips64el | 64 bits | Little Endian | Cobalt Servers, PlayStation 2 |
Pour ceux qui veulent en savoir plus sur les ISA, vous pouvez vous référer aux liens ci-dessous :
Une archive stage3 contient un environnement minimal d'utilisation à partir duquel vous pouvez installer Gentoo sur votre système en suivant les instructions de ce manuel. Des archives stage1 et stage2 ont été disponibles et documentées, mais ne sont plus documentées dans ce manuel bien que ces archives soient encore disponibles. Si vous tenez absolument à réaliser une installation à partir d'une de ces archives, veuillez consulter notre FAQ à ce sujet.
2.c. Aperçu du démarrage réseau
Dans ce chapitre, nous allons traiter de l'ensemble des points nécessaires pour réussir un démarrage réseau sur une machine Silicon Graphics ou un serveur Cobalt. Ce n'est qu'un condensé et n'a pas pour vocation d'être complet. Pour plus d'informations, il est conseillé de lire le Guide Gentoo sans disque dur.
Ce dont vous avez besoin : Selon la machine, il vous faudra réunir un certain nombre de critères pour démarrer en réseau et installer Linux avec succès.
Note : Les machines SGI utilisent un connecteur MiniDIN 8 pour les ports en série. Apparemment les câbles modem de chez Apple peuvent servir de câbles séries, mais maintenant que les machines Apple sont équipées de modems internes et de ports USB, ils commencent à être difficiles à trouver. Un schéma de câblage est disponible sur le Wiki Linux/MIPS et tout bon magasin d'électronique devrait avoir les connectiques nécessaires en stock. |
Note : Pour le terminal vous pouvez utiliser un vrai terminal VT100/ANSI ou un logiciel d'émulation de terminal exécuté sur PC (comme HyperTerminal, Minicom, seyon, Telex, xc, screen, comme vous voulez). Peu importe la plate-forme utilisée, du moment qu'elle dispose d'un port série RS-232 utilisable et des logiciels nécessaires. |
Note : Ce guide NE traite PAS des Qube originels. Ces serveurs ne disposent pas de port série sur la configuration par défaut et il n'est donc pas possible d'installer Gentoo dessus sans l'aide d'un tournevis et d'une machine hôte sur laquelle se fera l'installation. Le site suivant dispose d'un guide pour installer Gentoo sur ces machines : http://www.metzner.org/projects/qube/. |
Mise en place des serveurs TFTP et DHCP : rappels rapides
Bon, maintenant que vous disposez des pièces nécessaires on va pouvoir commencer les choses sérieuses. Comme mentionné auparavant, ce n'est pas un guide complet, seulement un ensemble de configurations minimales pour que tout puisse fonctionner. Vous pouvez au choix utiliser ce chapitre pour réaliser une configuration à partir de zéro ou utiliser les suggestions pour modifier votre configuration actuelle pour qu'elle supporte le démarrage réseau.
Notons que les serveurs utilisés ne sont pas obligatoirement sous Gentoo Linux,
vous pouvez bien sûr disposer d'un FreeBSD ou de toute autre plate-forme de
type UNIX. Cependant ce guide supposera que vous utilisez Gentoo Linux.
Vous pouvez également mettre le serveur TFTP/NFS sur une autre machine que celle
utilisée pour le serveur DHCP.
Attention : L'équipe Gentoo/MIPS n'est pas en mesure de vous aider à configurer d'autres systèmes d'exploitation en tant que serveurs de démarrage réseau. Si vous choisissez un autre système, cela suppose que vous savez ce que vous faites. |
Première étape, la configuration du DHCP. Afin que le démon ISC DHCP réponde aux requêtes de type BOOTP (obligatoire pour la BOOTROM des SGI et Cobalt), vous devez tout d'abord permettre le BOOTP dynamique sur le sous-réseau utilisé. Puis vous devez configurer une entrée sur chaque client qui pointe sur l'image de démarrage.
Exemple de code 3.1 : Installer le service DHCP |
# emerge dhcp
|
Une fois installé vous devez créer le fichier /etc/dhcp/dhcpd.conf. Voici une configuration de base que vous pouvez modifier pour vos besoins.
Exemple de code 3.2 : Configuration de dhcpd.conf |
# Indiquer à dhcpd de désactiver les DNS dynamiques. # dhcpd refusera de démarrer sans cela.. ddns-update-style none; # Créer un sous-réseau : subnet 192.168.10.0 netmask 255.255.255.0 { # Ensemble des adresses disponibles pour vos clients. N'oubliez pas le mot-clef 'dynamic-bootp' ! pool { range dynamic-bootp 192.168.10.1 192.168.10.254; } # Serveurs DNS et passerelle par défaut (à modifier selon votre convenance). option domain-name-servers 203.1.72.96, 202.47.56.17; option routers 192.168.10.1; # Indiquez au serveur DHCP qu'il a autorité sur le sous-réseau. authoritative; # Permet l'utilisation de BOOTP sur ce sous-réseau. allow bootp; } |
Avec cette configuration vous pouvez ajouter les clients que vous voulez dans la configuration du sous-réseau. Nous indiquerons plus tard ce que vous devez mettre.
Seconde étape, installer un serveur TFTP. Il est recommandé d'utiliser tftp-hpa, car c'est le seul démon TFTP à notre connaissance qui fonctionne correctement. Pour l'installer, il suffit de faire ceci :
Exemple de code 3.3 : Installer tftp-hpa |
# emerge net-ftp/tftp-hpa
|
Cela créera le répertoire /tftproot où vous devrez entreposer vos images de démarrage réseau. Vous pouvez les placer ailleurs si vous voulez. Dans ce guide, on supposera que vous les avez laissées dans le répertoire par défaut.
2.d. Démarrer une station SGI sur le réseau
Téléchargement d'une image Netboot
Selon le système que vous installez, plusieurs images sont disponibles au téléchargement. Elles sont toutes nommées selon le type de système et le processeur pour lesquels elles ont été compilées. Les types de machines sont les suivants :
| Nom de code | Machine |
| IP22 | Indy, *Indigo 2, **Challenge S |
| IP26 | *Indigo 2 Power |
| IP27 | Origin 200, Origin 2000 |
| IP28 | *Indigo 2 Impact |
| IP30 | Octane |
| IP32 | O2 |
Note : (*) Une erreur fréquente : se tromper entre les IRIS Indigo (IP12 avec un processeur R3000 ou IP20 avec un processeur R4000, aucun des deux ne fonctionne sous Linux), les Indigo 2 (IP22, qui fonctionne bien sous Linux), les Indigo 2 Power basés sur un processeur R8000 (qui ne fonctionne absolument pas sous Linux) et les Indigo 2 Impact basés sur un processeur R10000 (IP28, qui est à un stade très expérimental). Faites bien attention car ce sont des machines très différentes. |
Note : (**) Sur les machines Challenge S, le port réseau UTP est supporté par une carte SCSI WD33C95 qui n'est actuellement pas supportée sous Linux. À cause de cette limitation, vous devrez utiliser un « transceiver » AUI-->UTP connecté sur le port AUI. |
Enfin, dans le nom du fichier, r4k se réfère à la série des processeurs R4000, r5k aux R5000, rm5k aux RM5000 et r10k aux R10000. Vous trouverez les images disponibles sur ~kumba/mips/netboot.
Configuration DHCP pour un client SGI
Une fois que vous avez téléchargé ce fichier, placez le fichier décompressé dans le répertoire /tftproot. (Utilisez bzip2 -d pour la décompression). Puis, éditez le fichier /etc/dhcp/dhcpd.conf et ajoutez-y une entrée pour votre client SGI.
Exemple de code 4.1 : Modification de dhcpd.conf pour un station SGI |
subnet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx {
# ... éléments classiques...
# Station SGI... changer 'sgi' par le nom de votre machine SGI.
host sgi {
# Adresse MAC de votre machine SGI. Elle est normalement écrite derrière la
# machine ou en dessous.
hardware ethernet 08:00:69:08:db:77;
# Serveur TFTP où télécharger l'image de démarrage (par défaut, la même machine
# que le serveur DHCP).
next-server 192.168.10.1;
# Adresse IP à donner à la machine SGI.
fixed-address 192.168.10.3;
# Fichier que la PROM doit télécharger pour démarrer.
filename "/gentoo-r4k.img";
}
}
|
C'est presque fini mais il reste à faire quelques petites modifications pour que tout soit parfait. Ouvrez une console avec les privilèges administrateurs et entrez les commandes suivantes :
Exemple de code 4.2 : Quelques corrections pour les machines SGI pour que le TFTP fonctionne correctement |
(Désactiver « Path Maximum Transfer Unit », sinon la PROM SGI ne trouvera pas le noyau) # echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc (Indiquer l'intervalle des ports utilisables par la PROM SGI.) # echo "2048 32767" > /proc/sys/net/ipv4/ip_local_port_range |
Cela devrait être suffisant pour permettre au serveur Linux de bien fonctionner avec la PROM de votre machine SGI.
Vous êtes désormais prêt à démarrer vos démons. Entrez les lignes suivantes :
Exemple de code 4.3 : Démarrage des serveurs DHCP et TFTP |
# /etc/init.d/dhcp start # /etc/init.d/in.tftpd start |
Si tout se passe bien, vous devriez pouvoir maintenant démarrer votre station SGI et continuer à suivre le guide. Si le serveur DHCP ne démarre pas pour une raison ou pour une autre, essayez de lancer dhcpd en ligne de commande pour voir ce qu'il vous donne comme indications. Si tout va bien il devrait simplement se dupliquer en tâche de fond. Sinon, il vous retournera « exiting. » juste après vous avoir donné les raisons de ce problème.
une bonne méthode pour vérifier si le serveur TFTP fonctionne effectivement est de taper la commande suivante (si vous obtenez un résultat proche de celui mentionné ci-dessous c'est que tout va bien) :
Exemple de code 4.4 : Vérifiez que TFTPd fonctionne correctement |
# netstat -al | grep ^udp udp 0 0 *:bootpc *:* udp 0 0 *:631 *:* udp 0 0 *:xdmcp *:* udp 0 0 *:tftp *:* <-- (Cherchez cette ligne.) |
Démarrer depuis le réseau sur une machine SGI
Maintenant que tout est en place, le DHCP et le TFTP, vous pouvez démarrer votre machine SGI. Quand vous voyez à l'écran « Running power-on diagnostics », cliquez soit sur « Stop For Maintenance » ou tapez Échap. Vous obtiendrez alors à l'écran un menu comme celui présenté plus bas. Tapez la commande indiquée ci-dessous :
Exemple de code 4.5 : Menu de maintenance de la PROM SGI |
Running power-on diagnostics
System Maintenance Menu
1) Start System
2) Install System Software
3) Run Diagnostics
4) Recover System
5) Enter Command Monitor
Option? 5
Command Monitor. Type "exit" to return to the menu.
>> bootp(): root=/dev/ram0
|
À partir de là, la machine devrait commencer à télécharger l'image, puis, quelque chose comme 20 secondes plus tard, elle devrait commencer à démarrer sous Linux. Si tout va bien, vous devriez alors obtenir le shell ash de Busybox comme indiqué plus bas. Vous pouvez alors commencer à Configurer le réseau.
Exemple de code 4.6 : Quand tout va bien... |
init started: BusyBox v1.00-pre10 (2004.04.27-02:55+0000) multi-call binary Gentoo Linux; http://www.gentoo.org/ Copyright 2001-2004 Gentoo Technologies, Inc.; Distributed under the GPL Gentoo/MIPS Netboot for Silicon Graphics Machines Build Date: April 26th, 2004 * To configure networking, do the following: * For Static IP: * /bin/net-setup <IP Address> <Gateway Address> [telnet] * For Dynamic IP: * /bin/net-setup dhcp [telnet] * If you would like a telnetd daemon loaded as well, pass "telnet" * As the final argument to /bin/net-setup. Please press Enter to activate this console. |
Si votre machine se bloque et refuse de télécharger son image, cela peut venir de deux choses : ou bien vous vous êtes trompé quelque part, ou alors il faut la persuader gentiment de fonctionner correctement (non, pas à coups de marteau !). Voici une liste de ce que vous pouvez vérifier :
Si vous avez tout bien vérifié sur votre serveur et que vous continuez à avoir des problèmes de délais de réponse dépassés, essayez de taper sur votre console SGI :
Exemple de code 4.7 : Essayer de forcer le bon fonctionnement de la PROM SGI |
>> resetenv >> unsetenv netaddr >> unsetenv dlserver >> init >> bootp(): root=/dev/ram0 |
2.e. Alternative : Gentoo/MIPS SGI LiveCD
Sur les machines Silicon Graphics, il est possible de démarrer sur un CD afin d'installer un système d'exploitation (comme pour installer IRIX par exemple.) Récemment, des images de CD amorçables pour installer Gentoo ont été rendues disponibles.
Pour le moment, le LiveCD Gentoo/MIPS ne fonctionnera que sur les stations de travail SGI Indy, Indigo 2 et O2 équipées de processeurs R4000 ou R5000. Cependant, cela pourrait fonctionner avec d'autres plates-formes dans le futur.
Vous pouvez trouver les images des LiveCD en téléchargement sur votre miroir Gentoo favori, dans le répertoire experimental/mips/livecd.
Attention : Ces CD en sont encore au stade expérimental. Ils peuvent ne pas fonctionner. Vous pouvez rapporter un succès ou un échec soit sur notre Bugzilla, soit sur ce sujet du forum ou sur le canal IRC #gentoo-mips. Nous serions heureux d'avoir vos retours d'expérience. |
Il est important de noter que la PROM des SGI ne comprend pas le format ISO9660 et ne connait pas le standard El Torito. Ces images CD sont construites comme les labels disque SGI avec l'image de démarrage dans l'en-tête du volume, comme s'il s'agissait d'un disque dur. Il faut donc faire attention lorsqu'on grave l'image CD.
L'exemple ci-dessous suppose que vous gravez à une vitesse de 24x avec un graveur IDE. Si vous avez un graveur SCSI par exemple, il vous faut ajuster le paramètre dev pour qu'il corresponde. De même pour l'option speed. Si vous rencontrez des problèmes, vous pouvez essayer d'enlever l'option de vitesse.
Exemple de code 5.1 : Graver à l'aide de cdrecord |
# bzip2 -d mips-livecd-prototype-rc2-20041027.img.bz2 # cdrecord -vv -pad speed=24 dev=ATAPI:0,0,0 -tao mips-livecd-prototype-rc2-20041027.img |
Note : Il doit être possible de graver ces CD avec Windows, en supposant que votre logiciel de gravure grave l'image telle qu'elle est. Cependant, personne n'a réussi à obtenir un CD fonctionnel de cette manière. |
Note : Si vous ne savez pas quoi mettre pour l'argument dev, utilisez cdrecord -scanbus en tant qu'utilisateur root. Cela vous dira où se trouve votre graveur. |
2.f. Démarrer depuis le réseau sur un serveur Cobalt
Vue d'ensemble sur la procédure de démarrage réseau
Contrairement aux machines SGI, les serveurs Cobalt utilisent le protocole NFS pour effectuer le transfert du noyau sur lequel démarrer. Vous démarrez la machine en maintenant appuyées les boutons de flèches gauche et droite lors du démarrage de la machine. Elle essayera alors d'obtenir une adresse IP en faisant une requête BOOTP, montera le répertoire /nfsroot depuis le serveur grâce à NFS, puis essayera de télécharger et démarrer sur le fichier vmlinux_raq-2800.gz (selon le modèle) qui doit être un binaire ELF standard.
Télécharger une image de démarrage en réseau
Sur http://dev.gentoo.org/~redhatter/mips/cobalt/netboots/, vous trouverez les images nécessaires pour démarrer en réseau un serveur Cobalt. Les fichiers dont vous avez besoin s'appellent nfsroot-KERNEL-COLO-DATE-cobalt.tar. Choisissez le plus récent et décompressez-le dans le répertoire / comme montré ci-dessous :
Exemple de code 6.1 : Décompresser l'image nfsroot |
# tar -C / -xvf nfsroot-2.6.13.4-1.19-20051122-cobalt.tar
|
Dans la mesure où les Cobalt utilisent NFS pour télécharger l'image de démarrage, vous devez exporter le répertoire /nfsroot sur votre serveur. Si vous ne l'avez pas déjà fait, vous devrez installer le paquet net-fs/nfs-utils.
Exemple de code 6.2 : Installation de nfs-utils |
# emerge net-fs/nfs-utils
|
Maintenant que c'est fait, ajoutez la ligne suivante à votre fichier /etc/exports. Vous pouvez changer les restrictions d'accès si vous voulez.
Exemple de code 6.3 : Exporter le répertoire /nfsroot |
/nfsroot *(ro,sync) |
Il vous faut maintenant démarrer votre serveur NFS :
Exemple de code 6.4 : Démarrer le serveur NFS |
# /etc/init.d/nfs start
|
Si le serveur NFS fonctionnait déjà, vous pouvez lui demander de relire le fichier exports avec la commande exportfs.
Exemple de code 6.5 : Exporter un nouveau répertoire |
# exportfs -av
|
Configuration du serveur DHCP pour une machine Cobalt
La partie DHCP est assez simple et classique. Ajoutez les lignes suivantes à votre fichier /etc/dhcp/dhcpd.conf :
Exemple de code 6.6 : Modification du fichier dhcpd.conf pour un serveur Cobalt |
subnet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx {
# ... éléments classiques...
# Configuration pour un serveur Cobalt
# Indiquez le nom de la machine ici :
host qube {
# Chemin vers le répertoire nfsroot.
# Il est utilisé principalement pour quand vous utilisez l'option de
# démarrage via TFTP avec CoLo.
# Vous ne devriez pas devoir changer ceci.
option root-path "/nfsroot";
# Adresse MAC de la carte ethernet du serveur Cobalt.
hardware ethernet 00:10:e0:00:86:3d;
# Serveur sur lequel télécharger l'image.
next-server 192.168.10.1;
# Adresse IP à attribuer au serveur Cobalt.
fixed-address 192.168.10.2;
# Emplacement du fichier default.colo relatif à /nfsroot
# Vous ne devriez pas devoir changer ceci.
filename "default.colo";
}
}
|
Vous devriez maintenant pouvoir démarrer vos démons. Exécutez les lignes suivantes :
Exemple de code 6.7 : Démarrer les démons DHCP et NFS |
# /etc/init.d/dhcp start # /etc/init.d/nfs start |
Si tout va bien, vous devriez pouvoir démarrer votre station de travail et continuer à suivre le guide. Si le serveur DHCP ne démarre pas pour une raison ou pour une autre, essayez de lancer dhcpd en ligne de commande pour voir ce qu'il vous donne comme indications. Si tout va bien il devrait simplement se dupliquer en tâche de fond. Sinon, il vous retournera « exiting. » juste après vous avoir donné les raisons de ce problème.
Démarrer en réseau la machine Cobalt
Bon, maintenant que tout fonctionne bien, le DHCP comme le NFS, vous pouvez allumer votre machine Cobalt. Branchez votre câble null modem et configurez le terminal série pour utiliser une configuration 115 200 bauds, 8 bits, sans parité, 1 bit d'arrêt et une émulation VT100. Une fois que c'est fait, maintenez appuyées les boutons de flèches gauche et droite à la fois lors du démarrage de la machine.
Exemple de code 6.8 : Lancement du noyau |
elf: 80080000 <-- 00001000 6586368t + 192624t elf: entry 80328040 net: interface down CPU revision is: 000028a0 FPU revision is: 000028a0 Primary instruction cache 32kB, physically tagged, 2-way, linesize 32 bytes. Primary data cache 32kB 2-way, linesize 32 bytes. Linux version 2.4.26-mipscvs-20040415 (root@khazad-dum) (gcc version 3.3.3... Determined physical RAM map: memory: 08000000 @ 00000000 (usable) Initial ramdisk at: 0x80392000 (3366912 bytes) On node 0 totalpages: 32768 zone(0): 32768 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: console=ttyS0,115200 root=/dev/ram0 Calibrating delay loop... 249.85 BogoMIPS Memory: 122512k/131072k available (2708k kernel code, 8560k reserved, 3424k dat) |
Si tout va bien, vous devriez alors obtenir le shell ash de Busybox comme indiqué plus bas. Vous pouvez alors commencer à Configurer le réseau.
Exemple de code 6.9 : Quand tout se passe bien... |
VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 280k freed init started: BusyBox v1.00-pre10 (2004.04.27-02:55+0000) multi-call binary Gentoo Linux; http://www.gentoo.org/ Copyright 2001-2004 Gentoo Technologies, Inc.; Distributed under the GPL Gentoo/MIPS Netboot for Cobalt Microserver Machines Build Date: April 26th, 2004 * To configure networking, do the following: * For Static IP: * /bin/net-setup <IP Address> <Gateway Address> [telnet] * For Dynamic IP: * /bin/net-setup dhcp [telnet] * If you would like a telnetd daemon loaded as well, pass "telnet" * As the final argument to /bin/net-setup. Please press Enter to activate this console. |
Si votre machine se bloque et refuse de télécharger son image cela peut venir de deux choses : ou bien vous vous êtes trompé quelque part, ou alors il faut la persuader gentiment de fonctionner correctement (non, pas à coups de marteau !). Voici une liste de ce que vous pouvez vérifier :
3.a. Connexion au réseau automatique
Peut-être fonctionne-t-elle déjà ?
Si votre système est connecté à un serveur DHCP, il est probable que votre connexion ait déjà été configurée automatiquement. Si tel est le cas, les commandes habituelles telles que ssh, scp, ping, irssi, wget, links qui sont sur le CD d'installation fonctionnent.
Pour vérifier que votre connexion fonctionne, utilisez la commande /sbin/ifconfig. Elle devrait afficher la liste des interfaces réseau opérationnelles (en plus de lo).
Exemple de code 1.1 : Affichage de /sbin/ifconfig quand une connexion existe |
# /sbin/ifconfig (...) eth0 Link encap:Ethernet HWaddr 00:50:BA:8F:61:7A inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::50:ba8f:617a/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1498792 errors:0 dropped:0 overruns:0 frame:0 TX packets:1284980 errors:0 dropped:0 overruns:0 carrier:0 collisions:1984 txqueuelen:100 RX bytes:485691215 (463.1 Mb) TX bytes:123951388 (118.2 Mb) Interrupt:11 Base address:0xe800 |
Facultatif : configurer un mandataire
Si vous passez par un serveur mandataire (« proxy ») pour atteindre Internet, vous devrez spécifier les coordonnées de ce mandataire pendant l'installation. C'est très facile à faire : vous devez juste définir une variable d'environnement qui contiendra ces coordonnées.
Dans la plupart des cas, vous pouvez juste définir cette variable avec le nom du serveur. Pour illustrer, disons que le mandataire s'appelle proxy.gentoo.org et que le port soit 8080 :
Exemple de code 1.2 : Définition d'un serveur mandataire |
(Si le mandataire gère le HTTP) # export http_proxy="http://proxy.gentoo.org:8080" (Si le mandataire gère le FTP) # export ftp_proxy="ftp://proxy.gentoo.org:8080" (Si le mandataire gère le RSYNC) # export RSYNC_PROXY="rsync://proxy.gentoo.org:8080" |
Si le mandataire a besoin d'un nom d'utilisateur et d'un mot de passe, utilisez la syntaxe suivante pour définir la variable :
Exemple de code 1.3 : Ajout d'un nom d'utilisateur et d'un mot de passe au mandataire |
http://utilisateur:passe@serveur:port |
Par exemple, pour faire du HTTP avec notre serveur mandataire, le nom d'utilisateur « nico » et le mot de passe « f00b_r », vous ferez :
Exemple de code 1.4 : Utilisation d'un mandataire avec authentification |
# export http_proxy="http://nico:f00b_r@proxy.gentoo.org:8080"
|
Vous pouvez essayer une connexion vers le serveur DNS de votre fournisseur d'accès (son adresse figure dans /etc/resolv.conf) et un site web de votre choix, pour vérifier que vos paquets atteignent bien Internet et que la résolution de noms se fait bien.
Exemple de code 1.5 : Le test ultime |
# ping -c 3 www.gentoo.org
|
Si le réseau fonctionne, vous pouvez alors sauter le reste de cette section et continuer avec le chapitre Préparer les disques. Sinon, poursuivez la lecture.
3.b. Configuration automatique du réseau
Si le réseau n'a pas marché tout de suite, certains supports d'installation vous permettent d'utiliser net-setup (pour les réseaux classiques ou sans fil), pppoe-setup (pour les utilisateurs de l'ADSL) ou pptp (pour les utilisateurs de PPTP, disponible sur les architectures x86, amd64, alpha, ppc et ppc64).
Si votre support d'installation ne contient pas ces outils ou si votre réseau ne fonctionne pas, veuillez continuer avec la Configuration manuelle du réseau.
Par défaut : utilisation de net-setup
Le plus simple pour activer une interface réseau, si cela n'a pas été fait automatiquement, est de lancer le script net-setup :
Exemple de code 2.1 : Lancement du script net-setup |
# net-setup eth0
|
net-setup vous demandera des renseignements à propos de votre environnement réseau. Une fois terminé, vous devriez avoir une connexion réseau fonctionnelle. Testez votre connexion comme indiqué précédemment. Si le test est positif, alors bravo. Vous êtes maintenant fin prêt pour l'installation de Gentoo. Passez le reste de cette section et continuez avec la section Préparer les disques.
Si votre réseau ne marche toujours pas, continuez avec la section Configuration manuelle du réseau.
Si vous avez besoin de PPPoE pour vous connecter à Internet, le CD d'installation (n'importe quelle version) contient de quoi vous faciliter la tâche grâce à ppp. Utilisez le script pppoe-setup fourni pour configurer votre connexion. Il vous demandera le nom du périphérique Ethernet connecté à votre modem ADSL, votre nom d'utilisateur et votre mot de passe, les adresses IP de vos serveurs DNS et si vous voulez activer un pare-feu de base ou non.
Exemple de code 2.2 : Utilisation de pppo |
# pppoe-setup # pppoe-start |
Si cela ne marche pas, vérifiez scrupuleusement que les noms d'utilisateur et mots de passe fournis ont été correctement tapés en regardant dans le fichier /etc/ppp/pap-secrets ou /etc/ppp/chap-secrets et assurez-vous d'utiliser le bon périphérique réseau. Si votre périphérique réseau n'existe pas, vous devez charger les modules réseau appropriés. Dans ce cas, continuez avec la Configuration manuelle du réseau puisque nous y expliquons comment charger les modules réseau nécessaires.
Si tout marche, continuez avec la section Préparer les disques.
Alternative : utilisation de PPTP
Si vous avez besoin du support PPTP, vous pouvez utiliser pptpclient fourni sur le CD d'installation. Mais avant, vous devez vous assurer que votre configuration est correcte. Éditez /etc/ppp/pap-secrets ou /etc/ppp/chap-secrets afin qu'ils contiennent la bonne combinaison nom d'utilisateur/mot de passe :
Exemple de code 2.3 : Édition de /etc/ppp/chap-secrets |
# nano -w /etc/ppp/chap-secrets
|
Ensuite, modifiez /etc/ppp/options.pptp si nécessaire :
Exemple de code 2.4 : Édition de /etc/ppp/options.pptp |
# nano -w /etc/ppp/options.pptp
|
Une fois cela fait, lancez simplement pptp (avec les options que vous ne pouvez mettre dans options.pptp) pour vous connecter au serveur :
Exemple de code 2.5 : Connexion à un serveur PPTP |
# pptp <ip du serveur>
|
Maintenant, continuez avec la section Préparer les disques.
3.c. Configuration manuelle du réseau
Chargement des modules réseau nécessaires
Quand le CD d'installation démarre, il essaie de détecter tous vos périphériques et de charger les modules du noyau (les pilotes) appropriés pour faire marcher votre matériel. Dans la plupart des cas, cela marche très bien. Pourtant, dans certains cas, il peut ne pas charger certains modules dont vous avez besoin.
Si net-setup ou pppoe-setup n'ont pas marché, alors vous pouvez commencer à vous dire que votre carte réseau n'a pas été détectée et que vous devrez charger les modules requis vous-même.
Pour savoir quels modules du noyau nous fournissons pour le réseau, utilisez simplement ls :
Exemple de code 3.1 : À la recherche des modules fournis |
# ls /lib/modules/`uname -r`/kernel/drivers/net
|
Si vous trouvez un pilote pour votre carte réseau, utilisez modprobe pour le charger dans le noyau :
Exemple de code 3.2 : Utilisation de modprobe pour charger un module dans le noyau |
(Dans cet exemple, nous chargeons le pilote pcnet32.) # modprobe pcnet32 |
Pour vérifier si votre carte réseau est maintenant détectée, utilisez ifconfig. Une carte réseau détectée devrait provoquer ce genre d'affichage :
Exemple de code 3.3 : Test positif de la présence d'une carte réseau |
# ifconfig eth0
eth0 Link encap:Ethernet HWaddr FE:FD:00:00:00:00
BROADCAST NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
|
Par contre, si vous obtenez l'erreur suivante, alors la carte réseau n'a pas été détectée :
Exemple de code 3.4 : Test négatif de la présence d'une carte réseau |
# ifconfig eth0
eth0: error fetching interface information: Device not found
|
Si votre machine dispose de plusieurs cartes réseau, elles sont nommées eth0, eth1, etc. Utilisez le nom qui correspond à la carte qui est connectée. Dans le reste de ce document, nous utiliserons eth0.
Si votre carte réseau est maintenant détectée, vous pouvez ré-essayer net-setup ou pppoe-setup (ce qui devrait marcher). Pour les curieux, nous allons quand même expliquer comment configurer manuellement votre réseau.
Choisissez parmi les possibilités suivantes :
DHCP (Dynamic Host Configuration Protocol, Protocole Dynamique de Configuration d'un Hôte) sert à automatiser la récupération des informations réseau (adresse IP, masque de réseau, adresse de diffusion, passerelle, serveurs de noms, etc.) Cela ne marche que si vous disposez d'un serveur DHCP déjà configuré et actif dans votre réseau (ce peut être votre serveur ou celui de votre fournisseur d'accès). Pour qu'une interface réseau reçoive automatiquement ces informations, utilisez dhcpcd :
Exemple de code 3.5 : Utilisation de dhcpcd |
# dhcpcd eth0 Certains administrateurs de réseau imposent l'utilisation des noms de machine et de domaine attribués par le serveur DHCP. Dans ce cas, utilisez : # dhcpcd -HD eth0 |
Si cela marche (essayez d'envoyer un ping vers un serveur sur Internet, par exemple Google), alors vous êtes prêt à continuer. Sautez le reste de cette section et continuez avec la section Préparer les disques.
Configurer l'accès à un réseau sans fil
Note : Seuls les CD d'installation pour x86, amd64 et ppc ont la commande iwconfig. Avec d'autres machines, vous pouvez vous débrouiller en suivant les instructions relatives au projet linux-wlan-ng (en anglais). |
Si vous utilisez un réseau sans fil (aussi nommé WiFi ou 802.11), vous devrez sans doute configurer votre carte réseau avant de poursuivre. Pour afficher la configuration de votre carte, utilisez la commande iwconfig. Elle affichera un texte semblable à ceci :
Exemple de code 3.6 : Afficher la configuration en cours |
# iwconfig eth0
eth0 IEEE 802.11-DS ESSID:"GentooNode"
Mode:Managed Frequency:2.442GHz Access Point: 00:09:5B:11:CC:F2
Bit Rate:11Mb/s Tx-Power=20 dBm Sensitivity=0/65535
Retry limit:16 RTS thr:off Fragment thr:off
Power Management:off
Link Quality:25/10 Signal level:-51 dBm Noise level:-102 dBm
Rx invalid nwid:5901 Rx invalid crypt:0 Rx invalid frag:0 Tx
excessive retries:237 Invalid misc:350282 Missed beacon:84
|
Note : Remarquez que certaines cartes ont wlan0 ou ra0 comme nom de périphérique au lieu de eth0. Lancez iwconfig sans paramètre pour connaitre le nom exact du périphérique. |
Dans la plupart des cas, seuls deux paramètres doivent être définis : le code ESSID (aussi nommé « wireless network name » ou nom du réseau) et la clef WEP (cryptage). Si le code ESSID et l'adresse de votre point d'accès (« Access Point » ci-dessus) correspondent déjà à la configuration de votre réseau sans fil et que vous n'utilisez pas de clef WEP, alors votre connexion sans fil fonctionne déjà. Si vous devez modifier le code ESSID ou définir une clef WEP, utilisez les commandes suivantes :
Note : Si votre réseau sans fil est configuré avec du WPA ou du WPA2, vous devrez utiliser wpa_supplicant. Pour plus d'informations sur la configuration des réseaux sans fil sous Gentoo Linux, référez-vous au chapitre sur les réseaux sans fil du Manuel. |
Exemple de code 3.7 : Modifier le code ESSID et/ou définir une clef WEP |
(Nommer votre réseau « GentooNode ».) # iwconfig eth0 essid GentooNode (Définir une clef WEP en hexadécimal.) # iwconfig eth0 key 1234123412341234abcd (Définir un clef WEP avec un code ASCII - préfixez-le avec « s: ».) # iwconfig eth0 key s:le-mot-de-passe |
Vous pouvez vérifier vos paramètres en lançant la commande iwconfig. Une fois que votre connexion sans fil est opérationnelle, vous pouvez poursuivre avec la section suivante (Comprendre la terminologie réseau) ou utiliser l'outil net-setup décrit précédemment.
Comprendre la terminologie réseau
Note : Si vous connaissez votre adresse IP, votre adresse de diffusion (broadcast), votre masque réseau et vos serveurs de noms, vous pouvez sauter cette sous-section et continuer avec l'Utilisation de ifconfig et route. |
Si tout a échoué jusqu'à présent, vous allez devoir configurer votre réseau à la main. Ce n'est pas difficle du tout. Vous devez cependant être familier avec la terminologie réseau afin que vous puissiez configurer votre carte proprement. Quand vous aurez fini cette partie, vous saurez ce qu'est une passerelle, à quoi sert un masque réseau, comment est construite l'adresse de diffusion et pourquoi vous avez besoin de serveurs de noms.
Dans un réseau, les machines sont identifiées par leur adresse IP (« Internet Protocol »). Ces adresses sont une suite de quatre nombres compris entre 0 et 255. Du moins, c'est comme cela qu'on le voit. En réalité, une adresse IP est une suite de 32 bits (des uns ou zéros). Voyons un exemple :
Exemple de code 3.8 : Exemple d'adresse IP |
Adresse IP (nombres): 192.168.0.2
Adresse IP (bits): 11000000 10101000 00000000 00000010
-------- -------- -------- --------
192 168 0 2
|
Une adresse IP est unique dans un réseau donné, c'est-à-dire qu'il n'existe qu'une seule machine avec une certaine IP dans l'ensemble des réseaux connectés et accessibles. Pour faire la distinction entre les machines qui sont dans un réseau particulier et celles qui n'y sont pas, l'adresse IP est divisée en deux parties : la partie réseau et la partie hôte.
La séparation est faite grâce au masque réseau, une suite de 1 suivie d'une suite de 0. La partie de l'adresse IP qui correspond aux 1 est la partie réseau, l'autre est la partie hôte. Le masque réseau est souvent écrit sous la forme d'une adresse IP.
Exemple de code 3.9 : Exemple de séparation réseau/hôte |
Adresse IP: 192 168 0 2
11000000 10101000 00000000 00000010
Masque réseau 11111111 11111111 11111111 00000000
255 255 255 0
+--------------------------+--------+
Partie Réseau Hôte
|
Dans cet exemple, 192.168.0.14 fait toujours partie de notre réseau, mais pas 192.168.1.2.
L'adresse de diffusion (« broadcast ») d'une machine est une adresse IP spéciale qui a la même partie réseau que son adresse IP, avec que des 1 dans la partie hôte. Toutes les machines de votre réseau reçoivent les paquets émis à cette adresse ; elle est utilisée pour diffuser des paquets à tout le réseau.
Exemple de code 3.10 : Adresse de diffusion |
Adresse IP: 192 168 0 2
11000000 10101000 00000000 00000010
Adresse de diffusion: 11000000 10101000 00000000 11111111
192 168 0 255
+--------------------------+--------+
Réseau Hôte
|
Pour pouvoir surfer sur Internet, vous devez savoir quelle machine partage sa connexion Internet. Cette machine est appelée la passerelle. Comme c'est une machine comme une autre, elle a une adresse IP (par exemple 192.168.0.1).
Nous avons dit précédemment que chaque machine avait sa propre adresse IP. Pour pouvoir accéder à une machine grâce à un nom (au lieu d'une adresse IP, plus dure à retenir), vous avez besoin d'un service qui traduit un nom (comme dev.gentoo.org) en une adresse IP (comme 64.5.62.82). Ce service s'appelle service de noms (N.D.T. : ou DNS, pour Service de Noms de Domaine). Pour utiliser ce service, vous avez besoin de définir un ou plusieurs serveurs de noms dans le fichier /etc/resolv.conf.
Dans certains cas, votre passerelle sert aussi de serveur de noms. Sinon, entrez les serveurs de noms de votre fournisseur d'accès.
Pour résumer, vous avez besoin des informations suivantes pour continuer :
| Objet | Exemple |
| Votre adresse IP | 192.168.0.2 |
| Masque réseau | 255.255.255.0 |
| Adresse de diffusion | 192.168.0.255 |
| Passerelle | 192.168.0.1 |
| Serveur(s) de noms | 195.130.130.5, 195.130.130.133 |
Utilisation de ifconfig et route
La mise en place de votre réseau consiste en trois étapes. D'abord, nous nous assignons une adresse IP avec ifconfig. Ensuite, nous configurons le routage vers la passerelle avec route. Enfin, nous plaçons les adresses des serveurs de noms dans le fichier /etc/resolv.conf.
Pour assigner une adresse IP, vous avez besoin de votre adresse IP, de l'adresse de diffusion et du masque réseau. Ensuite, exécutez la commande suivante, en remplaçant ${IP_ADDR} par votre adresse IP, ${BROADCAST} par votre adresse de diffusion et ${NETMASK} par votre masque réseau :
Exemple de code 3.11 : Utilisation de ifconfig |
# ifconfig eth0 ${IP_ADDR} broadcast ${BROADCAST} netmask ${NETMASK} up
|
Maintenant, nous mettons en place le routage avec route. Remplacez ${GATEWAY} par l'adresse de votre passerelle :
Exemple de code 3.12 : Utilisation de route |
# route add default gw ${GATEWAY}
|
Ouvrez maintenant le fichier /etc/resolv.conf avec votre éditeur de texte favori (dans notre exemple, nous utilisons nano) :
Exemple de code 3.13 : Création du /etc/resolv.conf |
# nano -w /etc/resolv.conf
|
Entrez maintenant vos serveurs de noms de la façon suivante. Remplacez bien les variables ${NAMESERVER1} et ${NAMESERVER2} avec les adresses appropriées :
Exemple de code 3.14 : /etc/resolv.conf |
nameserver ${NAMESERVER1}
nameserver ${NAMESERVER2}
|
Et voilà. Maintenant, testez votre réseau en envoyant un ping vers un serveur Internet (Google par exemple). Si cela marche, toutes nos félicitations ! Vous êtes enfin prêt à installer Gentoo. Poursuivez avec le chapitre Préparer les disques.
4.a. Introduction aux périphériques de bloc
Nous allons regarder de manière approfondie la question des disques sous Gentoo Linux et sous Linux en général, y compris les systèmes de fichiers de Linux, les partitions et les périphériques de bloc. Ensuite, une fois que vous serez familiarisé avec les entrées et sorties des disques et des systèmes de fichiers, vous serez guidé pour réaliser la mise en place des partitions et des systèmes de fichiers pour votre installation de Gentoo Linux.
Pour commencer, nous allons présenter les périphériques de bloc. Le plus célèbre étant certainement celui qui représente le premier disque dur SCSI connu sous le nom /dev/sda.
Les périphériques de bloc cités ci-dessus représentent une interface abstraite vers les disques. Les programmes utilisateur peuvent les utiliser pour interagir avec votre disque sans devoir se tracasser si vos périphériques sont IDE, SCSI ou autres. Le programme peut simplement utiliser l'espace sur le disque comme un groupe de blocs continus de 512 octets accessibles aléatoirement.
Bien qu'il soit théoriquement possible d'utiliser un disque complet pour héberger votre système Linux, ceci n'est pratiquement jamais fait. À la place, les périphériques de bloc sont divisés pour être plus petits et plus facilement gérables. Ces subdivisions sont appelées partitions.
4.b. Concevoir un plan de partitionnement
Le nombre de partitions dépend beaucoup de votre environnement. Par exemple, si vous avez beaucoup d'utilisateurs, vous désirerez certainement avoir votre /home séparé afin d'améliorer la sécurité et de simplifier les sauvegardes. Si vous installez Gentoo comme serveur de courrier, votre /var devrait être séparé étant donné que tous les courriels sont stockés dans /var. Un bon choix de système de fichiers va vous permettre d'améliorer les performances. Les serveurs de jeu auront un /opt séparé étant donné que la plupart des serveurs de jeux sont installés à cet endroit. La raison est la même que pour /home : sécurité et sauvegarde. Vous devriez consacrer suffisamment de place au répertoire /usr, car il contient non seulement vos applications, mais aussi l'arbre Portage qui prend 500 Mo à lui seul et les sources des programmes que vous allez installer.
Comme vous pouvez le voir, cela dépend beaucoup de ce que vous souhaitez faire. Séparer les partitions ou volumes procure les avantages suivants :
Cependant, de multiples partitions ont un gros désavantage : si elles ne sont pas configurées correctement, vous risquez d'obtenir un système avec beaucoup d'espace libre sur une partition et plus du tout sur une autre. Notez également que Linux limite à 15 partitions par disque SCSI ou SATA.
4.c. Partitionner votre disque avec fdisk
Machines SGI : Création d'un label de disque SGI
Tous les disques dans un système SGI nécessitent un label disque SGI qui est similaire aux labels disques Sun ou MS-DOS. Les informations sur les partitions du disque y sont stockées. La création du label disque SGI va créer deux partitions spéciales sur le disque :
Attention : L'entête de volume SGI doit commencer au cylindre 0, sinon vous ne pourrez pas démarrer à partir du disque. |
La suite est un exemple tiré d'une session fdisk. Lisez-le et adaptez-le à vos besoins.
Exemple de code 3.1 : Création d'un label disque SGI |
# fdisk /dev/sda Command (m for help): x Expert command (m for help): m Command action b move beginning of data in a partition c change number of cylinders d print the raw data in the partition table e list extended partitions f fix partition order g create an IRIX (SGI) partition table h change number of heads m print this menu p print the partition table q quit without saving changes r return to main menu s change number of sectors/track v verify the partition table w write table to disk and exit Expert command (m for help): g Building a new SGI disklabel. Changes will remain in memory only, until you decide to write them. After that, of course, the previous content will be unrecoverably lost. Expert command (m for help): r Command (m for help): p Disk /dev/sda (SGI disk label): 64 heads, 32 sectors, 17482 cylinders Units = cylinders of 2048 * 512 bytes ----- partitions ----- Pt# Device Info Start End Sectors Id System 9: /dev/sda1 0 4 10240 0 SGI volhdr 11: /dev/sda2 0 17481 35803136 6 SGI volume ----- Bootinfo ----- Bootfile: /unix ----- Directory Entries ----- Command (m for help): |
Note : Si votre disque a déjà un label disque SGI, fdisk ne vous autorisera pas à créer un nouveau label. Il y a deux moyens de s'en sortir. Le premier est de créer un label Sun ou MS-DOS, écrire les changements sur disque et relancer fdisk. L'autre est d'écraser la table de partitions avec des données nulles avec la commande suivante : dd if=/dev/zero of=/dev/sda bs=512 count=1. |
Donner la bonne taille à l'entête de volume SGI
Important : Cette étape est souvent nécessaire à cause d'un bogue dans fdisk. Parfois, l'entête du volume n'est pas créé correctement. Dans ce cas, il commence et se termine au cylindre 0, ce qui bloque la création de partitions. Pour résoudre ce problème, lisez ce qui suit. |
Maintenant que le label SGI est créé, les partitions peuvent être définies. Dans l'exemple précédent, il y a déjà deux partitions définies pour vous. Ce sont les partitions spéciales mentionnées plus haut et elles ne devraient normalement pas être altérées. Cependant, pour installer Gentoo, nous devons charger un chargeur de démarrage et, éventuellement, plusieurs images de noyau directement dans l'entête de volume en fonction du type de système. L'entête de volume lui-même peut supporter jusqu'à huit images de n'importe quelle taille, avec pour chaque image un nom de maximum huit caractères.
Le processus pour rendre l'entête de volume plus grand n'est pas exactement simple — il y a pas mal de bidouillage. On ne peut pas simplement supprimer et rajouter l'entête de volume à cause du comportement bizarre de fdisk. Dans l'exemple fourni ci-dessous, nous allons créer un entête de volume de 50 Mo et une partition de démarrage de 50 Mo. Le plan actuel de notre disque peut varier, mais il ne s'agit ici que de propos illustratifs.
Exemple de code 3.2 : Redimensionner l'entête de volume SGI correctement |
Command (m for help): n Partition number (1-16): 1 First cylinder (5-8682, default 5): 51 Last cylinder (51-8682, default 8682): 101 (Vous avez vu que fdisk n'autorise la partition #1 à être recréée qu'à partir du cylindre 5 au minimum. Si vous avez essayé de supprimer et recréer l'entête de volume SGI de cette manière, vous devez avoir rencontré le même problème. Dans notre exemple, nous voulons que /boot fasse 50 Mo, c'est pourquoi nous commençons au cylindre 51 (souvenez-vous que l'entête de volume doit commencer au cylindre 0) et terminons au cylindre 101, ce qui fait plus ou moins 50 Mo, à 5 Mo près.) Command (m for help): d Partition number (1-16): 9 (Suppression de la partition #9 (entête de volume SGI).) Command (m for help): n Partition number (1-16): 9 First cylinder (0-50, default 0): 0 Last cylinder (0-50, default 50): 50 (Recréation de la partition #9, se terminant juste avant la partition #1.) |
Si vous ne savez pas trop comment utiliser fdisk, jetez un coup d'œil plus loin aux instructions de partitionnement pour serveurs Cobalt. Le principe est exactement le même, souvenez-vous juste de laisser tranquilles l'entête du volume SGI et le volume SGI.
Une fois ceci terminé, vous pouvez créer d'autres partitions comme bon vous semble. N'oubliez pas de définir le type de partition pour votre mémoire virtuelle (type 82), car le type par défaut est 83 (Linux).
Maintenant que vos partitions ont bien été créées vous pouvez continuer au chapitre Création des systèmes de fichiers.
Machines Cobalt : Partitionnement du disque
Sur les machines Cobalt, le BOOTROM s'attend à voir un MBR MS-DOS donc le partitionnement du disque dur est relativement classique. En fait, c'est le même procédé qui est utilisé sur les machines Intel x86. Cependant, vous devez tout de même faire attention à plusieurs points :
Pour cette raison, je vous recommande de créer une partition /boot d'environ 20 Mo formatée en EXT2r0 dans laquelle vous pourrez installer CoLo et vos noyaux. Cela vous permet d'utiliser un système de fichiers moderne (EXT3 ou ReiserFS) pour votre système de fichiers racine.
Je suppose ici que vous avez créé la partition /dev/hda1 qui sera montée plus tard en tant que partition /boot. Si vous voulez que ce soit la racine / vous devrez garder les exigences du BOOTROM en tête lors de la création.
Pour créer les partitions vous devez taper la commande fdisk /dev/hda à l'invite de commandes. Les commandes principales qui vous seront utiles sont :
Exemple de code 3.3 : Partitionner le disque |
# fdisk /dev/hda The number of cylinders for this disk is set to 19870. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with: 1) software that runs at boot time (e.g., old versions of LILO) 2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK) (Commencez par effacer toutes les partitions existantes.) Command (m for help): o Building a new DOS disklabel. Changes will remain in memory only, until you decide to write them. After that, of course, the previous content won't be recoverable. The number of cylinders for this disk is set to 19870. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with: 1) software that runs at boot time (e.g., old versions of LILO) 2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK) Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite) (Vous pouvez maintenant vérifier que votre table de partitions est vide en tapant la commande « p ».) Command (m for help): p Disk /dev/hda: 10.2 GB, 10254827520 bytes 16 heads, 63 sectors/track, 19870 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Device Boot Start End Blocks Id System (Créez la partition /boot.) Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 1 (Tapez Entrée ici pour accepter les valeurs par défaut.) First cylinder (1-19870, default 1): Last cylinder or +size or +sizeM or +sizeK (1-19870, default 19870): +20M (Vérifiez que la nouvelle partition est bien là avec «p ».) Command (m for help): p Disk /dev/hda: 10.2 GB, 10254827520 bytes 16 heads, 63 sectors/track, 19870 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Device Boot Start End Blocks Id System /dev/hda1 1 40 20128+ 83 Linux (Pour le reste, je préfère le mettre sur une partition étendue.) Command (m for help): n Command action e extended p primary partition (1-4) e Partition number (1-4): 2 (Encore une fois, les valeurs par défaut sont bien, tapez Entrée.) First cylinder (41-19870, default 41): Using default value 41 (Nous voulons utiliser tout l'espace disque, tapez Entrée encore une fois.) Last cylinder or +size or +sizeM or +sizeK (41-19870, default 19870): Using default value 19870 (Maintenant, la partition / peut être petite — j'utilise des partitions séparées pour /usr, /var, etc. Faites ce qui vous plait ici.) Command (m for help): n Command action l logical (5 or over) p primary partition (1-4) l First cylinder (41-19870, default 41):<Tapez Entrée> Using default value 41 Last cylinder or +size or +sizeM or +sizeK (41-19870, default 19870): +500M (... Même chose pour les autres partitions...) (Enfin, pour la mémoire virtuelle, je recommande un minimum de 256 Mo et de préférence 1 Go) Command (m for help): n Command action l logical (5 or over) p primary partition (1-4) l First cylinder (17294-19870, default 17294): <Tapez Entrée> Using default value 17294 Last cylinder or +size or +sizeM or +sizeK (1011-19870, default 19870): <Tapez Entrée> Using default value 19870 (Maintenant, si vous jetez un coup d'œil à votre table de partitions, vous devriez avoir quelque chose comme ceci...) Command (m for help): p Disk /dev/hda: 10.2 GB, 10254827520 bytes 16 heads, 63 sectors/track, 19870 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Device Boot Start End Blocks ID System /dev/hda1 1 21 10552+ 83 Linux /dev/hda2 22 19870 10003896 5 Extended /dev/hda5 22 1037 512032+ 83 Linux /dev/hda6 1038 5101 2048224+ 83 Linux /dev/hda7 5102 9165 2048224+ 83 Linux /dev/hda8 9166 13229 2048224+ 83 Linux /dev/hda9 13230 17293 2048224+ 83 Linux /dev/hda10 17294 19870 1298776+ 83 Linux (Vous avez vu hda10, notre partition d'échange est toujours de type 83) Command (m for help): t Partition number (1-10): 10 Hex code (type L to list codes): 82 Changed system type of partition 10 to 82 (Linux swap) (Ça devrait faire l'affaire... Vérifions.) Command (m for help): p Disk /dev/hda: 10.2 GB, 10254827520 bytes 16 heads, 63 sectors/track, 19870 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Device Boot Start End Blocks ID System /dev/hda1 1 21 10552+ 83 Linux /dev/hda2 22 19870 10003896 5 Extended /dev/hda5 22 1037 512032+ 83 Linux /dev/hda6 1038 5101 2048224+ 83 Linux /dev/hda7 5102 9165 2048224+ 83 Linux /dev/hda8 9166 13229 2048224+ 83 Linux /dev/hda9 13230 17293 2048224+ 83 Linux /dev/hda10 17294 19870 1298776+ 82 Linux Swap (Nous pouvons maintenant écrire notre nouvelle table de partitions sur le disque.) Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table. Syncing disks. # |
Et c'est tout ce qu'il y avait à faire. Vous pouvez maintenant passer à l'étape suivante : Création des systèmes de fichiers.
4.d. Création des systèmes de fichiers
Maintenant que vos partitions sont créées, il est temps d'y installer un système de fichiers. Si vous ne vous souciez pas de quel système de fichiers choisir et êtes satisfait de ceux que nous utilisons par défaut dans ce manuel, continuez avec Application d'un système de fichiers à une partition. Sinon, continuez à lire pour en apprendre plus sur les systèmes de fichiers disponibles.
De nombreux systèmes de fichiers sont disponibles. Reiserfs, Ext2 et ext3 sont considérés stables sur des machines MIPS ; les autres systèmes de fichiers sont expérimentaux.
ext2 est le système de fichiers original de Linux mais n'a pas de métadonnées journalisées, ce qui signifie que la routine de vérification du système de fichiers ext2 au démarrage peut prendre beaucoup de temps. À présent, vous avez le choix entre plusieurs systèmes de fichiers journalisés qui peuvent être vérifiés très rapidement et sont généralement préférés à leurs homologues non journalisés. Les systèmes de fichiers journalisés évitent de devoir attendre longtemps quand vous démarrez votre système et que vos systèmes de fichiers sont dans un état instable.
ext3 est la version journalisée du système de fichiers ext2, qui fournit des métadonnées journalisées pour une récupération rapide en plus d'autres modes journalisés comme la journalisation de données complètes et ordonnées. Il utilise un index à base de HTree qui permet d'obtenir d'excellentes performances dans pratiquement toutes les situations. En résumé, ext3 est un très bon système de fichiers fiable.
ReiserFS est un système de fichiers basé sur les B+tree qui a de très bonnes performances et qui surpasse ext2 et ext3 dans le cas de l'utilisation de petits fichiers (fichiers de moins de 4 ko), souvent avec un facteur allant de 10 à 15. ReiserFS résiste aussi très bien à la montée en charge et a des métadonnées journalisées. ReiserFS est stable et peut être utilisé aussi bien dans un système de fichiers destiné à une utilisation générale et pour des cas extrêmes comme la création de grands systèmes de fichiers et l'utilisation de grands fichiers et répertoires qui contiennent des dizaines de milliers de fichiers.
XFS est un système de fichiers avec des métadonnées journalisées qui possède un ensemble de fonctionnalités robustes et qui est optimisé pour la mise à l'échelle. Nous ne recommandons ce système de fichiers que pour des systèmes équipés d'unités de stockage SCSI haut de gamme ou connectés à des serveurs de stockage « Fibre Channel », et munis d'un onduleur. Puisque XFS utilise énormément le cache pour des données transitoires en mémoire vive, les programmes mal conçus (ceux qui ne prennent pas les précautions suffisantes quand ils écrivent les fichiers sur disque, et il y en a quelques uns) peuvent perdre beaucoup de données si le système s'interrompt de manière inattendue.
JFS est un système de fichiers journalisé à hautes performances d'IBM. Il a été récemment déclaré prêt pour un usage en production, mais il n'y a pas encore suffisamment d'information pour commenter sa stabilité générale de manière positive ou négative.
Application d'un système de fichiers à une partition
Pour créer un système de fichiers sur une partition ou un volume, chaque système de fichiers fournit ses propres outils :
| Système de fichiers | Commande de création |
| ext2 | mke2fs |
| ext3 | mke2fs -j |
| reiserfs | mkreiserfs |
| xfs | mkfs.xfs |
| jfs | mkfs.jfs |
Par exemple, pour formater la partition de démarrage (/dev/sda1 dans notre exemple) en ext2 et la partition principale (/dev/sda3 dans notre exemple) en ext3, nous utiliserons :
Exemple de code 4.1 : Application d'un système de fichiers sur une partition |
# mke2fs /dev/sda1 # mke2fs -j /dev/sda3 |
À présent, créons les systèmes de fichiers sur nos partitions fraichement créées.
Attention : Si vous êtes en train d'installer Gentoo sur un serveur Cobalt, souvenez-vous que /dev/hda1 DOIT être de type EXT2 revision 0 ; tout autre type (par exemple EXT2 revision 1, EXT3, Reiserfs, XFS, JFS et autres) NE FONCTIONNERA PAS ! Vous pouvez formater la partition avec la commande : mke2fs -r 0 /dev/hda1. |
Activation de la partition de mémoire virtuelle
mkswap est la commande utilisée pour créer et initialiser la partition de mémoire virtuelle :
Exemple de code 4.2 : Création d'une signature de mémoire virtuelle |
# mkswap /dev/sda2
|
Pour activer la partition de mémoire virtuelle, utilisez swapon :
Exemple de code 4.3 : Activation de la partition de mémoire virtuelle |
# swapon /dev/sda2
|
Créez et activez la partition de mémoire virtuelle avec les commandes mentionnées plus haut.
Maintenant que nos partitions sont initialisées et contiennent un système de fichiers, il est temps de les monter avec la commande mount. N'oubliez pas de créer les points de montage nécessaires pour toutes les partitions que vous avez créées. Par exemple, pour monter les partitions de démarrage et racine :
Exemple de code 5.1 : Monter les partitions |
# mount /dev/sda3 /mnt/gentoo # mkdir /mnt/gentoo/boot # mount /dev/sda1 /mnt/gentoo/boot |
Note : Si vous installez /tmp sur une partition séparée, n'oubliez pas de définir les permissions nécessaires après avoir monté la partition. Utilisez la commande chmod 1777 /mnt/gentoo/tmp. La même remarque s'applique à /var/tmp. |
Nous devrons également monter le système de fichiers proc (une interface virtuelle avec le noyau) sur /proc, mais nous devons d'abord placer nos fichiers sur les partitions.
Continuez avec Installer les fichiers d'installation de Gentoo.
5.a. Installer une archive « stage »
Avant de poursuivre, vous devez régler l'heure et la date de votre système. Si l'horloge de votre machine n'est pas à l'heure et surtout à la bonne date, des effets indésirables se produiront.
Pour afficher la date et l'heure, tapez date :
Exemple de code 1.1 : Afficher la date et l'heure |
# date
Fri Mar 29 16:21:18 CEST 2005
|
Pour changer la date et l'heure de votre système, utilisez date MMJJhhmmAAAA (Mois, Jour, heure, minute, Année). Vous pourrez définir votre fuseau horaire plus tard. Par exemple, pour le 29 mars 2005 à 16:21, utilisez :
Exemple de code 1.2 : Régler la date et l'heure |
# date 032916212005
|
La prochaine étape consiste à installer l'archive stage de votre choix sur votre système.
5.b. Télécharger l'archive depuis Internet
Allez au point de montage Gentoo sur lequel vous avez monté vos systèmes de fichiers (probablement /mnt/gentoo) :
Exemple de code 2.1 : Aller au point de montage Gentoo |
# cd /mnt/gentoo
|
Le tableau ci-dessous précise exactement quelle archive il vous faut pour votre système. Les archives peuvent être téléchargées depuis un miroir officiel Gentoo dans le répertoire releases/mips/current.
| Endianness | Processeur | Emplacement |
|
Big Endian (Utilisateurs SGI) |
R4000 R4400 R4600 |
mips3/stage#-mips3-RELEASE.tar.bz2 |
|
Big Endian (Utilisateurs SGI) |
R5000 RM5200 RM7000 R10000 R12000 R14000 |
mips4/stage#-mips4-RELEASE.tar.bz2 |
|
Little Endian (Utilisateurs Cobalt) |
RM5230 RM5231 |
cobalt/stage#-mipsel4-RELEASE.tar.bz2 |
|
Little Endian (Autres) |
Tous les types standards de CPU | cobalt/stage#-mipsel1-RELEASE.tar.bz2 |
Attention : Bien que nous fournissions des archives de stages pour MIPS1 Little Endian, le support concernant les systèmes MIPS Little Endian est actuellement restreint à la gamme de serveurs Cobalt. Ces archives sont fournies pour ceux qui voudraient expérimenter Gentoo sur du matériel non supporté, auquel cas nous supposons que vous savez bien ce que vous faites. |
Si vous devez passer par un serveur mandataire, vous devez définir les variables d'environnement http_proxy et ftp_proxy :
Exemple de code 2.2 : Définir un serveur mandataire pour wget |
# export http_proxy="http://proxy.server.com:port" # export ftp_proxy="http://proxy.server.com:port" |
L'image d'amorçage réseau Gentoo/MIPS fournit wget pour télécharger des fichiers. À cause des contraintes de place, il est impossible de founir un navigateur plus puissant avec les images d'amorce réseau SGI. Les utilisateurs du LiveCD peuvent utiliser elinks.
Exemple de code 2.3 : Télécharger l'archive avec wget |
# wget -c http://distfiles.gentoo.org/releases/mips/mips4/stage3-mips4-2007.0.tar.bz2
|
Vous pouvez utiliser les commandes md5sum ou sha1sum pour vérifier l'intégrité de l'archive que vous venez de télécharger. Pour cela, comparez le résultat affiché par la commande avec la somme de contrôle disponible sur le miroir. Par exemple, pour vérifier l'intégrité du fichier stage pour mips4 :
Exemple de code 2.4 : Exemple de calcul de somme de contrôle d'une archive |
# md5sum -c stage3-mips4-2007.0.tar.bz2.DIGESTS stage3-mips4-2007.0.tar.bz2: OK # sha1sum -c stage3-mips4-2007.0.tar.bz2.DIGESTS stage3-mips4-2007.0.tar.bz2: OK |
Décompresser l'archive « stage »
Ensuite, décompressez l'archive sur votre système. Nous utiliserons l'outil GNU tar, car c'est la méthode la plus aisée.
Exemple de code 2.5 : Décompressez l'archive |
# tar xjpf stage?-*.tar.bz2
|
Faites bien attention à utiliser les mêmes options (xjpf). Le x signifie extraire, le j décompresser avec bzip2, le p préserver les permissions et le f veut dire que nous désarchivons un fichier d'archive, pas l'entrée standard.
Maintenant que le « stage » a été décompressé, continuons avec le chapitre Installer Portage.
Décompresser un instantané de Portage
Vous devez maintenant installer un instantané de l'arbre Portage. Celui-ci contient l'ensemble des fichiers qui permettent à Gentoo d'installer des paquets, les différents profils, etc.
Télécharger et installer un instantané de Portage
Aller au point de montage de votre système de fichier, probablement /mnt/gentoo :
Exemple de code 3.1 : Aller au point de montage Gentoo |
# cd /mnt/gentoo
|
Téléchargez l'instantané depuis un miroir Gentoo. Vous le trouverez dans le répertoire snapshots/. Procédez de la même manière que pour télécharger l'archive « stage ».
Exemple de code 3.2 : Extraire l'instantané de Portage |
# tar -xjf portage-*.tar.bz2 -C /mnt/gentoo/usr
|
5.d. Configurer les options de compilation
Pour optimiser Gentoo, vous pouvez définir quelques variables qui influencent le comportement de Portage. Toutes ces variables peuvent être définies comme des variables d'environnement (en utilisant export), mais elles ne sont dans ce cas pas permanentes. Pour conserver votre configuration, vous pouvez utiliser /etc/make.conf, un fichier de configuration de Portage. C'est ce fichier que nous allons éditer maintenant.
Note : Une liste commentée de toutes les variables de Portage se trouve dans le fichier /mnt/gentoo/etc/make.conf.example. Pour installer Gentoo avec succès, seules celles mentionnées ci-dessous sont indispensables. |
Lancez votre éditeur préféré (dans ce guide, nous utiliserons nano, mais vi est aussi fourni) pour modifier les variables d'optimisation décrites ci-dessous.
Exemple de code 4.1 : Ouvrir /etc/make.conf |
# nano -w /mnt/gentoo/etc/make.conf
|
Comme vous l'avez sans doute remarqué, le fichier make.conf.example est structuré de manière générique : les lignes de commentaires commencent par un "#", les autres définissent des variables en utilisant la syntaxe VARIABLE="contenu". Le fichier make.conf utilise la même syntaxe. Certaines variables sont décrites ci-dessous.
Les variables CFLAGS et CXXFLAGS définissent les options d'optimisation pour le compilateur gcc, respectivement en C et C++. Bien que nous les définissions de manière générale ici, vous n'obtiendrez des performances maximales qu'en définissant les optimisations individuellement pour chaque programme. La raison est que chaque programme est différent.
Dans make.conf, vous devriez définir les options d'optimisation qui, selon vous, donneront plus de rapidité à votre système de manière générale. Ne mettez pas d'options expérimentales dans cette variable : trop d'optimisations peut engendrer des comportements anormaux dans certains programmes (plantage ou, pire, fonctionnement défectueux).
Nous n'allons pas expliquer toutes les options d'optimisations possibles. Pour les connaitre toutes, consultez les manuels en ligne GNU ou la page d'info de gcc (info gcc — ne marche que sur un système Linux fonctionnel). Le fichier make.conf lui-même contient de nombreux exemples et renseignements ; n'oubliez pas non plus de le lire.
Un premier paramètre est l'option -march= qui spécifie le nom de l'architecture cible. Les options possibles sont décrites dans le fichier make.conf (en commentaires). Il y a des exemples pour les couches ISA (mips1 ... mips4) et les modèles de processeurs (r4400, r4600 etc). Pour une architecture purement ISA, on peut simplement spécifier -mips3 plutôt que -march=mips3.
Exemple de code 4.2 : Les paramètres -march et -mips# de GCC |
(Pour un système R4600...) -march=r4600 (N'importe quel processeur de classe MIPS4...) -march=mips4 (Ou bien on peut seulement spécifier la couche ISA...) -mips4 |
Un deuxième paramètre est l'option -O (la lettre O majuscule) qui spécifie la classe d'optimisation de gcc. Les classes possibles sont s (pour optimiser en taille), 0 (zéro, pour ne pas optimiser), 1, 2, 3 pour plus d'optimisation de la vitesse d'exécution (chacune de ces classes a les mêmes options que celle qui la précède plus quelques autres). Par exemple, pour une optimisation de classe 2 :
Exemple de code 4.3 : Le paramètre O de GCC |
-O2 |
Un paramètre très important pour les MIPS, -mabi=. Les MIPS ont trois ABI différents : 32 (pur 32 bits, idem o32), 64 (pur 64 bits, idem n64) et n32 (un mélange de structures de données 32 bits et d'instructions 64 bits). Ce paramètre définit lequel de ces trois vous voulez utilisez. Veuillez prendre note que vous aurez des bibliothèques correspondantes à l'ABI choisi. En d'autres termes, cela veut dire que vous ne pouvez pas utiliser -mabi=64 dans un environnement 32 bits (ou bien même dans un environnement n32).
Une autre option d'optimisation populaire est -pipe (utilise des tubes plutôt que des fichiers temporaires pour la communication entre les différentes étapes de la compilation).
Veuillez remarquer que l'option -fomit-frame-pointer (qui permet de ne pas garder le pointeur de cadre dans un registre pour les fonctions qui n'en ont pas besoin) peut rendre le dépistage d'erreurs très difficile.
Lorsque vous définissez les variables CFLAGS et CXXFLAGS, vous devez combiner plusieurs options d'optimisation, comme dans l'exemple suivant :
Exemple de code 4.4 : Définir les variables CFLAGS et CXXFLAGS |
CFLAGS="-mabi=32 -mips4 -pipe -O2"
CXXFLAGS="${CFLAGS}" # Utilise les mêmes paramètres pour les deux variables
|
Avec MAKEOPTS, vous pouvez définir le nombre de compilations à lancer en parallèle. Une valeur souvent utilisée est le nombre de processeurs dans votre système plus un, mais une autre valeur peut parfois mieux fonctionner.
Exemple de code 4.5 : MAKEOPTS pour un système classique à 1 processeur |
MAKEOPTS="-j2" |
À vos marques, prêts, partez !
Mettez à jour votre /mnt/gentoo/etc/make.conf comme vous le souhaitez, et sauvez (Ctrl-X avec nano). Vous êtes maintenant prêt à continuer avec Installer le système de base Gentoo.
6.a. Entrer dans le nouvel environnement (chroot)
Facultatif : sélection des miroirs
Il est recommandé de choisir un miroir rapide pour télécharger les sources. Portage utilise la variable GENTOO_MIRRORS définie dans make.conf pour connaitre les différents serveurs à contacter. Vous pouvez consulter la liste de nos miroirs et en choisir quelques-uns proches de chez vous, car ils sont en général les plus rapides pour vous. Cependant, l'outil mirrorselect vous présente la même liste et vous permet de choisir plus facilement.
Exemple de code 1.1 : Choisir des miroirs avec mirrorselect |
# mirrorselect -i -o >> /mnt/gentoo/etc/make.conf
|
Attention : Ne sélectionnez pas de miroir IPv6, car les « stages » utilisés pour l'installation ne supportent pas IPv6. |
Une autre variable importante de make.conf est SYNC qui indique à Portage le serveur à utiliser pour synchroniser votre arbre Portage (l'ensemble des ebuilds, des scripts et autres fichiers dont Portage a besoin pour installer des paquets). Au lieu de définir SYNC manuellement, vous pouvez aussi utiliser mirrorselect.
Exemple de code 1.2 : Choisir un miroir pour RSYNC |
# mirrorselect -i -r -o >> /mnt/gentoo/etc/make.conf
|
Après avoir utilisé mirrorselect, il est conseillé de vérifier le contenu de /mnt/gentoo/etc/make.conf.
Il reste une dernière chose à faire avant d'entrer dans le nouvel environnement. Il s'agit de copier l'information DNS de /etc/resolv.conf. Vous devez le faire afin d'assurer le bon fonctionnement du réseau dans le nouvel environnement. /etc/resolv.conf contient les serveurs de noms pour votre réseau.
Exemple de code 1.3 : Copier l'information DNS |
(L'option -L garantit qu'on ne copie pas un lien symbolique.) # cp -L /etc/resolv.conf /mnt/gentoo/etc/ |
Montez le système de fichiers /proc dans /mnt/gentoo/proc permet à l'installation d'utiliser les informations fournies par le noyau, même lorsqu'on se trouve dans l'environnement chroot ainsi que /dev.
Exemple de code 1.4 : Monter /proc et /dev |
# mount -t proc none /mnt/gentoo/proc # mount -o bind /dev /mnt/gentoo/dev |
Entrer dans le nouvel environnement
Maintenant que toutes les partitions sont initialisées et que l'environnement de base est installé, il est temps d'entrer dans notre nouvel environnement d'installation. Cela signifie que l'on passe de l'environnement d'installation actuel (CD d'installation ou autre environnement d'installation) à l'environnement de votre système (soit les partitions initialisées).
L'entrée se fait en trois étapes. D'abord, on change la racine de / (sur l'environnement d'installation) en /mnt/gentoo (sur vos partitions) en utilisant chroot. Ensuite, on crée un nouvel environnement en utilisant env-update dont l'effet est essentiellement de créer les variables d'environnement. Finalement, ces variables sont chargées en mémoire en utilisant source.
Exemple de code 1.5 : Entrer dans le nouvel environnement |
# chroot /mnt/gentoo /bin/bash # env-update >> Regenerating /etc/ld.so.cache... # source /etc/profile # export PS1="(chroot) $PS1" |
Félicitations ! Vous êtes maintenant dans votre propre environnement Gentoo Linux. Bien sûr, ce dernier est loin d'être complet. C'est pourquoi il reste encore quelques sections à ce guide d'installation :-)
Mettre l'arbre de Portage à jour
Vous devriez mettre votre arbre Portage à jour avec la commande emerge --sync.
Exemple de code 2.1 : Mise à jour de l'arbre de Portage |
# emerge --sync (Si vous utilisez un terminal lent comme certains framebuffers ou une connexion série, vous pouvez ajouter l'option --quiet pour gagner du temps :) # emerge --sync --quiet |
Si vous vous trouvez derrière un pare-feu qui bloque le trafic rsync, vous pouvez utiliser emerge-webrsync qui télécharge un instantané de l'arbre Portage depuis un miroir et l'utilise pour mettre votre arbre à jour.
Si vous recevez un avertissement vous suggérant de mettre Portage à jour parce qu'une nouvelle version est disponible, il est recommandé de le faire. Utilisez la commande emerge --oneshot portage.
Qu'est-ce qu'un profil ?
Un profil est un composant important d'une installation de Gentoo. Il spécifie non seulement les valeurs par défaut des options de compilation (les variables CFLAGS et CXXFLAGS) et d'autres paramètres importants (comme la variable USE), mais aussi quels paquets sont disponibles ou pas. Les profils sont mis à jour par les développeurs Gentoo.
Les utilisateurs n'avaient pas à se préoccuper des profils jusqu'à présent. Cependant, il existe des situations dans lesquelles vous pourriez estimer qu'un changement de profil est nécessaire.
Pour connaitre le profil que vous utilisez, lancez la commande suivante :
Exemple de code 2.2 : Connaitre le profil utilisé |
# eselect profile list
Available profile symlink targets:
Available profile symlink targets:
[1] default-linux/mips/2007.0/generic-be/o32/ *
[2] default-linux/mips/2007.0/generic-be/o32//desktop
[3] default-linux/mips/2007.0/generic-be/o32//server
|
Le profil par défaut utilise un noyau 2.6. Ce profil est recommandé, mais vous pouvez choisir un autre profil si vous le désirez.
Les sous-profils desktop et server sont également disponibles pour d'autres architectures. La commande eselect profile list vous listera les profils disponibles.
Après avoir examiné les différents profils possibles pour votre architecture, vous pouvez en changer si vous le désirez :
Exemple de code 2.3 : Changer de profil |
# eselect profile set 2
|
Note : Le sous-profil developer est réservé aux tâches de développement pour Gentoo Linux. Il n'est pas destiné à créer un environnement global de développement. |
USE est une des plus puissantes variables mises à la disposition des utilisateurs de Gentoo. Plusieurs programmes peuvent être compilés avec ou sans le support optionnel disponible pour certaines fonctionnalités. Par exemple, certains programmes peuvent être compilés avec un support pour GTK ou pour Qt. D'autres peuvent être compilés avec ou sans support pour SSL. Certains programmes peuvent même être compilés avec un support pour le « framebuffer » (svgalib) plutôt que pour X11 (serveur X).
La plupart des distributions compilent leurs paquets avec un support aussi complet que possible, augmentant ainsi la taille des programmes et le temps de chargement, sans mentionner le nombre énorme de dépendances qui en résulte. Avec Gentoo, vous pouvez définir les options à utiliser lors de la compilation d'un paquet. C'est ici que la variable USE entre en jeu.
La variable USE contient des mots-clés que vous choisissez et qui correspondent à des options de compilation. Par exemple, ssl compilera le support ssl dans les programmes qui le supportent. -X retirera le support pour le serveur X (remarquez le signe moins devant le mot-clé). gnome gtk -kde -qt3 -qt4 compilera vos programmes avec le support pour GNOME (et GTK), mais sans le support pour KDE (ni Qt). Le résultat sera un système complètement réglé pour GNOME.
Les options par défaut pour USE se trouvent dans les fichiers make.defaults de votre profil. Vous trouverez ces fichiers make.defaults dans le répertoire sur lequel le lien /etc/make.profile pointe, ainsi que dans tous ses répertoires parents. Les options par défaut de USE sont donc la somme de toutes les options USE de ces fichiers. Vos modifications à /etc/make.conf sont jugées en fonction de ces options par défaut. Si vous ajoutez quelque chose aux options USE, c'est ajouté à la liste par défaut. Si vous retirez quelque chose des options USE (en le précédant du signe moins), c'est retiré de la liste par défaut (en supposant que cela s'y trouvait). Ne modifiez jamais quoi que ce soit dans le répertoire /etc/make.profile car ces fichiers sont écrasés lors des mises à jour de Portage !
Une description complète de USE peut être consultée dans la seconde partie du Manuel Gentoo, La variable USE. Une description complète des options disponibles se trouve dans le fichier /usr/portage/profiles/use.desc qui devrait déjà être sur votre système.
Exemple de code 2.4 : Afficher les options de la variable USE disponibles |
# less /usr/portage/profiles/use.desc (Utilisez les flèches de votre clavier pour faire défiler le texte et tapez 'q' pour quitter.) |
L'exemple suivant montre les options de USE pour un système basé sur KDE avec support pour ALSA, pour les DVD et pour la gravure de CD :
Exemple de code 2.5 : Ouverture de /etc/make.conf |
# nano -w /etc/make.conf
|
Exemple de code 2.6 : Options de USE |
USE="-gtk -gnome qt3 qt4 kde dvd alsa cdr" |
Facultatif: les « locales » de glibc
Vous n'utiliserez probablement qu'une ou deux « locales » sur votre système. Vous pouvez définir les zones qui vous intéressent dans le fichier /etc/locale.gen.
Exemple de code 2.7 : Ouvrir le fichier /etc/locale.gen |
# nano -w /etc/locale.gen
|
L'exemple ci-dessous sélectionne l'anglais américain et le français en France dans les encodages ISO et UTF-8.
Exemple de code 2.8 : Exemple de /etc/locale.gen |
en_US ISO-8859-1 en_US.UTF-8 UTF-8 fr_FR ISO-8859-1 fr_FR@euro ISO-8859-15 fr_FR.UTF-8 UTF-8 |
Ensuite, exécutez la commande locale-gen pour créer les locales que vous venez de définir.
Ensuite, passez à la Configuration du noyau.
Vous devez maintenant choisir votre fuseau horaire afin que votre système sache où il se trouve. Cherchez votre fuseau horaire dans /usr/share/zoneinfo, puis copiez-le sur /etc/localtime. Évitez les zones /usr/share/zoneinfo/Etc/GMT*, car leur nom prête à confusion. En effet, GMT-8 signifie en fait GMT+8.
Exemple de code 1.1 : Définir l'information relative au fuseau horaire |
# ls /usr/share/zoneinfo (En supposant que vous utilisiez l'heure de Paris.) # cp /usr/share/zoneinfo/Europe/Paris /etc/localtime |
Le cœur autour duquel sont bâties toutes les distributions est le noyau (en anglais « kernel ») Linux. Ce noyau est l'interface entre les programmes utilisateur et le matériel. Gentoo offre un choix de plusieurs noyaux à ses utilisateurs. Une liste complète, accompagnée de descriptions, est disponible dans le Guide du noyau Gentoo Linux.
Les seules sources de noyau Linux utilisables pour les systèmes MIPS sont mips-sources. Elles contiennent un ensemble de correctifs spécifiques aux architectures MIPS qui ne se trouvent pas dans les autres sources de noyau.
Exemple de code 2.1 : Installer les sources du noyau |
# emerge mips-sources
|
Important : Sur les Origin 200/2000, Indigo2 Impact (R10000), Octane/Octane2 et O2, vous devez impérativement démarrer sur un noyau 64 bits. emerge kgcc64 vous installera le compilateur croisé nécessaire à la construction de ce type de noyau. |
Exemple de code 2.2 : Installer kgcc64 |
# emerge kgcc64
|
Si vous examinez le contenu de /usr/src, vous devriez voir un lien symbolique nommé linux pointant vers les sources de votre noyau. L'exemple suivant pointe sur mips-sources-2.6.17.10-mips, mais vous aurez sans doute installé une autre version.
Exemple de code 2.3 : Examiner le lien symbolique vers le noyau |
# ls -l /usr/src/linux
lrwxrwxrwx 1 root root 12 Oct 13 11:04 /usr/src/linux -> linux-2.6.17.10-mips
|
Il est maintenant temps de configurer et de compiler votre noyau.
7.c. Compilation et installation du noyau
Ce guide effectuait auparavant une configuration manuelle des codes source du noyau. Devant le nombre grandissant de systèmes supportés, ce n'est plus possible. Cette section détaille plusieurs configurations de noyau pour vous montrer au mieux comment procéder pour votre système.
Utiliser les exemples de configurations du noyau
Certains des systèmes supportés peuvent utiliser des fichiers de configurations exemples .config qui se cachent dans l'arborescence du noyau. Vous ne trouverez pas de fichier exemple pour tous les types de systèmes, mais ceux qui en possèdent peuvent alors être configurés comme mentionné dans le tableau suivant :
| Système | Commande pour le configurer |
| Cobalt Servers | make cobalt_defconfig |
| Indy, Indigo2 (R4k), Challenge S | make ip22_defconfig |
| Origin 200/2000 | make ip27_defconfig |
| Indigo2 Impact (R10k) | make ip28_defconfig |
| O2 | make ip32_defconfig |
Reprendre la configuration noyau utilisée lors de l'installation
Toutes les images d'installation Gentoo contiennent la configuration de leur noyau, accessible par le pseudo-fichier /proc/config.gz. Dans la plupart des cas, vous pouvez réutiliser cette configuration. Il vaut mieux cependant que votre version de noyau soit le plus près possible de celle de l'image. Pour l'extraire, utilisez simplement zcat :
Exemple de code 3.1 : Extraire .config depuis /proc/config.gz |
# zcat /proc/config.gz > .config
|
Important : Cette configuration de noyau est faite pour démarrer par le réseau. C'est-à-dire qu'elle s'attend à trouver un système de fichiers racine quelque part, que ce soit un répertoire pour initramfs ou un fichier de périphérique pour initrd. Lorsque vous ferez make menuconfig plus bas, n'oubliez pas d'aller dans « General Setup » pour désactiver les options qui concernent initramfs. |
Base de compatibilité matérielle
Afin d'aider les utilisateurs à trouver les réglages qui leur conviendront, une base de compatibilité matérielle a été mise en place. Cette base de données contient une liste de matériels MIPS supportés et permet aux utilisateurs d'y contribuer leurs configurations qui marchent pour eux. L'adresse du site est http://stuartl.longlandclan.hopto.org/gentoo/mips.
Si vous trouvez ce service utile, vous êtes encouragés à y laisser vos notes et vos .config qui marchent pour que les autres puissent bénéficier de votre expérience. Bien entendu, les informations que vous pourrez trouver sur ce site ne sont aucunement garanties.
Personnaliser la configuration aux petits ognons
Une fois que vous avez trouvé la configuration qui vous convenait, téléchargez le fichier et mettez-le dans le répertoire des codes source du noyau. Renommez le fichier en .config. À partir de là, vous pouvez lancer la commande make oldconfig pour tout mettre à jour et personnaliser un peu plus la configuration avant de compiler le code.
Exemple de code 3.2 : Configurer le noyau |
# cd /usr/src/linux # cp /répertoire/vers/exemple-config .config # make oldconfig (Appuyez simplement sur Entrée à chaque question pour accepter les valeurs par défaut. Elles seront personnalisées plus tard.) # make menuconfig |
Important : Dans la section « Kernel Hacking », vous trouverez une option nommée « Are You Using A Cross Compiler? ». Elle indique aux Makefile du noyau d'ajouter mips-linux- (ou mipsel-linux, etc.) aux commandes gcc et as lors de la compilation du noyau. Cette option doit être désactivée, même si vous faites de la compilation croisée. À la place, si vous devez utiliser un compilateur croisé, spécifiez le préfixe en utilisant la variable CROSS_COMPILE comme expliqué dans la section suivante. |
Important : Il y a un problème connu avec JFS et ALSA sur les systèmes Octane, ALSA ne fonctionne pas. Étant donné la nature expérimentale de JFS sur MIPS, nous vous recommandons d'éviter JFS pour le moment. |
Maintenant que votre noyau est configuré, il est temps de le compiler et de l'installer. Quittez la configuration et lancez la compilation :
Note : Sur les machines 64 bits, vous devez spécifier CROSS_COMPILE=mips64-unknown-linux-gnu- (ou mips64el-... sur les systèmes little-endian) pour utiliser le compilateur 64 bits. |
Exemple de code 3.3 : Compiler le noyau |
(Compilation nativement) # make vmlinux modules modules_install (Compilation croisée) (Ajustez mips64-unknown-linux-gnu- en fonction.) # make vmlinux modules modules_install CROSS_COMPILE=mips64-unknown-linux-gnu- (En cas de compilation depuis une autre machine (x86 par exemple), utilisez les commandes suivantes pour compiler le noyau et installer les modules dans un répertoire spécifique à transférer vers la machine cible.) # make vmlinux modules CROSS_COMPILE=mips64-unknown-linux-gnu- # make modules_install INSTALL_MOD_PATH=/quelquepart |
Important : Si vous compilez un noyau 64 bits pour Indy, Indigo2 (R4k), Challenge S ou O2, utilisez la cible vmlinux.32 plutôt que vmlinux. Car sinon, votre machine ne démarrera pas à cause du PROM qui ne comprend pas le format ELF64. |
Exemple de code 3.4 : Utiliser la cible vmlinux.32 |
# make vmlinux.32 (Cela créera vmlinux.32, le noyau à utiliser.) |
Lorsque la compilation est terminée, copiez l'image du noyau dans /boot.
Note : Sur les serveurs Cobalt, le chargeur de démarrage s'attend à trouver une image compressée. N'oubliez pas d'utiliser la commande gzip -9 une fois le noyau copié dans /boot. |
Exemple de code 3.5 : Installer le noyau |
# cp vmlinux /boot/kernel-2.6.17.10-mips (Sur un Cobalt Server, compressez le noyau.) # gzip -9v /boot/kernel-2.6.17.10-mips |
7.d. Installer des modules du noyau individuels
Vous devez lister les modules à charger automatiquement lors du démarrage du système dans le fichier /etc/modules.autoload.d/kernel-2.6. Vous pouvez aussi ajouter des options supplémentaires aux modules si vous le jugez nécessaire.
Pour dresser la liste des modules disponibles, exécutez la commande find telle qu'indiquée ci-dessous. N'oubliez pas de substituer « <kernel version> » par la version du noyau que vous venez juste de compiler :
Exemple de code 4.1 : Consulter la liste des modules disponibles |
# find /lib/modules/<version du noyau>/ -type f -iname '*.o' -or -iname '*.ko'
|
Par exemple, pour charger automatiquement le module 3c59x.ko, spécifiez-le dans le fichier approprié.
Exemple de code 4.2 : Modifier le fichier /etc/modules.autoload.d/kernel-2.6 |
# nano -w /etc/modules.autoload.d/kernel-2.6
|
Exemple de code 4.3 : Exemple de fichier /etc/modules.autoload.d/kernel-2.6 |
3c59x |
Poursuivez l'installation avec Configurer votre système.
8.a. Information sur le système de fichiers
Sous Linux, toutes les partitions utilisées par le système doivent être listées dans /etc/fstab. Ce fichier contient l'information relative aux points de montage de ces partitions (où elles se situent dans le système de fichiers de Linux), la façon dont elles sont montées (décrite par des options spéciales) et les circonstances de leur montage (qui peut être automatique ou non, sous le contrôle des utilisateurs ou non, etc.). (N.D.T. : Bien que l'on emploie fréquemment l'expression « monter une partition », il serait plus exact de dire que l'on monte le système de fichiers présent sur la partition et non pas la partition elle-même).
/etc/fstab emploie une syntaxe particulière. Chaque ligne contient six champs séparés par des blancs (une ou plusieurs espaces ou tabulations ou encore un mélange d'espaces et de tabulations). Chaque champ a une signification particulière :
Important : Vous devez modifier le fichier /etc/fstab qui a été installé par Gentoo, car celui-ci n'est qu'un exemple et votre système ne démarrera pas si vous le laissez tel quel. Ouvrez nano (ou votre éditeur favori) pour créer votre /etc/fstab : |
Exemple de code 1.1 : Ouvrir /etc/fstab |
# nano -w /etc/fstab
|
Jetons un coup d'œil à la façon d'écrire l'entrée correspondant à la partition /boot. Il ne s'agit que d'un exemple, aussi ne le copiez pas si votre n'avez pas ou ne pouvez pas créer de partition /boot.
Dans notre exemple de stratégie de partitionnement par défaut pour les systèmes MIPS, /boot est sur la partition /dev/sda1, dans un système de fichiers ext2. Il doit être vérifié au démarrage. Nous écrivons donc :
Exemple de code 1.2 : Exemple d'une ligne pour /boot dans /etc/fstab |
/dev/sda1 /boot ext2 defaults 1 2 |
Certains utilisateurs ne désirent pas que leur partition /boot soit montée automatiquement au démarrage pour des raisons de sécurité. Dans ce cas, il convient de remplacer defaults par noauto. Ceci signifie que la partition /boot devra être montée manuellement avant chaque usage, par exemple pour installer un nouveau noyau et configurer grub.
Ajoutez les règles qui correspondent à votre schéma de partitions ainsi que pour vos lecteurs de CD-ROM, et, si vous en avez, pour vos disques et partitions supplémentaires.
Maintenant, servez-vous de l'exemple ci-dessous pour créer votre /etc/fstab :
Exemple de code 1.3 : Un exemple complet de fichier /etc/fstab |
/dev/sda1 /boot ext2 defaults,noatime 1 2 /dev/sda2 none swap sw 0 0 /dev/sda3 / ext3 noatime 0 1 /dev/cdrom /mnt/cdrom auto noauto,user 0 0 |
L'option auto indique à mount de tenter de deviner le type du système de fichiers (ce qui est recommandé pour les périphériques amovibles puisqu'ils peuvent contenir différents types de systèmes de fichiers). L'option user permet aux utilisateurs (autres que root) de monter le système de fichiers (en l'occurence celui présent sur le CD-ROM).
Afin d'améliorer les performances, la plupart des utilisateurs devraient ajouter l'option noatime au champ options de montage, ce qui donnera un système plus rapide puisque les temps d'accès ne seront pas consignés. De toute façon, vous n'en avez généralement pas besoin.
Relisez votre /etc/fstab, sauvegardez, puis quittez l'éditeur.
Nom d'hôte, nom de domaine, etc.
Une des choses que chaque utilisateur doit faire est nommer son PC. Cela peut sembler aisé, mais de nombreux utilisateurs ont bien du mal à trouver un nom approprié pour leur PC Linux. Afin d'accélérer les choses, dites-vous que le nom que vous choisissez maintenant pourra être changé plus tard. Si vous êtes embêté, nommez temporairement votre système tux et choisissez homenetwork comme nom de domaine.
Exemple de code 2.1 : Définir le nom d'hôte |
# nano -w /etc/conf.d/hostname (Attribuez le nom de votre machine à la variable HOSTNAME.) HOSTNAME="tux" |
Ensuite, si vous avez besoin d'un nom de domaine, définissez-le dans /etc/conf.d/net. Vous avez besoin d'un nom de domaine uniquement si votre fournisseur d'accès ou si votre administrateur vous l'indiquent ou si vous utilisez un serveur DNS sans utiliser de serveur DHCP. Vous n'avez pas à vous occuper du DNS ou du nom de domaine si votre réseau est configuré via DHCP.
Exemple de code 2.2 : Définir le nom de domaine |
# nano -w /etc/conf.d/net (Attribuez le nom de votre domaine à la variable dns_domain.) dns_domain_lo="mondomaine" |
Note : Si vous choisissez de ne pas spécifier de nom de domaine, vous devriez éditer le fichier /etc/issue en y supprimant la chaine .\O afin de ne pas avoir ce genre de message de bienvenue au login : « This is hostname.(none) ». |
Si vous avez un domaine NIS, vous devez également le définir : (Si vous ne savez pas ce qu'est un domaine NIS, vous n'en avez certainement pas.)
Exemple de code 2.3 : Définir le domaine NIS |
# nano -w /etc/conf.d/net (Attribuez le nom de votre domaine à la variable nis_domain.) nis_domain_lo="mondomaineNIS" |
Note : Pour plus d'information sur la configuration du DNS et du NIS, lisez l'exemple fourni dans le fichier /etc/conf.d/net.example. En plus, vous pourriez être intéressé par l'installation du paquet openresolv pour vous aider à gérer votre configuration DNS/NIS. |
Si vous éprouvez une sensation de déjà-vu, souvenez-vous que les paramètres réseau que vous avez définis au début de l'installation ne concernaient que l'installation elle-même. Vous devez maintenant vous attarder à la configuration permanente du réseau pour votre système Gentoo.
Note : Ce manuel détaille la configuration réseau, y compris les ponts, le couplage d'interface, les réseaux 802.1Q et sans fil, plus loin. |
Toute l'information réseau est rassemblée dans /etc/conf.d/net. Ce fichier utilise une syntaxe simple mais pas nécessairement intuitive si vous ne savez pas comment paramétrer manuellement un réseau. Pas d'inquiétude, tout vous sera expliqué. Un exemple commenté complet se trouve dans le fichier /etc/conf.d/net.example.
DHCP est utilisé par défaut. Pour que le DHCP fonctionne, vous devez installer un client DHCP. La procédure à suivre est décrite dans installation des outils systèmes. N'oubliez pas d'installer un client DHCP.
Si vous devez configurer votre réseau soit pour spécifier des options particulières pour DHCP, soit parce que vous n'utilisez pas DHCP, ouvrez le fichier /etc/conf.d/net avec votre éditeur favori :
Exemple de code 2.4 : Ouvrir /etc/conf.d/net |
# nano -w /etc/conf.d/net
|
Vous devriez voir le fichier suivant :
Exemple de code 2.5 : Fichier /etc/conf.d/net par défaut |
# This blank configuration will automatically use DHCP for any net.* # scripts in /etc/init.d. To create a more complete configuration, # please review /etc/conf.d/net.example and save your configuration # in /etc/conf.d/net (this file :]!). |
Pour entrer une adresse fixe, un masque de réseau et une adresse de passerelle, vous devez définir config_eth0 et routes_eth0 :
Exemple de code 2.6 : Définir une adresse statique pour eth0 |
config_eth0=( "192.168.0.2 netmask 255.255.255.0 brd 192.168.0.255" ) routes_eth0=( "default via 192.168.0.1" ) |
Pour utiliser DHCP, définissez la variable config_eth0 :
Exemple de code 2.7 : Obtenir une adresse IP automatiquement avec DHCP |
config_eth0=( "dhcp" ) |
Le fichier /etc/conf.d/net.example contient une série d'exemples commentés pour vous aider à configurer votre réseau. Veuillez également lire la page de manuel de votre client DHCP si vous souhaitez activer des options DHCP supplémentaires.
Si vous avez plusieurs interfaces réseau, répétez ces étapes avec config_eth1, config_eth2, etc.
Sauvegardez votre configuration, puis quittez l'éditeur afin de poursuivre.
Activer les connexions réseau automatiquement au démarrage
Pour que vos interfaces réseau soient activées automatiquement lors du démarrage, vous devez les ajouter au niveau d'exécution « default ».
Exemple de code 2.8 : Ajouter net.eth0 au niveau d'exécution « default » |
# rc-update add net.eth0 default
|
Si vous avez plusieurs interfaces réseau, vous devez créer les scripts appropriés (net.eth1, net.eth2 etc.). Pour ce faire, utilisez ln :
Exemple de code 2.9 : Créer des scripts d'initialisation supplémentaires |
# cd /etc/init.d # ln -s net.lo net.eth1 # rc-update add net.eth1 default |
Noter l'information relative au réseau
Vous devez maintenant fournir à Linux l'information relative à votre réseau. Cela est défini dans /etc/hosts et permet de faire le lien entre les noms d'hôtes et les adresses IP pour les hôtes qui ne sont pas gérés par le serveur de noms. Vous devez y faire figurer votre propre machine. Vous pouvez également y mettre d'autres machines de votre réseau si vous ne voulez pas configurer un serveur DNS interne.
Exemple de code 2.10 : Ouvrir /etc/hosts |
# nano -w /etc/hosts
|
Exemple de code 2.11 : Inscrire les informations réseau |
(Ceci sert à définir votre propre machine) 127.0.0.1 tux.homenetwork tux localhost (Définit des machines supplémentaires sur le réseau. Ces machines doivent avoir une IP statique pour que celà fonctionne.) 192.168.0.5 jenny.homenetwork jenny 192.168.0.6 benny.homenetwork benny |
Sauvegardez et quittez l'éditeur afin de poursuivre.
Pour commencer, définissons le mot de passe root en tapant :
Exemple de code 3.1 : Définition du mot de passe root |
# passwd
|
Gentoo utilise /etc/rc.conf pour la configuration générale qui s'applique à l'ensemble du système. Ouvrez /etc/rc.conf et appréciez les commentaires qui s'y trouvent :)
Exemple de code 3.2 : Ouvrir /etc/rc.conf |
# nano -w /etc/rc.conf
|
Ensuite, sauvez votre fichier et quittez votre éditeur.
Comme vous pouvez le voir, ce fichier est généreusement commenté afin de vous aider à paramétrer les différentes variables relatives à la configuration. Vous pouvez configurer votre système pour qu'il utilise Unicode. Vous pouvez aussi définir votre éditeur par défaut et votre gestionnaire d'affichage préféré (gdm ou kdm).
Le fichier /etc/conf.d/keymaps permet de spécifier le type de clavier que vous utilisez.
Exemple de code 3.3 : Ouvrir /etc/conf.d/keymaps |
# nano -w /etc/conf.d/keymaps
|
La valeur que vous attribuez à la variable KEYMAP détermine la disposition des touches de votre clavier. Si vous choisissez une valeur incorrecte, vous serez surpris quand vous taperez sur votre clavier.
Quand vous en avez terminé avec le fichier /etc/conf.d/keymaps, sauvez et quittez.
Ensuite, éditez le fichier /etc/conf.d/clock pour configurer les options relatives à l'horloge :
Exemple de code 3.4 : Ouvrir /etc/conf.d/clock |
# nano -w /etc/conf.d/clock
|
Si l'horloge de votre PC n'utilise pas l'heure UTC, vous devez ajouter CLOCK="local" à ce fichier sans quoi votre horloge fera des « saut d'heures ».
Vous devez déclarer le fuseau horaire que vous avez copié précédemment vers /etc/localtime afin que les prochaines mises à jour du paquet sys-libs/timezone-data puissent mettre à jour le fichier /etc/localtime automatiquement. Par exemple, si vous vous trouvez sur le fuseau de Paris, ajoutez la variable TIMEZONE="Europe/Paris".
Lorsque vous aurez fini de configurer /etc/conf.d/clock, sauvegardez puis quittez l'éditeur.
Poursuivez votre lecture avec l'installation des outils systèmes.
9.a. Système de journalisation des évènements
Certains outils ne sont pas inclus dans l'archive stage3 parce que plusieurs paquets fournissent la même fonctionnalité. À vous de choisir ceux que vous voulez installer.
Le premier outil que vous devez choisir devra enregistrer les étapes du démarrage du système. Unix et Linux ont une histoire riche en systèmes de journalisation. Si vous le voulez, vous pouvez enregistrer tous ce qui se passe sur votre système dans des fichiers de journalisation. Cela se passe via le système de journalisation.
Gentoo offre le choix entre différents systèmes de journalisation. Il y a sysklogd qui est l'ensemble d'utilitaires traditionnel, syslog-ng, un système de journalisation avancé et metalog, qui est un système de journalisation hautement configurable. D'autres sont peut-être disponibles, car le nombre de paquets dans Portage ne cesse de croitre.
Si vous avez l'intention d'utiliser sysklogd ou syslog-ng, vous devriez aussi installer logrotate qui permet de recycler les vieux fichiers de journalisation.
Pour installer le système de journalisation de votre choix, utilisez emerge puis ajoutez-le au niveau d'exécution « default » avec la commande rc-update. L'exemple suivant installe syslog-ng. Bien sûr, n'oubliez pas d'y substituer le nom de votre système de journalisation.
Exemple de code 1.1 : Installer un système de journalisation |
# emerge syslog-ng # rc-update add syslog-ng default |
9.b. Facultatif : le démon Cron
Bien qu'il ne soit pas nécessaire pour votre système, il est judicieux d'installer un démon « cron ». Mais qu'est-ce qu'un tel démon ? Un démon « cron » exécute des commandes planifiées. Il est très utile si vous avez besoin de lancer des commandes régulièrement (par exemple quotidiennement, hebdomadairement, mensuellement).
La Gentoo offre trois possibilités de démon cron : dcron, fcron et vixie-cron. En installer un est similaire à installer un système de journalisation. Cependant, dcron et fcron requièrent une commande de configuration supplémentaire, crontab /etc/crontab. Si vous ne savez pas lequel choisir, prenez vixie-cron.
Seul le paquet vixie-cron est disponible lors d'une installation sans réseau. Si vous préférez en installer un autre, vous pouvez attendre et l'installer quand vous le pourrez.
Exemple de code 2.1 : Installer un démon cron |
# emerge vixie-cron # rc-update add vixie-cron default (Seulement si vous avez choisi dcron ou fcron.) # crontab /etc/crontab |
9.c. Facultatif : indexation des fichiers
Si vous voulez indexer vos fichiers pour pouvoir les retrouver rapidement grâce à l'outil locate, vous devez installer le paquet sys-apps/slocate.
Exemple de code 3.1 : Installer slocate |
# emerge slocate
|
9.d. Outils du système de fichiers
En fonction du système de fichiers que vous utilisez, vous devez installer ses utilitaires (pour vérifier l'intégrité du système de fichiers, pour ajouter des systèmes de fichiers, etc.). Notez cependant que les outils qui gèrent les systèmes de fichiers ext2 et ext3 (e2fsprogs) sont déjà installés dans le système de base.
La table suivante liste les outils à installer en fonction du système de fichiers.
| Système de fichiers | Outil | Commande d'installation |
| XFS | xfsprogs | emerge xfsprogs |
| ReiserFS | reiserfsprogs | emerge reiserfsprogs |
| JFS | jfsutils | emerge jfsutils |
Si vous utilisez EVMS, vous devez installer le paquet evms :
Exemple de code 4.1 : Installer les outils EVMS |
# USE="-gtk" emerge evms
|
On utilise USE="-gtk" pour éviter d'installer les outils graphiques d'EVMS et leurs dépendances. Si vous voulez utiliser ces outils graphiques, vous pourrez recompiler evms plus tard.
Si vous n'avez pas besoin d'outils supplémentaires relatifs au réseau tels que ppp ou un client DHCP, continuez avec la Configuration du chargeur de démarrage.
Facultatif : installer un client DHCP
Si vous voulez que votre système acquière une adresse IP automatiquement, vous devez installer dhcpcd (ou tout autre client DHCP — consultez Les modules réseaux pour la liste des clients DHCP disponibles). Si vous ne le faites pas, vous risquez de ne pas pouvoir vous connecter à Internet après avoir fini l'installation.
Exemple de code 5.1 : Installer dhcpcd |
# emerge dhcpcd
|
Facultatif : installer un client PPPoE
Si vous avez besoin de ppp pour vous connecter à Internet, installez-le maintenant.
Exemple de code 5.2 : Installer ppp |
# emerge ppp
|
Poursuivez avec la configuration du chargeur de démarrage.
10.a. Configuration d'Arcload pour les machines Silicon Graphics
Pour démarrer une machine SGI, nous utilisons maintenant le chargeur de démarrage arcload qui remplace officiellement l'obsolète arcboot que nous utilisions auparavant pour installer Gentoo.
Note : L'entête de volume SGI ne peut contenir que 16 fichiers, avec chacun 8 caractères maximum pour le nom du fichier. |
arcload a été écrit pour les machines qui nécessitent un noyau 64 bits et qui ne peuvent donc pas utiliser arcboot (qui demande beaucoup de travail pour qu'on puisse le compiler en tant que binaire 64 bits). Il permet également de contourner certains problèmes qui apparaissent lorsqu'on charge un noyau directement depuis l'entête de volume. Passons donc à son installation :
Exemple de code 1.1 : Installer arcload et dvhtool |
# emerge arcload dvhtool
|
Les binaires arcload ont dû être installés dans /usr/lib/arcload :
Utilisez maintenant dvhtool pour installer le bon binaire dans l'entête de volume :
Exemple de code 1.2 : Placer arcload dans l'entête de volume |
(Pour les Indy/Indigo2/Challenge S/O2.) # dvhtool --unix-to-vh /usr/lib/arcload/sashARCS sashARCS (Pour les Indigo2 Impact/Octane/Octane2/Origin 200/Origin 2000.) # dvhtool --unix-to-vh /usr/lib/arcload/sash64 sash64 |
Note : Vous n'êtes pas obligé de garder les noms sashARCS ou sash64, à moins que vous ne placiez les fichiers dans l'entête de volume d'un CD-ROM amorçable. Le fichier peut porter le nom que vous voulez si c'est pour démarrer sur disque dur. |
Utilisez maintenant dvhtool pour vérifier que les fichiers sont correctement installés.
Exemple de code 1.3 : Vérifier l'installation d'arcload dans l'entête de volume |
# dvhtool --print-volume-directory
----- directory entries -----
Entry #0, name "sash64", start 4, bytes 55859
|
Le fichier de configuration, arc.cf, a une syntaxe à la C. Pour de longues explications sur son utilisation, voyez la page sur Arcload sur le wiki Linux/MIPS. Pour faire court, vous définissez un certain nombre d'options qui configureront le démarrage en utilisant la variable OSLoadFilename.
Exemple de code 1.4 : Un exemple de arc.cf |
# Configuration d'Arcload # Quelques valeurs par défaut... append "root=/dev/sda3"; append "ro"; append "console=ttyS0,9600"; # La définition principale, vous pouvez changer ip28 si vous voulez. ip28 { # Définition d'un noyau *fonctionnel* # Sélectionnez-le avec OSLoadFilename="ip28(working)" working { description "SGI Indigo2 Impact R10000\n\r"; image system "/working"; } # Définition d'un noyau en *test* # Sélectionnez-le avec OSLoadFilename="ip28(new)" new { description "SGI Indigo2 Impact R10000 - Testing Kernel\n\r"; image system "/new"; } # Pour déboguer un noyau # Sélectionnez-le avec OSLoadFilename="ip28(working,debug)" # ou OSLoadFilename="ip28(new,debug)" debug { description "Debug console"; append "init=/bin/bash"; } } |
À partir d'arcload-0.5, arc.cf et les noyaux peuvent résider dans l'entête de volume ou bien dans une partition. Si cette fonctionnalité vous intéresse, vous pouvez placer les fichiers directement dans votre partition /boot (ou / si vous n'avez pas de /boot séparé). arcload utilise le code du pilote de système de fichiers du populaire grub, et donc supporte les mêmes systèmes de fichiers.
Exemple de code 1.5 : Placer arc.cf et le noyau dans l'entête de volume |
# dvhtool --unix-to-vh arc.cf arc.cf # dvhtool --unix-to-vh /usr/src/linux/vmlinux new |
Ceci fait, tout ce qu'il reste à faire est de régler quelques options dans la PROM. Voyez cela dans la section Redémarrer le système.
10.b. Configuration de CoLo pour les serveurs Cobalt
Les capacités du firmware installé sur les cartes des serveurs Cobalt sont bien plus limitées. Le BOOTROM de Cobalt est primitif en comparaison à la PROM SGI et a un certain nombre de limitations critiques.
Pour s'affranchir de toutes ces limitations, un firmware alternatif nommé CoLo (Cobalt Loader) a été développé. C'est une image BOOTROM qui peut au choix être incorporée directement dans la carte du serveur Cobalt ou être chargée par le firmware actuel.
Note : Ce guide va vous indiquer comment installer CoLo afin qu'il soit chargé par le firmware d'origine. C'est la seule méthode sure et recommandée d'installer CoLo. |
Attention : Si vous le souhaitez, vous pouvez tout aussi bien le « flasher » dans votre serveur et remplacer le firmware originel. Cela dit, vous prenez vos propres risques en faisant cela. Si quelque chose ne va pas, il vous faudra supprimer physiquement le BOOTROM et le reprogrammer vous-même avec le firmware d'origine. Si vous n'êtes pas sûr de la méthode, alors NE TOUCHEZ À RIEN. Nous ne sommes pas responsable de ce que vous ferez si vous ignorez cet avertissement. |
Bon, cela étant dit, nous pouvons procéder à l'installation de CoLo. Tout d'abord commencez par installer le paquet.
Exemple de code 2.1 : Installation de colo |
# emerge colo
|
Maintenant que c'est installé (j'espère que vous avez lu les messages) vous devriez jeter un coup d'œil au répertoire /usr/lib/colo qui contient deux fichiers : colo-chain.elf, qui est le « noyau » à charger par le firmware d'origine, et colo-rom-image.bin, qui est une image ROM pour remplacer son BOOTROM. Commençons par monter /boot et y mettre une copie compressée de colo-chain.elf là où le système s'attend à la trouver.
Exemple de code 2.2 : Mettre CoLo à sa place |
# gzip -9vc /usr/lib/colo/colo-chain.elf > /boot/vmlinux.gz
|
Maintenant, quand le système démarre pour la première fois, il chargera CoLo. Celui-ci va afficher un menu sur votre LCD à l'arrière de la machine. La première option (celle par défaut qui sera validée après 5 secondes) est de démarrer sur le disque dur. Le système propose alors de monter la première partition Linux qu'il trouvera et d'exécuter le script default.colo. La syntaxe de ce fichier est très bien documentée dans la documentation de CoLo (jetez un coup d'œil au fichier /usr/share/doc/colo-X.YY/README.shell.gz — où X.YY est la version de CoLo installée) et est très simple.
Note : Astuce : gardez toujours deux noyaux, un kernel.gz.working dont vous savez qu'il fonctionne et kernel.gz.new, celui que vous venez de compiler. Ensuite, utilisez un lien symbolique vers l'un ou l'autre, ou faites une copie de l'un d'eux. |
Exemple de code 2.3 : Un fichier default.colo de base |
#:CoLo:#
mount hda1
load /kernel.gz.working
execute root=/dev/hda3 ro console=ttyS0,115200
|
Note : CoLo refusera de charger un script qui ne commence pas par la ligne #:CoLo:#. Prenez-le comme une sorte d'équivalent à la ligne #!/bin/sh dans un script shell. |
Il est également possible de proposer un menu qui vous demanderait par exemple quel noyau et configuration vous souhaiteriez charger. Le menu aurait un délai de réponse par défaut. Dans cet exemple, le menu demande à l'utilisateur quel noyau il souhaite utiliser, puis l'exécute. vmlinux.gz.new et vmlinux.gz.working peuvent être des images de noyau ou bien simplement des liens pointant vers les images sur le disque. L'argument 50 de select signifie que CoLo démarrera la première option (ici « Working ») après 50 dixièmes de secondes.
Exemple de code 2.4 : Configuration avec menu |
#:CoLo:#
lcd "Monter hda1"
mount hda1
menu "Quel noyau ?" 50 Working New
goto {menu-option}
var image-name vmlinux.gz.working
goto 3f
@var image-name vmlinux.gz.working
goto 2f
@var image-name vmlinux.gz.new
@lcd "Chargement de Linux" {menu-option}
load / {image-name}
lcd "Démarrage..."
execute root=/dev/hda5 ro console=ttyS0,115200
boot
|
Référez-vous à la documentation dans /usr/share/doc/colo-VERSION pour plus de détails.
10.c. Mise en place pour une console en série
Bon, l'installation de Linux devrait désormais démarrer correctement, mais suppose que vous allez vous connecter dessus depuis un terminal physique. Sur les machines Cobalt, c'est particulièrement ennuyeux dans la mesure où les terminaux physiques... n'existent pas.
Note : Ceux qui ont le luxe d'avoir une carte graphique supportée peuvent sauter ce chapitre s'ils le souhaitent. |
Tout d'abord, ouvrez un éditeur et allez cherchez le fichier /etc/inittab. Dans celui-ci, vous devriez voir les lignes suivantes :
Exemple de code 3.1 : Configuration de inittab |
# SERIAL CONSOLE #c0:12345:respawn:/sbin/agetty 9600 ttyS0 vt102 # TERMINALS c1:12345:respawn:/sbin/agetty 38400 tty1 linux c2:12345:respawn:/sbin/agetty 38400 tty2 linux c3:12345:respawn:/sbin/agetty 38400 tty3 linux c4:12345:respawn:/sbin/agetty 38400 tty4 linux c5:12345:respawn:/sbin/agetty 38400 tty5 linux c6:12345:respawn:/sbin/agetty 38400 tty6 linux # What to do at the "Three Finger Salute". ca:12345:ctrlaltdel:/sbin/shutdown -r now |
Commencez par enlever le commentaire de la ligne c0. Par défaut il est configuré pour utiliser un terminal ayant un taux de transfert de 9600bps. Sur les serveurs Cobalt, vous pouvez changer la valeur à 115200 pour que cela corresponde au taux de transfert décidé par le BOOTROM. Voici à quoi ressemble cette section après avoir commenté les lignes pour les terminaux locaux (c1 à c6) dans la mesure où ceux-ci posent problème quand ils ne peuvent pas ouvrir /dev/ttyX.
Exemple de code 3.2 : Extrait de la configuration de inittab |
# SERIAL CONSOLE c0:12345:respawn:/sbin/agetty 115200 ttyS0 vt102 # TERMINALS -- These are useless on a headless qube #c1:12345:respawn:/sbin/agetty 38400 tty1 linux #c2:12345:respawn:/sbin/agetty 38400 tty2 linux #c3:12345:respawn:/sbin/agetty 38400 tty3 linux #c4:12345:respawn:/sbin/agetty 38400 tty4 linux #c5:12345:respawn:/sbin/agetty 38400 tty5 linux #c6:12345:respawn:/sbin/agetty 38400 tty6 linux |
Finalement, nous devons indiquer au système que le port série local peut être considéré comme un terminal sûr. Le fichier qu'il vous faudra modifier est /etc/securetty. Il contient une liste de terminaux que le système peut utiliser. Il nous suffit d'ajouter deux lignes pour permettre au port série d'être utilisé pour se connecter en tant que root.
Exemple de code 3.3 : Permettre la connexion de root sur la console en série |
(/dev/ttyS0, le nom traditionnel du premier port série) # echo 'ttyS0' >> /etc/securetty (Ensuite, Linux appelle également cela /dev/tts/0, donc nous l'ajoutons aussi) # echo 'tts/0' >> /etc/securetty |
Sortez de l'environnement « chroot » et démontez toutes les partitions montées. Ensuite, tapez la commande magique tant attendue : reboot.
Exemple de code 4.1 : Sortie du chroot, démontage des partitions et redémarrage |
# exit cdimage ~# cd cdimage ~# umount /mnt/gentoo/boot /mnt/gentoo/dev /mnt/gentoo/proc /mnt/gentoo cdimage ~# reboot |
Note : Pour les utilisateurs de Cobalt : la suite de ce chapitre concerne la configuration de la PROM SGI afin qu'elle puisse démarrer arcload et charger Linux. Ce n'est pas applicable à la configuration des serveurs Cobalt. En fait, vous avez fini votre travail de configuration et pouvez désormais démarrer sur votre système. Passez directement au chapitre : Finaliser votre installation de Gentoo. |
Configuration générale de la PROM
Maintenant que le chargeur de démarrage est installé, vous êtes prêt à redémarrer la machine.
Exemple de code 5.1 : Redémarrer |
(Quitter l'environnement chroot.) # exit (Démonter les disques.) # umount /gentoo/boot # umount /gentoo (Redémarrer.) # reboot |
Lorsque vous avez redémarré, allez dans le menu System Maintenance Menu et sélectionnez Enter Command Monitor (5) comme lorsque vous avez démarré votre machine sur le réseau.
Exemple de code 5.2 : Configuration de la PROM pour démarrer Gentoo |
1) Start System 2) Install System Software 3) Run Diagnostics 4) Recover System 5) Enter Command Monitor Option? 5 Command Monitor. Type "exit" to return to the menu. (Quelques options pour arcload.) (Situer l'entête de volume.) >> setenv SystemPartition scsi(0)disk(1)rdisk(0)partition(8) (Démarrer automatiquement Gentoo.) >> setenv AutoLoad Yes (Régler le fuseau horaire.) >> setenv TimeZone EST5EDT (Utiliser la console série : « g » au lieu de « d1 » pour les possesseurs de carte graphique.) >> setenv console d1 (Régler la console série : de 9600 (par défaut) à 38400.) >> setenv dbaud 9600 |
Les réglages suivants dépendent de comment vous démarrez votre système.
Réglages concernant le démarrage sur l'entête de volume
Nous en partons uniquement dans un soucis d'exhaustivitvé, nous vous recommandons plutôt d'utiliser arcload pour démarrer.
Note : Ceci n'est valable que pour Indy, Indigo2 (R4k) et Challenge S. |
Exemple de code 5.3 : Configuration de la PROM pour démarrer Gentoo depuis l'entête de volume |
(<périphérique racine> = la partition racine (root) Gentoo, /dev/sda3 par exemple >> setenv OSLoadPartition <périphérique racine> (Pour obtenir la liste des noyaux disponibles, tapez « ls ».) >> setenv OSLoader <nom du noyau> >> setenv OSLoadFilename <nom du noyau> (Déclarez les paramètres du noyau à passer en argument.) >> setenv OSLoadOptions <paramètres du noyau> |
Pour essayer un noyau directement, vous pouvez utiliser la commande PROM boot -f :
Exemple de code 5.4 : Démarrer sans changer les variables d'environnement |
(Démarrer un noyau, « new », avec des paramètres supplémentaires.) # boot -f new root=/dev/sda3 ro |
arcload utilise l'option OSLoadFilename pour indiquer quelles options charger depuis arc.cf. Ce fichier est essentiellement un script dont les blocs principaux définissent les images de démarrage des différents systèmes et contiennent les options. Donc, l'option OSLoadFilename=mysys(serial) ira chercher les réglages du bloc mysys et applique les options supplémentaires de serial.
Dans l'exemple suivant, nous avons un bloc système de défini, ip28, avec les options working, new et debug. Voici comment nous définissons nos variables PROM :
Exemple de code 5.5 : Réglages PROM pour utiliser arcload |
(Choisir le chargeur de démarrage : sash64 ou sashARCS) >> setenv OSLoader sash64 (Utilisation de l'image « working », définie dans la section « ip28 ».) >> setenv OSLoadFilename ip28(working) |
À partir d'arcload-0.5, les fichiers n'ont plus besoin d'être chargés dans l'entête de volume, ils peuvent simplement se trouver sur une partition ext2/3. Pour dire à arcload où chercher ses fichiers de configuration et ses noyaux, vous devez définir la variable PROM OSLoadPartition. La valeur exacte dépendra d'où se situe votre disque sur le bus SCSI. Utilisez la variable PROM SystemPartition pour vous guider, seul le numéro de partition devrait changer.
Note : Les partitions sont numérotées à partir de 0. |
Exemple de code 5.6 : Indiquer à arcload où trouver arc.cf |
(Si vous souhaitez le charger depuis l'entête de volume, spécifiez la partition 8.) >> setenv OSLoadPartition scsi(0)disk(1)rdisk(0)partition(8) (Sinon, spécifiez le numéro et le type de partition.) >> setenv OSLoadPartition scsi(0)disk(1)rdisk(0)partition(0)[ext2] |
Vous êtes maintenant fin prêt pour apprécier Gentoo ! Démarrer votre installation et concluez avec la finalisation de l'installation.
11.a. Administration des utilisateurs
Ajouter un utilisateur pour une utilisation quotidienne
Travailler en temps que root sur un système Unix/Linux est dangereux et devrait être évité aussi souvent que possible. Par conséquent, il est vivement recommandé d'ajouter un utilisateur pour une utilisation quotidienne.
Les actions qu'un utilisateur a le droit de faire sont définies par les groupes dont l'utilisateur est membre. Le tableau ci-dessous liste quelques groupes importants :
| Groupe | Description |
| audio | accès autorisé aux périphériques audio |
| cdrom | accès direct autorisé aux lecteurs optiques |
| floppy | accès direct autorisé au lecteur de disquettes |
| games | accès aux jeux |
| portage | permet d'utiliser emerge --pretend |
| usb | accès autorisé aux périphériques USB |
| plugdev | permet de monter de périphériques à chaud et de les utiliser, par exemple des appareils photos numériques ou des clés USB |
| video | accès autorisé au matériel de capture vidéo et à l'accélération matérielle |
| wheel | commande su utilisable |
Par exemple, pour créer un utilisateur nommé john qui est membre des groupes wheel , users et audio, identifiez-vous en tant qu'utilisateur root (seul root peut créer des comptes) et faites :
Exemple de code 1.1 : Ajouter un compte pour une utilisation de tous les jours |
Login: root Password: (votre mot de passe root) # useradd -m -G users,wheel,audio -s /bin/bash john # passwd john Password: (tapez le mot de passe pour john) Re-enter password: (retapez-le pour vérifier) |
Si cet utilisateur à besoin d'utiliser le compte root, il peut utiliser su - pour obtenir les privilèges root. Un autre moyen est d'utiliser le paquet sudo qui est, s'il est configuré correctement, très sécurisé.
Maintenant que l'installation de Gentoo est terminée et que vous avez redémarré, si tout s'est bien passé, vous pouvez supprimer l'archive stage3 et l'instantané de Portage que vous avez téléchargés et sauvés sur votre disque dur. Normalement vous les aviez placés dans /.
Exemple de code 2.1 : Supprimer l'archive stage3 |
# rm /stage3-*.tar.bz2*
|
Exemple de code 2.2 : Supprimer l'instantané de Portage |
# rm /portage-latest.tar.bz2*
|
Félicitations ! Vous avez maintenant un système Gentoo utilisable. Mais que pouvez-vous en faire ? Quelle sont les options ? Que pouvez-vous explorer maintenant ? Gentoo donne beaucoup de possibilités à ses utilisateurs, et donc beaucoup de fonctionnalités documentées (et d'autres qui le sont moins).
Vous devriez vraiment regarder la partie suivante du Manuel Gentoo : Utiliser Gentoo qui explique comment garder votre système à jour, installer des logiciels supplémentaires, quelles sont les options de USE, comment le système d'initialisation de Gentoo fonctionne, etc.
Si vous êtes intéressé par l'optimisation de votre système pour une utilisation graphique ou que vous voulez apprendre comment configurer votre système pour qu'il soit entièrement fonctionnel en mode graphique, consultez la Documentation Gentoo relative au bureau. Le Guide de localisation vous sera particulièrement utile si vous préférez utiliser un système francisé.
De plus, notre Manuel de sécurité Gentoo Linux pourra sans doute vous être utile.
Pour une liste complète de la documentation disponible, regardez notre Centre de documentation Gentoo.
Vous êtes bien sûr invité sur les Forums Gentoo (en anglais) et sur le Forum Gentoo francophone, ou sur un de nos nombreux canaux IRC Gentoo en anglais, en français, et bien d'autres langues.
Nous avons aussi quelques listes de diffusion (N.D.T. : surtout en anglais, mais il y a aussi des listes francophones) ouvertes à tous les utilisateurs. Cette page vous explique comment y participer.
C'est fini, vous pouvez maintenant éteindre votre ordinateur et reprendre une activité normale. ;-)
1.a. Bienvenue dans le monde de Portage
Portage est probablement l'innovation de Gentoo la plus remarquable en ce qui concerne la gestion des logiciels. Sa grande flexibilité et ses nombreuses fonctionnalités font parfois dire de Portage qu'il est le meilleur outil de gestion des logiciels pour Linux.
Portage a été écrit en Python et en Bash qui sont tous les deux des langages scriptés, c'est-à-dire que 100 % du code source est installé et consultable sur tous les systèmes Gentoo.
La plupart des utilisateurs interagiront avec Portage via la commande emerge. Ce chapitre n'a pas pour vocation de dupliquer toute l'information disponible dans la page man de emerge. Pour consulter la page man, faites :
Exemple de code 1.1 : Consulter la page man de emerge |
$ man emerge
|
Quand nous parlons de paquets, nous parlons des logiciels qui sont disponibles dans Gentoo grâce à l'arbre de Portage. Celui-ci est un ensemble d'ebuilds qui sont en fait des fichiers qui donnent toutes les informations nécessaires à Portage pour installer un logiciel. Par défaut, ces ebuilds se trouvent dans /usr/portage.
Dès que vous employez Portage pour une action relative aux paquets, il utilisera les ebuilds de votre système. Il est donc important de maintenir les ebuilds de votre système à jour pour que Portage puisse installer des nouvelles versions des logiciels que vous utilisez ou des correctifs de failles de sécurité.
Mise à jour de l'arbre Portage
L'arbre Portage est généralement mis à jour avec rsync qui est un outil de transfert de fichiers incrémental. La mise à jour se fait simplement avec la commande emerge. L'utilisation de rsync est tout à fait transparente :
Exemple de code 2.1 : Mettre l'arbre Portage à jour |
# emerge --sync
|
Si vous ne pouvez pas utiliser rsync à cause, par exemple, d'un pare-feu, vous pouvez quand même mettre votre arbre Portage à jour avec la commande emerge-webrsync. Celle-ci télécharge le dernier instantané de l'arbre Portage et l'installe sur votre système. Un instantané est généré automatiquement chaque jour sur les miroirs de Gentoo.
Exemple de code 2.2 : Utiliser emerge-webrsync |
# emerge-webrsync
|
Pour rechercher un logiciel dans l'arbre Portage, vous pouvez utiliser emerge. En effet, la commande emerge --search affiche la liste des paquets dont le titre correspond plus ou moins au terme recherché.
Par exemple, pour trouver tous les paquets dont le nom contient « pdf », vous utiliseriez :
Exemple de code 3.1 : Trouver les paquets dont le nom contient « pdf » |
$ emerge --search pdf
|
Si vous voulez aussi chercher dans les descriptions, utilisez l'option --searchdesc (ou -S) :
Exemple de code 3.2 : Trouver les paquets relatifs à « pdf » |
$ emerge --searchdesc pdf
|
La liste des paquets affichés contient quelques informations utiles pour chaque paquet. Les libellés sont explicites et nous n'en dirons pas plus ici.
Exemple de code 3.3 : Exemple de résultat d'une recherche avec « emerge --search » |
* net-print/cups-pdf
Latest version available: 1.5.2
Latest version installed: [ Not Installed ]
Size of downloaded files: 15 kB
Homepage: http://cip.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/
Description: Provides a virtual printer for CUPS to produce PDF files.
License: GPL-2
|
Une fois que vous avez identifié un paquet que vous voulez installer, il vous suffit d'utiliser la commande emerge suivie du nom du paquet pour l'installer. Par exemple, pour installer gnumeric :
Exemple de code 3.4 : Installer gnumeric |
# emerge gnumeric
|
De nombreuses applications dépendent d'autres paquets. Par conséquent, quand vous installez un logiciel, il se peut que Portage en installe d'autres qui sont nécessaires au bon fonctionnement du paquet que vous installez. Si vous voulez connaitre la liste des paquets que Portage installerait si vous installiez un paquet donné, vous pouvez utiliser l'option --pretend. Un exemple :
Exemple de code 3.5 : Lister les paquets à installer pour gnumeric |
# emerge --pretend gnumeric
|
Quand vous installez un paquet avec Portage, il télécharge les sources nécessaires et les sauve dans le répertoire /usr/portage/distfiles. Ensuite, Portage décompresse l'archive, compile son contenu et installe le logiciel. Si vous voulez télécharger les sources sans installer le paquet, utilisez l'option --fetchonly. Par exemple, pour télécharger les sources de gnumeric :
Exemple de code 3.6 : Télécharger les sources de gnumeric |
# emerge --fetchonly gnumeric
|
Trouver la documentation d'un paquet installé
De nombreux paquets installent leur propre documentation. Parfois l'option USE doc indique si la documentation d'un paquet doit être installée ou non. Vous pouvez vérifier l'existence de l'option USE doc avec la commande emerge -vp <nom du paquet>.
Exemple de code 3.7 : Vérifier l'existence de l'option USE doc |
(L'utilisation d'alsa-lib n'est qu'un exemple bien sûr.) # emerge -vp alsa-lib [ebuild N ] media-libs/alsa-lib-1.0.14_rc1 -debug +doc 698 kB |
La meilleure façon d'activer l'option USE doc est de le faire paquet par paquet via /etc/portage/package.use, afin que vous n'ayez la documentation que pour les paquets qui vous intéressent. L'activation de manière globale de cette option est connue pour causer des problèmes de dépendances circulaires. Pour plus d'informations, veuillez lire le chapitre La variable USE.
Une fois le paquet installé, la documentation se trouve généralement dans un sous-répertoire au nom du paquet dans le répertoire /usr/share/doc. Vous pouvez également lister tous les fichiers installés avec l'outil equery qui fait partie du paquet app-portage/gentoolkit .
Exemple de code 3.8 : Trouver la documentation d'un paquet |
# ls -l /usr/share/doc/alsa-lib-1.0.14_rc1 total 28 -rw-r--r-- 1 root root 669 May 17 21:54 ChangeLog.gz -rw-r--r-- 1 root root 9373 May 17 21:54 COPYING.gz drwxr-xr-x 2 root root 8560 May 17 21:54 html -rw-r--r-- 1 root root 196 May 17 21:54 TODO.gz (Autre méthode, avec equery :) # equery files alsa-lib | less media-libs/alsa-lib-1.0.14_rc1 * Contents of media-libs/alsa-lib-1.0.14_rc1: /usr /usr/bin /usr/bin/alsalisp (etc.) |
Pour désinstaller un paquet de votre système, utilisez emerge --unmerge. Cette commande supprime les fichiers qui avaient été installés par Portage, mais ne supprime pas les fichiers de configuration si vous les avez modifiés après l'installation. Cela vous permet de réutiliser vos fichiers de configuration si vous réinstallez le paquet plus tard.
Cependant, un avertissement est de mise :Portage ne vérifie pas que le paquet que vous supprimez est nécessaire au bon fonctionnement d'un autre paquet. Toutefois, un message s'affichera si vous essayez de supprimer un paquet important dont la disparition causerait de graves problèmes.
Exemple de code 3.9 : Supprimer gnumeric de votre système |
# emerge --unmerge gnumeric
|
Quand vous supprimez un paquet, les paquets dont il dépend qui avaient été installés initialement ne seront pas désinstallés automatiquement. Pour que Portage recherche les dépendances qui peuvent être supprimées, utilisez l'option depclean. Nous en reparlerons plus loin.
Pour maintenir votre système en bon état et disposer des correctifs de failles de sécurité, vous devriez le mettre à jour régulièrement. Puisque Portage ne se base que sur les ebuilds de votre machine, vous devez vous assurez que votre arbre Portage est à jour. Une fois votre arbre Portage à jour, vous pouvez mettre votre système à jour avec la commande emerge --update world. Dans l'exemple ci-dessous, on utilise aussi l'option --ask pour que Portage affiche la liste des paquets qu'il va mettre à jour et pour qu'il demande une confirmation.
Exemple de code 3.10 : Mettre votre système à jour |
# emerge --update --ask world
|
Portage recherche alors des versions plus récentes des logiciels que vous avez installés explicitement et uniquement ceux-là. Portage ignorera les paquets qui ont été installés automatiquement pour qu'un paquet que vous avez demandé puisse être installé. Si vous voulez que Portage prenne ces paquets en considération, utilisez l'option --deep :
Exemple de code 3.11 : Mettre tout votre système à jour |
# emerge --update --deep world
|
Étant donné que des mises à jour qui corrigent des failles de sécurité sont apportées à des paquets que vous n'avez pas explicitement installés, mais qui ont été installés parce que d'autres paquets en dépendent, il est recommandé d'exécuter la commande ci-dessus de temps en temps.
Si vous avez modifié les options de la variable USE, vous devriez également ajouter l'option --newuse pour que Portage vérifie si certains paquets ne doivent pas être recompilés. Par exemple :
Exemple de code 3.12 : Une mise à jour complète |
# emerge --update --deep --newuse world
|
Certains paquets ne contiennent aucun logiciel, mais servent à installer un ensemble de paquets. Par exemple, le paquet kde sert à installer un environnement KDE complet et provoque l'installation d'un grand nombre de paquets relatifs à KDE.
Supprimer un tel paquet avec la commande emerge --unmerge n'aurait aucune influence sur votre système puisque tous les paquets dépendants resteraient installés.
Portage permet de supprimer les dépendances orphelines, mais, pour cela, vous devez d'abord mettre votre système complètement à jour en tenant compte d'éventuelles modifications apportées à votre variable USE. Vous pouvez ensuite utiliser emerge --depclean pour supprimer les dépendances orphelines. Par après, vous devriez recompiler les applications qui étaient liées dynamiquement avec les paquets que vous venez de supprimer. Les paquets désinstallés ne sont plus nécessaires à la bonne marche de ces applications.
Tout cela peut être résumé en trois commandes :
Exemple de code 3.13 : Supprimer les dépendances orphelines |
# emerge --update --deep --newuse world # emerge --depclean # revdep-rebuild |
La commande revdep-rebuild fait partie du paquet gentoolkit ; n'oubliez pas de l'installer :
Exemple de code 3.14 : Installer gentoolkit |
# emerge gentoolkit
|
1.d. Quand Portage se plaint...
À propos des « SLOTs », paquets virtuels, branches, architectures et profils
Comme nous l'avons déjà dit, Portage est très puissant et offre de nombreuses fonctionnalités que d'autres gestionnaires de logiciels n'ont pas. Survolons les différents aspects de Portage.
Portage permet à plusieurs versions d'un même paquet de cohabiter sur le même système. D'autres distributions ont tendance à renommer les paquets en fonction de la version (par exemple freetype et freetype2) alors que Portage utilise des « SLOTs ». Un ebuild peut placer chaque version du logiciel dans un slot et des versions qui sont dans des slots différents peuvent être installées en même temps. Par exemple, le paquet freetype a des versions avec SLOT="1" et SLOT="2".
Dans certains cas, différents paquets installent la même fonctionnalité. Par exemple, metalogd, sysklogd et syslog-ng gèrent tous le jounal du système, mais un logiciel qui dépendrait du journal système ne peut pas dépendre directement de metalogd ou d'un autre. Le système doit aussi fonctionner si l'utilisateur a choisi un autre gestionnaire de journal. Portage permet de définir des paquets virtuels. Les trois paquets cités ci-dessus fournissent la fonctionnalité virtual/syslog et les paquets qui ont besoin d'un journal système dépendent de celle-ci.
Portage classe les paquets dans plusieurs branches. Par défaut, votre système n'accepte que les paquets que Gentoo considère stables. Bien souvent, quand une nouvelle version d'un logiciel sort, elle est d'abord ajoutée à la branche dite « instable », ce qui signifie que plus de tests sont nécessaires avant de considérer le logiciel comme stable. Vous verrez les paquets dits instables dans votre arbre, mais Portage ne les installera pas automatiquement avant qu'ils ne soient stabilisés.
Certains logiciels ne sont disponibles que pour certaines architectures ou ne fonctionnent pas du tout sur d'autres. Parfois, un logiciel a besoin de plus de tests sur une architecture donnée ou les développeurs responsables d'un paquet n'ont pas la possibilité de le valider pour d'autres processeurs.
Chaque installation de Gentoo appartient à un profil qui contient la liste des paquets qui forment un système minimal.
Exemple de code 4.1 : Avertissement à propos d'un paquet bloquant (avec --pretend) |
[blocks B ] mail-mta/ssmtp (is blocking mail-mta/postfix-2.2.2-r1) |
Exemple de code 4.2 : Avertissement à propos d'un paquet bloquant (sans --pretend) |
!!! Error: the mail-mta/postfix package conflicts with another package. !!! both can't be installed on the same system together. !!! Please use 'emerge --pretend' to determine blockers. |
Les ebuilds contiennent des informations relatives aux dépendances des logiciels entre eux. Il y a deux sortes de dépendances : les dépendances à l'installation définies par DEPEND et les dépendances à l'utilisation définies dans RDEPEND. Un blocage peut se produire quand un paquet est considéré incompatible avec une dépendance.
Pour résoudre un tel blocage, vous pouvez soit ne pas installer le logiciel en question, soit désinstaller le paquet qui bloque. Dans l'exemple ci-dessus, vous auriez le choix entre ne pas installer postfix ou d'abord désinstaller ssmtp.
Un blocage peut être provoqué par une version spécifique d'un logiciel, par exemple : <media-video/mplayer-bin-1.0_rc1-r2. Dans ce cas, il suffit de mettre à jour le logiciel en question vers une version plus récente pour supprimer le blocage.
Il se peut que deux paquets qui ne sont pas encore installés se bloquent entre eux. Dans ce rare cas, vous devez trouver pourquoi les deux paquets veulent s'installer car normalement un seul suffit. Si le problème persiste, veuillez remplir un rapport de bogue sur notre système de gestion de bogues.
Exemple de code 4.3 : Avertissement à propos de paquets masqués |
!!! all ebuilds that could satisfy "bootsplash" have been masked. |
Exemple de code 4.4 : Avertissement à propos de paquets masqués avec la raison |
!!! possible candidates are: - gnome-base/gnome-2.8.0_pre1 (masked by: ~x86 keyword) - lm-sensors/lm-sensors-2.8.7 (masked by: -sparc keyword) - sys-libs/glibc-2.3.4.20040808 (masked by: -* keyword) - dev-util/cvsd-1.0.2 (masked by: missing keyword) - games-fps/unreal-tournament-451 (masked by: package.mask) - sys-libs/glibc-2.3.2-r11 (masked by: profile) |
Quand vous essayez d'installer un paquet qui n'est pas disponible pour votre système, vous recevez ce type d'erreur. Vous devriez essayer d'installer une autre application qui est disponible pour votre environnement ou attendre que le paquet devienne disponible. Un paquet est toujours masqué pour une bonne raison :
Exemple de code 4.5 : Avertissement à propos de dépendances manquantes |
emerge: there are no ebuilds to satisfy ">=sys-devel/gcc-3.4.2-r4". !!! Problem with ebuild sys-devel/gcc-3.4.2-r2 !!! Possibly a DEPEND/*DEPEND problem. |
L'application que vous essayez d'installer dépend d'autres paquets qui ne sont pas disponibles pour votre système. Veuillez vérifier sur bugzilla si le problème est déjà connu et veuillez le signaler dans le cas contraire. À moins que vous ne mélangiez les branches stables et instables, cela de doit pas arriver et peut être considéré comme un bogue.
Exemple de code 4.6 : Avertissement à propos de noms d'ebuilds ambigus |
!!! The short ebuild name "aterm" is ambiguous. Please specify
!!! one of the following fully-qualified ebuild names instead:
dev-libs/aterm
x11-terms/aterm
|
Le paquet que vous essayez d'installer a un nom qui désigne plusieurs paquets dans des catégories différentes. Vous devez mentionner la catégorie du paquet que vous voulez installer. Portage affiche les différentes possibilités.
Exemple de code 4.7 : Avertissement à propos de dépendances circulaires |
!!! Error: circular dependencies: ebuild / net-print/cups-1.1.15-r2 depends on ebuild / app-text/ghostscript-7.05.3-r1 ebuild / app-text/ghostscript-7.05.3-r1 depends on ebuild / net-print/cups-1.1.15-r2 |
Deux (ou plus) paquets dépendent l'un de l'autre et ne peuvent pas être installés. Il est très probable que cela soit un bogue. Veuillez synchroniser votre arbre Portage. Si le problème persiste, veuillez vérifier si le problème est connu dans bugzilla et le signaler dans le cas contraire.
Problèmes lors du téléchargement
Exemple de code 4.8 : Avertissement à propos d'un problème au téléchargement |
!!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing...
(...)
!!! Some fetch errors were encountered. Please see above for details.
|
Portage n'a pas pu télécharger les sources de l'application et essaie éventuellement d'installer les autres paquets que vous auriez spécifiés avec la commande emerge. Ce problème peut être dû à un miroir qui n'est pas encore synchronisé ou à un ebuild qui référence un serveur de sources incorrect. Il se peut aussi que le serveur soit momentanément indisponible.
Veuillez réessayer après quelques heures.
Protection des paquets du profil système
Exemple de code 4.9 : Avertissement à propos du profil système |
!!! Trying to unmerge package(s) in system profile. 'sys-apps/portage' !!! This could be damaging to your system. |
Vous avez demandé à Portage de supprimer un paquet qui fait partie du profil système. Le supprimer pourrait rendre votre système inutilisable.
Échecs à la vérification des sommes de contrôle (Digest)
Parfois, quand vous essayez d'installer un paquet, cela échoue avec le message :
Exemple de code 4.10 : Digest verification failure |
>>> checking ebuild checksums !!! Digest verification failed: |
Ceci est le signe d'une erreur dans l'arbre de Portage et souvent il se peut qu'un développeur ait fait une erreur lors de l'envoi d'une mise à jour d'un paquet dans l'arbre.
Quand la vérification de la somme de contrôle échoue, n'essayez pas de régénérer le fichier Digest vous-même. Exécuter ebuild toto manifest ne réglera pas le problème, au contraire !
Attendez plutôt une heure ou deux que l'arbre soit corrigé. Il est probable que l'erreur ait été déjà signalée, mais cela peut prendre un petit moment pour la correction et la propagation dans l'arbre de Portage. Vous pouvez, pendant ce temps, vérifier dans Bugzilla si quelqu'un a déjà signalé le problème. Si ça n'est pas le cas, envoyez un rapport de bogue pour un paquet cassé.
Dès que vous voyez que le bogue est corrigé, vous pouvez mettre à jour votre arbre de Portage pour récupérer le fichier Digest corrigé.
Important : Cela ne signifie pas que vous pouvez multiplier les mises à jour de votre arbre de Portage ! Comme expliqué dans les règles d'usage de rsync (quand vous exécutez emerge --sync), les utilisateurs qui synchronisent trop souvent seront bannis ! Le plus sage est d'attendre votre prochaine mise à jour d'arbre de Portage comme vous l'aviez prévu, de cette manière vous ne surchargerez pas les serveurs rsync. |
2.a. Que sont les paramètres USE ?
Les notions sous-jacentes aux paramètres USE
Losque vous installez Gentoo (ou n'importe quelle autre distribution, voire système d'exploitation), vous faites des choix qui dépendent de l'environnement dans lequel vous travaillez. La configuration d'un serveur est différente de celle d'une station de travail. Une machine destinée aux jeux diffère d'une station de travail pour du rendu 3D.
Cela s'applique non seulement au choix des paquets que vous comptez installer, mais aussi aux fonctionnalités que chaque paquet devrait supporter. Si vous n'avez pas besoin d'OpenGL, pourquoi prendre la peine d'installer OpenGL et de construire la plupart de vos paquets avec support pour OpenGL ? Si vous ne souhaitez pas utiliser KDE, pourquoi compiler des paquets avec le support KDE alors qu'ils fonctionneraient parfaitement sans ce support ?
Pour aider les utilisateurs à déterminer ce qu'ils veulent installer ou activer, nous souhaitions que l'utilisateur spécifie son environnement de manière simple. Il est ainsi obligé de décider ce qu'il veut vraiment, et cela facilite la tâche de Portage, notre gestionnaire de paquets, pour prendre les décisions utiles.
C'est ici qu'interviennent les paramètres USE. Un tel paramètre est un mot-clé qui définit le support et les dépendances pour un concept donné. Si vous définissez un paramètre USE donné, Portage saura que vous voulez avoir le support correspondant au mot-clé choisi. Bien entendu, cela affecte aussi les dépendances des paquets.
Considérons un exemple spécifique : le mot-clé kde. Si vous n'avez pas ce mot-clé dans votre variable USE, tous les paquets qui offrent un support optionnel pour KDE seront compilés sans ce support. Tous les paquets qui possèdent des dépendances KDE optionnelles seront installés sans installer les bibliothèques KDE (en tant que dépendances). Si vous avez le mot-clé kde, alors ces paquets seront compilés avec le support KDE et les bibliothèques KDE seront installées en tant que dépendances.
Définir correctement ces mots-clés vous donnera finalement un système adapté spécifiquement à vos besoins.
Quels sont les paramètres USE disponibles ?
On distingue deux types de paramètres USE : les paramètres globaux et les paramètres locaux.
Une liste des paramètres USE peut être trouvée en ligne ou localement dans /usr/portage/profiles/use.desc.
La liste des paramètres USE locaux se trouve dans le fichier /usr/portage/profiles/use.local.desc.
2.b. Utiliser les paramètres USE
Déclarer des paramètres USE permanents
Nous allons maintenant vous expliquer comment déclarer des paramètres USE, en espérant que vous soyez convaincu de leur importance.
Comme mentionné plus haut, tous les paramètres USE sont déclarés dans la variable USE. Pour permettre aux utilisateurs de trouver et choisir facilement les paramètres USE, nous fournissons une configuration par défaut de USE. Cette configuration est un ensemble de paramètres USE dont nous pensons qu'ils sont communément employés par les utilisateurs de Gentoo. Cette configuration par défaut est déclarée dans les fichiers make.defaults de votre profil.
Le profil de votre système est défini par le fichier vers lequel pointe le lien symbolique /etc/make.profile. Différents profils s'empilent les uns sur les autres. Le profil le plus haut est base (/usr/portage/profiles/base).
Voyons les valeurs par défaut d'un profil 2004.3 :
Exemple de code 2.1 : Variable USE après cumul d'un profil 2004.3 |
(Cet exemple est le résultat du cumul des options définies dans base, default-linux,
default-linux/x86 et default-linux/x86/2004.3)
USE="x86 oss apm arts avi berkdb bitmap-fonts crypt cups encode fortran f77
foomaticdb gdbm gif gpm gtk imlib jpeg kde gnome libg++ libwww mad
mikmod motif mpeg ncurses nls oggvorbis opengl pam pdflib png python qt
quicktime readline sdl spell ssl svga tcpd truetype X xml2 xmms xv zlib"
|
Comme vous pouvez le voir, cette variable contient déjà un bon nombre de mots-clés. Ne modifiez en aucun cas les fichiers make.defaults pour adapter la variable USE à vos besoins : les changements effectués dans ce fichier seront effacés lorsque vous mettrez Portage à jour !
Pour modifier cette configuration par défaut, vous devrez ajouter ou enlever des mots-clés dans la variable USE. Cela est fait de manière globale en définissant la variable USE dans /etc/make.conf. Dans cette variable, vous ajouterez les paramètres USE que vous désirez et enlèverez ceux que vous ne voulez pas. Cette dernière action est réalisée en préfixant le mot-clé d'un signe moins ("-").
Par exemple, pour enlever le support pour KDE et QT, et ajouter le support pour ldap, vous pourriez définir USE comme suit dans /etc/make.conf :
Exemple de code 2.2 : Exemple de configuration USE dans /etc/make.conf |
USE="-kde -qt3 -qt4 ldap" |
Déclarer des paramètres USE spécifiques à des paquets
Parfois, vous voudrez déclarer certains paramètres USE pour une ou plusieurs applications particulières mais pas pour l'ensemble du système. Pour cela, vous devez créer le répertoire /etc/portage (s'il n'existe pas déjà) et éditer /etc/portage/package.use. C'est souvent qu'un simple fichier, mais il peut aussi être un répertoire ; lisez man portage pour plus d'informations. Les exemples suivants supposent que package.use est un simple fichier.
Par exemple, si vous ne voulez pas du support global berkdb mais si vous le voulez tout de même pour mysql, vous devrez y ajouter la ligne suivante :
Exemple de code 2.3 : Exemple de /etc/portage/package.use |
dev-db/mysql berkdb |
Vous pouvez également désactiver explicitement un paramètre USE pour une application particulière. Par exemple, si vous ne voulez pas du support java dans PHP :
Exemple de code 2.4 : Second exemple de /etc/portage/package.use |
dev-php/php -java |
Déclarer des paramètres USE temporaires
Il peut arriver que vous ne souhaitiez définir un paramètre USE donné qu'en une seule occasion. Plutôt qu'éditer /etc/make.conf deux fois (pour faire puis défaire les changements), vous pouvez simplement déclarer USE comme une variable d'environnement. Gardez toutefois à l'esprit que cette modification de l'environnement sera probablement perdue lorsque vous réinstallerez ou mettrez à jour cette application (soit explicitement, soit lors d'une mise à jour du système).
Par exemple, nous allons retirer temporairement le support java de notre configuration USE pendant l'installation de seamonkey.
Exemple de code 2.5 : Utilisation de USE comme une variable d'environnement |
# USE="-java" emerge seamonkey
|
Les différentes configurations de USE se conforment évidemment à un certain ordre de priorité. Vous ne souhaitez sans doute pas déclarer USE="-java" pour vous rendre compte après coup que java est déclaré malgré tout à cause d'une valeur par défaut qui a priorité sur votre définition. Les priorités dans les déclarations USE sont ordonnées comme suit (la première déclaration a la plus faible priorité) :
Pour voir la configuration finale de USE telle qu'elle est vue par Portage, exécutez emerge --info. Cela listera toutes les variables significatives (dont la variable USE) avec leur contenu tel qu'il est vu par Portage.
Exemple de code 2.6 : Exécuter emerge --info |
# emerge --info
|
Reconfigurer votre système pour tenir compte des options USE
Si vous avez modifié vos options de la variable USE et que vous voulez reconfigurer votre système pour tenir compte de ces nouvelles options, utilisez l'option --newuse :
Exemple de code 2.7 : Recompiler tout le système |
# emerge --update --deep --newuse world
|
Ensuite, utilisez l'option depclean pour supprimer les dépendances conditionnelles qui ne seraient plus utilisées.
Attention : Exécuter emerge --depclean est une opération risquée qui ne devrait pas être lancée à la légère. Vérifiez bien que la liste des paquets qui vont être supprimés ne contient pas de paquet dont vous avez encore besoin. Dans l'exemple ci-dessous, nous utilisons l'option -p pour afficher la liste sans rien supprimer. |
Exemple de code 2.8 : Supprimer les paquets inutiles |
# emerge -p --depclean
|
Quand cette opération est terminée, lancez revdep-rebuild pour recompiler les applications qui avaient été liées dynamiquement avec les paquets que vous venez de supprimer. La commande revdep-rebuild fait partie du paquet gentoolkit ; n'oubliez pas de l'installer.
2.c. Paramètres USE spécifiques à un paquet
Savoir quels paramètres USE influencent un paquet
Prenons l'exemple de seamonkey : à quels paramètres USE est-il sensible ? Pour le savoir, nous utilisons emerge avec les options --pretend et --verbose :
Exemple de code 3.1 : Afficher les paramètres USE qui influencent un paquet |
# emerge --pretend --verbose seamonkey
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[ebuild R ] www-client/seamonkey-1.0.7 USE="crypt gnome java -debug -ipv6
-ldap -mozcalendar -mozdevelop -moznocompose -moznoirc -moznomail -moznopango
-moznoroaming -postgres -xinerama -xprint" 0 kB
|
emerge n'est pas le seul outil utilisable à cette fin. En effet, nous disposons d'un outil dédié pour obtenir des informations sur les paquets. Il s'appelle equery et appartient au paquet gentoolkit. Commencez par installer gentoolkit :
Exemple de code 3.2 : Installer gentoolkit |
# emerge gentoolkit
|
Exécutez maintenant equery avec l'argument uses pour afficher les paramètres USE d'un paquet donné. Par exemple, pour le paquet gnumeric :
Exemple de code 3.3 : Utiliser equery pour afficher les paramètres USE |
# equery --nocolor uses =gnumeric-1.6.3 -a
[ Searching for packages matching =gnumeric-1.6.3... ]
[ Colour Code : set unset ]
[ Legend : Left column (U) - USE flags from make.conf ]
[ : Right column (I) - USE flags packages was installed with ]
[ Found these USE variables for app-office/gnumeric-1.6.3 ]
U I
- - debug : Enable extra debug codepaths, like asserts and extra output.
If you want to get meaningful backtraces see
http://www.gentoo.org/proj/en/qa/backtraces.xml .
+ + gnome : Adds GNOME support
+ + python : Adds support/bindings for the Python language
- - static : !!do not set this during bootstrap!! Causes binaries to be
statically linked instead of dynamically
|
3.a. Les caractéristiques de Portage
Portage offre un ensemble de fonctionnalités qui vous aident à mieux utiliser Gentoo. Certaines fonctionnalités sont basées sur des outils tiers qui permettent d'améliorer les performances, la fiabilité, la sécurité, etc.
Pour activer ou désactiver certaines fonctionnalités, vous devez modifier la variable FEATURES dans le fichier /etc/make.conf. Séparez les mots-clefs par des espaces. Souvent, vous devrez aussi installer l'outil requis pour utiliser la fonctionnalité souhaitée.
Toutes les fonctionnalités disponibles ne sont pas reprises ici. Veuillez lire la page man de make.conf pour en savoir plus.
Exemple de code 1.1 : Lire la page man de make.conf |
$ man make.conf
|
Pour connaitre les fonctionnalités qui sont actives sur votre système, utilisez la commande emerge --info et regardez le contenu de la variable « FEATURES ».
Exemple de code 1.2 : Afficher les fonctionnalités actives |
$ emerge --info | grep FEATURES
|
distcc est un programme qui permet de distribuer des compilations sur plusieurs machines, pas nécessairement identiques, d'un réseau. Le client distcc envoie toutes les données nécessaires aux serveurs distcc (qui exécutent distccd) disponibles afin qu'ils puissent compiler des parties du code source au profit du client. Le résultat est une compilation plus rapide.
Vous trouverez une description plus élaborée de distcc (et des informations sur la manière de le faire fonctionner avec Gentoo) dans notre Documentation Gentoo pour distcc.
Distcc est fourni avec une interface graphique qui permet de suivre les tâches de compilation que votre ordinateur envoie. Si vous utilisez Gnome, ajoutez « gnome » à votre variable USE. Mais si vous n'utilisez pas Gnome et souhaitez tout de même avoir une interface graphique, vous pouvez ajouter « gtk » à votre variable USE.
Exemple de code 2.1 : Installer distcc |
# emerge distcc
|
Activer le support distcc pour Portage
Ajoutez le mot-clé distcc à la variable FEATURES du fichier /etc/make.conf. Ensuite, modifiez la variable MAKEOPTS pour y ajouter -jX où X est le nombre de processeurs qui exécutent distccd (l'hôte actuel inclus) plus un. Cette valeur donne en général les meilleurs résultats, mais vous pouvez en essayer d'autres.
Ensuite, exécutez distcc-config et entrez la liste des serveurs distcc disponibles. Pour donner un exemple simple, nous supposerons que les serveurs distcc disponibles sont 192.168.1.102 (l'hôte actuel), 192.168.1.103 et 192.168.1.104 (deux hôtes « distants ») :
Exemple de code 2.2 : Configurer distcc pour qu'il utilise trois serveurs distcc |
# distcc-config --set-hosts "192.168.1.102 192.168.1.103 192.168.1.104"
|
Bien entendu, n'oubliez pas de lancer le démon distccd :
Exemple de code 2.3 : Lancer le démon distccd |
# rc-update add distccd default # /etc/init.d/distccd start |
3.c. Utiliser un cache pour la compilation
ccache est un cache rapide pour compilateur. Lorsque vous compilez un programme, il mettra les résultats intermédiaires en cache afin que, s'il vous arrive de recompiler le même programme, le temps de compilation soit largement réduit. Avec des applications communes, cela peut entrainer des compilations 5 à 10 fois plus rapides.
Si vous êtes intéressé par le fonctionnement interne de ccache, veuillez visiter le site de ccache.
Utilisez la commande emerge ccache pour installer ccache :
Exemple de code 3.1 : Installer ccache |
# emerge ccache
|
Activer le support ccache pour Portage
Ajoutez le mot-clé ccache à la variable FEATURES du fichier /etc/make.conf. Ensuite, ajoutez la variable CCACHE_SIZE qui définit la taille par défaut du cache utilisé par ccache. Une valeur de 2 Go est recommandée.
Exemple de code 3.2 : Editer CCACHE_SIZE dans /etc/make.conf |
CCACHE_SIZE="2G" |
Pour vérifier que ccache fonctionne, vous pouvez exécuter ccache -s pour afficher les statistiques de ccache. Puisque Portage utilise un répertoire différent du répertoire par défaut, vous devez définir la variable CCACHE_DIR :
Exemple de code 3.3 : Afficher les statistiques de ccache |
# CCACHE_DIR="/var/tmp/ccache" ccache -s
|
Le répertoire /var/tmp/ccache est utilisé par Portage par défaut. Vous pouvez spécifier le répertoire de votre choix en définissant la variable CCACHE_DIR dans le fichier /etc/make.conf.
Cependant, quand vous exécutez ccache, pour voir les statistiques par exemple, le répertoire par défaut est ${HOME}/.ccache, ce qui explique pourquoi vous devez définir la variable CCACHE_DIR pour voir les statistiques ccache de Portage.
Utilisation de ccache en dehors de Portage
Si vous souhaitez utiliser ccache pour les compilations en dehors de celles de Portage, vous pouvez ajouter /usr/lib/ccache/bin au début de votre variable PATH (ou tout au moins avant /usr/bin). Pour cela, éditez le fichier .bash_profile qui se trouve à la racine de votre compte utilisateur. Utiliser .bash_profile est une des manières de définir la variable PATH :
Exemple de code 3.4 : Modifier le fichier .bash_profile |
PATH="/usr/lib/ccache/bin:/opt/bin:${PATH}"
|
Nous avons déjà parlé de l'utilisation de paquets précompilés, mais comment crée-t-on son propre paquet précompilé ?
Si le paquet est déjà installé, vous pouvez utiliser la commande quickpkg. Si ce n'est pas le cas, utilisez les options --buildpkg ou --buildpkgonly avec la commande emerge. La deuxième option prépare un paquet binaire sans l'installer sur votre machine.
Si vous souhaitez que Portage construise par défaut des paquets binaires pour tous les paquets que vous installez sur votre système, vous pouvez mettre le mot-clé builpkg dans la variable FEATURES dans le fichier /etc/make.conf.
Vous trouverez plus de détails à propos de la création de paquets binaires dans la documentation de catalyst (en anglais) : Catalyst FAQ.
Installer des paquets précompilés
Bien que Gentoo ne fournisse pas de système centralisé de distribution de paquets binaires, rien ne vous empêche d'en créer un. Vous pourriez très bien stocker tous vos paquets binaires sur un serveur et utiliser celui-ci pour mettre plusieurs machines à jour. Pour utiliser un tel serveur, vous devez le définir dans la variable PORTAGE_BINHOST. Si vous avez stocké vos paquets sur un serveur ftp ftp://buildhost/gentoo, utilisez :
Exemple de code 4.1 : Définir PORTAGE_BINHOST dans /etc/make.conf |
PORTAGE_BINHOST="ftp://buildhost/gentoo" |
Quand vous voulez utliser un paquet binaire pour installer une application, spécifiez l'option --getbinpkg en plus de --usepkg avec la commande emerge. La première option indique à Portage de télécharger le paquet binaire depuis le serveur que vous avez défini plus tôt et la seconde indique d'utiliser le même paquet binaire plutôt que de compiler l'application.
Par exemple, pour installer gnumeric à partir de paquets binaires précompilés :
Exemple de code 4.2 : Installer gnumeric en utilisant un paquet précompilé |
# emerge --usepkg --getbinpkg gnumeric
|
La page man de emerge décrit l'utilisation des paquets précompilés plus en détail.
Exemple de code 4.3 : Lire la page man de emerge |
$ man emerge
|
3.e. Récupération des fichiers
Quand vous installez une série de paquets, Portage peut commencer la récupération des sources du paquet suivant dans la liste pendant qu'il en compile un autre, réduisant ainsi la durée de l'installation. Pour activer cette option, ajoutez « parallel-fetch » à la variable FEATURES.
Userfetch : récupération en tant qu'utilisateur normal
Quand Portage est lancé par le super-utilisateur, l'option FEATURES="userfetch" autorise Portage à rendre les privilèges du super-utilisateur pendant qu'il récupère les sources du paquet. Ceci est une légère amélioration en termes de sécurité.
Quand vous démarrez votre système, vous voyez beaucoup de texte défiler à l'écran. Vous remarquerez sans doute que ce texte est le même à chaque démarrage. La séquence d'actions qui se déroule devant vos yeux s'appelle la séquence de démarrage et elle est définie de façon plus ou moins statique.
D'abord, votre chargeur de démarrage charge l'image du noyau que vous avez définie dans son fichier de configuration et ensuite, il exécute ce noyau. Ce dernier s'initialise, démarre les tâches spécifiques au noyau et lance le processus init.
Ce processus monte les systèmes de fichiers définis dans /etc/fstab et exécute quelques scripts placés dans le répertoire /etc/init.d qui, à leur tour, démarrent les services nécessaires au bon fonctionnement du système.
Finalement, quand tous les scripts ont été exécutés, init active les terminaux (en général, les consoles virtuelles que vous obtenez avec les touches Alt-F1, Alt-F2, etc.) et attache un processus appelé agetty à chacun. Ce processus vous permet de vous identifier sur ces terminaux avec login.
En fait, init n'exécute pas les scripts du répertoire /etc/init.d n'importe comment. De plus, il n'exécute pas non plus tous les scripts, mais seulement ceux qui doivent l'être. Les scripts à exécuter sont définis dans /etc/runlevels.
Le processus init exécute d'abord les scripts de /etc/init.d vers lesquels un lien symbolique existe dans /etc/runlevels/boot. Les scripts sont généralement exécutés par ordre alphabétique, mais certains contiennent des dépendances qui indiquent quels scripts doivent être exécutés en premier.
Quand tous les scripts liés dans /etc/runlevels/boot ont été exécutés, init poursuit avec ceux liés dans /etc/runlevels/default. Ici aussi, les scripts sont généralement exécutés par ordre alphabétique, sauf quand ils contiennent des informations sur des dépendances qui spécifient une séquence d'exécution particulière.
Comment init fonctionne-t-il ?
Évidemment, init ne décide pas tout seul de ce qu'il doit faire. Il a besoin d'un fichier de configuration qui lui indique quelles actions il doit effectuer. Ce fichier est /etc/inittab.
Dans la séquence de démarrage que nous venons d'expliquer, nous avons dit que la première action de init était de monter les systèmes de fichiers. La ligne du fichier /etc/inittab qui provoque cela est la suivante :
Exemple de code 1.1 : La ligne d'initialisation du système dans /etc/inittab |
si::sysinit:/sbin/rc sysinit |
En fait, cette ligne indique à init qu'il doit exécuter /sbin/rc sysinit pour initialiser le système. C'est le script /sbin/rc qui fait vraiment le travail d'initialisation et pas init qui ne fait que déléguer les tâches.
Ensuite, init exécute tous les scripts vers lesquels un lien symbolique est défini dans /etc/runlevels/boot. La ligne suivante provoque cela :
Exemple de code 1.2 : L'initialisation du système, suite |
rc::bootwait:/sbin/rc boot |
Encore une fois, le script rc fait le travail. Remarquez que l'option boot passée au script rc correspond au nom du sous-répertoire qui se trouve dans /etc/runlevels.
Ensuite, init lit son fichier de configuration pour savoir quel runlevel il doit exécuter (N.D.T. : un « runlevel », ou niveau d'exécution, correspond à l'état dans lequel il faut amener la machine). La ligne suivante définit le niveau d'exécution :
Exemple de code 1.3 : La ligne initdefault |
id:3:initdefault: |
Dans ce cas (la majorité des utilisateurs de Gentoo sont dans ce cas), le niveau d'exécution est le numéro 3. Avec ce numéro, init trouve ce qu'il doit exécuter pour lancer le niveau d'exécution 3 :
Exemple de code 1.4 : Les définitions des niveaux d'exécution |
l0:0:wait:/sbin/rc shutdown l1:S1:wait:/sbin/rc single l2:2:wait:/sbin/rc nonetwork l3:3:wait:/sbin/rc default l4:4:wait:/sbin/rc default l5:5:wait:/sbin/rc default l6:6:wait:/sbin/rc reboot |
La ligne qui définit le niveau 3 utilise à nouveau le script rc pour démarrer les services, cette fois avec le paramètre default. Remarquez que, encore une fois, le paramètre correspond au nom du sous-répertoire dans /etc/runlevels.
Quand le script rc a terminé, init trouve la liste des consoles virtuelles à activer et quelles commandes il doit utiliser dans son fichier de configuration :
Exemple de code 1.5 : La définition des consoles virtuelles |
c1:12345:respawn:/sbin/agetty 38400 tty1 linux c2:12345:respawn:/sbin/agetty 38400 tty2 linux c3:12345:respawn:/sbin/agetty 38400 tty3 linux c4:12345:respawn:/sbin/agetty 38400 tty4 linux c5:12345:respawn:/sbin/agetty 38400 tty5 linux c6:12345:respawn:/sbin/agetty 38400 tty6 linux |
Qu'est-ce qu'un niveau d'exécution ?
Vous avez constaté que init numérote les niveaux d'exécution qu'il doit activer. Un niveau d'exécution définit un état dans lequel votre système se trouve et contient les scripts nécessaires pour entrer dans ou quitter cet état.
Dans Gentoo, sept niveaux d'exécution sont définis :trois internes et quatre définis par l'utilisateur. Les niveaux d'exécution internes sont sysinit, shutdown et reboot et sont utilisés respectivement pour initialiser, éteindre et redémarrer le système.
Les niveaux d'exécution définis par l'utilisateur sont ceux qui correspondent à un sous-répertoire dans /etc/runlevels : boot, default, nonetwork et single. Le niveau d'exécution boot est utilisé pour démarrer tous les services système utilisés par les autres niveaux d'exécution. Les autres niveaux d'exécution se différencient par les services qu'ils activent : default est utilisé en temps normal, nonetwork est utilisé quand aucune connexion réseau n'est souhaitée et single est utilisé pour résoudre d'éventuels problèmes du système.
Utiliser les scripts d'initialisation
Les scripts que rc exécute sont appelés des scripts d'initialisation. Chaque script peut être exécuté avec les options start, stop, restart, pause, zap, status, ineed, iuse, needsme, usesme ou broken.
Pour démarrer, arrêter ou relancer un service (et les autres services nécessaires éventuels), utilisez start, stop et restart.
Exemple de code 1.6 : Démarrer postfix |
# /etc/init.d/postfix start
|
Note : Seuls les services qui ont besoin du service spécifié sont arrêtés ou redémarrés. Les services qui l'utilisent ne sont pas affectés. |
Pour stopper un service sans toucher aux services qui l'utilisent, utilisez l'option pause :
Exemple de code 1.7 : Stopper postfix sans toucher aux services qui l'utilisent |
# /etc/init.d/postfix pause
|
Pour afficher le statut d'un service (démarré, arrêté, en pause), utilisez l'option status :
Exemple de code 1.8 : Afficher le statut du service postfix |
# /etc/init.d/postfix status
|
Si le système affirme qu'un service est actif, mais que vous savez qu'il ne l'est pas, utilisez l'option zap pour réinitialiser son statut à « arrêté ».
Exemple de code 1.9 : Réinitialiser le statut de postfix |
# /etc/init.d/postfix zap
|
Vous pouvez aussi afficher les services dont un service a besoin avec les options iuse ou ineed. Avec l'option ineed, les services réellement nécessaires sont affichés. Avec iuse, ce sont les services qui peuvent être utilisés sans être indispensables qui sont affichés.
Exemple de code 1.10 : Afficher la liste des services dont Postfix a besoin |
# /etc/init.d/postfix ineed
|
De la même façon, vous pouvez afficher la liste des services qui ont besoin (needsme) ou qui utilisent (usesme) un service particulier :
Exemple de code 1.11 : Afficher la liste des services qui ont besoin de Postfix |
# /etc/init.d/postfix needsme
|
Enfin, vous pouvez aussi demander la liste des services requis qui manquent :
Exemple de code 1.12 : Afficher la liste des services manquants dont Postfix a besoin |
# /etc/init.d/postfix broken
|
Gentoo construit un arbre de dépendances pour déterminer l'ordre d'exécution des services. Cela est loin d'être trivial et nous avons donc créé des outils qui facilitent l'administration des niveaux d'exécution et des scripts d'initialisation.
La commande rc-update permet d'ajouter ou d'enlever un script d'un niveau d'exécution. Cette commande utilise automatiquement le script depscan.sh qui reconstruit l'arbre des dépendances.
Ajouter et enlever des services
Vous avez déjà ajouté des scripts d'initialisation au niveau d'exécution « default » pendant l'installation de Gentoo. Vous ignoriez alors la signification de « default », mais maintenant, vous la connaissez. Le script rc-update a besoin d'un second argument qui spécifie l'action à effectuer : add, del ou show pour respectivement ajouter, supprimer ou afficher.
Pour ajouter ou supprimer un service, ajoutez simplement add ou del à la commande rc-update et spécifiez ensuite le nom du script d'initialisation et le niveau d'exécution. Par exemple :
Exemple de code 2.1 : Supprimer Postfix du niveau d'exécution « default » |
# rc-update del postfix default
|
La commande rc-update -v show affiche la liste des scripts d'initialisation disponibles et les niveaux d'exécution dans lesquels ils ont été ajoutés :
Exemple de code 2.2 : Afficher la liste des scripts d'initialisation |
# rc-update -v show
|
Vous pouvez aussi lancer rc-update show (sans l'option -v) pour simplement voir les scripts d'initialisation activés et leurs niveaux d'exécution.
Les scripts d'initialisation peuvent être complexes. Il vaut donc mieux éviter que les utilisateurs ne doivent les modifier. Cela évite bien des problèmes. Cependant, les services ont parfois besoin d'être configurés ou de recevoir certaines options.
Une autre raison pour séparer les scripts de leur configuration est que cela vous permet de mettre à jour les scripts sans que leur configuration ne soit perdue.
Gentoo offre un système facile pour configurer les services. Chaque script d'initialisation qui peut être configuré a un fichier de configuration dans le répertoire /etc/conf.d. Par exemple, le script d'initialisation d'apache2 (/etc/init.d/apache2) a un fichier de configuration /etc/conf.d/apache2 qui contient les options à passer au serveur Apache 2 quand ce dernier est lancé.
Exemple de code 3.1 : Variables définies dans /etc/conf.d/apache2 |
APACHE2_OPTS="-D PHP5" |
Un tel fichier de configuration ne contient que des définitions de variables (tout comme /etc/make.conf), ce qui permet de configurer facilement un service. Cela permet aussi de fournir des explications sur ces options sous forme de commentaires.
4.d. Écrire un script d'initialisation
Non. Rédiger un script d'initialisation n'est généralement pas nécessaire puisque Gentoo fournit des scripts complets pour tous les services supportés. Cependant, si vous avez installé un service sans l'aide de Portage, vous devrez sans doute écrire un tel script.
N'utilisez pas le script fourni avec le logiciel à moins qu'il ne soit écrit spécifiquement pour Gentoo, car les scripts d'initialisation de Gentoo ne sont pas compatibles avec ceux des autres distributions.
La structure de base d'un script d'initialisation est décrite ci-dessous.
Exemple de code 4.1 : Structure de base d'un script d'initialisation |
#!/sbin/runscript
depend() {
(Information sur les dépendances)
}
start() {
(Commandes à exécuter pour démarrer le service)
}
stop() {
(Commandes à exécuter pour arrêter le service)
}
restart() {
(Commandes à exécuter pour redémarrer le service)
}
|
La partie start() est indispensable, les autres sont facultatives.
Il existe deux types de dépendances : use et need. Comme mentionné précédemment, la dépendance need est plus stricte que use. Vous devez faire suivre le type de dépendance par le nom du service dont votre service dépend, ou par une dépendance virtuelle.
Une dépendance virtuelle est une dépendance qui peut être satisfaite par plusieurs services différents. Par exemple, votre service pourrait dépendre du système de journalisation qui peut être fourni par plusieurs services différents (metalogd, syslog-ng, sysklogd...) Étant donné que votre service ne peut pas dépendre de tous ces services (on ne peut installer qu'un seul système de journalisation), nous avons défini une seule dépendance virtuelle que chacun de ces services satisfait.
Jetons un œil aux dépendances du service postfix.
Exemple de code 4.2 : Dépendances de Postfix |
depend() {
need net
use logger dns
provide mta
}
|
Comme vous pouvez le voir, postfix :
Ordonner la séquence d'exécution
Dans certains cas, vous voudrez peut-être démarrer un service avant ou après un autre, pour autant que cet autre service soit disponible. Notez qu'il ne s'agit plus d'une dépendance, mais simplement d'une demande de lancement de services dans un ordre défini au sein d'un même niveau d'exécution. Pour définir une séquence d'exécution, utilisez les mots-clefs before ou after.
Voyez, par exemple, le service portmap :
Exemple de code 4.3 : La fonction depend() du service Portmap |
depend() {
need net
before inetd
before xinetd
}
|
Vous pouvez aussi remplacer le nom de service par une étoile ("*") pour spécifier tous les services d'un niveau d'exécution, mais cela n'est pas recommandé.
Exemple de code 4.4 : Lancer un script avant tous les autres dans un niveau d'exécution |
depend() {
before *
}
|
Si votre service doit écrire sur des disques locaux, il aura besoin du localmount. S'il place quelque chose dans /var/run, tel un fichier .pid, alors il devra démarrer après bootmisc :
Exemple de code 4.5 : Exemple de fonction depend() |
depend() {
need localmount
after bootmisc
}
|
En plus de la fonction depend(), vous devez définir la fonction start() qui doit contenir les commandes nécessaires pour activer le service. Il est conseillé d'utiliser les fonctions ebegin et eend pour afficher des messages à l'écran et ainsi informer l'utilisateur que le service démarre.
Exemple de code 4.6 : Exemple de fonction start() |
start() {
ebegin "Starting my_service"
start-stop-daemon --start --exec /chemin/vers/mon_service \
--pidfile /chemin/vers//mon_fichier_pid
eend $?
}
|
Les options --exec et --pidfile devraient être utilisées dans les fonctions start et stop. Si le service ne crée pas de fichier .pid, alors utilisez --make-pidfile, si possible, bien que vous devriez le tester pour en être sûr. Dans le cas contraire, n'utilisez pas de fichier .pid. Vous pouvez aussi ajouter --quiet aux options start-stop-daemon, bien que cela soit déconseillé à moins que le service soit extrêmement verbeux. En effet, utiliser --quiet peut cacher des informations de débogage utiles si le démarrage du service échoue.
Note : Assurez-vous que --exec appelle effectivement un service et pas simplement un script shell qui lance des services (c'est ce que le script init est censé faire). |
Vous trouverez plus d'exemples de fonctions start() dans les sources des scripts d'initialisation, localisés dans le répertoire /etc/init.d.
Vous pouvez aussi définir les fonctions facultatives stop() et restart() pour respectivement arrêter et relancer un service, mais Gentoo est capable de s'en passer si vous avez utilisé la commande start-stop-daemon.
Bien que vous ne devriez pas créer de fonction stop(), en voici quand même un exemple :
Exemple de code 4.7 : Exemple de fonction stop() |
stop() {
ebegin "Arrêt de mon_service"
start-stop-daemon --stop --exec /chemin/vers/mon_service \
--pidfile /chemin/vers/mon_fichier_pid
eend $?
}
|
Si votre service exécute un script (Bash, Python ou Perl par exemple) dont le nom change par la suite (par exemple, toto.py devient toto), il faut alors ajouter l'option --name à la commande start-stop-daemon. Vous devez y spécifier le nom du script après changement. Dans cet exemple, un service démarre toto.py dont le nom devient toto :
Exemple de code 4.8 : Un service qui lance le script toto |
start() {
ebegin "Démarrage de mon_script"
start-stop-daemon --start --exec /chemin/vers/mon_script \
--pidfile /chemin/vers/mon_fichier_pid --name toto
eend $?
}
|
Pour de plus amples informations, un excellent manuel est disponible pour la commande start-stop-daemon :
Exemple de code 4.9 : Consulter le manuel de start-stop-daemon |
$ man start-stop-daemon
|
Les scripts d'initialisation utilisent bash. Vous pouvez utiliser toutes les fonctionnalités de bash dans vos scripts.
Si vous voulez utiliser une option non prévue par nos scripts, vous devez l'ajouter à la variable opts et créer une fonction qui a le même nom. Par exemple, pour ajouter une option restartdelay :
Exemple de code 4.10 : Ajouter une option restartdelay |
opts="${opts} restartdelay"
restartdelay() {
stop
sleep 3 # Temporisation de 3 secondes
start
}
|
Variables de configuration d'un service
Vous ne devez rien faire de particulier pour utiliser un fichier de configuration dans /etc/conf.d : avant que votre script d'initalisation ne soit exécuté, les variables des fichiers suivants sont initialisées dans cet ordre :
De plus, si votre script fournit un service virtuel (comme net), le fichier de configuration correspondant (comme /etc/conf.d/net) sera également lu.
4.e. Modifier le comportement des niveaux d'exécution
Les utilisateurs d'ordinateurs portables connaissent bien le problème : vous devez démarrer net.eth0 à la maison, mais pas lorsque vous êtes en vadrouille puis que vous n'êtes alors plus connecté à votre réseau. Vous pouvez adapter le comportement de Gentoo.
Par exemple, vous pouvez créer un second niveau d'exécution similaire au niveau « default », mais sans les options réseau. Vous pourrez ensuite sélectionner le niveau d'exécution au démarrage de votre machine.
Créez votre second niveau d'exécution similaire à « default ». Dans notre exemple, nous créons un niveau « offline ».
Exemple de code 5.1 : Créer le répertoire du nouveau niveau d'exécution |
# mkdir /etc/runlevels/offline
|
Ajoutez les scripts d'initialisation à votre nouveau niveau d'exécution. Par exemple, pour copier le niveau « default » sauf le script net.eth0 :
Exemple de code 5.2 : Recopier les scripts d'initialisation |
(Copier tous les services du niveau d'exécution default vers offline.) # cd /etc/runlevels/default # for service in *; do rc-update add $service offline; done (Supprimer les services superflus du niveau d'exécution offline.) # rc-update del net.eth0 offline (Afficher les services du niveau d'exécution offline.) # rc-update show offline (Affichage partiel :) acpid | offline domainname | offline local | offline net.eth0 | |
Même si net.eth0 a été retiré du niveau d'exécution offline, udev va quand même essayer de démarrer les interfaces qu'il détecte et lancer les services associés. C'est pourquoi vous devez ajouter les services réseaux que vous ne souhaitez pas voir démarrés au fichier /etc/conf.d/rc (cela est vrai pour tout autre service pouvant être lancé par udev) :
Exemple de code 5.3 : Désactiver un service démarré par une interface dans /etc/conf.d/rc |
RC_COLDPLUG="yes"
(Ensuite, spécifiez les services que vous ne souhaitez pas voir
démarrés automatiquement)
RC_PLUG_SERVICES="!net.eth0"
|
Note : Vous trouverez plus d'informations sur les services démarrés par les interfaces en consultant les commentaires du fichier /etc/conf.d/rc. |
Ensuite, modifiez la configuration de votre chargeur de démarrage pour y ajouter une nouvelle option pour le niveau offline. Par exemple, pour grub, modifiez /boot/grub/grub.conf :
Exemple de code 5.4 : Ajouter une entrée dans le menu de démarrage |
title Gentoo Linux Offline
root (hd0,0)
kernel (hd0,0)/kernel-2.4.25 root=/dev/hda3 softlevel=offline
|
Voilà, c'est terminé. Si vous redémarrez votre machine et que vous choisissez la nouvelle entrée, le niveau d'exécution offline sera utilisé au lieu du niveau default.
Vous pouvez aussi remplacer le niveau d'exécution « boot » avec l'option bootlevel exactement de la même façon qu'avec softlevel.
5.a. Variables d'environnement ?
Une variable d'environnement est un objet nommé qui contient des informations utilisées par une ou plusieurs applications. Beaucoup d'utilisateurs (particulièrement les nouveaux Linuxiens) trouvent que c'est un peu trop compliqué et ingérable. C'est bien sûr faux : en utilisant des variables d'environnement, on peut changer facilement la valeur d'une configuration pour une ou plusieurs applications.
Le tableau suivant liste un certain nombre de variables utilisées par le système Linux et décrit leur utilisation. Des exemples de valeurs seront présentés après le tableau.
| Variable | Description |
| PATH | Cette variable contient une liste de répertoires séparés par des deux-points dans lesquels le système cherche des fichiers exécutables. Si vous entrez le nom d'un exécutable (tel que ls, rc-update ou emerge), mais que cet exécutable n'est pas situé dans un des répertoires listés, votre système ne l'exécutera pas (tant que vous n'aurez pas spécifié le chemin complet avec ligne de commande, tel que /bin/ls). |
| ROOTPATH | Cette variable a la même fonction que PATH, mais celle-ci liste les répertoires qui doivent être parcourus lorsque l'utilisateur root entre une commande. |
| LDPATH | Cette variable contient une liste de répertoires séparés par des deux-points dans lesquels l'éditeur de liens dynamique cherche les bibliothèques. |
| MANPATH | Cette variable contient une liste de répertoires séparés par des deux-points dans lesquels la commande man cherche les pages man. |
| INFODIR | Cette variable contient une liste de répertoires séparés par des deux-points dans lesquels la commande info cherche les pages info. |
| PAGER | Cette variable contient le chemin vers le programme utilisé pour lister le contenu des fichiers (tel que less ou more). |
| EDITOR | Cette variable contient le chemin vers le programme utilisé pour éditer le contenu des fichiers (tel que nano ou vi). |
| KDEDIRS | Cette variable contient une liste de répertoires séparés par des deux-points qui contiennent les éléments spécifiques à KDE. |
| CONFIG_PROTECT | Cette variable contient une liste de répertoires séparés par des espaces qui doivent être préservés par Portage pendant les mises à jour. |
| CONFIG_PROTECT_MASK | Cette variable contient une liste de répertoires séparés par des espaces qui ne doivent pas être préservés par Portage pendant les mises à jour. |
Voici un exemple de définition de toutes ces variables :
Exemple de code 1.1 : Exemple de définitions |
PATH="/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/games/bin"
ROOTPATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
LDPATH="/lib:/usr/lib:/usr/local/lib:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3"
MANPATH="/usr/share/man:/usr/local/share/man"
INFODIR="/usr/share/info:/usr/local/share/info"
PAGER="/usr/bin/less"
EDITOR="/usr/bin/vim"
KDEDIRS="/usr"
CONFIG_PROTECT="/usr/X11R6/lib/X11/xkb /opt/tomcat/conf \
/usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ \
/usr/share/texmf/tex/platex/config/ /usr/share/config"
CONFIG_PROTECT_MASK="/etc/gconf"
|
5.b. Définir des variables globalement
Pour centraliser les définitons de ces variables, la distribution Gentoo utilise le répertoire /etc/env.d. Dans ce répertoire, vous trouverez un certain nombre de fichiers tels que 00basic, 05gcc, etc. qui contiennent les variables requises par les applications mentionnées dans leurs noms.
Par exemple, quand vous installez gcc, un fichier nommé 05gcc est créé par l'ebuild et contient les définitions des variables suivantes :
Exemple de code 2.1 : /etc/env.d/05gcc |
PATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2" ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2" MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/man" INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/info" CC="gcc" CXX="g++" LDPATH="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3" |
Les autres distributions vous disent de changer ou d'ajouter ces variables d'environnement dans /etc/profile ou ailleurs. Par contre, Gentoo vous facilite la maintenance et l'administration de ces variables d'environnement, ce qui vous évite de vous soucier des nombreux fichiers qui peuvent contenir ces variables d'environnement. (Cela profite également au système Portage.)
Par exemple, lorsque gcc est mis à jour, le fichier /etc/env.d/05gcc est aussi mis à jour sans que l'utilisateur ne fasse quoi que se soit.
Cela n'est pas uniquement profitable à Portage, mais aussi à vous, en tant qu'utilisateur. Occasionnellement, vous serez amené à définir des variables d'environnement pour tout le système. Par exemple, avec la variable http_proxy. Au lieu de vous embêter avec /etc/profile, vous devez juste créer un fichier (/etc/env.d/99local) et y entrer vos définitions :
Exemple de code 2.2 : /etc/env.d/99local |
http_proxy="proxy.server.com:8080" |
En utilisant le même fichier pour toutes vos variables, vous avez une vue d'ensemble aisée de toutes les variables que vous avez définies.
Plusieurs fichiers dans /etc/env.d définissent la variable PATH. Ce n'est pas une erreur : quand vous lancez env-update, celui-ci concatènera les définitions avant de mettre à jour les variables d'environnement. Ainsi, il aide les paquets (et les utilisateurs) à ajouter leurs propres variables d'environnement sans interférer avec les valeurs déjà définies.
Le script env-update liste les valeurs des fichiers de /etc/env.d par ordre alphabétique. Les noms des fichiers dans /etc/env.d doivent commencer par deux chiffres décimaux.
Exemple de code 2.3 : Ordre de mise à jour par env-update |
00basic 99kde-env 99local
+-------------+----------------+-------------+
PATH="/bin:/usr/bin:/usr/kde/3.2/bin:/usr/local/bin"
|
Cette concaténation de définitions pour la même variable n'est réalisée que pour KDEDIRS, PATH, LDPATH, MANPATH, INFODIR, INFOPATH, ROOTPATH, CONFIG_PROTECT, CONFIG_PROTECT_MASK, PRELINK_PATH et PRELINK_PATH_MASK. Les autres variables reçoivent uniquement la dernière valeur définie.
Quand vous lancez env-update, le script crée toutes les variables d'environnement et les place dans /etc/profile.env (qui est utilisé par /etc/profile). Il extrait aussi les informations de la variable LDPATH et les utilise pour créer /etc/ld.so.conf. Après cela, il lance ldconfig pour créer le fichier /etc/ld.so.cache utilisé par l'éditeur de liens dynamique.
Si vous voulez connaitre le résultat de env-update immédiatement après son exécution, lancez la commande suivante pour mettre votre système à jour. Les utilisateurs qui ont installé Gentoo eux-même se souviendront surement que cela se trouvait dans les instructions d'installation :
Exemple de code 2.4 : Mettre l'environnement à jour |
# env-update && source /etc/profile
|
Note : La commande ci-dessus ne met à jour que les variables de votre terminal courant, des nouvelles consoles et leurs enfants. Donc, si vous êtes sous X11, vous devrez soit taper source /etc/profile dans chaque nouveau terminal ouvert, soit relancer X afin que la source des nouveaux terminaux possède les bonnes variables. Si vous utiliser un gestionnaire de session (xdm, kdm, gdm...), passez root et tapez /etc/init.d/xdm restart. Sinon, vous devrez vous déloguer et revenir dans X pour avoir les nouvelles variables. |
Important : Vous ne pouvez pas utiliser de variables d'environnement lors d'une définition de variable. C'est-à-dire que, par exemple, FOO="$BAR" (où $BAR est une autre variable) est interdit. |
5.c. Définir des variables localement
Vous n'avez pas toujours besoin de définir des variables d'environnement globalement. Par exemple, vous pourriez avoir besoin d'ajouter /home/my_user/bin et le répertoire courant (celui dans lequel l'utilisateur se trouve quand il lance une commande) à la variable PATH, mais vous ne voulez pas que les autres utilisateurs de votre système l'aient aussi dans PATH. Si vous voulez définir une variable d'environnement localement, vous devriez utiliser ~/.bashrc ou ~/.bash_profile :
Exemple de code 3.1 : Étendre PATH pour un usage local avec ~/.bashrc |
(Les deux-points à la fin sans répertoire à leur suite
ajoutent le répertoire courant automatiquement.)
PATH="${PATH}:/home/my_user/bin:"
|
Quand vous vous réidentifierez, votre variable PATH sera mise à jour.
Quelquefois, une définition plus spécifique est requise. Vous voudriez être capable d'utiliser des binaires d'un répertoire temporaire que vous avez créé sans utiliser le chemin complet ou éditer ~/.bashrc qui vous prendrait trop de temps.
Dans ce cas-ci, vous pouvez juste définir la variable PATH dans votre session courante en utilisant la commande export. Tant que vous ne vous serez pas déconnecté, la variable PATH utilisera la valeur temporaire.
Exemple de code 3.2 : Définir une variable d'environnement spécifique à une session |
# export PATH="${PATH}:/home/my_user/tmp/usr/bin"
|
1.a. Les fichiers utilisés par Portage
La configuration par défaut de Portage se trouve dans le fichier /etc/make.globals. Vous remarquerez que toute la configuration de Portage se fait grâce à des variables. Les variables et leur utilisation sont décrites ci-dessous.
Puisque certaines directives de configuration diffèrent d'une architecture à l'autre, Portage utilise aussi plusieurs fichiers de configuration qui font partie de votre profil. Le profil sélectionné est celui vers qui le lien /etc/make.profile/make.defaults pointe. La configuration de Portage réside dans les différents fichiers make.defaults situés dans l'arborescence qui mène au répertoire de votre profil. Nous aborderons les profils et le répertoire /etc/make.profile plus loin dans ce document.
Pour modifier une variable de configuration, ne modifiez ni le fichier /etc/make.globals, ni les fichiers make.defaults. Modifiez plutôt /etc/make.conf qui a priorité sur les autres fichiers. Vous trouverez aussi un fichier /usr/share/portage/config/make.conf.example, un fichier d'exemple que vous pouvez utiliser pour configurer votre propre /etc/make.conf.
Vous pouvez aussi définir ces variables dans votre environnement, mais nous ne recommandons pas cette pratique.
Informations spécifiques au profil
Nous avons déjà mentionné le répertoire /etc/make.profile. Ce n'est pas vraiment un répertoire, mais un lien symbolique vers un profil qui se trouve, par défaut, dans /usr/portage/profiles ; vous pouvez créer des profils ailleurs. Ce lien symbolique définit le profil utilisé par votre système.
Un profil contient des informations spécifiques pour chaque architecture telles que la liste des paquets qui forment un système de base, une liste de paquets qui ne fonctionnent pas ou qui sont masqués pour ce profil, etc.
Configuration par l'utilisateur
Pour influencer le comportement de Portage, vous devrez modifier des fichiers dans le répertoire /etc/portage. Il est vivement recommandé d'utiliser ces fichiers et de ne pas utiliser de variables d'environnement.
Vous pouvez créer les fichiers suivants dans le répertoire /etc/portage :
Ce ne sont pas forcément des fichiers. Vous pouvez choisir de créer des répertoires qui contiendraient un fichier par paquet. La page man contient plus d'information à propos de ce que l'on peut faire avec le répertoire /etc/portage et une liste exhaustive des fichiers qui influencent le comportement de Portage.
Exemple de code 1.1 : Lire la page man de Portage |
$ man portage
|
Déplacer les fichiers et les répertoires de Portage
Les fichiers de configuration mentionnés ci-dessus ne peuvent pas se trouver ailleurs. Portage les recherche toujours au même endroit. Cependant, Portage peut être configuré pour utiliser d'autres répertoires pour certains fichiers : le répertoire temporaire d'installation, les sources, l'arbre Portage, etc.
Par défaut, tous ces fichiers sont stockés dans des répertoires bien connus, mais ils peuvent être stockés ailleurs en fonction de variables définies dans le fichier /etc/make.conf. Ce qui suit est consacré aux différents répertoires utilisés par Portage et à la methode à utiliser pour les déplacer.
Ce document n'est pas une liste exhaustive de tous les répertoires disponibles. Cette liste est disponible dans les pages man de Portage et de make.conf :
Exemple de code 1.2 : Lire les pages man de Portage et de make.conf |
$ man portage $ man make.conf |
1.b. Emplacemements des fichiers
Le répertoire par défaut pour l'arbre Portage est /usr/portage. La variable PORTDIR peut être utilisée pour définir un autre emplacement. N'oubliez pas de rediriger le lien symbolique /etc/make.profile vers le répertoire ad hoc.
Si vous redéfinissez la variable PORTDIR, vous devriez sans doute redéfinir les variables PKGDIR, DISTDIR et RPMDIR, car elles ne prendront pas la valeur de PORTDIR en compte.
Portage peut également utiliser des paquets précompilés lors des installations, bien que cette fonctionnalité soit désactivée par défaut. Les paquets précompilés sont placés dans le répertoire défini par la variable PKGDIR, qui vaut /usr/portage/packages par défaut.
Le code source des applications est conservé dans /usr/portage/distfiles. Cet emplacement est défini par la variable DISTDIR.
Le cache de Portage (contient les dates de modification, les paquets virtuels, les informations de dépendance...) est stocké dans /var/cache/edb. Ce n'est vraiment qu'un cache : vous pouvez l'effacer à un moment donné si vous n'utilisez pas Portage à ce moment-là.
Portage stocke l'état de votre système (quels paquets sont installés, quels fichiers appartiennent à quel paquet...) dans /var/db/pkg. Ne modifiez pas ces fichiers à la main ! Cela pourrait complètement déboussoler Portage vis-à-vis de votre système.
Portage sauve ses fichiers temporaires dans /var/tmp par défaut. La variable PORTAGE_TMPDIR définit cet emplacement.
Si vous redéfinissez la variable PORTAGE_TMPDIR, vous devriez aussi redéfinir BUILD_PREFIX, car elle ne tient pas compte du changement automatiquement.
Portage crée un répertoire de compilation pour chaque paquet dans le répertoire /var/tmp/portage. Cet emplacement est défini par la variable BUILD_PREFIX.
Localisation du système de fichiers principal
Par défaut, Portage installe tous les fichiers sur le système de fichiers courant (/), mais il peut copier les fichiers ailleurs si vous redéfinissez la variable ROOT. Cela peut être utile si vous voulez construire des nouvelles images d'installation pour d'autres systèmes.
1.d. Fonctions de journalisation des événements
Portage peut journaliser les messages des événements relatifs aux ebuilds en utilisant un fichier pour chaque ebuild, mais uniquement si la variable PORT_LOGDIR correspond à un répertoire dans lequel Portage peut écrire (l'utilisateur portage doit disposer des permissions nécessaires). Par défaut, cette variable n'est pas définie. Si PORT_LOGDIR n'est pas définie, vous ne recevrez pas les messages des événements relatifs à la construction des paquets avec le système de journal actuel, mais vous devriez en recevoir quelques-uns avec le nouveau système appelé elog. Si PORT_LOGDIR est définie et que vous utilisez elog, vous recevrez à la fois les messages de construction et tous ceux qui sont sauvegardés par elog, comme expliqué plus loin.
Portage propose un contrôle fin de la tenue du journal des événements via elog :
Important : Si vous utilisiez enotice avec Portage-2.0.*, vous devez le désinstaller complétement car enotice est incompatible avec elog. |
Portage peut être configuré grâce à de nombreuses variables que vous définissez dans le fichier /etc/make.conf. Vous trouverez une description complète de ces variables dans la page man de make.conf. Pour la consulter, faites :
Exemple de code 1.1 : Lire la page man de make.conf |
$ man make.conf
|
2.b. Options relatives à la compilation
Les options de configuration et de compilation
Quand Portage compile une application, il passe les variables suivantes au script de configuration et au compilateur :
La variable USE est aussi utilisée par les processus de configuration et de compilation et a déjà été documentée dans des chapitres précédents.
Quand Portage a fini d'intégrer une nouvelle version d'un paquet au système, il supprime les fichiers des versions précédentes. Portage attend cinq secondes avant de supprimer ces fichiers. Ce délai est paramétrable grâce à la variable CLEAN_DELAY.
Vous pouvez aussi configurer emerge pour qu'il se lance systématiquement accompagné de certaines options en configurant la variable EMERGE_DEFAULT_OPTS. Cela peut-être utile pour des options comme --ask, --verbose et --tree par exemple.
2.c. Protection des fichiers de configuration
Portage remplace les fichiers des anciennes versions des logiciels par ceux des nouvelles versions qu'il installe sauf si ceux-ci se trouvent dans un répertoire protégé. La liste de ces répertoires est définie par la variable CONFIG_PROTECT. Les répertoires sont séparés par des espaces. Ceux-ci sont généralement des répertoires qui accueillent des fichiers de configuration.
Un fichier qui devrait être installé dans un répertoire protégé est renommé et l'utilisateur est averti de la présence d'un nouveau fichier de configuration.
Vous pouvez afficher la liste des répertoires protégés avec la commande emerge --info :
Exemple de code 3.1 : Afficher la variable CONFIG_PROTECT |
$ emerge --info | grep 'CONFIG_PROTECT='
|
La section CONFIGURATION FILES de la page man d'emerge contient plus d'informations à propos de la proctection des fichiers de configuration par Portage :
Exemple de code 3.2 : Afficher l'aide de Portage sur la protection des fichiers |
$ man emerge
|
Vous pouvez exclure certains répertoires de cette protection en les définissant dans la variable CONFIG_PROTECT_MASK.
2.d. Options de téléchargement
Quand Portage a besoin de fichiers qui ne sont pas sur votre machine, il essaie de les télécharger. Les serveurs qu'il contacte sont définis dans les variables suivantes :
Une troisième variable contient le nom du serveur que Portage contacte quand il doit synchroniser son arbre :
Les variables GENTOO_MIRRORS et SYNC peuvent être définies automatiquement par le programme mirrorselect. Vous devez l'installer avec la commande emerge mirrorselect si vous comptez l'utiliser. Vous pouvez consulter l'aide de mirrorselect avec la commande suivante :
Exemple de code 4.1 : Plus d'information sur mirrorselect |
# mirrorselect --help
|
Si vous devez utiliser un serveur mandataire (« proxy server »), vous devez définir son nom dans les variables http_proxy, ftp_proxy et RSYNC_PROXY.
Quand Portage doit télécharger les sources d'un paquet, il utilise wget par défaut. Vous pouvez lui faire utiliser une autre commande grâce à la variable FETCHCOMMAND.
Portage est capable de reprendre un téléchargement interrompu. Il utilise aussi la commande wget par défaut, mais vous pouvez changer cela grâce à la variable RESUMECOMMAND.
Veuillez vérifier que les commandes que vous définissez dans les variables FETCHCOMMAND et RESUMECOMMAND sauvent les fichiers téléchargés à la bonne place. Utilisez les valeurs \${URI} et \${DISTDIR} pour indiquer respectivement l'origine des sources et le répertoire dans lequel les enregistrer.
Vous pouvez même définir des commandes spécifiques par protocole grâce aux variables FETCHCOMMAND_HTTP, FETCHCOMMAND_FTP, RESUMECOMMAND_HTTP, RESUMECOMMAND_FTP.
Vous ne pouvez pas utiliser une autre commande que rsync pour mettre l'arbre Portage à jour, mais vous pouvez configurer cette commande avec les variables suivantes :
Pour plus d'informations sur toutes les options disponibles, référez-vous à la page du manuel rsync.
Vous pouvez définir la branche à utiliser avec la variable ACCEPT_KEYWORDS. La valeur par défaut est la branche stable pour votre architecture. Vous trouverez plus de détails à ce sujet dans le chapitre suivant.
Vous pouvez activer certaines fonctionnalités de Portage grâce à la variable FEATURES. Celles-ci ont déjà été abordées dans des chapitres précédents tels que Portage et ses fonctionnalités.
La variable PORTAGE_NICENESS permet de réduire ou d'augmenter la valeur « nice » avec laquelle Portage s'exécute. La valeur de PORTAGE_NICENESS est ajoutée à la valeur « nice » en cours. Cette valeur permet de rendre le processus de compilation plus ou moins prioritaire. Une valeur élevée rend Portage moins prioritaire par rapport aux autres processus et laisse le système plus disponible.
Pour plus d'information à propos de nice, veuillez consulter sa page man :
Exemple de code 6.1 : La page man de nice |
$ man nice
|
La variable NOCOLOR, dont la valeur par défaut est « false », indique à Portage de ne pas utiliser de couleurs dans son affichage.
La variable ACCEPT_KEYWORDS définit quelle branche vous voulez utiliser. La valeur par défaut est la branche stable pour votre architecture, par exemple x86.
Il est recommandé de n'utiliser que la branche stable. Cependant, si la stabilité des logiciels n'est pas votre première préoccupation ou si vous souhaitez aider Gentoo et envoyer des rapports de bogues sur http://bugs.gentoo.org, alors lisez ce qui suit.
Si vous désirez utiliser les versions les plus récentes des logiciels, vous pouvez envisager de passer à la branche de test. Pour cela, ajoutez un ~ (tilde) devant le nom de votre architecture.
La branche de test désigne exactement ce que son nom indique - Test. Si un paquet appartient à cette branche, cela signifie que les développeurs pensent qu'il est fonctionnel mais qu'il n'a pas été suffisamment testé. Vous pouvez très bien être le premier à découvrir un bogue sur le paquet, auquel cas vous devriez remplir un rapport de bogue pour que les développeurs soient au courant du problème.
Si vous décidez d'utiliser cette branche de test, attendez-vous à rencontrer des problèmes de stabilité, des paquets imparfaits, notamment en ce qui concerne les dépendances, des mises à jour fréquentes et donc beaucoup de compilations, voire des paquets qui cessent de fonctionner. Si vous ne maitrisez pas Gentoo ou si vous ne savez pas comment résoudre les problèmes éventuels, il est fortement recommandé de vous en tenir à la branche stable.
Par exemple, pour utiliser la branche de test sur une machine x86, modifiez le fichier /etc/make.conf comme suit :
Exemple de code 1.1 : Modifier la variable ACCEPT_KEYWORDS |
ACCEPT_KEYWORDS="~x86" |
Si vous mettez votre système à jour maintenant, vous constaterez que beaucoup de paquets vont être mis à jour. Veuillez noter qu'une fois passé à la branche de test, il est pratiquement impossible de revenir à la branche stable.
L'emplacement package.keywords
Il est possible d'indiquer à Portage d'utiliser les versions de test pour certains paquets tout en restant dans la branche stable. Pour cela, ajoutez le nom du paquet dont vous voulez la version instable et sa catégorie dans le fichier /etc/portage/package.keywords. Vous pouvez aussi créer un répertoire (du même nom) et lister les paquets dans des fichiers contenus dans ce répertoire. Par exemple, pour utiliser la version instable de gnumeric, ajoutez :
Exemple de code 2.1 : Ajouter gnumeric dans /etc/portage/package.keywords, ligne complète |
app-office/gnumeric ~x86 |
Si vous voulez tester une version donnée, mais ne voulez pas que Portage mette cette version à jour par la suite, vous pouvez spécifier le numéro de version désiré dans l'emplacement /etc/portage/package.keywords avec l'opérateur =. Il est également possible de spécifier une plage de versions avec les opérateurs <=, <, > ou >=.
Si vous spécifiez un numéro de version, vous devez utiliser un opérateur. Sans numéro de version, vous ne pouvez pas utiliser d'opérateur.
Dans l'exemple suivant, demandons à Portage d'accepter la version 1.2.13 de gnumeric :
Exemple de code 2.2 : Utiliser une version de test précise de gnumeric |
=app-office/gnumeric-1.2.13 ~x86 |
3.c. Utiliser des paquets masqués
Les développeurs Gentoo ne fournissent aucun support pour l'utilisation de cet emplacement. Faites très attention quand vous l'utilisez. Les demandes de support concernant package.unmask et/ou package.mask ne seront pas considérées. Vous aurez été prévenu.
Si un paquet a été masqué par les développeurs Gentoo et que vous voulez l'installer malgré les raisons précisées dans le fichier package.mask (par défaut dans le répertoire /usr/portage/profiles), ajoutez exactement la même ligne dans le fichier /etc/portage/package.unmask (ou dans un fichier de ce répertoire, si c'est un répertoire).
Par exemple, si =net-mail/hotwayd-0.8 a été masqué, vous pouvez le rendre disponible en ajoutant la même ligne dans l'emplacement package.unmask :
Exemple de code 3.1 : Exemple de /etc/portage/package.unmask |
=net-mail/hotwayd-0.8 |
Si vous voulez empêcher Portage d'installer un paquet ou une version particulière d'un paquet, vous pouvez ajouter son nom dans l'emplacement /etc/portage/package.mask (soit dans ce fichier, soit dans un fichier qui appartient à ce répertoire, s'il en est).
Par exemple, pour empêcher Portage d'installer des sources de noyaux plus récentes que gentoo-sources-2.6.8.1, ajoutez la ligne suivante dans l'emplacement package.mask :
Exemple de code 3.2 : Exemple de /etc/portage/package.mask |
>sys-kernel/gentoo-sources-2.6.8.1 |
L'outil dispatch-conf vous aide à intégrer les fichiers ._cfg0000_<nom>. Les fichiers ._cfg0000_<nom> sont créés par Portage quand un nouveau fichier devrait en remplacer un autre dans un répertoire protégé par la variable CONFIG_PROTECT.
Le programme dispatch-conf permet de garder une trace des modifications apportées à vos fichiers de configuration. En effet, il stocke les différences grâce au système de contrôle de versions RCS. Cela signifie que si vous faites une erreur en modifiant un fichier de configuration, vous avez la possibilité de revenir en arrière à tout moment.
Lorsque vous utilisez dispatch-conf pour mettre à jour un fichier, vous avez le choix de le garder intact, de le remplacer par sa version mise à jour, de le modifier directement ou d'intégrer les différences interactivement entre la version actuelle et sa mise à jour. dispatch-conf peut même :
Commencez par éditer le fichier /etc/dispatch-conf.conf et par créer le répertoire défini par la variable « archive-dir ».
Exemple de code 1.1 : Exécuter dispatch-conf |
# dispatch-conf
|
dispatch-conf va vous proposer chaque fichier de configuration ayant été modifié, un par un. Pressez u (update) pour remplacer le fichier actuel par sa mise à jour et continuer avec le fichier suivant. Pressez z pour « zapper » (supprimer) cette mise à jour et continuer avec le fichier suivant. Lorsque vous aurez traité tous les fichiers, dispatch-conf terminera. Vous pouvez également presser q à n'importe quel moment pour quitter.
Pour plus d'informations, allez donc voir la page man de dispatch-conf. Elle vous dira comment intégrer les différences une par une entre une mise à jour et le fichier actuel, comment éditer la mise à jour avant de remplacer la version actuelle, comment voir les différences entre les deux, etc.
Exemple de code 1.2 : Lire la page man de dispatch-conf |
$ man dispatch-conf
|
Vous pouvez aussi utiliser etc-update pour mettre à jour vos fichiers de configuration. Il n'est pas aussi simple d'utilisation que dispatch-conf, il contient moins de fonctionnalités, mais il peut intégrer les différences d'une manière interactive et peut aussi s'occuper automatiquement des mises à jour triviales.
Par contre, à la différence de dispatch-conf, etc-update ne garde pas l'historique des modifications des fichiers. Une fois qu'un fichier est modifié, l'ancienne version est irrécupérable. Alors, soyez très prudent, l'utilisation d'etc-update est significativement moins sure que celle de dispatch-conf.
Exemple de code 2.1 : Démarrer etc-update |
# etc-update
|
Après avoir intégré les modifications triviales, le programme affiche une liste des fichiers protégés qui n'ont pas été remplacés et pour lesquels une mise à jour est peut-être souhaitable. Les choix suivants sont indiqués au bas de la liste :
Exemple de code 2.2 : Menu etc-update |
Please select a file to edit by entering the corresponding number.
(-1 to exit) (-3 to auto merge all remaining files)
(-5 to auto-merge AND not use 'mv -i'):
|
Si vous entrez -1, etc-update quitte et ne change rien aux fichiers qui restent dans la liste. Si vous entrez -3 ou-5, tous les fichiers seront remplacés par les nouvelles versions. Il est donc très important de sélectionner les fichiers qui ne doivent pas être remplacés automatiquement avant de choisir cette option. Il suffit d'entrer le numéro du fichier dans la liste.
Par exemple, si vous sélectionnez le fichier /etc/pear.conf :
Exemple de code 2.3 : Mettre un fichier de configuration à jour |
Beginning of differences between /etc/pear.conf and /etc/._cfg0000_pear.conf
[...]
End of differences between /etc/pear.conf and /etc/._cfg0000_pear.conf
1) Replace original with update
2) Delete update, keeping original as is
3) Interactively merge original with update
4) Show differences again
|
Vous pouvez voir les différences entre le fichiers. Si vous pensez que la nouvelle version peut être utilisée sur votre système, tapez 1. Si vous pensez que la nouvelle version n'apporte rien qui ne vous soit utile ou qu'elle n'est pas nécessaire, tapez 2. Si vous voulez intégrer des parties de la nouvelle version de façon interactive, tapez 3.
Pendant l'intégration interactive, vous devez choisir entre les anciennes et les nouvelles lignes. Les commandes suivantes vous permettent d'indiquer votre choix :
Exemple de code 2.4 : Commandes disponibles pendant l'intégration interactive |
ed: Modifier et garder les deux versions avec un en-tête. eb: Modifier et garder les deux versions. el: Modifier et garder la version de gauche. er: Modifier et garder la version de droite. e: Saisir une nouvelle version. l: Garder la version de gauche. r: Garder la version de droite. s: Garder les deux lignes, sans commentaire. v: Garder les deux lignes, avec commentaire. q: Quitter. |
Après avoir traité les fichiers que vous jugez importants, vous pouvez laisser Portage intégrer les fichiers restants. Le programme etc-update n'insistera pas s'il n'y a plus de fichiers à intégrer.
Le programme quickpkg permet de créer un paquet binaire à partir d'un paquet qui est déjà installé sur votre système. Un tel paquet binaire peut être réinstallé sans devoir le recompiler. Il suffit de taper la liste des paquets à construire.
Par exemple, pour créer des paquets binaires pour curl, arts et procps :
Exemple de code 3.1 : Exemple d'utilisation de quickpkg |
# quickpkg curl arts procps
|
Les paquets seront placés dans le répertoire $PKGDIR/All (/usr/portage/packages/All par défaut) et des liens symboliques vers ceux-ci seront créés dans $PKGDIR/<catégorie>.
5.a. Utiliser un sous-ensemble de l'arbre Portage
Exclure des paquets ou des catégories
Vous pouvez mettre certains paquets ou certaines catégories à jour et en ignorer d'autres. Portage fait exclure ces catégories ou paquets par la commande rsync qu'il utilise pour l'action emerge --sync.
Dans /etc/make.conf, la variable PORTAGE_RSYNC_EXTRA_OPTS doit définir le nom du fichier qui contient les filtres d'exclusion.
Exemple de code 1.1 : Définir le fichier qui contient les filtres d'exclusion dans /etc/make.conf |
PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes" |
Exemple de code 1.2 : Exclure tous les jeux dans /etc/portage/rsync_excludes |
games-*/* |
Veuillez remarquer que cela peut causer des problèmes dans la gestion des dépendances puisque de nouveaux paquets pourraient dépendre de paquets que vous avez exclus.
5.b. Ajouter des ebuilds non officiels
Définir un répertoire superposé
Portage peut utiliser des ebuilds qui ne se trouvent pas dans l'arbre Portage de Gentoo. Pour cela, créez un répertoire, par exemple /usr/local/portage, dans lequel vous pourrez copier des ebuilds d'origines diverses. Vous devrez utiliser la même structure que pour l'arbre officiel.
Ensuite, définissez la variable PORTDIR_OVERLAY dans le fichier /etc/make.conf et attribuez-lui le nom du répertoire que vous avez créé. Portage utilisera alors les ebuilds qui se trouvent dans ce répertoire, mais ne les modifiera pas lors de l'opération de synchronisation emerge --sync.
Utiliser plusieurs sur-couches
Les utilisateurs avancés ont parfois besoin de conserver plusieurs répertoires superposés, par exemple pour des ebuilds en test ou des arbres d'origines diverses. Le paquet app-portage/gentoolkit-dev contient l'outil gensync qui permet de maintenir ces répertoires à jour.
L'outil gensync permet de mettre tous les répertoires superposés à jour en une seule opération. À chaque répertoire doit correrspondre un fichier .syncsource dans le répertoire /etc/gensync/ qui contient son nom, son emplacement, son identifiant, etc.
Supposons que vous avez deux répertoires superposés appelés java (pour vos développements d'ebuils java) et entapps (pour les ebuilds utilisés dans votre entreprise). Vous pouvez mettre vos répertoires à jour avec la commande suivante :
Exemple de code 2.1 : Mettre vos répertoires Portage superposés à jour avec gensync |
# gensync java entapps
|
5.c. Paquets gérés hors de Portage
Utiliser Portage avec des paquets gérés manuellement
Dans certains cas, vous voudrez peut-être configurer, installer et maintenir des paquets vous-même sans que Portage ne s'en mêle même si le paquet est disponible dans l'arbre Portage. Des cas typiques sont le noyau et les pilotes nvidia. Vous pouvez configurer Portage pour qu'il sache que certains paquets ont été installés manuellement. On appelle cela « injecter un paquet » et cela se fait grâce au fichier /etc/portage/profile/package.provided.
Par exemple, pour informer Portage que vous avez installé le noyau gentoo-sources-2.6.11.6 manuellement, ajoutez la ligne suivante au fichier /etc/portage/profile/package.provided :
Exemple de code 3.1 : Une ligne dans package.provided |
sys-kernel/gentoo-sources-2.6.11.6 |
Note : Ce document suppose que vous avez correctement configuré votre noyau et vos modules en fonction de votre matériel et que vous connaissez le nom de vos interfaces. De plus, ce guide procédera à la configuration d'eth0, mais cela pourrait tout aussi bien être eth1, wlan0, etc. |
Note : Vous devez utiliser baselayout-1.11.11 ou supérieur pour pouvoir suivre ce document. |
Pour être prêt à configurer votre carte réseau, vous devez indiquer au système RC (N.D.T : Configuration des ressources) de Gentoo le nom de cette interface. Pour cela, un lien symbolique doit être créé de net.lo vers net.eth0 dans le répertoire /etc/init.d/.
Exemple de code 1.1 : Déclarer une interface réseau |
# cd /etc/init.d # ln -s net.lo net.eth0 |
Le système RC de Gentoo est à présent au courant pour votre interface. Il doit maintenant savoir comment la configurer. Toutes les interfaces réseaux sont configurées dans le fichier /etc/conf.d/net. Voici un exemple de configuration en DHCP ou en adressage statique :
Exemple de code 1.2 : Exemples de /etc/conf.d/net |
# Pour DHCP : config_eth0=( "dhcp" ) # Pour une adresse IP statique en utilisant la notation CIDR : config_eth0=( "192.168.0.7/24" ) routes_eth0=( "default via 192.168.0.1" ) # Pour une adresse IP statique en utilisant un masque réseau config_eth0=( "192.168.0.7 netmask 255.255.255.0" ) routes_eth0=( "default via 192.168.0.1" ) |
Note : Si vous ne spécifiez pas de configuration pour votre interface, elle sera automatiquement configurée en DHCP. |
Note : CIDR signifie « Classless InterDomain Routing » (N.D.T : routage sans tenir compte des classes). À l'origine, les adresses IPv4 étaient classées A, B ou C. Ce vieux système de classification n'avait pas prévu la popularité que connait aujourd'hui Internet et menaçait de ne plus pouvoir offrir de nouvelles adresses. Le CIDR est un schéma d'adressage qui permet à une adresse IP de désigner plusieurs adresses IP. Une adresse IP CIDR ressemble à une adresse normale, sauf qu'elle se termine par un « / » (slash) suivi d'un nombre. Par exemple : 192.168.0.0/16. Le CIDR est décrit en anglais dans la RFC 1519. |
Maintenant que notre interface est configurée, nous pouvons la démarrer et l'arrêter grâce aux commandes suivantes :
Exemple de code 1.3 : Démarrage et arrêt du réseau |
# /etc/init.d/net.eth0 start # /etc/init.d/net.eth0 stop |
Important : Lorsque vous chercher à résoudre un problème de réseau, il est recommandé de mettre RC_VERBOSE="yes" dans le fichier de configuration /etc/conf.d/rc afin d'avoir plus d'informations sur ce qui se passe. |
Maintenant que vous avez démarré et arrêté votre carte réseau avec succès, vous voulez peut-être qu'elle soit démarrée automatiquement lorsque Gentoo démarre. Voici comment faire. La commande « rc » demande à Gentoo de démarrer tous les scripts du niveau d'exécution actuel qui ne le sont pas.
Exemple de code 1.4 : Activer une interface réseau au démarrage du système |
# rc-update add net.eth0 default # rc |
La variable config_eth0 est le cœur de la configuration d'une interface. Sa valeur est une liste d'instructions de haut niveau pour configurer une interface (eth0 dans notre cas). Chaque commande de la liste d'instructions est exécutée séquentiellement. L'interface est considérée active si au moins une commande marche.
Voici une liste des instructions intégrées :
| Commande | Description |
| null | Ne fait rien. |
| noop | Si l'interface est active et possède une adresse, alors annule sa configuration en renvoyant un code de succès. |
| Une adresse IPv4 ou IPv6 | Ajoute l'adresse à l'interface. |
|
dhcp, adsl ou apipa (ou bien une commande personnalisée venant d'une module tiers) |
Exécute le module qui fournit la commande. Par exemple, dhcp exécutera un module qui fournit le DHCP, ce qui peut être dhcpcd, dhclient ou pump. |
Si une commande échoue, vous pouvez spécifier une commande de secours. Celle-ci doit correspondre exactement à la structure de configuration.
Vous pouvez enchainer ces commandes ensemble. Voici quelques vrais exemples :
Exemple de code 1.1 : Exemples de configuration |
# Ajout de trois adresses IPv4 : config_eth0=( "192.168.0.2/24" "192.168.0.3/24" "192.168.0.4/24" ) # Ajout d'une adresse IPv4 et deux adresses IPv6 config_eth0=( "192.168.0.2/24" "4321:0:1:2:3:4:567:89ab" "4321:0:1:2:3:4:567:89ac" ) # On garde l'adresse déjà assignée par le noyau, sauf si l'interface # tombe. Dans ce cas, on en assigne une autre grâce à DHCP. Si DHCP ne marche # pas, alors on ajoute une adresse statique déterminée par APIPA. config_eth0=( "noop" "dhcp" ) fallback_eth0=( "null" "apipa" ) |
Note : Lorsque vous utilisez le module ifconfig pour ajouter plusieurs adresses, un alias d'interface est alors créé pour chaque adresse supplémentaire. Donc, avec les deux exemples précédents, vous obtiendrez eth0, eth0:1 et eth0:2. Vous ne pouvez rien faire de particulier avec ces interfaces car le noyau et les applications considèreront eth0:1 et eth0:2 comme n'étant juste qu'eth0. |
Important : L'ordre des commandes de secours est très important ! En effet, si nous n'avions pas spécifié la commande null, alors la commande apipa aurait été lancée si seule la commande noop avait échoué. |
Les scripts de démarrage du répertoire /etc/init.d/ peuvent dépendre d'une interface réseau particulière ou simplement de net. Ce que signifie réellement net est configurable grâce à la variable RC_NET_STRICT_CHECKING dans le fichier /etc/conf.d/rc.
| Valeur | Description |
| none | Le service net est toujours considéré comme actif. |
| no | Cela signifie qu'au moins un service net.*, excepté net.lo, doit être actif. Cela peut être utile pour les utilisateurs de portables qui ont une interface wifi et une statique car une seule interface active à la fois suffit. |
| lo | C'est la même chose que l'option no, mis à part que net.lo compte. C'est utile pour les gens qui se fichent d'avoir forcément une interface activée au démarrage du système. |
| yes | Ici, toutes les interfaces réseaux doivent être actives pour que le service net soit considéré comme démarré. |
Mais comment fait-on si net.br0 dépend de net.eth0 et de net.eth1 ? net.eth1 peut être une interface wifi ou bien une connexion ppp qui nécessite une configuration avant de pouvoir être ajouté au pont réseau. Nous ne pouvons régler ce problème dans /etc/init.d/net.br0 puisque c'est un lien symbolique vers net.lo.
La réponse est que vous pouvez fabriquer votre propre fonction depend() dans /etc/conf.d/net.
Exemple de code 2.1 : Les dépendances de net.br0 dans /etc/conf.d/net |
# Vous pouvez utiliser n'importe quel type de dépendance (use, after,
# before) tels qu'on les trouve dans les scripts.
depend_br0() {
need net.eth0 net.eth1
}
|
Pour une explication plus détaillée des dépendances, veuillez consulter la section « Écrire un script d'initialisation » du Manuel Gentoo.
2.c. Noms et valeurs des variables
Le nom des variables est dynamique. En principe, il suit le schéma variable_${interface|mac|essid|apmac}. Par exemple, la variable dhcpcd_eth0 contient la valeur des options dhcpcd pour eth0 et dhcpcd_essid contient la valeur des options dhcpcd pour quand une interface se connecte à l'ESSID « essid ».
Cependant, il n'y a pas de règle pure et simple stipulant que les noms d'interface doivent être de la forme ethX. En fait, de nombreuses interfaces sans fil ont des noms tels que wlanX, raX ou encore ethX. Aussi, les interfaces définies par l'utilisateur, telles que les ponts réseaux, peuvent avoir n'importe quel nom, « foo » par exemple. Pour rendre la vie encore plus intéressante, les bornes d'accès wifi peuvent avoir des noms qui contiennent des caractères non alphanumériques (c'est important car vous pouvez configurer les paramètres réseaux en fonction de l'ESSID)...
Le problème, dans tout ceci, c'est que Gentoo utilise des variables Bash pour gérer le réseau... et Bash ne peut rien utiliser d'autre que les alphanumériques anglais. Pour contourner cette limitation, nous transformons tout caractère qui n'est pas un alphanumérique anglais en un souligné _.
Un autre problème de Bash est le contenu des variables : certains caractères doivent être échappés. La parade est d'ajouter un antislash \ devant chacun de ces caractères. Les caractères qui doivent être échappés sont ", ' et \.
Dans cet exemple, nous utilisons un ESSID wifi car ils peuvent contenir un ensemble plus large de caractères. Disons que nous devons utiliser l'ESSID Mon "\ rézo :
Exemple de code 3.1 : Exemple de nom de variable |
# Cela marche, mais le domaine est invalide. dns_domain_Mon____r_zo="Mon \"\\ rézo" # La ligne ci-dessus configure le domaine DNS à « Mon "\ rézo » # lorsqu'une carte sans fil se connecte à un point d'accès # dont l'ESSID est « Mon "\ rézo ». |
Nous utilisons à présent des scripts réseaux modulaires, c'est-à-dire que nous pouvons facilement ajouter du support pour un nouveau type d'interface ou des nouveaux modules de configuration tout en gardant une compatibilité avec les anciens.
Par défaut, un module se charge si le paquet nécessaire à son utilisation est installé. Si vous spécifiez ici un module dont le paquet n'est pas installé, vous obtiendrez alors une erreur vous indiquant quel paquet doit être installé pour utiliser ce module. Typiquement, cette configuration n'est à faire que si vous avez installé plusieurs paquets qui fournissent le même service et si vous en préférez un en particulier.
Note : Tous les réglages mentionnés ci-dessous se trouvent dans etc/conf.d/net sauf mention contraire. |
Exemple de code 1.1 : Choix des modules |
# On préfère iproute2 plutôt que ifconfig. modules=( "iproute2" ) # Vous pouvez également spécifier un module pour une interface particulière. # Ici, on préfère utiliser pump plutôt que dhcpcd pour eth0. modules_eth0=( "pump" ) # Vous pouvez enfin spécifier quels modules *ne pas* charger. # Par exemple, vous pouvez utiliser WPA Supplicant ou # linux-wlan-ng pour contrôler la configuration du sans fil mais vous voulez # toujours configurer le réseau en fonction de l'ESSID. modules=( "!iwconfig" ) |
3.b. Outils de configuration d'interfaces réseau
Nous fournissons deux outils de configuration d'interfaces réseau actuellement : ifconfig et iproute2. Vous avez besoin d'un de ces deux outils pour pouvoir procéder à la configuration du réseau.
ifconfig est l'outil par défaut de Gentoo et est inclu dans le profil « system ». proute2 est un paquet bien plus puissant et plus flexible, mais n'est pas inclu par défaut.
Exemple de code 2.1 : Installer iproute2 |
# emerge sys-apps/iproute2 # Pour préférer iproute2 à ifconfig si les deux sont installés : modules=( "iproute2" ) |
Puisqu'ifconfig et iproute2 font à peu près la même chose, nous avons fait en sorte que la configuration de base fonctionne indifféremment avec les deux modules. Par exemple, les deux extraits de code ci-dessous fonctionnent quel que soit le module utilisé.
Exemple de code 2.2 : Exemple avec ifconfig ou iproute2 |
config_eth0=( "192.168.0.2/24" )
config_eth0=( "192.168.0.2 netmask 255.255.255.0" )
# On peut aussi spécifier l'adresse de diffusion (broadcast) :
config_eth0=( "192.168.0.2/24 brd 192.168.0.255" )
config_eth0=( "192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255" )
|
Le DHCP est un moyen d'obtenir les informations nécessaires à la configuration du réseau (adresse IP, serveurs DNS, passerelle, etc.) depuis un serveur DHCP. Cela signifie que si un serveur DHCP est actif sur le réseau, vous n'avez qu'à indiquer à chaque client d'utiliser DHCP et ce dernier se débrouillera tout seul. Cependant, vous aurez peut-être quelque chose à configurer (réseau sans fil, liaison PPP ou autre) avant de pouvoir utiliser le DHCP.
Le DHCP peut être fourni par dhclient, dhcpcd ou pump. Chaque module DHCP a ses avantages et ses inconvénients. Voici un rapide résumé.
| Module DHCP | Paquet | Avantages | Inconvénients |
| dhclient | net-misc/dhcp |
Produit par ISC, ceux-là même qui font le serveur DNS Bind. Très configurable. |
La configuration est trop complexe. L'application est vraiment énorme. Ne récupère pas les serveurs NTP en DHCP. N'envoie pas le nom de la machine au serveur par défaut. |
| dhcpcd | net-misc/dhcpcd |
C'est le client par défaut de Gentoo depuis longtemps. Ne s'appuie pas sur d'autre outils. Est maintenu par l'équipe Gentoo. |
Parfois lent. Reste lancé même si l'adresse IP est allouée « pour toujours ». |
| pump | net-misc/pump |
Léger. Ne repose pas sur d'autres outils. |
N'est plus maintenu par ses développeurs. Pas fiable, en particulier au travers des modems. Ne sait pas récupérer les informations NIS depuis DHCP. |
Si vous avez plus d'un client DHCP installé, vous devez spécifier lequel utiliser, sinon nous utiliserons dhcpcd s'il est disponible.
Pour faire passer des options spécifiques au module dhcp, utilisez module_eth0="..." en changeant « module » par le nom du module DHCP à utiliser. Par exemple : dhcpcd_eth0.
Nous essayons de garder la configuration du DHCP relativement indépendante du module utilisé. Ainsi, voici la liste des commandes utilisables avec la variable dhcp_eth0. Par défaut, aucune n'est exécutée.
Exemple de code 3.1 : Exemple de configuration DHCP dans /etc/conf.d/net |
# Nécessaire seulement si plusieurs modules DHCP sont installés. modules=( "dhcpcd" ) config_eth0=( "dhcp" ) dhcpcd_eth0="-t 10" # On attend une réponse en 10 secondes maxi. dhcp_eth0="release nodns nontp nonis" # On ne fait que récupérer une adresse. |
Note : dhcpcd et pump envoient le nom actuel de la machine au serveur DHCP par défaut donc vous n'avez plus besoin de le spécifier. |
Installons tout d'abord le logiciel pour gérer l'ADSL.
Exemple de code 4.1 : Installer le paquet ppp |
# emerge net-dialup/ppp
|
Note : Vous devez utiliser >=baselayout-1.12.x pour avoir le support de PPPoA. |
Ensuite, créez le script net PPP et le script net de l'interface Ethernet que doit utiliser PPP :
Exemple de code 4.2 : Créer les script net PPP et Ethernet |
# ln -s /etc/init.d/net.lo /etc/init.d/net.ppp0 # ln -s /etc/init.d/net.lo /etc/init.d/net.eth0 |
Mettez bien RC_NET_STRICT_CHECKING="yes" dans le fichier /etc/conf.d/rc.
Nous devons maintenant éditer le fichier /etc/conf.d/net.
Exemple de code 4.3 : Une configuration simple de PPPoE |
config_eth0=( null ) (Remplacez éventuellement eth0 par le nom correct.) config_ppp0=( "ppp" ) link_ppp0="eth0" (Ici aussi.) plugins_ppp0=( "pppoe" ) username_ppp0='nom_utilisateur' password_ppp0='mot_de_passe' pppd_ppp0=( "noauth" "defaultroute" "usepeerdns" "holdoff 3" "child-timeout 60" "lcp-echo-interval 15" "lcp-echo-failure 3" noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp ) depend_ppp0() { need net.eth0 } |
Vous pouvez également placer votre mot de passe dans /etc/ppp/pap-secrets.
Exemple de code 4.4 : Exemple de fichier /etc/ppp/pap-secrets |
# Le caractère « * » est important.
"nom_utilisateur" * "mot_de_passe"
|
Si vous utilisez PPPoE avec un modem USB, vous devez installer br2684ctl. Lisez le fichier /usr/portage/net-dialup/speedtouch-usb/files/README pour savoir comment le configurer correctement.
Important : Lisez attentivement la section sur l'ADSL et PPP dans le fichier /etc/conf.d/net.example. Elle contient des explications très détaillées sur les réglages à votre disposition pour configurer votre PPP. |
3.e. APIPA (Adressage automatique d'adresse IP privée)
APIPA essaye de trouver une adresse libre dans l'intervalle 169.254.0.0-169.254.255.255 en faisant un arping sur une adresse au hasard sur l'interface. S'il n'y a pas de réponse, alors l'adresse est assignée à cette interface.
Cette méthode est utile pour les réseaux où il n'y a pas de serveur DHCP, où les machines ne sont pas connectées directement à Internet et où tous les autres ordinateurs utilisent APIPA.
Pour obtenir le support APIPA, installez net-misc/iputils ou net-analyzer/arping.
Exemple de code 5.1 : Configuration APIPA dans /etc/conf.d/net |
# Essaye d'abord DHCP puis APIPA, si cela ne marche pas. config_eth0=( "dhcp" ) fallback_eth0=( "apipa" ) # Utilise juste APIPA. config_eth0=( "apipa" ) |
3.f. Agrégation de liens (Bonding)
Pour pouvoir faire de l'agrégation de liens (bonding, trunking), installez net-misc/ifenslave.
L'agrégation de liens est utilisée pour augmenter la bande passante réseau. Si vous avez deux cartes réseaux branchées sur le même réseau, vous pouvez les fusionner afin que vos applications ne voient qu'une seule interface qui utilise en réalité les deux cartes.
Exemple de code 6.1 : Configurer une agrégation de liens dans /etc/conf.d/net |
# Pour fusionner des interfaces ensemble : slaves_bond0="eth0 eth1 eth2" # Vous pourriez vouloir ne pas assigner d'adresse à cette interface : config_bond0=( "null" ) # On dépend de la configuration des interfaces utilisées : depend_bond0() { need net.eth0 net.eth1 net.eth2 } |
3.g. Pont réseau (« bridge » 802.1d)
Pour activer le support des ponts réseaux, installez net-misc/bridge-utils.
Le pontage de réseaux est utilisé pour connecter plusieurs réseaux ensemble. Par exemple, un serveur qui se connecte à Internet via un modem ADSL peut utiliser un pont réseau pour permettre aux machines connectées sur sa carte réseau sans fil d'accéder à Internet.
Exemple de code 7.1 : Configuration d'un pont réseau dans /etc/conf.d/net |
# Configuration du pont (voir « man brctl » pour plus de détails) : brctl_br0=( "setfd 0" "sethello 0" "stp off" ) # Ajout de ports au pont br0 : bridge_br0="eth0 eth1" # Les ports doient être explicitement non configurés pour ne pas # lancer DHCP : config_eth0=( "null" ) config_eth1=( "null" ) # On assigne enfin une adresse au pont. Nous aurions pu utiliser DHCP ici : config_br0=( "192.168.0.1/24" ) # On dépend de la configuration des interfaces utilisées : depend_br0() { need net.eth0 net.eth1 } |
Important : Pour la configuration de certains ponts, vous pourriez avoir besoin de consulter la documentation sur les noms des variables. |
Vous n'avez pas besoin d'installer quoi que ce soit pour changer l'adresse MAC de votre interface si vous utilisez sys-apps/baselayout-1.11.14 ou une version plus récente. En revanche, si vous utilisez une version de baselayout plus ancienne ou si vous voulez assigner une adresse aléatoire, vous devez installer net-analyzer/macchanger.
Exemple de code 8.1 : Exemples de modification d'adresse MAC |
# Pour assigner une adresse MAC à une interface : mac_eth0="00:11:22:33:44:55" # Pour tirer au hasard les trois derniers octets : mac_eth0="random-ending" # Pour obtenir une adresse aléatoire en gardant le type physique de # votre interface (par exemple : fibre, cuivre, sans fil...) : mac_eth0="random-samekind" # Pour obtenir une adresse aléatoire sans garder le type physique de # votre interface (par exemple : fibre, cuivre, sans fil...) : mac_eth0="random-anykind" # Pour une adresse totalement aléatoire (ATTENTION : certaines adresses # générées de cette façon n'agissent pas comme l'on pourrait s'y attendre) : mac_eth0="random-full" |
Vous n'avez pas à installer quoi que ce soit pour créer des tunnels car l'outil de configuration d'interfaces réseaux peut s'en charger.
Exemple de code 9.1 : Configuration de tunnels dans /etc/conf.d/net |
# Pour un tunnel GRE : iptunnel_vpn0="mode gre remote 207.170.82.1 key 0xffffffff ttl 255" # Pour un tunnel IPIP : iptunnel_vpn0="mode ipip remote 207.170.82.2 ttl 255" # Pour configurer l'interface du tunnel : config_vpn0=( "192.168.0.2 peer 192.168.1.1" ) |
Pour activer le support des VLAN, installez net-misc/vconfig.
Un réseau virtuel (ou VLAN) est un groupe d'équipements réseaux qui agissent comme s'ils se trouvaient sur un seul segment réseau, même si ce n'est pas le cas. Les membres d'un VLAN peuvent uniquement voir les autres membres du même VLAN, même s'ils sont physiquement sur le même réseau.
Exemple de code 10.1 : Configuration de VLAN dans /etc/conf.d/net |
# Spécifiez les numéros des VLAN auxquels l'interface appartient. # Veuillez vous assurez que les identifiants des VLAN ne sont pas # complétés par des zéros. vlans_eth0="1 2" # On configure ensuite le VLAN (voir « man vconfig » pour plus de détails) : vconfig_eth0=( "set_name_type VLAN_PLUS_VID_NO_PAD" ) vconfig_vlan1=( "set_flag 1" "set_egress_map 2 6" ) # Enfin, on configure les interfaces comme d'habitude : config_vlan1=( "172.16.3.1 netmask 255.255.254.0" ) config_vlan2=( "172.16.2.1 netmask 255.255.254.0" ) |
Important : Pour la configuration de certains VLAN, vous pourriez avoir besoin de consulter la documentation sur les noms des variables. |
Actuellement, nous supportons la configuration des interfaces sans fil au moyen des outils wireless-tools et wpa_supplicant. Une chose essentielle à retenir est que la configuration des réseaux sans fil se fait d'une manière globale et non d'une manière propre à l'interface.
wpa_supplicant est le meilleur choix mais il ne gère pas tous les pilotes. Pour une liste des matériels supportés, lisez le site web de wpa_supplicant. De plus, pour le moment, wpa_supplicant ne peut se connecter qu'aux SSID pour lesquels il a été configuré.
wireless-tools supporte pratiquement toutes les cartes et tous les pilotes, mais il ne sait pas se connecter aux points d'accès qui ne font que du WPA.
Attention : Le pilote linux-wlan-ng n'est pas supporté par baselayout pour le moment, à cause de sa mise en place et de sa configuration qui est complètement différente de ce qui se fait ailleurs. Des rumeurs émanant des développeurs de linux-wlan-ng affirmeraient que leur procédure de mise en place se conformerait à celle de wireless-tools. Lorsque ceci sera effectif, vous pourrez utiliser linux-wlan-ng avec notre baselayout. |
WPA Supplicant est un paquet qui vous permettra de vous connecter à un point d'accès WPA. Sa mise en place est assez instable puisque c'est une application bêta ; elle marche pourtant très bien.
Exemple de code 2.1 : Installer wpa_supplicant |
# emerge net-wireless/wpa_supplicant
|
Important : Vous devez activer CONFIG_PACKET dans votre noyau pour que wpa_supplicant puisse fonctionner. |
Nous devons maintenant indiquer dans le fichier /etc/conf.d/net que nous préférons utiliser wpa_supplicant plutôt que wireless-tools (qui est celui par défaut si les deux sont installés).
Exemple de code 2.2 : Configuration de /etc/conf.d/net avec wpa_supplicant |
# On préfère utiliser wpa_supplicant : modules=( "wpa_supplicant" ) # Il est important de spécifier à wpa_supplicant quel pilote nous # allons utiliser car il n'est pas encore doué pour les devinettes : wpa_supplicant_eth0="-Dmadwifi" |
Note : Si vous utilisez le pilote host-ap, vous devez placer la carte en mode Managed afin qu'elle puisse être utilisée correctement par wpa_supplicant. Vous pouvez utiliser la commande iwconfig_eth0="mode managed" dans /etc/conf.d/net pour accomplir cette tâche. |
Plutôt simple, n'est-ce pas ? Pourtant, nous devons encore configurer wpa_supplicant lui-même, ce qui peut devenir bien plus fastidieux selon le niveau de sécurité demandé par le point d'accès auquel vous souhaitez vous connecter. L'exemple ci-dessous est repris puis adapté depuis le fichier /usr/share/doc/wpa_supplicant-<version>/wpa_supplicant.conf.gz fourni avec wpa_supplicant.
Exemple de code 2.3 : Un exemple de fichier /etc/wpa_supplicant/wpa_supplicant.conf |
# La ligne ci-dessous ne doit pas être changée sinon cela ne marchera pas : ctrl_interface=/var/run/wpa_supplicant # On s'assure que seul root peut lire la configuration WPA : ctrl_interface_group=0 # Laissons wpa_supplicant se charger de scanner et de choisir un # point d'accès : ap_scan=1 # Cas simple : WPA-PSK, une phrase ASCII en guise de PSK, on autorise # tous les mécanismes disponibles : network={ ssid="simple" psk="une phrase super secrete" # Plus la priorité est haute, plus tôt se fera la reconnaissance : priority=5 } # Idem, mais en demandant un scan spécifique à un SSID (pour les points # d'accès qui rejettent les SSID de diffusion (broadcast) : network={ ssid="second ssid" scan_ssid=1 psk="phrase tres secrete" priority=2 } # Seul WPA-PSK est utilisé. N'importe quel mécanisme est autorisé. network={ ssid="exemple" proto=WPA key_mgmt=WPA-PSK pairwise=CCMP TKIP group=CCMP TKIP WEP104 WEP40 psk=06b4be19da289f475aa46a33cb793029d4ab3db7a23ee92382eb0106c72ac7bb priority=2 } # Connexion en clair (pas de WPA, pas de IEEE 802.1X) : network={ ssid="test-en-clair" key_mgmt=NONE } # Connexion à clé WEP partagée (pas de WPA, pas de IEEE 802.1X) : network={ ssid="static-wep-test" key_mgmt=NONE # Les clefs entres guillemets sont des chaines ASCII wep_key0="abcde" # Les clefs sans guillemets sont en hexadécimal wep_key1=0102030405 wep_key2="1234567890123" wep_tx_keyidx=0 priority=5 } # Connexion à clé WEP partagée (pas de WPA, pas de IEEE 802.1X) en # utilisant une authentification à clé partagée IEEE 802.11 : network={ ssid="static-wep-test2" key_mgmt=NONE wep_key0="abcde" wep_key1=0102030405 wep_key2="1234567890123" wep_tx_keyidx=0 priority=5 auth_alg=SHARED } # Réseau IBSS/ad-hoc avec WPA-None/TKIP : network={ ssid="test adhoc" mode=1 proto=WPA key_mgmt=WPA-NONE pairwise=NONE group=TKIP psk="une phrase secrete" } |
Mise en place et mode « Managed »
Wireless Tools fournit un moyen générique de configurer des interfaces sans fil jusqu'au niveau de sécurité WEP. Bien que WEP soit une méthode faiblement sécurisée, elle reste la plus répandue.
La configuration de Wireless Tools est contrôlée par quelques variables. L'exemple de fichier de configuration ci-dessous devrait couvrir tous vos besoins. Sachez simplement qu'en cas de non-configuration, nous essayons tout de même de connecter l'interface au point d'accès le plus fort, quel qu'il soit.
Exemple de code 3.1 : Installer wireless-tools |
# emerge net-wireless/wireless-tools
|
Note : Bien que vous puissiez stocker la configuration du réseau sans fil dans le fichier /etc/conf.d/wireless, ce guide vous recommande de la placer dans le fichier /etc/conf.d/net. |
Important : Vous devrez consulter la documentation sur les noms des variables. |
Exemple de code 3.2 : Exemple de configuration /etc/conf.d/net avec iwconfig |
# On préfère utiliser iwconfig plutôt que wpa_supplicant : modules=( "iwconfig" ) # On configure les clés WEP pour les points d'accès nommés ESSID1 et ESSID2. # Vous pouvez mettre jusqu'à quatre clés WEP, mais seulement une pourra # être active à la fois. Au cas où vous auriez déjà une clé WEP active, on # spécifie un index [1] lors de la création de la clé. On règle ensuite le # niveau de sécurité pour ce même index [1]. # # Le préfixe « s: » de la clé indique que c'est une clé ASCII. Sinon, ce serait # une clé hexadécimale. # # « enc open » spécifie le mode de sécurité « open » (le moins sécurisé), # « enc restricted » spécifie le mode « restricted » (le plus sécurisé). key_ESSID1="[1] s:votrecle key [1] enc open" key_ESSID2="[1] aaaa-bbbb-cccc-dd key [1] enc restricted" # La variable ci-dessous n'est utilisée que lorsqu'on procède à un scan # pour trouver les points d'accès disponibles. # Parfois, plusieurs points d'accès peuvent être accessibles. Nous # devons donc définir un ordre pour pouvoir choisir auquel se connecter. preferred_aps=( "ESSID1" "ESSID2" ) |
Réglages personnalisés pour la sélection de points d'accès
Vous pouvez éventuellement rajouter des options pour contrôler la sélection des points d'accès. Ceci n'est pas indispensable.
Vous pouvez décider si nous devons nous connecter uniquement aux points d'accès listés précédemment ou pas. Par défaut, si tout ce qui a été configuré a échoué et si nous pouvons nous connecter à un point d'accès non chiffré, alors nous le ferons. Ce comportement peut être contrôlé par la variable associate_order. Voici une table qui présente les valeurs acceptables et à quoi elles servent.
| Valeur | Description |
| any | Comportement par défaut. |
| preferredonly | Nous nous connecterons uniquement à un point d'accès présent dans la liste. |
| forcepreferred | Nous forcerons la connexion à un point d'accès dans l'ordre listé si ceux-ci ne sont pas trouvés lors d'un scan. |
| forcepreferredonly | Ne lance pas le scan. Essaye simplement de se connecter à l'un d'entre eux dans l'ordre indiqué. |
| forceany | Pareil que forcepreferred puis essaie n'importe quel autre point d'accès si cela n'a pas marché. |
Enfin, voici les variables blacklist_aps et unique_ap. blacklist_aps fonctionne d'une manière similaire à preferred_aps. unique_ap attend yes ou no pour savoir si une deuxième interface peut se connecter sur le même point d'accès que la première.
Exemple de code 3.3 : Exemples pour blacklist_aps et unique_ap |
# Il se peut que vous souhaitiez ne pas vous connecter à certains # points d'accès : blacklist_aps=( "ESSID3" "ESSID4" ) # Si vous avez plus d'une carte sans fil, vous pouvez spécifier ici si vous # acceptez que plusieurs cartes se connectent au même point d'accès. # Il faut mettre « yes » (par défaut) ou « no ». unique_ap="yes" |
Vous pouvez aussi vous déclarer comme nœud Ad-Hoc si vous n'arrivez pas à joindre un point d'accès.
Exemple de code 3.4 : Passer en mode Ad-Hoc |
adhoc_essid_eth0="Mon noeud Adhoc" |
Et pourquoi pas se connecter à des réseaux Ad-Hoc ou bien tourner en mode Master pour devenir nous-même un point d'accès ? Voici la configuration qu'il vous faut. Vous aurez peut-être à spécifier des clés WEP comme indiqué précédemment.
Exemple de code 3.5 : Exemple de configuration Ad-Hoc/Master |
# Spécifie le mode. # Peut être « managed » (par défaut), « ad-hoc » ou « master ». # Attention, tous les pilotes ne supportent pas forcément tous les modes. mode_eth0="ad-hoc" # Spécifie l'ESSID des interfaces. # En mode managed, cela force l'interface à essayer de se connecter à l'ESSID # spécifié et à aucun autre. essid_eth0="Mon noeud adhoc" # Le canal à utiliser (par défaut c'est 3) : channel_eth0="9" |
Important : Ce qui suit est repris tel quel depuis la documentation NetBSD sur WaveLAN. Il y a 14 canaux possibles. Nous avons été informés que les canaux 1 à 11 sont légaux en Amérique du Nord, 1 à 13 dans une grande partie de l'Europe, 10 à 13 en France et uniquement le 14 au Japon. En cas de doute, consultez la documentation fournie avec la carte ou avec le point d'accès. Assurez-vous que le canal choisi correspond à celui du point d'accès (ou de l'autre carte en réseau Ad-Hoc). Par défaut, ce canal est le numéro 3 sur les cartes vendues en Amérique du Nord et dans une grande partie de l'Europe, 11 en France et 14 au Japon). |
Problèmes et résolutions concernant Wireless Tools
Il existe quelques variables supplémentaires que vous pouvez utiliser pour vous aider à résoudre les problèmes de pilote ou d'environnement pour faire fonctionner votre réseau sans fil. Voici une table répertoriant ce que vous pouvez essayer :
| Variable | Valeur par défaut | Description |
| iwconfig_eth0 | Lisez man iwconfig pour savoir ce qu'il est possible d'indiquer à iwconfig. | |
| iwpriv_eth0 | Lisez man iwpriv pour savoir ce qu'il est possible d'indiquer à iwpriv. | |
| sleep_scan_eth0 | 0 | Le nombre de secondes à attendre avant de lancer un scan. Cette commande est requise lorsque le pilote a besoin de temps supplémentaire pour compléter son activation et pour devenir utilisable. |
| sleep_associate_eth0 | 5 | Le nombre de secondes permis à l'interface pour qu'elle réussisse à s'associer avec le point d'accès avant de passer au suivant. |
| associate_test_eth0 | MAC |
Certains pilotes n'assignent pas une adresse MAC invalide pendant qu'ils
essayent de se connecter. Certains pilotes ne remettent pas à zéro le niveau de qualité pendant qu'ils essayent se se connecter. Les valeurs autorisées sont MAC, quality ou all, pour les deux. |
| scan_mode_eth0 | Certains pilotes doivent scanner en mode Ad-Hoc. Donc si le scan échoue systématiquement, essayez de spécifier ad-hoc ici. | |
| iwpriv_scan_pre_eth0 |
Envoie des commandes iwpriv à l'interface avant le scan. Veuillez lire man iwpriv pour les détails. |
|
| iwpriv_scan_post_eth0 |
Envoie des commandes iwpriv à l'interface après le scan. Veuillez lire le man iwpriv pour les détails. |
4.d. Spécifier une configuration réseau selon l'ESSID
Il se peut que lorsque vous vous connectez à ESSID1, vous ayez besoin d'une adresse IP statique et que lorsque vous vous connectez à ESSID2, vous vouliez du DHCP. En fait, on peut spécifier la plupart des variables selon l'ESSID. Voici comment faire.
Note : Cela marche si vous utilisez WPA Supplicant ou Wireless Tools. |
Important : Vous devrez consulter la documentation sur les noms des variables. |
Exemple de code 4.1 : Surcharger la configuration réseau selon l'ESSID |
config_ESSID1=( "192.168.0.3/24 brd 192.168.0.255" ) routes_ESSID1=( "default via 192.168.0.1" ) config_ESSID2=( "dhcp" ) fallback_ESSID2=( "192.168.3.4/24" ) fallback_route_ESSID2=( "default via 192.168.3.1" ) # On peut également définir les serveurs de noms, entre autres. # Note : DHCP écraserait ces valeurs à moins qu'on ne lui # indique le contraire. dns_servers_ESSID1=( "192.168.0.1" "192.168.0.2" ) dns_domain_ESSID1="un.certain.domaine" dns_search_domains_ESSID1="cherche.ce.domaine puis.cherche.celui.la" # On surcharge en fonction de l'adresse MAC du point d'accès. # C'est pratique si plusieurs points d'accès ont le même ESSID. config_001122334455=( "dhcp" ) dhcpcd_001122334455="-t 10" dns_servers_001122334455=( "192.168.0.1" "192.168.0.2" ) |
5.a. Fonctions d'interception standard
Quatre fonctions, qui peuvent être définies par l'administrateur, sont appelées lors du démarrage ou de l'arrêt du réseau. Ces fonctions sont appelées en spécifiant le nom de l'interface en premier, afin de pouvoir contrôler plusieurs interfaces avec un même script.
La valeur renvoyée par les fonctions preup() et predown() doit être 0 (succès) pour que la configuration ou la déconfiguration de l'interface puisse continuer. Si preup() renvoie autre chose que zéro, alors la configuration de l'interface sera annulée. Si predown() renvoie autre chose que zéro, alors l'interface ne sera pas autorisée à être désactivée.
La valeur renvoyée par les fonctions postup() et postdown() n'ont pas d'importance car il n'y a rien à faire après.
La variable ${IFACE} contient le nom de l'interface qui doit être activée ou désactivée. La variable ${IFVAR} contient une version utilisable dans un nom de variable Bash du nom de l'interface.
Exemple de code 1.1 : Exemples de fonctions pre/post up/down |
preup() {
# On teste l'état du lien de l'interface avant de l'activer. Cela ne
# fonctionne qu'avec certaines cartes réseaux et utilise le paquet ethtool.
if ethtool ${IFACE} | grep -q 'Link detected: no'; then
ewarn "No link on ${IFACE}, aborting configuration"
return 1
fi
# On n'oublie surtout pas de renvoyer 0 en cas de succès :
return 0
}
predown() {
# La fonction predown par défaut vérifie que le système de fichiers / n'est
# pas monté en NFS et bloque l'arrêt de l'interface si c'est le cas. Sachez
# que si vous spécifiez votre fonction predown, ceci ne sera plus vérifié.
# Voici la fonction, au cas où vous voudriez la voir...
if is_net_fs /; then
eerror "root filesystem is network mounted -- can't stop ${IFACE}"
return 1
fi
# On n'oublie surtout pas de renvoyer 0 en cas de succès :
return 0
}
postup() {
# Cette fonction pourrait servir, par exemple, à activer une redirection DNS
# dynamique ou bien à récupérer des mails une fois que l'interface est
# activée.
return 0
}
postdown() {
# Cette fonction est surtout présente pour faire un compte rond... Je n'ai pas
# encore trouvé quelque chose d'intéressant à faire avec ;-)
return 0
}
|
5.b. Fonction d'interception pour Wireless Tools
Note : Cela ne marchera pas avec WPA Supplicant, mais les variables ${ESSID} et ${ESSIDVAR} sont disponibles dans la fonction postup(). |
Deux fonctions qui seront appelées avant et après la connexion à un point d'accès peuvent être personnalisées. Les fonctions sont appelées en spécifiant le nom de l'interface en premier afin de pouvoir contrôler plusieurs interfaces avec la même fonction.
La valeur renvoyée par la fonction preassociate() doit être 0 pour indiquer que la configuration ou la déconfiguration de l'interface peut continuer. Si preassociate() renvoie autre chose que zéro, alors la configuration de l'interface sera annulée.
La valeur renvoyée par la fonction postassociate() est ignorée, car il n'y a plus rien à faire après.
La variable ${ESSID} contient le nom exact de l'ESSID du point d'accès auquel on se connecte. ${ESSIDVAR} contient ce même nom, mais transformé afin qu'il puisse être utilisé dans le nom d'une variable Bash.
Exemple de code 2.1 : Exemples de fonctions pre/post association |
preassociate() {
# Le code ci-dessous ajoute deux variables de configuration leap_user_ESSID et
# leap_pass_ESSID. Lorsqu'elles correspondent à l'ESSID auquel on se connecte,
# on lance le script Cisco Leap.
local user pass
eval user=\"\$\{leap_user_${ESSIDVAR}\}\"
eval pass=\"\$\{leap_pass_${ESSIDVAR}\}\"
if [[ -n ${user} && -n ${pass} ]]; then
if [[ ! -x /opt/cisco/bin/leapscript ]]; then
eend "For LEAP support, please emerge net-misc/cisco-aironet-client-utils"
return 1
fi
einfo "Waiting for LEAP Authentication on \"${ESSID//\\\\//}\""
if /opt/cisco/bin/leapscript ${user} ${pass} | grep -q 'Login incorrect'; then
ewarn "Login Failed for ${user}"
return 1
fi
fi
return 0
}
postassociate() {
# Cette fonction est surtout présente pour faire un compte rond... Je n'ai pas
# encore trouvé quelque chose d'intéressant à faire avec ;-)
return 0
}
|
Note : Les variables ${ESSID} et ${ESSIDVAR} ne sont pas disponibles dans les fonctions predown() et postdown(). |
Si votre ordinateur et vous êtes tout le temps en déplacement, cela signifie qu'il n'y a pas tout le temps un câble réseau de branché sur votre carte réseau ou un point d'accès sans fil prêt à vous accueillir. Aussi, vous pouvez configurer le système pour que le réseau soit automatiquement activé dès qu'un câble est branché ou dès qu'un point d'accès est disponible.
Voici quelques outils qui vous aideront à réaliser cela.
Note : Ce document ne parle que d'ifplugd, mais il existe d'autres alternatives intéressantes, comme netplug. netplug est une alternative plus légère à ifplugd mais il suppose que les pilotes réseau du noyau fonctionnent correctement, ce qui n'est pas toujours le cas. |
ifplugd est un démon qui démarre et arrête les interfaces lorsqu'un câble Ethernet est branché ou débranché. Il sait aussi détecter les associations à un point d'accès ou lorsqu'un nouveau point d'accès devient disponible.
Exemple de code 2.1 : Installer ifplugd |
# emerge sys-apps/ifplugd
|
La configuration d'ifplugd est vraiment très simple. Consultez man ifplugd pour savoir quelles sont les variables utilisables dans le fichier /etc/conf.d/net. Lisez également /etc/conf.d/net.example pour plus d'exemples.
Exemple de code 2.2 : Exemple de configuration d'ifplugd |
(Remplacez eth0 par l'interface à surveiller.) ifplugd_eth0="..." (Pour surveiller une interface sans fil.) ifplugd_eth0="--api-mode=wlan" |
En plus de gérer plusieurs connexions réseaux, vous pouvez utiliser un petit utilitaire qui facilite la gestion des configurations DNS. C'est vraiment pratique lorsque vous recevez votre adresse IP par DHCP. Installez simplement openresolv.
Exemple de code 2.3 : Installer openresolv |
# emerge openresolv
|
Voir man resolvconf pour mieux comprendre comment il fonctionne.
Ce document est protégé par la licence Creative Commons : Paternité - Partage des Conditions Initiales à l'Identique 2.5.