Manuel d'installation de serveur Netboot sous Gentoo Linux

1.  Introduction

Ce document décrira comment configurer un environnement démarrant par le réseau pour un ordinateur de type Sun Microsystem SPARC ou UltraSPARC. Le document suppose que vous ayez une machine avec un système Gentoo Linux pouvant servir de serveur netboot.

Le serveur netboot et le client netboot devront appartenir au même sous-réseau, du fait que le protocole ARP n'est typiquement pas transmis d'un sous-réseau à un autre.

Voici une vue d'ensemble de ce qui se passe lors du processus de démarrage par le réseau :

1. La machine cliente envoie une requête Reverse ARP (RARP) afin d'obtenir une adresse IP.
2. La machine serveur retourne une réponse au client, contenant l'adresse IP.
3. Le client tente alors de télécharger l'image de démarrage du serveur RARP en utilisant le protocole TFTP.
4. Une fois l'image téléchargée, le client netboot démarre alors sur l'image.

D'après cette vue d'ensemble, nous aurons besoin d'installer un démon pour le reverse ARP et un serveur pour le TFTP.

2.  Installation des logiciels et configuration

Le serveur de Reverse ARP

Vous pouvez choisir actuellement entre deux démons de Reverse ARP, net-misc/iputils (installé en tant que partie du profil système) et net-misc/rarpd.

Configurer les éléments standards de rarpd : /etc/ethers

Quel que soit le démon rarpd que vous choisissez, vous aurez besoin de configurer le fichier /etc/ethers. Ce fichier indique quels seront les clients auxquels rarpd devra répondre lorsqu'une requête sera reçue et quelle adresse envoyer en réponse.

Le fichier /etc/ethers contient l'adresse MAC de la machine depuis laquelle on démarrera et le nom de la machine en question. Un espace délimite l'adresse MAC du nom de la machine et chaque entrée a sa propre ligne. L'exemple suivant est pour une machine nommée sparc-netboot.gentoo.org :

08:00:20:77:1f:3e sparc-netboot.gentoo.org

Si vous désirez ajouter d'autres machines à /etc/ethers, vous n'avez pas besoin de redémarrer le service rarpd puisque le fichier est vérifié à chaque fois qu'une requête est reçue.

Résoudre les noms de machine : /etc/hosts

Puisque chaque entrée de /etc/ethers a un nom de machine, le serveur netboot doit être capable de résoudre le nom de la machine par son adresse IP. Cela peut être fait de deux façons, avec /etc/hosts ou en utilisant le serveur de noms de domaine utilisé par le serveur netboot.

Une entrée dans /etc/hosts pour résoudre le nom de machine ressemblera à l'une de celles qui existent probablement déjà depuis que vous avez installé Gentoo sur le serveur netboot. Pour notre hôte exemple, sparc-netboot.gentoo.org, nous supposerons qu'il a l'adresse IP 10.0.1.15. Donc l'entrée dans /etc/hosts ressemblera à :

10.0.1.15  sparc-netboot.gentoo.org

Si vous utilisez un serveur de noms, alors l'administrateur du serveur DNS devra ajouter un enregistrement pour l'hôte, dans notre exemple sparc-netboot.gentoo.org, pointant vers l'adresse IP appropriée. Merci de consulter l'administrateur de votre serveur de noms et/ou la documentation des logiciels de serveurs de noms pour y ajouter une entrée.

Configurer le serveur rarpd de net-misc/iputils

Premièrement, nous aurons besoin de déterminer les options à utiliser pour rarpd. Même s'il y a plus d'options que celles que nous allons présenter ici, ces options devraient vous permettre de commencer. Comme il n'y a actuellement pas de script d'initialisation init.d pour la version net-misc/iputils de rarpd, une entrée devra être ajoutée à /etc/conf.d/local.start si vous souhaitez activer les services rarpd au démarrage. Voici un exemple d'entrée :

/usr/sbin/rarpd -v -e eth0

Une explication des options précédentes pour rarpd (issue de la page de man) :

• -v pour être verbeux.
• -e pour que le serveur ne vérifie pas la présence de l'image de démarrage et qu'il réponde si l'adresse MAC résout une adresse IP valide en utilisant la base de donnée /etc/ethers et le DNS.
• eth0 représente l'interface que rarpd devra écouter.

