Cet article montrait comme mettre en place et utiliser gPXE : http://monorailc.at/cms/?d=2014/11/02/19/23/12-boot-pxe
Seulement, gPXE est un peu ancien et a été remplacé par iPXE, qui apporte des fonctionnalités en plus.
Mise a jour
On remplace le fichier undionly.kpxe situé sur le serveur par celui d'iPXE, et on modifie quelques lignes de la configuration du serveur DHCP.
Jusque là, ça fonctionne de la même façon que gPXE.
Menus
L'intérêt est de pouvoir afficher un menu nativement (sans PXELinux), qui permet de booter plusieurs OS différents.
Pour cela, on va modifier le fichier boot.gpxe présent sur le serveur, et ajouter les images que l'on veut booter.
Le menu est au debut du fichier et commence par le mot clé menu, suivi d'un choix par ligne commençant par item, un label, puis le nom affiché à l'écran.
menu
item shell iPXE shell
item dsarge Debian Sarge NFS
item dsqueeze Debian Sqeeze NFS
item dos DOS
item memtest Memtest86+
choose --default dsqueeze --timeout 5000 target && goto ${target}
La dernière ligne donne le choix par défaut et l'action a faire une fois une option choisie.
Linux
Avec Linux, on peut charger directement un noyau et une initrd. :dsqueeze
kernel http://192.168.3.3/pxe/vmlinuz-squeeze ip=:::::eth0:dhcp root=/dev/nfs nfsroot=192.168.3.3:/media/stuff/chroot/nfsroot/ panic=10 ro ipv6.disable=1
initrd http://192.168.3.3/pxe/initrd.img-squeeze
boot
La première ligne correspond au choix du menu, les deux suivantes chargent le noyau et son initrd, en leur passant des parametres, et la dernière ligne donne l'ordre de booter sur ce qui vient d'être chargé.
DOS
Le plus simple est d'utiliser une image de disquette ou de CD suffisament petite pour rentrer entièrement dans la mémoire de la machine.
Exemple
J'ai filmé un PC sans disque bootant Debian par iPXE, sans autre périphérique bootable que sa carte réseau (avec un firmware gPXE chargé dans le BIOS).
Il peut arriver à tout le monde de vouloir mettre à jour un bios, et de le rater, même si c'est de plus en plus difficile.
Ce bricolage fonctionne avec toutes les cartes mères qui utilisent des mémoires EEPROM montées sur un socket.
Il faut récupérer une puce compatible avec celle équipant la carte-mère d'origine, utilisant les mêmes pins, les mêmes tensions de service et d'écriture/effacement, et une taille supérieure ou égale.
Dans mon cas, j'utilise une carte-mère MSI MS6147 (Chipset Intel BX, slot 1), qui a une EEPROM Winbond W29C020-12 montée dans un socket DIL. La puce de remplacement est une Macronix MX29F002T trouvée sur une carte mère HS.
Pour être sûr de la compatibilité entre ces deux puces, il faut vérifier le contenu de leurs datasheets :
DIL/DIP-32 package
5V operation : read, write, erase
256k × 8bits
Les temps d'accès n'ont pas l'air de poser problème.
Sauvegarde du BIOS
Avant tout, on arrête le pc, et on utilise un tournevis plat pour enlever l'EEPROM d'origine. Il faut bien faire attention à ne pas abimer la carte mère avec le tournevis, ni plier les pattes de l'EEPROM.
Ensuite, on pose la carte mère horizontalement et on pose la puce d'EEPROM sur son socket. Une fois le pc démarré et le système d'exploitation chargé, on va sauvegarder le contenu de l'EEPROM dans un fichier.
Ensuite, on enlève la puce de son socket (sans tournevis), et on pose sa remplaçante sur le socket.
Il est ainsi possible de flasher la seconde puce d'EEPROM avec le contenu de la première, ou même avec un contenu sans rapport (un BIOS de carte SCSI ou d'une autre carte-mère, par exemple).
Récupération
Il suffit de faire exactement pareil que pour la sauvegarde, en échangeant les deux puces.
Software
En utilisant Unix, flashrom permet de lire, effacer, écrire et vérifier de nombreuses mémoires avec de nombreux programmateurs, peu importe le contenu de la mémoire.
Les programmes livrés d'origine avec les cartes mères (awdflash, aflash ou amiflash) utilisent DOS et sont souvent limités à un type de BIOS/mémoire.
Modification de BIOS
Les BIOS des cartes mères sont fragmentés en plusieurs parties :
Bootblock : chargeur de boot, un bios "failsafe" qui va charger le vrai bios, ou le reflasher depuis un CD en cas d'échec.
Une "table de fichiers" sommaire qui va charger les différentes parties du BIOS (compressées) en mémoire au bon moment.
Le Setup : ce qui va permettre de modifier différents paramètres sauvegardés dans une SRAM.
Les "Option ROM" : des drivers de cartes réseau/graphique/SCSI.
Les Logos : des images bitmap en plein écran ou en plus petit.
Des outils comme awbedit, modbin, cbrom ou amibcp, pour DOS ou Windows permettent d'extraire/ajouter ou de modifier le contenu de BIOS.
Les valeurs par défaut du setup sont souvent intéressants à modifier. Il est aussi possible d'afficher certaines options cachées d'origine (parfois sans effet ou dangereuses).
S'il reste de la place libre, il est possible de rajouter des "Option ROM", ou d'enlever celles qui sont inutiles. Supprimer les logos permet de gagner facilement de la place. Il est même possible de faire fonctionner un OS minimaliste (comme DOS) directement.
Notes
Il est aussi possible d'utiliser des EPROM à UV ou OTP, ou des EEPROMs, mais avec une tension d'effacement ou d'écriture différente, tant qu'elles sont compatibles pin-à-pin. L'effacement ou l'écriture d'une EPROM ou d'une EEPROM avec une tension supérieure à celle que fournit la carte-mère sera impossible, mais sa lecture ne posera pas de problème.
Dans le cas d'une carte-mère fournissant une tension d'écriture/effacement supérieure à celle supportée par l'EEPROM, il est possible d'isoler la patte Vpp, et son effacement/écriture seront impossible, mais sans dommages.
Les cartes mères récentes utilisent des sockets PLCC, qui rendent le démontage difficile, mais il est possible de glisser une ficelle sous le socket. Les cartes mères récentes utilisent parfois des puces avec un bus parallèle 3.3V, ou série SPI ou 4bits, incompatibles entre eux.
Premier boot
Au premier boot, Alphabios chargeait le noyau d'une redhat, mais le système de fichiers est abimé et plusieurs périphériques ne sont pas détectés. J'ai décidé d'utiliser SRM et d'installer une redhat sur un autre disque dur.
Activation de SRM
La procédure pour passer d'AlphaBIOS à SRM n'est pas forcément évidente :
Appuyer sur F2 au démarrage de la machine (chargement d'AlphaBIOS)
Choisir CMOS Setup
Choisir Advanced CMOS Setup avec F6
Changer Console Selection d'AlphaBIOS à OpenVMS Console (SRM)
Sauvegarder avec F10
Redémarrer en coupant l'alimentation
Il est aussi possible de repasser de SRM à AlphaBIOS en tapant au prompt de SRM : set os_type NT
Boot sur CD
La première étape est de trouver le nom du lecteur cdrom avec la commande show device >>> show device
dka0.0.0.15.0 DKA0 RZ1CF-BF 1614
dqb0.0.1.13.0 DQB0 COMPAQ CDR-8435 0013
dva0.0.0.0.0 DVA0
ewa0.0.0.9.0 EWA0 08-00-2B-86-26-5B
pka0.7.0.15.0 PKA0 SCSI Bus ID 7 5.57
Ici, la première lettre correspond au type de périphérique : disque, ethernet, ..., la seconde correspond au périphérique (SCSI, IDE, floppy), la troisième au canal/contrôleur, et la dernière à l'ID du périphérique.
Ainsi dqb0 est un disque sur le 2nd canal IDE. D'après son nom, on remarque que c'est un lecteur de CD.
SRM interprète les systèmes de fichiers (à travers aboot), par conséquence, il faut aussi connaître le chemin des fichiers à charger : le noyau et l'initrd (si-nécessaire).
On peut booter RedHat 6.2 avec la commande suivante : boot dqb0 -file /kernels/generic.gz -flags "initrd=/images/ramdisk.img root=/dev/hdc"
Ou bien pour Debian Woody : boot dqb0 -file /boot/linux -flags "root=/dev/hdc"
Partitionnement du disque
Le disque est partitionné en utilisant le disklabel d'UNIX plutôt que le MBR de DOS.
Par défaut, la slice c représente le disque entier. On va ajouter trois autres partitions :
a : 2Gio, système de fichiers /
b : 512Mio, swap
c : 18.4Gio, disque complet
d : 15+Gio, /home
Il reste à indiquer le type de chaque slice, à activer le flag de boot sur la slice a, et les formater (sauf c, évidemment).
Il faut aussi faire attention à ne pas faire commencer la première slice sur le premier secteur du disque, à priori pour laisser de la place au bootloader.
À partir de cette étape, RedHat s'installe comme sur un PC, en installant tous les paquets.
Bootloader
Avant de terminer l'installation de RedHat, il faut installer aboot sur le disque dur, avec la commande "swriteboot".
Pour booter sur le disque dur, il suffit de changer les paramètres boot_dev, boot_file et boot_osflags. Ainsi il est possible de booter directement en tapant seulement boot au prompt de SRM.
Changement de noyau
Pour une raison inexpliquée, une fois aboot installé sur le disque, il est devenu impossible pour le noyau d'origine de Redhat de détecter les disques SCSI. L'utilisation du noyau 2.2.22-generic de Debian Woody a corrigé le problème.
Il faut booter sur le cd de Debian Woody, basculer sur la console (alt + F2), puis monter la partition /, et ensuite copier le noyau présent sur le CD, pool/main/k/kernel-image-2.2.22-alpha/kernel-image-2.2.22-generic_2.2.22-2_alpha.deb, le décompresser avec ar puis tar, et enfin copier les modules dans /lib/modules/ et l'image dans /boot/ (il est nécessaire de la décompresser avec deflate ou gzip, selon la version de aboot installée).
Recompilation d'un noyau
L'USB et le réseau restent non fonctionnels.
Le contrôleur réseau est reconnu par les modules de4x5 et tulip, mais je n'ai pas réussi à les faire fonctionner.
Par contre il est possible d'ajouter une carte réseau PCI sans aucun problème, une Realtek 8139 (rtl8139 ou 8139too) a fait l'affaire.
La configuration du noyau est utilisable sur le lien précédent.
Bricolage
L'horloge système ne semble pas fonctionner correctement en 2015, en se remettant toujours en 1995. (même en la réglant dans SRM ou avec hwclock).
Une correction rapide va changer l'année à la fin du chargement d'init, en rajoutant une ligne au fichier /etc/rc.local : date $(date +%m%d%H%M2015).
L'année 2015 est à adapter manuellement (on peut aussi améliorer le script pour changer automatiquement l'année).
Hardware
Cette station de travail était déjà un monstre à sa sortie en 1998 : processeur 64bits entre 433 et 600MHz, 128Mio à 1.5Gio de ram, le tout en 1998 (les gens normaux se contentaient d'un processeur 32 bits à 300MHz et 64Mio de ram).
Carte riser : 3 PCI 32bits, 2 PCI 64bits, 3 ISA 16bits, 2 IDE, disquette, connecteur MAU (extension réseau), connecteurs game/midi/audio (extension audio).
Carte mère : 2 USB, Ports PS/2 clavier/souris, 2 Ports série RS-232 (câblage standard), Port parallèle IEEE-1284.
Carte audio : ESS 1887 intégrée à la carte riser, extension avec line-in, line-out et port midi, pas de synthétiseur midi.
Carte réseau : DC21143 intégrée à la carte riser, extension avec un PHY ethernet.
L'intérieur du boitier est très bien rangé, avec des câbles sur-mesure. Tout est fait pour que rien ne bouge ni ne vibre.
Aux premiers boots, la carte réseau et la carte scsi étaient détectées aléatoirement et le système plantait avec SRM ou pendant le chargement du noyau. Il a été nécessaire d'enlever la poussière et de nettoyer les connecteurs des slots de RAM et de la carte riser.
Le support en plastique noir en forme d'équerre est indispensable lorsque le boitier est à l'horizontale, pour éviter à la carte mère de plier sous son propre poids.
Les barrettes de SDRAM sont clairement impressionnantes (256Mio, en 1998) :
Les cartes système sont assez encombrantes et denses :
Il faut aussi remarquer que toutes les entrées-sorties sont protégées par des transceivers isolés.
Hardware
Cette station de travail fait partie du "bas de gamme" de Sun en 2002.
La solution pour avoir une station de travail "cheap" était d'utiliser beaucoup de pièces de PC.
Par rapport aux autres machines Sun, on remarque que tous les connecteurs sont "standard", avec un clavier et une souris à brancher en USB, et un écran en VGA.
Il n'y a que le CPU et la carte mère faits sur-mesure par Sun :
On peut voir que pas mal de capas sont à changer... Mais ça ne semble pas rendre la machine instable.
La RAM est de la SDRAM ECC unbuffered (commune sur certains serveurs et stations de travail de 1999 à 2003), le disque dur et le lecteur CD-ROM sont en IDE et l'alimentation est au format ATX, compatibles avec touts les PC de l'époque.
Carte Mère : 4 USB, 2 Firewire IEEE-1394, Port série RS-232 (câblage standard), VGA, Port parallèle IEEE-1284, 4 jacks audio.
Software
La bête fonctionne avec Sun Solaris 8 (SunOS 5.8), un UNIX des années 90 conçu pour les stations de travail.
Au démarrage, la machine effectue un self-test (POST), puis charge le noyau, démarre tous les services (Consoles, SSH, affichage X11). En moins d'une minute on arrive à un menu qui permet de s'identifier.
En ayant créé un utilisateur, la machine utilise CDE (Common Desktop Environment), qui ressemble étrangement à XFCE et aux premières versions de KDE, qui l'ont ouvertement copié.
On peut utiliser le navigateur web Netscape, taper quelques commandes dans un terminal, mais pas grand chose de plus, puisque la machine semble avoir été "nettoyée" de tout programme autre que l'OS.
On peut avoir un peu d'informations sur la machine et le système d'exploitation : # uname -a
SunOS unknown 5.8 Generic_108528-29 sun4u sparc SUNW,Sun-Blade-100
Avec SunOS 5.8 sur un processeur sparc et une machine Sun Blade 100
# psrinfo -v
Status of virtual processor 0 as of: 08/21/15 14:13:43
on-line since 08/21/15 12:07:44.
The sparcv9 processor operates at 502 MHz,
and has a sparcv9 floating point processor.
Ce qui est un peu plus clair sur le processeur (SPARC IIe, 64-bit RISC, 256Kio de cache).
On cherche des informations sur les disques : # swap -s
total: 25592k bytes allocated + 8648k reserved = 34240k used, 2546648k available
bash-2.03# swap -l
swapfile dev swaplo blocks free
/dev/dsk/c0t0d0s1 136,1 16 4195280 4195280
On voit que le disque est partitionné "à la UNIX", avec une hiérarchie contrôleur ; target (SCSI ID) ; disque ; partition (slice).
On a donc 1.9Go pour la racine du système (/) et 15Gio pour les données des utilisateurs.
Pour le reste des informations, la commande qui est la plus bavarde est dmesg, qui donne les informations du système en chargeant le noyau, et les informations de chaque périphérique en chargeant leurs pilotes.
Configuration
Avec beaucoup de chance, un post-it contenant le mot-de-passe root était collé sous le capot.
Seulement, au premier boot, la souris en USB ne fonctionne pas avec X11, ni avec la console, mais ça m'a permis de découvrir que Solaris est très différent des BSD et de Linux.
Il a suffit de se connecter en SSH pour configurer la machine :
Utilisation du BASH au lieu du KSH (on y gagne la complétion automatique et la mémoire des commandes précédentes)
Configuration du réseau : DHCP était déjà activé, mais les serveurs DNS étaient à renseigner dans /etc/resolv.conf
Ajout d'un utilisateur : commande useradd
Tentative de configuration de la souris
Il a été possible d'identifier le nom du serveur graphique avec la commande /usr/ucb/ps -auxww
Qui nous donne (entre 45 processus) les programmes dt et Openwin, situés dans /usr/dt/ et /usr/openwin, mais dont la configuration est à copier de /usr/openwin/etc/ (configuration par défaut) vers /etc/openwin/server/etc (configuration modifiée).
On remarque que la souris devrait être mappée comme /dev/mouse. En réalité, elle est avec le clavier dans /dev/usb/hid{0,5}.
On peut tenter de modifier le lien /dev/mouse pour pointer vers la souris ou de modifier le fichier /etc/openwin/server/etc/OWconfig, sans succès (soit X crash, soit la souris n'est pas fonctionnelle). C'est bêtement en essayant une autre souris qu'on arrive à un un système fonctionnel (la mollette ne fonctionne pas, mais ce n'est pas critique).
Compatibilité
Souris fonctionnelles : Logitech Premium Wheel Mouse M-BT58 (2005), Microsoft Optical Mouse Blue USB (2005)
Souris non-fonctionnelle : Microsoft Comfort Mouse 3000 (2011)
Il est possible de booter une machine sans disque dur, ni lecteur cd (ni même de clé usb).
Beaucoup de cartes réseaux (j'utilise des 3com 3C905CX) ont une EEPROM qui contient un chargeur de boot réseau.
Il y a donc plusieurs parties:
Serveur DHCP
Serveur TFTP
Image(s) PXE
Boot du noyau
Il faut d'abord configurer le serveur DHCP, pour qu'il donne les paramètres de boot à la machine qui va le lui demander. Pour l'instant, je n'ai pas réussi à configurer dnsmasq pour avoir un serveur tftp sur une autre machine que le serveur dhcp, alors j'ai adapté...
Comme le bootloader embarqué dans la carte va charger un autre bootloader (undionly.kpxe), qui lui, va charger le noyau, on va interroger le serveur DHCP deux fois. Ces deux accès sont distingués par le flag "userclass"
dnsmasq est tellement bien fait qu'il a aussi un serveur tftp embarqué. Il suffit de rajouter les lignes suivantes dans le fichier /etc/dnsmasq.conf
enable-tftp
tftp-root=/tmp
Comme le routeur a peu de flash, j'ai mis la raçine du serveur tftp dans /tmp (tmpfs) pour éviter les problèmes. Mais il faut rajouter un script qui télécharge l'image au boot de la machine. undionly.kpxe est une image de gPXE qui permet de booter sur n'importe quel protocole (même http).
Pas mal d'hébergeurs de pub n'hébergent que de la pub sur le même hostname. Du coup, on ne perd pas grand chose à filtrer leurs domaines.
En même temps, quasiment tous les routeurs ont un cache DNS, mes routeurs (OpenWRT) utilisent dnsmasq.
Dans la config de dnsmasq, /etc/dnsmasq.conf, on fait des redirections arbitraires avec l\'instruction suivante : address=/hostname/adresse
À grande échelle, on arrive à une petite commande : for i in $(cat list); do echo "address=/$i/127.0.0.1" >> /etc/dnsmasq.conf ; done
Il ne suffit plus que de redémarrer le service dnsmasq, et ça fonctionne.
Pour trouver la liste, on peut récupérer les listes d'adblock et les trier (les bouts d'url et toutes les regexp n'intéressent pas dnsmasq). On a aussi des listes toutes faites comme ici.
Pour upgrader la liste, on peut rajouter ce qui manque : for i in $(cat nouvelle_liste); do if !(grep -q dnsmasq.conf) ; then echo >> dnsmasq.conf ; fi; done
Avoir un serveur @home, ce n'est pas très compliqué, ni très coûteux, et c'est aussi pratique que formateur.
Utilisation
Un serveur "de maison" va servir à partager des fichiers entre les différentes machines, et à pouvoir les rendre disponibles depuis internet, et éventuellement héberger plus de services.
Pour ça, il y a quelques contraintes :
Le serveur doit rester connecté et allumé quand on va y accéder
Le serveur doit être fiable, aussi bien au niveau logiciel que matériel
Le serveur ne doit absolument pas rendre toutes vos données publiques
Bien sûr, pourquoi ne pas utiliser d'autres services, "gratuits" ? Parfois on peut être rebuté par des conditions d'utilisation trop restrictives trop de publicité, des droits d'auteur non respectés, ou même lorsqu'il n'existe pas de service équivalent gratuit et fiable.
Hardware
On va avoir un serveur qui va être allumé pendant de longues périodes, avec de longues périodes d'inactivité, et d'activité intense. Là aussi, on va imposer quelques contraintes :
Machine peu-chère
Faible consommation électrique
Faible bruit
Matériel fiable
Grande capacité de stockage
Le premier critère impose directement une machine d'occasion ou de récupération. Les second, troisième et quatrième critères renvoient vers les machines d'entreprise (HP Compaq, Dell Optiplex), très répandues.
En s'attardant sur la fiabilité et le bruit, on peut remarquer que ces machines sont souvent usées après une dizaine d'années : les premiers composants usés sont mécaniques : ventilateurs (encrassés, et roulements usés), et disques durs.
J'ai ainsi récupéré un IBM PC-300GL de 2000 en 2007.
Nettoyage complet de la machine, au compresseur
Changement des ventilateurs (utilisation de patins anti-vibration)
Upgrades basiques
Changement du disque dur (8Go -> 320Go)
Réglages dans le BIOS : activation du reboot en cas de coupure de secteur, désactivation du test du clavier
Ainsi, on a un serveur coûtant 100€ (pièces neuves), qui consomme peu (40~50W à la prise), quasiment inaudible et fiable (plusieurs années sans interuption). Par contre, le matériel n'est pas tout jeune, mais on verra que ça ne pose pas tant de problèmes que ça.
Upgrades
2007 : Disque dur 8Go IDE -> 320Go IDE, 64Mio de RAM -> 256Mio, ventilateurs
2011 : Contrôleur SATA, carte réseau Gigabit, disque dur 320Go IDE -> 2To SATA
2016 : Disque dur 2To (remplacement avant panne), remplacement
OS
Comme il faut un système d'exploitation peu cher, fiable et facile à maintenir, le choix se porte tout de suite vers Linux.
J'ai choisi la distribution Debian, pour son installation et sa maintenance automatisable.
Comme on a un serveur, il ne faut pas perdre de vu quelques rudiments :
Pas d'interface graphique
Partitionnement du/des disques séparant les données du système
Une interface graphique consomme des ressources système, pas illimitées avec ce genre de machine, rajoute des problèmes de sécurité potentiels, et ne sert à rien sur un serveur (puisqu'on a pas de clavier ni d'écran).
Le schéma de partitions suivant :
sda1 : /boot ~100Mo
sda5 : swap 200~500Mo
sda6 : / 2~5Go
sda7 : /stuff (tout le reste)
La partition /boot pourra être montée en lecture seule pour éviter les problèmes. La séparation des documents et du système facilite grandement la maintenance (changement de disque dur, sauvegardes et restorations...).
Services
On va mettre quelques services :
SSH : administration et utilisation à distance (et transferts de fichiers)
Apache : serveur web "usine à gaz"
lighttpd : serveur web "light"
vsftpd : serveur FTP : transferts de fichiers
SaMBa et NFS : partage de fichiers en réseau local
On peut y rajouter quelques uns, comme un serveur DNS avec bind ou dnsmasq, l'extension PHP, des bases de données mySQL, un serveur mail...
Pour une machine connectée h24, ça peut être très utile pour partager des torrents (torrentflux) ou pour rester connecté sur IRC ou jabber (ssh + screen + client im).
Configuration
On va connecter le serveur au réseau local, pour celà, il faut configurer le serveur avec une adresse statique, sur la même plage que le routeur, hors de sa réserve DHCP. Le serveur est ainsi utilisable en réseau local.
On va configurer les routes et le DNS:
Mais comme ce n'est pas persistant, il faut le forcer dans /etc/network/interfaces. Le serveur peut maintenant accéder à internet.
Ensuite, on configure le routeur pour qu'il redirige les ports voulus de l'adresse publique (internet) vers l'adresse privée (réseau local). Les ports 21 (FTP), 22 (SSH), 80 (HTTP), 433 (HTTPs) sont utiles. Mais attention, il y a beaucoup d'attaques sur les protocoles FTP et SSH, assurez-vous de bien les avoir configurés avant de les rendre publics, et dans certains cas (brute-force ou firewall "fasciste"), il est utile de changer les ports (mettre SSH sur le port 443 permet d'accèder à son serveur depuis n'importe où.
2015-10-15 - No comments
Tags de l'article : info, PXE, réseau, vieilleries
