OpenBSD sur une sparc32 - installation réseau

Introduction

Le contexte: récupération d'une vielle Sun SS20: c'est aujourd'hui une machine obsolète, mais qui reste d'une grande qualité. Beaucoup de plaisir pour bien peu d'argent !

On commence par quelques aventures avec le matériel, histoire de fouiner un peu avant les choses sérieuses, installer une version d'OpenBSD par le réseau sur cette nouvelle meeEeeEeEEErveille.

Spécificiations matérielles

Sun SS20 - Sparc Station 20 ; processeur 50 Mhz. ; disque 1 Go SCSI, carte Ethernet 10Mb, sbus. Pas d'écran, de terminal ni de clavier.Ça fait rêver. On va tenter un boot par le réseau (net-boot) en surveillant tout cela via le port série, connecté à un pc portable.

Au sujet du cable série: la sun SS20 dispose d'un port série 25 femelle, il lui faut donc un 25 mâle, à connecter au port série 9 mâle pécé (il faut donc sur le cable un 9 femelle). Soit:

   SS20   |-----------------|   P.C.
        25 mâle        9 femelle

note: cette filasse est assez difficile à trouver, mais elle se bricole, au pire, assez facilement à partir d'autres cables qu'on trouve, assemble et désosse.

Découverte et premiers pas de la bête

Bon, histoire d'améliorer le google rank de cette page, parlons de nos premiers émois, en tournant autour de la station quelques jours, avec respect. Laissons-la booter, pour entendre sa poésie même si on ne sait rien d'elle pour le moment.

L'application minicom a d'abord été utiliées pour controler le boot de la sun depuis le port série d'un pc, auquel est connectée la sun, mais cela n'a pas bien marché pour des raisons restées assez obscures, on parlera donc ici du logiciel cu (du paquet uucp) qui a finalement été préféré et cela marche maintenant très bien. Voici des traces après avoir allumé la sun:

$ cu -s 9600 -l /dev/ttyS0

ok help

ok test-all
Testing /memory@0,0
                                                                      
Testing /obio/SUNW,fdtwo@0,700000
Testing floppy disk system.  A formatted disk should be in the drive.
Recalibrate failed.  The floppy drive is either missing,
improperly connected, or defective.
Selftest failed. Return code = -1 
Testing /obio/zs@0,0
No Keyboard
Selftest failed. Return code = -1 
Testing /obio/zs@0,100000

Testing /iommu@f,e0000000/sbus@f,e0001000/ledma@f,400010/le@f,c00000

Using AUI Ethernet Interface 
 Internal loopback test -- succeeded.
 External loopback test -- Lost Carrier  (transceiver cable problem?)  
send failed.

Using TP Ethernet Interface 
 Internal loopback test -- succeeded.
 External loopback test -- Lost Carrier  (transceiver cable problem?)  
send failed.
Selftest failed. Return code = -1 
Testing /iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000/esp@f,800000

Plein de poésie donc, mais violente et engagée. Après une lente exégèse purificatrice, on comprend qu'apparemment, ethernet ne marche pas bien. On reboot, mais cette fois, on prend bien soin de lui avoir envoyé un signal BREAK lors du boot. Ah, à propos, pour lancer un break avec cu se fait, lors du démarrage, en tapant ~#.

Là, la mélodie secrète de la SS20 est bien plus harmonieuse.

$ cu -s 9600 -l /dev/ttyS0
Connected.

           SMCC SPARCstation 10/20 UP/MP POST version 3.1 (11/19/93)


CPU_#0       TI, TMS390Z50(3.x)       0Mb External cache

CPU_#1       ******* NOT installed *******
CPU_#2       ******* NOT installed *******
CPU_#3       ******* NOT installed *******


           >>>>> Power On Self Test (POST) is running .... <<<<<