Pour plus d'options, consultez le manuel man 8 rarpd.

Mettre en place net-misc/rarpd

Tout d'abord, nous devons installer rarpd en utilisant la commande suivante :

# emerge net-misc/rarpd

Ensuite, les options pour rarpd devront être mises dans /etc/conf.d/rarpd. Pour une configuration équivalente à celle utilisée précédemment pour le rarpd de net-misc/iputils, ajustez /etc/conf.d/rarpd pour qu'il ressemble à ce qui suit :

RARPD_OPTS="-v -i eth0"

Une explication des options précédentes (issue de la page de manuel) :

• -v pour la verbosité. Montre les requêtes auxquelles le démon répond.
• -i pour que le démon écoute l'interface nommée. Par défaut rarpd écoute l'interface par défaut du type du système local, si disponible.

Pour plus d'options, consultez le manuel man 8 rarpd et rarpd --help.

Le démon tftpd

Ici, il y a trois options pour le démon TFTP : net-misc/atftp, net-misc/netkit-tftp et net-misc/tftp-hpa. N'en installez qu'un seul, pour une configuration correcte.

Mettre en place les éléments communs de tftpd

Chaque démon TFTP aura besoin d'un répertoire depuis lequel seront servis les fichiers aux clients tftp. Le répertoire que nous utiliserons dans ce manuel sera /tftpboot. Il apparaîtra comme le répertoire racine (/) pour les clients lorsque les requêtes sont reçues. De plus, nous configurerons le démon TFTP pour être lancé avec le groupe et l'utilisateur nobody.

Si le répertoire que vous avez choisi n'existe pas déjà, il devra être créé avec la commande mkdir. La commande pour l'exemple /tftpboot est :

# /bin/mkdir /tftpboot

Ensuite, nous devrons changer le propriétaire de /tftpboot de telle manière qu'il appartienne à l'utilisateur nobody et au groupe nobody :

# chown nobody:nobody /tftpboot

Le serveur atftp

Tout d'abord, installez le paquet net-misc/atftp :

# emerge net-misc/atftp

Une fois le paquet net-misc/atftp installé, il vous faudra le configurer. Si les services tftpd sont requis au démarrage de la machine, une entrée dans /etc/conf.d/local.start devra être ajoutée puisque atftp n'a pas de script init.d, ni inetd ou xinetd. Si vous souhaitez utiliser inetd ou xinetd pour contrôler le service tftpd, merci de lire leur page de manuel respectives.

Voici un exemple d'entrée pour atftpd dans /etc/conf.d/local.start.

/usr/sbin/in.tftpd -v --daemon /tftpboot

Une explication des options précédentes pour atftpd (issue de la page de manuel) :

• -v Augmente ou attribue le niveau de journalisation. Le nombre d'arguments augmentera d'autant la valeur actuelle. Par défaut, c'est LOG_NOTICE, voir dans la page de manuel syslog(3) pour le niveau de journalisation. Les valeurs peuvent aller de 0 (LOG_EMERG) à 7 (LOG_DEBUG).
• --daemon Démarre comme un démon. Ne pas utiliser cette option si atftp est démarré par le biais d'inetd ou de xinetd.

Pour plus d'options, consultez le manuel man 8 atftpd.

Le serveur netkit-tftp

Tout d'abord, installez le paquet net-misc/netkit-tftp :

# emerge net-misc/netkit-tftp

Ensuite, installez sys-apps/xinetd s'il n'est pas déjà présent. Une fois les paquets netkit-tftp et sys-apps/xinetd installés, netkit-ftp doit être configuré. netkit-tftp a besoin d'être démarré depuis xinetd. Cependant, il ne fournit pas d'exemple de script. Un exemple du fichier xinetd est fourni ci-dessous :

service tftp
{
    protocol        = udp
    port            = 69
    socket_type     = dgram
    wait            = yes
    user            = nobody
    group           = nobody
    server          = /usr/sbin/in.tftpd
    server_args     = /tftpboot
    only_from       = 10.0.1.0
    disable         = no
}

