Si votre machine est connectée à un réseau local, vous pouvez l'amorcer directement à partir d'une autre machine de ce réseau en utilisant TFTP. Pour cela, les fichiers d'amorçage doivent être placés à un endroit spécifique de cette machine et celle-ci doit savoir amorcer votre machine.
Vous devez configurer un serveur TFTP et, pour beaucoup de machines, un serveur DHCP, un serveur RARP ou un serveur BOOTP.
Le protocole de recherche des adresses inverses (Reverse address Resolution Protocol ou RARP) indique à votre client l'adresse IP qu'il doit utiliser pour lui-même. Une autre solution est d'utiliser le protocole BOOTP. BOOTP est un protocole IP qui indique à un ordinateur quelle est son adresse IP et lui dit où obtenir sur le réseau une image d'amorçage. Le protocole DHCP (« Dynamic Host Configuration Protocole », Protocole de configuration dynamique des hôtes) est une extension bien plus flexible de BOOTP (et respectant la compatibilité ascendante). Certains systèmes ne peuvent être configurés que par DHCP.
Le protocole trivial de transfert de fichiers (Trivial File Transfert Protocol, TFTP) est utilisé pour transférer l'image d'amorçage au client. Théoriquement, tout serveur sur les plateformes qui implémentent ces protocoles peut être utilisé. Dans les exemples qui vont suivre, on donnera les commandes pour SunOS 4.x, SunOS 5.x (mieux connu sous le nom de Solaris) et GNU/Linux.
Pour configurer RARP, il vous faudra connaître l'adresse Ethernet du client
(c'est-à-dire, l'« adresse MAC »).
Si vous n'avez pas cette donnée, vous pouvez
l'extraire des messages d'amorçage initiaux de l'OpenPROM,
utiliser la commande OpenBoot .enet-addr ou
amorcer en mode « secours » (p. ex. à partir de la disquette
de secours) et utiliser la commande
/sbin/ifconfig eth0.
Pour les systèmes avec un noyau Linux 2.4 ou 2.6, ou les systèmes Solaris/SunOS,
il faut utiliser le programme rarpd.
Vous devez vous assurer que les adresses matérielles Ethernet pour les clients
sont listées dans la base de données « ether » (soit dans le fichier
/etc/ethers soit via NIS/NIS+) et dans la base de
données « hosts ». Ensuite, vous devez lancer le démon RARP.
Pour la plupart des systèmes Linux et SunOS 5 (Solaris 2), essayez la commande
(en tant que superutilisateur) : /usr/sbin/rarpd -a.
Pour d'autres systèmes Linux, essayez /usr/sbin/in.rarpd -a.
Pour SunOS 4 (Solaris 1), essayez /usr/etc/rarpd -a.
Il existe deux serveurs BOOTP pour GNU/Linux, bootpd CMU
et dhcpd ISC ; le second est en fait un serveur DHCP.
On peut trouver ces serveurs dans les paquets bootp et
dhcp3-server dans Debian GNU/Linux.
Pour utiliser bootpd CMU, vous devez commencer par
décommenter (ou ajouter) la ligne adéquate dans
/etc/inetd.conf. Dans Debian GNU/Linux, vous pouvez tout
simplement lancer update-inetd --enable bootps suivi
de /etc/init.d/inetd reload pour le faire. Au cas où le serveur
BOOTP ne fonctionnerait pas sous Debian, la ligne en question devrait ressembler à :
bootps dgram udp wait root /usr/sbin/bootpd bootpd -i -t 120
Maintenant, vous devez créer le fichier /etc/bootptab qui
utilise le même genre de format familier et cryptique que les bons vieux
fichiers BSD printcap, termcap et
disktab. Voyez la page de manuel de
bootptab pour d'autres informations.
Pour bootpd CMU, il sera nécessaire d'obtenir l'adresse
matérielle (MAC) du client. Voici un exemple du fichier
/etc/bootptab :
client:\ hd=/tftpboot:\ bf=tftpboot.img:\ ip=192.168.1.90:\ sm=255.255.255.0:\ sa=192.168.1.1:\ ha=0123456789AB:
Vous devrez changer au moins l'option « ha » qui spécifie l'adresse matérielle du client. L'option « bf » spécifie le fichier que le client devra récupérer par TFTP ; cf. Section 4.3.5, « Mettre les images TFTP en place » pour plus de précisions.
En comparaison, configurer BOOTP avec dhcpd ISC est très
facile parce qu'il traite les clients BOOTP comme des clients DHCP légèrement
spéciaux. Certaines architectures requièrent une configuration complexe pour
amorcer les clients par BOOTP. Si la vôtre en fait partie, lisez la
Section 4.3.3, « Configurer un serveur DHCP ». Dans ce cas vous pouvez simplement ajouter la directive
allow bootp au bloc de configuration pour le
sous-réseau contenant le client, puis redémarrer dhcpd
avec /etc/init.d/dhcpd3-server restart.
Il existe un serveur DHCP libre, dhcpd ISC. Pour
Debian GNU/Linux, le paquet dhcp3-server est recommandé.
Voici un exemple de fichier de configuration (habituellement
/etc/dhcp3/dhcpd.conf) :
option domain-name "example.com";
option domain-name-servers ns1.example.com;
option subnet-mask 255.255.255.0;
default-lease-time 600;
max-lease-time 7200;
server-name "servername";
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.200 192.168.1.253;
option routers 192.168.1.1;
}
host clientname {
filename "/tftpboot/tftpboot.img";
server-name "servername";
next-server servername;
hardware ethernet 01:23:45:67:89:AB;
fixed-address 192.168.1.90;
}
Dans cet exemple, le serveur servername
joue le rôle de serveur DHCP, serveur TFTP et passerelle réseau. Vous
devrez certainement changer les options concernant le nom de domaine
ainsi que le nom du serveur et l'adresse matérielle du client. L'option
filename devrait être le nom du fichier extrait
par TFTP.
Après avoir modifié le fichier de configuration de dhcpd,
relancez dhcpd par
/etc/init.d/dhcpd3-server restart.
Pour faire fonctionner le serveur TFTP, vous devez vous assurer au préalable
que tftpd est activé. Ce dernier est généralement activé
grâce à la ligne suivante dans /etc/inetd.conf :
tftp dgram udp wait root /usr/sbin/tcpd in.tftpd /tftpboot
Les paquets Debian, quand ils sont installés, placent correctement cette ligne.
Les serveurs TFTP utilisaient habituellement le répertoire /tftpboot pour
stocker les images. Cependant les paquets Debian GNU/Linux se servent d'autres répertoires
pour obéir au standard sur l'organisation des fichiers.
Par exemple, tftpd-hpa utilise par défaut
/var/lib/tftpboot. Vous aurez à modifier les exemples de cette section.
Lisez le fichier /etc/inetd.conf et mémorisez le répertoire
passé en paramètre à in.tftpd
[2] ; vous en aurez besoin ultérieurement.
Si vous avez dû modifier /etc/inetd.conf, vous devrez le
signaler au processus inetd. Sur une machine Debian,
lancez /etc/init.d/inetd reload ; sur les autres
machines, retrouvez le numéro de processus de inetd et
exécutez la commande
kill -HUP .
inetd-pid
Ensuite, placez les images TFTP dont vous avez besoin (décrites dans la
Section 4.2.1, « Où trouver les fichiers d'installation ? ») dans le répertoire des images d'amorçage
de tftpd. Généralement, ce répertoire s'appelle
/tftpboot. Vous aurez à faire un lien depuis ce fichier
vers le fichier que tftpd utilisera pour amorcer le client.
Malheureusement, le nom du fichier est déterminé par le client
TFTP et il n'y a pas vraiment de standard.
Certaines architectures SPARC ajoutent au nom de fichier la sous-architecture, comme
« SUN4M » ou « SUN4C ». Ainsi, si votre sous-architecture système
est SUN4C et que son adresseIP est 192.168.1.3, le nom de fichier sera
C0A80103.SUN4C. Cependant, pour certaines architectures, le fichier
recherché est simplement client-ip-en-hex.
Pour déterminer facilement ce nom et en supposant que l'adresse IP est
10.0.0.4, lancez un interpréteur de commandes et faites :
$ printf '%.2x%.2x%.2x%.2x\n' 10 0 0 4
Il suffira de mettre les lettres en majuscule et d'ajouter le nom de la sous-architecture pour obtenir le nom du fichier.
Si tout a été fait correctement, la commande boot net
depuis l'OpenPROM devrait charger l'image. Si l'image n'est pas trouvée,
vérifiez dans les journaux du serveur tftp sous quel nom elle a été demandée.
Vous pouvez aussi forcer certains systèmes SPARC à rechercher un nom de
fichier spécifique en l'ajoutant à la fin de la commande d'amorçage de
OpenPROM, p. ex. boot net my-sparc.image.
Ce fichier doit bien sûr être présent dans un répertoire connu du serveur TFTP.
[2]
Toutes les alternatives à in.tftpd disponibles dans Debian
doivent enregistrer les requêtes TFTP dans le journal du système. Quelques unes
acceptent une option -v qui augmente la quantité d'informations
enregistrées. En cas d'erreur d'amorçage, il est recommandé de consulter ces enregistrements
pour rechercher les causes des erreurs.