SPARCstation 20 (1 X 390Z50), No Keyboard
ROM Rev. 2.15, 128 MB memory installed, Serial #7407019.
Ethernet address 8:0:20:1a:a6:00, Host ID: 727105ab.
Boot device: /iommu/sbus/espdma@f,400000/esp@f,800000/sd@3,0  File and args: 
SunOS Release 5.6 Version Generic_105181-23 [UNIX(R) System V Release 4.0]
Copyright (c) 1983-1997, Sun Microsystems, Inc.
configuring network interfaces: le0.
Hostname: musun98007
The / file system (/dev/rdsk/c0t3d0s0) is being checked.
/dev/rdsk/c0t3d0s0: 41250 files, 739256 used, 161262 free 
/dev/rdsk/c0t3d0s0: (4910 frags, 19544 blocks,  0.5% fragmentation)
The system is coming up.  Please wait.
add net default: gateway 123.456.789.123
NIS domainname is sc41
starting rpc services: rpcbind keyserv

HMmhmHMhmHMHMHMhmhmHMmhhmhmm !! ELLE PARLE ! ELLE CHANTE ! LE CHANT DU MONDE !

Le système semble rester bloqué sur starting rpc services: rpcbind keyserv ; au meme moment, un tcpdump sur le pc donne comme résultat:

tcpdump: listening on eth0
17:16:46.791504 123.456.789.123.32785 > 123.456.255.255.sunrpc:  udp 96
(DF) [ttl 1]

plein de fois. Mais plein.

Pas de doute, c'est la sun qui pleure sa maman car elle n'arrive pas à se connecter sur yp.

Cela veut dire aussi que juste avant, un break astucieusement lancé a permis d'avoir le bootloader. Bon à savoir pour la suite, faudra faire cela tout le temps.

Histoire d'espérer un boot normal après un `time-out` sur les tentatives de connexion sunrpc, on laisse la babasse mariner tranquillement pendant un gros weekend. Elle en profite pour brailler continuellement et remplir les logs du firewall avec ses tentatives de connexion permanentes (oups, pardon gentil admin). En résumé, elle refuse de booter sans ses connexions sunrpc, autrement dit, une partie essentielle du système est distante. Le système seul n'est pas autonome, donc, pas de timeout, elle s'entête, la bougresse !

Pour tenter de booter quand même, tentons un:

ok> boot -s

qui réussit, mais le système réclame le mot de passe root pour la maintenance (ou, comme toujours CTRL-D pour le processus normal de démarrage). Mot de passe qu'on ne connait pas, pour cause de récupération.

D. me conseille de faire un montage complet par nfs avec un système entièrement configuré. On repère:

ok> boot net -s

Mais il faut creuser un peu plus. Donc, dans les docs NetBSD sur le port Sparc32, on lit:

Ramdisk kernel This one is no trouble at all. Place the ramdisk kernel at the root of your nfs mountpoint, named netbsd. This ramdisk kernel contains the /dev entries and install tools. The bootloader should just load this kernel and immediately start the install tools.

Donc, si on en croit la doc (haha, pourtant, ne jamais faire, cela famous last words), cela devrait juste marcher.

Pour mémoire:

Why do you want an "installer" if you are so far, that you have a
complete system running diskless? Installing the system on a disk from
a diskless boot is easy and straightforward:

disklabel sd0 > /tmp/dl		# read in core default label
disklabel -r -R sd0 /tmp/dl	# write it to the disk
disklabel -i sd0		# and edit it. -i needs a valid

Et alors …:

newfs /dev/rsd0a
newfs ....
mount -o async /dev/sd0a /mnt	# async speeds things up during...
mount ...
tar xzpf /where/ever/your/dist/sets/are.tgz -C /mnt
tar ...
cd /mnt/dev && ./MAKEDEV all
cd /mnt/usr/mdec
../installboot ....		# works only in singe user mode
cd /mnt/etc
vi rc.conf			# look at /etc/defaults/rc.conf
vi fstab
echo sunshine > myname
echo inet 192.168.1.1 netmask 255.255.255.0 > ifconfig.le0
echo 192.168.1.254 > mygate	# or what ever you want / need
vi ...
reboot				# from disk.

