Pour pouvoir mettre à jour l'OS de la gateway, je me suis dis que dupliquer les services sur ma machine principale serait sympa, ça permet de garder la main et de ne pas se retrouver coupé du monde en cas de soucis.

J'ai donc posé une petite conf de bind à partir de l'install fournie par défaut dans NetBSD. La bonne surprise, c'est que chez NetBSD, ils fournissent fromage et dessert : le chrootage du bouzin est de base.

En activant le paramètre named_chrootdir=”/var/chroot/named” dans son /etc/rc.conf, la magie opère :

# rndc-confgen -a -t /var/chroot/named
wrote key file "/etc/rndc.key"
wrote key file "/var/chroot/named/etc/rndc.key"

# /etc/rc.d/named start
Migrating /etc/namedb to /var/chroot/named/etc/namedb
Starting named.

# rndc status
...
server is up and running

Conclusion : si quelque chose est dans le système de base, il vaut mieux l'utiliser, c'est fait pour.

Je viens enfin de réussir à booter un kernel -current (le 5.99.22 pour être précis). J'ai pas mal buté sur le manque de doc concernant l'évolution majeure : le passage aux modules par défaut. La solution est indiquée dans ce post de la ml current-users@. En gros, voici la marche à suivre:

• Compiler son kernel avec build.sh -O /usr/obj comme d'habitude:

$ build.sh -O ../obj -T ../tools -U -u kernel=GENERIC

• Installer le kernel comme d'habitude
• Compiler les modules avec et la cible modules:

$ build.sh -O ../obj -T ../tools -U -u modules

• Copier le boot loader dans /:

# cp ../obj/destdir.i386/usr/mdec/boot /

• Copier les modules dans /:

# cd ../obj/destdir.i386
# pax -rwvpe stand /

En fait, le fichier BUILDING indique que la cible module installe les modules, je pense que ça prête à confusion, ça n'installe pas dans / comme on pourrait s'y attrendre. Je ne connais pas assez le système de construction du système pour comprendre pourquoi, malheureusement.

Enfin, le fait de devoir également mettre le boot loader à jour ne s'invente pas. Tout comme le workaround pour que le système puisse monter la partition racine, qui consiste à charger le module du filesystem de / au prompt du loader :

> load /stand/i386/5.99.X/modules/ffs/ffs.kmod
> boot

En fait, c'est dur de se rendre compte à quel point on peut être passif face aux communautés des divers logiciels libres qu'on utilise. Même si j'essaye d'écrire des docs dans ce wiki chaque fois que je fais un truc potentiellement intéressant pour d'autres, ça reste planqué dans un coin du web…

Alors là, ça y est, je me sens plus et je commence à causer sur de la mailing-list suivie par des vrais gens (pas des robots d'indexation). Je viens de poster un tip sur netbsd-users@ dans une conversation concernant la configuration de fontconfig par défaut de NetBSD. En effet, quand on a x11 natif, il faut ajouter le path des fonts installées pas pkgsrc, pour que les applis utilisant fontconfig (genre firefox) puisse voir ces fonts.

On va voir ce que ça donne, émulation, indifférence ou mépris ? Dans tous les cas, ça m'apprendra des trucs…

Ces derniers temps, j'ai fait pas mal de wiki pour noter diverses choses sur mon nouvel OS préféré: NetBSD. Ce qui fait que je me suis rendu compte que le Dotclear n'avait plus trop d'intérêt comparé à DokuWiki, pour les raisons suivantes :

• Je ne raconte pas ma vie, j'ai pas le temps.
• Le Planet-Libre syndique les docs sur le FOSS, il faut donc faire des docs complètes pour que ça ait un intérêt. D'ailleurs, c'est pété depuis la modif…
• C'est pas facile de maintenir des infos dans un blog, l'édition du wiki s'y prête mieux.

C'est pourquoi, j'ai mis pleins de plugins dokuwiki et un nouveau thème, de quoi faire du blog (au cas où) et toutes les docs du dotclear sont maintenant dans le wiki.

Depuis un moment, pkg_chk me remontait un warning sur des packages installés mais n'existant plus dans l'arbre de pkgsrc. J'ai donc examiné le cas des packages *-dirs pour voir que plusieurs autres packages en avait besoin.

Les packages *-dirs ont été retirés de pkgsrc. Ils servaient à créer des répertoires potentiellement nécessaires à d'autres packages, et on été remplacés par une gestion des répertoires au niveau du package.

Bref, ça me laissait avec un peu de nettoyage à faire : retirer xdg-dirs sans tout péter ma base de packages. La solution a donc consisté à:

• Supprimer le package avec pkg_delete -f
• Editer les fichiers +CONTENTS des autres packages l'ayant comme dépendances dans /var/db/pkg, pour y supprimer toutes les lignes référençant xdg-dirs
• Utiliser un peu pkg_admin rebuild-tree pour s'assurer de la cohérence de la DB de pkgsrc

Merci beaucoup au chan IRC #netbsdfr, Guigui2 m'a pointé sur les mailing-lists, qui ne sont pas ressorties dans mes recherches.