Voici une explication des options précédentes qui peuvent être changées :

• user : l'utilisateur sous lequel les requêtes in.tftp sont manipulées.
• group : le groupe sous lequel les requêtes in.tftpd sont manipulées.
• server_args : le répertoire racine pour le démon TFTP depuis lequel les fichiers sont servis.
• only_from : indique à xinetd quels sont les hôtes à autoriser pour les connexions TFTP.

De plus amples informations sur les fichiers de configuration de xinetd peuvent être trouvées dans le manuel man 5 xinetd.conf.

Si xinetd est démarré vous devez lui envoyer le signal HUP pour qu'il relise ses fichiers de configuration :

# /bin/killall -HUP xinetd

Si xinetd n'est pas démarré, démarrez-le avec la commande init.d :

# /etc/init.d/xinetd start

Pour plus d'informations, consultez le manuel man 8 in.tftpd.

Le serveur tftp-hpa

Tout d'abord, installez le paquet tftp-hpa :

# emerge net-misc/tftp-hpa

tftp-hpa est fourni avec un script init.d et son fichier de configuration associé pour conf.d. Assurez-vous que INIITFTPD_PATH et INITFTP_OPTS dans /etc/conf.d/in.tftpd correspondent avec les valeurs ci-dessous :

INTFTPD_PATH="/tftpboot"
INTFTPD_OPTS="-s -v -l ${INTFTPD_PATH}"

Le serveur TFTP peut être démarré via le script init.d :

# /etc/init.d/in.tftpd start

Pour plus d'informations, consultez le manuel man 8 tftpd.

3.  Préparer une image tftpboot utilisable par le client

Assurez-vous d'avoir l'image que vous voulez utiliser avec netboot. Vérifiez votre miroir local distfiles pour l'image appropriée. Nous supposerons que vous avez décidé de démarrer en utilisant l'image gentoo-sparc64-20100128.tftpboot.

Une fois que vous avez l'image, copiez la dans /tftpboot :

# cp gentoo-sparc64-20100128.tftpboot /tftpboot
# chmod 644 /tftpboot/gentoo-sparc64-20100128.tftpboot

Maintenant, lorsque le client netboot émettra des requêtes TFTP, il cherchera un fichier qui est le nombre hexadécimal correspondant à son adresse IP et, sur certaines plates-formes, avec une extension .ARCH.

Pour notre adresse IP exemple, 10.0.1.15, regardons son équivalent en hexadecimal :

# printf "%.2X%.2X%.2X%.2X\n" 10 0 1 15

decimal       10  0   1   15
hexidecimal   0a  00  01  0f

Pour l'exemple du client netboot, il va essayer de récupérer un fichier nommé 0a00010f lorsqu'il démarrera via tftp.

Si vous êtes vraiment vraiment feignant (comme moi), vous pouvez tenter un netboot sur le client pour obtenir le nom du fichier que le client réclame dans les fichiers de journalisation du server netboot.

Assurez-vous que les services rarpd et tftpd que vous aviez choisis sont démarrés. Ensuite, démarrez la machine comme décrit dans Démarrer le client en netboot.

Le client va sembler s'arrêter après que la commande boot net soit effectuée. Alors, sur le serveur netboot, vérifiez que les fichiers de journalisation du système contiennent une entrée dans in.tftpd.

Un exemple d'entrée d'un serveur netboot utilisant syslogd et tftp-hpa ressemble à :

Jan  3 22:48:59 stargazer in.tftpd[8368]: RRQ from 10.0.1.15 filename 0a00010f

Le nom de fichier est visible juste après « filename » dans la ligne de journalisation, qui est dans notre cas : 0a00010f.

Pour conserver une trace de l'image netboot que vous utilisez et permettre à plusieurs machines d'utiliser la même image netboot, vous pouvez utiliser un lien symbolique afin de créer un fichier ayant pour nom la valeur décimale désirée. Pour notre exemple d'un client SPARC64 et l'image gentoo-sparc64-20100128.tftpboot, utilisez la commande suivante :

# /bin/ln -s /tftpboot/gentoo-sparc64-20100128.tftpboot \
/tftpboot/0a00010f