Thats all. No fscking "installer" needed. p.s.
for a in /your/dist/sets/*.tgz ; do tar xzpf $a -C /mnt ; done
does the unTARing all in one line.

Bon, en fait, tout cela est bien marrant, mais changeons de jeu, car on n'a pas eu le temps de tenter ce truc, qui pourrait être convi: en gros, ca pourrait être un peu «comme booter sur un CD-ROM Live CD ou une clef USB Live-Key» mais, par le réseau. Malgré l'envie, ce point n'a pas été creusé.

Le retour de la vengeance: OpenBSD en installation réseau

Finalement, on décide que la gentille machine va servir à quelque chose et on va lui donner un joli système, ca sera, hop, OpenBSD (la version utilisée pour ce truc est celle disponible à ce moment, c'est à dire 3.7, oula, ca ne nous rajeunit pas tout cela).

L'installation se fait à partir d'une machine OpenBSD (3.7 pour cet exemple) sur un pc, en vue d'installer OpenBSD 3.7 sur la SS20. Suivez bien.

On récupère l'archive 3.7/sparc d'OpenBSD sur la machine courante (le PC).

Sur le pc: créer deux fichiers: /etc/ethers et /etc/bootparams.

/etc/ethers contient l'adresse MAC et le nom symbolique du système à installer. Le fichier /etc/bootparams contient les montages NFS nécessaires pour le système de boot en réseau (netboot ou netinstall) depuis le système hote vers le système à installer.

Dans le fichier /etc/ethers:

  % cat /etc/ethers 
  8:0:20:1a:a6:45  ss20

Dans le fichier /etc/bootparams:

  % cat /etc/bootparams 
  ss20    root=vob:/usr/local/home/ss20/root
          swap=vob:/usr/local/home/ss20/swap

On récupère ces infos, notamment l'adresse MAC de la SS20, évidemment, en fouinant sur la machine comme on l'a fait ci-dessus. Vous aviez de toute façon bien suivi, hein ?

Le dépôt local OpenBSD sur le pc est ici par exemple, /usr/local/home/ss20/root simplement parce que la partition /usr/local avec plein de place libre.

Ne pas oublier à renseigner, dans /etc/hosts, à la fois le système hote et le système cible:

  192.168.43.21 vob  ## pc qui sera le serveur de boot
  192.168.43.31 ss20 ## station à installer

Il faut ensuite préparer les répertoires propres à l'installation, ici, /usr/local/home/ss20 :

 # mkdir -p /usr/local/home/ss20/root
 # dd if=/dev/zero of=/usr/local/home/ss20/swap bs=1k count=16000
 # cd /usr/local/home/ss20/root 
 # tar xzpf /chemin/archive/openbsd/sparc/base37.tgz
 # cp /chemin/archive/openbsd/sparc/bsd.rd . 
 # ln -s bsd.rd bsd

Frisson magique ! on a préparé le lit de la petite !

On doit donc avoir dans le répertoire:

  % pwd ; ls -F 
  /usr/local/home/ss20/root
  altroot/ bsd@     dev/     home/    root/    stand/   usr/
  bin/     bsd.rd   etc/     mnt/     sbin/    tmp/     var/

Songeons maintenant à exporter par NFS le répertoire principal, toujours sur le pc:

 % cat /etc/exports 
 #  [...]
 /usr/local/home/ss20/ -alldirs  -network 192.168.43 -mask 255.255.255.0

Modifiez bien évidemment votre réseau (par exemple 10.0.0 ou 192.168.0) pour que cela corresponde à votre configuration). En cas de problème sur NFS, voir ci après, y'a d'autres enjeux. Parfois.

On va aussi placer quelques fichiers aussi pour l'utilisation du protocole tftp. tftp pour trivial ftp est le canal magique par lequel la SS20 va naître au monde, ce qui permet de faire le Bien à partir du rien.

 # mkdir /tftpboot
 # cp /chemin/archive/openbsd/sparc/boot.net /tftpboot/

Reste maintenant à lancer les démons bas niveau qui vont permettre à notre sun à installer de configurer automatiquement son réseau. C'est l'objet des démons rarpd et rpc.bootparamd. Sur le système servant à l'installation, taper:

# rpc.bootparamd
# rarpd -l -f le1

(le1 étant bien évidemment à remplacer par le nom de la carte réseau qui relie le système hote à au système à installer).

Maintenant, une belle difficulté nous arrive … La sun aura besoin d'un paramètre supplémentaire, que nous ne connaissons pas encore: son nom interne.

Lorsqu'on va faire un boot net avec la sun, elle va demander un fichier d'un nom bizarre sur le serveur tftp. Ce nom bizarre doit être un lien symbolique avec notre fichier boot.net … Le problème est donc qu'on ne connait pas ce nom. Avec un serveur tftp Linux/Debian, les options de log et de debug peuvent, lorsque la sun se connecte, nous dire le nom du fichier recherché par la SS20. Mais sous OpenBSD sur le PC (système qui fait office de serveur tftp), ces options n'existent pas. On va donc ruser, en utilisant la commande d'analyse réseau tcpdump (encore une fois, il faut remplacer le1 par l'interface réseau qui va bien):

 # tcpdump -i le1 port tftp

Faire maintenant booter la sun:

1. mettre la sous tension 2. envoyer un BREAK 3. au prompt de l'OpenPROM, la commande suivante:

 
 ok> boot net

Si boot net échoue (et il a échoué ici plusieurs fois) tapez:

ok> boot net-tpe

Sur le système hote qui fait le tcpdump, on doit voir apparaître:

# tcpdump -i le1 port tftp

03:47:58.153426 ss20.maleloria.org.1263 > vob.maleloria.org.tftp:  
23 RRQ "C0A42B2F.SUN4M"

HAhaHAHAHaHaHahaHAHA : l'a lâché le morceau !

Le mot bizarre après le RRQ est le nom magique. On file vers /tftpboot et on tape:

# cd /tftpboot && ln -s boot.net C0A42B2F.SUN4M

Si vous devez faire cela, mettez, bien sûr, le nom que votre sun crachera. Arrêter le boot de la sun, puis la redémarrer. L'installation commence alors tout simplement:

ok
ok boot net-tpe
Boot device: /iommu/sbus/ledma@f,400010:tpe/le@f,c00000  File and args:
Lost Carrier  (transceiver cable problem?)
Twisted pair cable problem or hub link-test disabled.
Use the PROM command "help ethernet" for more information.

ARP/RARP send failed.  Check Ethernet cable and transceiver.
10600
>> OpenBSD BOOT 2.2
boot: client IP address: 192.168.43.31
boot: client name: ss20
root addr=192.168.43.21 path=/usr/local/home/ss20/root
Booting bsd @ 0x4000
[...]

On ronronne de plaisir.

Il arrive parfois que le logiciel cu se déconnecte. Cela n'a pas grande importance. On s'y reconnecte.

Après l'installation, qui est très classique, même sur cette architecture, le boot est très long. C'est lié à la création des clefs cryptographiques du système:

  ssh-keygen: generating new DSA host key...
  done.
  ssh-keygen: generating new RSA host key... done.
  ssh-keygen: generating new RSA1 host key... done.
  openssl: generating new isakmpd RSA key...

Mais après ce délai, tout fonctionne:

  starting network daemons: sendmail inetd sshd.
  starting local daemons:.
  standard daemons: cron.
  Sun Aug 28 02:43:14 CEST 2005    
  OpenBSD/sparc (ss20.maleloria.org) (console)
  login: root
  Password:
  OpenBSD 3.7 (GENERIC) #312: Mon Mar 21 00:14:33 MST 2005
  
  Welcome to OpenBSD: The proactively secure Unix-like operating system.
  
  Please use the sendbug(1) utility to report bugs in the system.
  Before reporting a bug, please try to reproduce it with the latest
  version of the code.  With bug reports, please try to ensure that
  enough information to reproduce the problem is enclosed, and if a
  known fix for it exists, include that as well.
  
  You have mail.
  Terminal type? [sun]
  Don't login as root, use su
  Read the afterboot(8) man page for administration advice.
  ss20# uname -a
  OpenBSD ss20.maleloria.org 3.7 GENERIC#312 sparc
  ss20#

HoohohOHOHOhOhoHOHoHOhoOho. Non seulement elle chante, mais en plus, maintenant, on peut lui parler !@#

Le système reste cependant assez lent, voici quelques exemples:

  # time pkg_add -v ftp://ftp.openbsd.org/pub/OpenBSD/3.7/packages/sparc/vim-6.3.61-no_x11.tg
  z
  parsing vim-6.3.61-no_x11
  Dependencies for vim-6.3.61-no_x11 resolve to: gettext-0.10.40p2, libiconv-1.9.2 (todo: lib
  iconv-1.9.2,gettext-0.10.40p2)
  vim-6.3.61-no_x11:parsing libiconv-1.9.2
  vim-6.3.61-no_x11:libiconv-1.9.2: complete
  vim-6.3.61-no_x11:parsing gettext-0.10.40p2
  Dependencies for gettext-0.10.40p2 resolve to: libiconv-1.9.2
  vim-6.3.61-no_x11:gettext-0.10.40p2: complete
  vim-6.3.61-no_x11: complete
      6m47.37s real     1m4.97s user     0m19.26s system

Tout de même. Et nan, c'est pas le réseau qui rame.

Remarques annexes

NFS pas si pratique ...

Si votre serveur NFS ne fonctionne pas correctement, c'est que vous ne l'avez pas configuré. Il faut suivre les indications de ce document: http://www.openbsd.org/faq/faq6.html#NFS

Pour aller plus vite: éditer /etc/rc.conf (sur une machine de prod, préferer /etc/rc.conf.local) et mettre les chaînes suivantes comme indiqué:

 nfs_server=YES 
 portmap=YES

On pourrait mettre aussi rarpd et autre, mais on les lancera à la main une seule fois. Éditer /etc/exports comme indiqué précédemment. Rebootez la machine. Vous devez avoir les démons suivants qui tournent: mountd, portmap, nfsd (plusieurs).

Assurez vous-en:

% ps auxwww|grep -i nfs
 92 ??  IL     3:30AM    0:00.01 nfsd: server (nfsd)
120 ??  Is     3:30AM    0:00.01 nfsd: master (nfsd)
 92 ??  IL     3:30AM    0:00.76 nfsd: server (nfsd)
 92 ??  IL     3:30AM    0:00.00 nfsd: server (nfsd)
 92 ??  IL     3:30AM    0:00.01 nfsd: server (nfsd)

Pour vous assurer que vous pouvez bien monter vos partages NFS, tapez showmount -e votre_machine_nfs. Elle doit indiquer les partages offerts, par exemple:

% /sbin/showmount -e 192.168.43.21
Export list for 192.168.43.21:
/usr/local/home/ss20 (everyone

Et si on prenait un serveur virtuel pour faire serveur de boot ?

La machine OpenBSD 3.7 hôte à partir de laquelle l'installation d'OpenBSD sur la sparc a été effectuée était en fait une machine virtuelle VMWare. C'était tout ce qu'il y avait sous la main. Mal. Pardon.

On a choisi d'installer une machine virtuelle ad-hoc pour, précisément, installer tous les services (comme rarpd) sans problème, tester sans avoir de risquer de mettre en danger la configuration d'une vraie machine, vraiment utilisée.

Or, dans les opérations décrites ci-après, il s'avère que VMWare ne permet pas le passage en mode promisc de la carte réseau, pour capturer le nom de la sun32 lors du boot.

Pour réaliser cela, éteindre les machines virtuelles, arrêter le système VMWare, puis taper:

chmod a+rw /dev/vmwet0

Puis relancer VMWare et la machine virtuelle. On peut alors passer le système hébergé en mode promisc.

Voir en particulier le document: http://www.vmware.com/support/kb/enduser/std_adp.php?p_faqid=287

sur ce sujet. VMware. Désolé.

Références

http://www.netbsd.org/Documentation/network/netboot/local.install.html

http://www.netbsd.org/Documentation/network/netboot/

http://www.sunhelp.org/pipermail/geeks/2002-April/018089.html

Note: oui, IP et MAC ont été changées et le droit à la vie privée alors #@!