NetBSD

On oublie le post ci dessous. En effet, après avoir posté le resultat de mes travaux sur tech-userlevel@, j’ai appris une astuce des plus magiques. Arnaud Lacombe me dit dans une réponse : _ Just looking quickly at the code, you can avoid the “#ifdef BBOX commant_() #else main() #endif” heavy logic and the commonfunc.sh' hack by using nm(1), objcopy(1) and symbol renaming as done by crunchgen(1). </foo>_ Je regarde donc comment s'y prend le gaillard de crunchgen(1)` pour eviter les conflits de symboles et je vois ceci :

Y’a quelques jours, je me suis lancé dans un nouveau projet. Plus pour le fun que par réelle nécéssité, je me suis mis en tête d’ecrire un BusyBox-like orienté BSD. J’en suis pour le moment aux balbutiements du projet, mais quelques commandes sont déjà fonctionnelles.

Mon approche est un tantinet differente du fonctionnement de BusyBox. Afin de permettre l’écriture simple et rapide de plugins, je supporte deux modes, un mode statique (ala BB), et un mode dynamique grace aux interfaces DLFCN(3).

NetBSD 4.0 a vu apparaitre un nouveau filesystem, plus ou moins équivalent au FUSE de GNU/Linux. Il s’agit de proposer un framework qui permettra de manipuler sous forme de filesystem (via les opérations associées open, close, read, write…) des outils userland. Parmi les plus pratiques de ces utilisations, citons par exemple SSHfs ou CurlFtpFS. Et c’est précisemment de cette dernière abstraction dont j’ai recemment eu besoin.

Un rapide tour dans pkgsrc nous montre l’existence du package filesystems/fuse-curlftpfs, ce qui signifie que ce que nous envisageons semble à portée. On note cependant dans le Makefile de ce package la dépendance suivante :

Ce midi, le domU GCU était injoignable. Une connexion VNC nous permet de voir que le noyau vomissait depuis quelques minutes une floppée de :

Une rapide recherche nous amène sur ce post qui, comme on pouvait le soupçonner, explique que les cartes de type rtl8139 sont moisies, mais que dans l’urgence, l’ajout de la directive :

à la conf kernel permet de résoudre le problème.

Dans le cadre d’un projet perso dont j’aurai bientot largement l’occasion de vous parler, j’ai été confronté à un petit casse tête dont je vais vous exposer l’énoncé et la solution.

Le but de l’opération est de faire booter plusieurs instances de NetBSD diskless, en utilisant le même root filesystem NFS, mais avec des repertoires /etc et /dev séparés pour des raisons évidentes de marchage sur les pieds.

La réalisation de cette bidouille s’effectue en deux étapes. Tout d’abord, il est evidemment nécessaire de “reconnaitre” la machine qui boote, et pour cela, c’est une directive du dhcpd.conf qui nous vient en aide. En effet, la directive option host-name permet de “passer” à la machine qui boote une information sur son nom. Voici à quoi ressemble une section typique du fichier :

Depuis le temps que j’en parle, je me suis enfin mis à pkg_comp. Ce tool ecrit en shell permet de simuler un environnement NetBSD dans un chroot avec pour but de compiler en toute sérénité l’ensemble des packages nécessitant un upgrade sur votre machine afin d’en faire des packages binaires tout prêts à être processés par pkg_chk -uab. pkg_comp se charge de mounter tout seul /usr/pkgsrc via nullfs afin de déposer le résultat de la compilation directement dans le repertoire packages/, qui sera plus tard scanné par pkg_chk. C’est très classe. Voici une rapide procédure pour réaliser un upgrade sans prise de tête, on présume dans la suite que votre package pkg_install est à jour (c’est important) :

"re0: watchdog timeout"

Voila tout ce que nous obtenions lorsque nous choisissions le driver NIC rtl8139 pour un domU NetBSD ou OpenBSD. Finalement, c’est une réponse de Manuel Bouyer sur port-xen qui donne la solution: Désactiver re* ! C’est alors rtk* qui prend la main, et là, point de timeout, de latences ou autres dysfonctionnement, “juste ça marche”.

NetBSD possède dans pkgsrc les packages nss_ldap et pam_ldap. J’utilise essentiellement OpenSSH-lpk pour l’authentification par clé des utilisateurs virtuels, de fait je n’utilise pas ou peu pam_ldap. Reste à faire comprendre au système qu’il doit utiliser une base LDAP pour verifier si un utilisateur est valide ou pas. Ceci se réalise grace au fichier /etc/nsswitch.conf, et plus paticulièrement, aux directives suivantes :

Qui précisent de verifier l’existence d’un utilisateur dans les fichiers plats, puis dans une base LDAP. Cette dernière est pointée par le fichier /usr/pkg/etc/nss_ldap.conf dans lequel je me contente de renseigner les directives :

Sur un certain reseau ou je n’ai pas la main, j’ai voulu fournir une connectivité IPv6. À l’époque du 6bone je réalisais cette opération sur le routeur (avant d’apprendre l’existence de 6to4) à l’aide de tspc, un client freenet6 disponible entre autres dans pkgsrc. Il est a priori possible, selon ce qu’on peut lire dans le fichier tspc.conf, de réaliser cette opération derrière du NAT, pourtant, si le tunnel s’établit bien, impossible de faire transiter un paquet. J’ai trouvé la réponse au problème dans ce thread. Une vilaine magouille est nécessaire pour obtenir un tunnel opérationnel :

En echo à ce très bon post montrant une configuration réseau qui fonctionne pour qemu / kvm, je vous propose ma petite sauce. La finalité étant :

. Une VM NetBSD 3.1 sur le même LAN que le host . Son fonctionnement en background . Son administration potentielle via VNC en cas de crash

à la Xen quoi.

Le host est une debian x86, et evidemment le hardware supporte les instructions VT :