NetBSD

Il parait qu’y’a un tool là, pour NetBSD, qui essaierait de mimer apt(8). Le gars il doute de rien, il a même pondu une page expliquant le projet. Je suis dubitatif.

Bon, blague à part, je pense que pkg_dry commence à être utilisable. Il reste encore quelques petites choses à ajouter, probablement un tas de vilains bugs et des ajustements divers, mais dans les grandes lignes, on y est.

Si donc vous vous sentez l’âme d’un testeur et que vous avez sous la main une machine / VM sous NetBSD ou DragonFlyBSD (voir ici pour ce dernier), je serais ravi de recevoir vos feedbacks.

Petit à petit, mon apt(8) wanabee prend forme. Hier j’ai passé deux étapes (ou pratiquement): actions sur plusieurs packages passés en paramètre et première approche de la fonction d’autoremove.

Pour la première, la finalité est évidente :

Pour la seconde, si la finalité semble tout aussi évidente, la mise en oeuvre l’est beaucoup moins. Pour le moment, l’autoremove est une action volontaire, exemple :

Je le sous-entend sans vraiment en causer depuis quelques semaines: je bosse sur un clone d’apt(8) pour NetBSD. Le projet n’est pas fini, loin s’en faut, mais j’ai atteint une Milestone aujourd’hui. Démonstration.

Installation :

Desinstallation :

Ça a l’air de rien comme ça, et c’est pas pour me lamenter, mais gérer les dépendances récursives et l’ordre de ces dernières pour pas que pkg_add(1) et surtout pkg_delete(1) ne gueulent, c’était pas une mince affaire. En tout cas, ça prend forme. En réalité, l’upgrade doit également fonctionner, mais, à nouveau pour satisfaire les ancestraux outils sus-cités, il faudra un peu d’astuce.

Pour tester “en vrai” mon fameux pkg_dry (work in progress, pas du tout utilisable, pas d’affolement), je devais posséder une VM NetBSD 5 “poubelle”. Seulement, depuis quelques temps déjà, je sais que cette version panic’e sur KVM, VirtualBox et Xen HVM. Aussi me suis-je décidé à Xenifier ma machine de developpement NetBSD qui n’a pas d’instructions VT, afin d’y faire tourner un domU en paravirtualisation.

Voici la compilation des documents utiles :

• Le HOWTO officiell NetBSD/xen (pas à jour)
• Le HOWTO du wiki NetBSD
• Un post sur port-xen qui donne quelques informations supplémentaires

Ce qu’il faut savoir :

Pour mon projet top secret que j’ai, j’avais besoin de télécharger un fichier, en C, via FTP ou HTTP. En cherchant ce qui est fait dans pkg_install, et plus particulièrement dans admin/audit.c, j’ai trouvé un bon exemple d’utilisation de la libfetch, dont le man est à mon avis complètement indigeste.

Petit résumé.

Afin de visualiser un code complet et fonctionnel sur l’utilisation de la libfetch, le fichier audit.c précedemment cité fera reference.

Considérons une fonction, fetch_url qui prendra en paramètre une URL. Afin d’utiliser la libfetch, nous auront besoin du header fetch.h. Voici donc le début de notre fichier contenant la fonction fetch_url :

J’ai dans mes cartons un “vieux” laptop Compaq. Ce dernier, bien que peu véloce, a une belle résolution, un clavier et une dale assez agréables, par conséquent, il faisait un candidat idéal au loutrage-canapé.

Mon premier reflexe fut evidemment d’insérer un CD de NetBSD 5.0RC2 fraîchement gravé, mais si l’installation et le boot furent une vraie rigolade, j’ai déchanté assez rapidement en voyant le noyau panic()’er aléatoirement :(

Qu’à cela ne tienne, je décide de me rabattre sur un NetBSD 4.0.1, valeur sure. Et vla que ça bloque au boot. J’aime pas les laptops Compaq. Comme je le suspectais, c’est evidemment cette grosse merde d’ACPI qui empêchait le noyau de se dérouler, donc à grands coups de userconf(4), je désactive acpi0. Démonstration :

Je suis en train de packager un module apache, mod-vhost-ldap, qui a pour dépendence www/apache22 et par conséquent devel/apr-util. Jusque là, rien de terrible, les inclusions suivantes gèrent ces dépendances directes :

Seulement voila, pour que mod-vhost-ldap compile correctement, devel/apr-utils doit impérativement être compilé avec le support LDAP. Ceci est réalisé en plaçant la variable PKG_OPTIONS.apr-util=ldap par exemple dans /etc/mk.conf. Cependant, si cette variable n’est pas renseignée, et que rien de particulier n’est spécifié dans le Makefile du package mod-vhost-ldap, la compilation de ce dernier foirera lamentablement et je vous met au défi d’en trouver la cause.

J’me suis tâté à balancer ça sur imil.net, mais après tout, puisque j’y raconte ma vie et que ceci est probablement l’un des instants les plus magiques de cette dernière, je vais pas m’en priver (non on attend pas un gamin).

Depuis combien de temps j’attend ça… je sais plus bien, à vue de nez, je dirais une huitaine d’années, depuis que j’ai commencé à contribuer chez eux. J’ai pondu des trucs, plus ou moins interessants, j’ai participé dans la mesure du possible et surtout dans la mesure de mes compétences, de mon temps, un peu au petit bonheur. Et finalement, c’est arrivé, sous l’œil bienveillant de mes deux sponsors que je remercie sincèrement: je suis officiellement développeur NetBSD.

Premier post de l’année àla ma-vie-mon-œuvre.

Pour Noël, nourrissant l’illusion que je vais reussir à m’accrocher à un projet plus de 2 mois, j’ai topé le domaine beastiebox.org, qui, aussi surprenant que cela puisse paraitre, était disponible. Alors plutot que de se le faire squatter hein…

Toujours sur ce sujet, j’ai reçu juste avant mon départ un mail de monsieur Thorsten Glaser du projet MirBSD qui me demandait si je pouvais intégrer mksh dans BeastieBox. C’est chose faite, mais sa compilation est désactivée par défaut car ce shell, un clone léger du Korn Shell, pèse tout de même autour de 160K, soit deux fois plus que sh(1) dans sa version BBOX. J’ai par contre été assez bluffé par la qualité du code de mksh, ultra propre, ultra portable, je vous le recommande :)

En comparant le projet qui m’obsède jour et nuit et les outils similaires déjà existants (crunchgen(1), rescue), j’en suis venu à me poser des questions sur le cas d’un mode “full static”. Pour mémoire, BeastieBox “trouve” la fonction à appeler fonction de argv[0], et je pars du principe que chaque nom de fonction doit être construit dynamiquement. Ce tour de passe-passe est facilement geré par les fonctions dlopen(3) / dlsym(3) dans le cas d’un binaire compilé dynamiquement, mais quid d’un binaire beastiebox compilé à l’aide du swtich -static ? Point de ld.so_elf à la rescousse ici, la seule solution qui m’est apparue… c’est d’attaquer le binaire comme le fait précisemment ld.so_elf, en mmap‘ant le binaire et en l’adressant via les structures ELF.