Maintenant, tout doit être configuré correctement pour le netboot !

4.  Démarrer le client par le netboot

Dans l'OpenBoot PROM (OBP) de votre machine SPARC, entrez la commande :

ok boot net

Autre méthode pour certaines machines :

ok boot net-tpe

Cela va initialiser le processus de démarrage par le réseau. Une chaîne de caractères de chiffres en hexadécimal devrait apparaître, qui changera. Lorsque l'image aura fini de se charger, le noyau prendra le relais et entamera le processus de démarrage du système d'exploitation. Dans le cas de notre image d'installation pour SPARC64, vous aurez alors une invite de commande shell, à partir de laquelle vous pourrez commencer avec le processus d'installation.

5.  Problèmes récurrents

Construire les logiciels prérequis

Si le serveur netboot est un système Gentoo Linux et que vous avez rencontré des problèmes après l'installation des paquets rarpd et tftpd, vérifiez dans les forums Gentoo et dans le bugzilla Gentoo pour voir si le problème a déjà été identifié par une autre personne. Si ce n'est pas le cas ou si les solutions rencontrées ne fonctionnent pas, merci de créer un nouveau rapport de bogue.

J'ai rencontré des problèmes avec la commande boot net, qui semble se bloquer.

C'est probablement parce que le fichier que votre système essaye de charger sur le serveur tftpboot n'est pas disponible. Sur un système SPARC, vous devriez voir les lignes suivantes :

Rebooting with command: boot
Boot device: net  File and args:

Vérifiez encore une fois que le fichier nécessaire pour votre client existe vraiment dans /tftpboot. Vous pouvez vous assurer de cela en regardant dans les fichiers de journalisation du système. De plus, une fois que le fichier existe, le client essayera de le charger. Parfois, quand le fichier manquait au départ, il se bloquera en chargeant le fichier dès qu'il apparaîtra. Pour résoudre cela, retournez simplement à l'invite de commande OBP et lancez la commande boot net une nouvelle fois. Le client devrait désormais commencer à charger l'image tftpboot et démarrer sur le système d'exploitation.

J'essaye de démarrer par le netboot, mais tout ce que je vois, c'est des messages « Timeout waiting for ARP/RARP packet ».

Cela peut venir de plusieurs choses :

1. Assurez-vous que l'entrée dans /etc/ethers existe pour le client en question. Si l'adresse MAC est incorrecte et/ou si le serveur netboot ne peut pas résoudre le nom du client, il ne pourra répondre à ses requêtes.
2. Vérifiez que le hub ou switch réseau entre le serveur netboot et le client est connecté de manière à laisser passer librement le trafic RARP. Si la requête du client ne peut atteindre le serveur et vice-versa, alors le client ne pourra pas continuer.
3. Personne ne répond aux requêtes RARP parce qu'aucun service n'écoute. Vérifiez que le serveur rarpd est prêt et en fonctionnement.
4. Le client pense qu'il n'y a pas de lien entre son interface réseau et le hub/switch réseau sur lequel elle est connecté. Vérifiez que l'interface réseau et le port sur le hub/switch réseau ont bien une lumière allumée. Si la lumière de lien est allumée, vérifiez que la configuration de tpe-link-test? est dans l'OBP avec la commande : printenv tpe-link-test?. Vous devriez avoir une réponse du genre tpe-link-test? false true. La première colonne représente le nom du paramètre, la seconde la valeur actuelle pour ce paramètre et la troisième indique la valeur par défaut de celui-ci. Dans notre exemple, vous pouvez voir que la valeur par défaut est « false », ce qui signifie que le client ne vérifie pas si le client et le hub ou switch réseau peuvent dialoguer avant d'effectuer une requête RARP. C'est souvent ce point qui pose problème.

Pour changer la valeur de tpe-link-test? dans l'invite de commande, tapez la commande suivante :

ok setenv tpe-link-test? true
tpe-link-test? =      true

Cela indique que la valeur de tpe-link-test? est maintenant « true ». Essayez maintenant de démarrer de nouveau avec le netboot.

Ce document est protégé par la licence Creative Commons : Paternité - Partage des Conditions Initiales à l'Identique 2.5.