NetBSD en production : de l'intérêt de la diversité

Mais si cette introduction s'écrit vite, préparer un environnement de production utilisant divers systèmes d'exploitation demande un soin particulier, tout spécialement lorsqu'il s'agit d'installer et mettre à jour des paquets ; ce que nous nous proposons d'étudier aujourd'hui, c'est l'utilisation de pkgsrc de manière industrielle, et s'éviter ainsi de voir fleurir dans son parc des dizaines de machines aux logiciels versionnés cahotiquement, et éviter la catastrophe.

1. pkgsrc n'est pas celui qu'on croit

Dans la série « à la découverte du système NetBSD », la fine équipe de NetBSDfr [2] vous a vanté les mérites du système de gestion de paquets pkgsrc. Ce système, d'une puissance et d'une enviable simplicité, permet de manipuler des paquets « source » : installation, mise à jour, effacement, pkgsrc dispose d'un ensemble des cibles que l'on est en droit d'attendre d'un gestionnaire de paquets. Seulement voilà, ils sont loin les jours où nous n'avions rien d'autre à faire de nos journées que de recompiler des noyaux à la main en supprimant méticuleusement chaque module inutile à votre configuration, époque à laquelle 4 heures de compilation pour la mise à jour de votre unique machine vous emplissait de joie, époque également à laquelle vous espériez qu'une compilation allait échouer pour mettre la main à la pâte et publier un patch salvateur. Aujourd'hui, 'faut qu'ça tourne ! Parce que si d'aventure, un de vos relais SMTP tombait en panne, ce ne serait pas votre maman à l'étage qui vous demanderait des comptes, mais un client furieux dont le site n'a pas pu envoyer 20000 € de commandes.

Et c'est là que le bât blesse. Car si en effet pkgsrc est le jouet favori des petits et des grands, son utilisation est simplement inenvisageable en production. Imaginez simplement devoir attendre le temps de la recompilation d'un dovecot qui embarquerait à peu près tous les plugins disponibles pour fixer un bogue impactant un client désireux de récupérer ses mails à l'aide d'un client de messagerie aussi ésotérique que bogué, heureusement supporté dans la version +1 de votre serveur IMAP.

« Mais dans pkgsrc, y'a bien des binaires, non ? » vous entends-je vous gausser. Oui, oui, mais laissez-moi reformuler. Tous les trois mois, des binaires issus d'une branche dite « gelée » sont construits, par exemple, à l'heure où j'écris ces lignes (Joyeuse Saint Valentin !), nous attendons les binaires issus de pkgsrc-2011Q1. Pendant toute la durée de vie de cette branche, une équipe dédiée va s’occuper de suivre les problèmes de sécurité et autres avancées mineures des logiciels présents. On peut alors, par exemple, installer ces paquets binaires avec divers outils, comme pkgin dont je vous entretenais dans ces colonnes voici un peu plus d'un an.

Où est le problème, me direz-vous ? Les problèmes sont multiples. Le premier concerne les licences. En effet, un outil dont la licence explique clairement que sa redistribution est prohibée, s'il aura bien une entrée dans pkgsrc, ne disposera par contre pas de paquet binaire. Citons par exemple le sempiternel flash, ou encore Opera en passant par les codecs de Mplayer.

Le second problème est le résultat d'un choix dont il est difficile de dire s'il est pertinent ou pas. Les paquets compilés sont volontairement réduits à leur plus simple appareil. Par exemple, si l'on reprend l'exemple de dovecot, point de fioritures, pas de LDAP, pas de SSL et encore moins de Sieve, de la même façon, nagios-nrpe ne supportera pas SSL, et irssi, quant à lui, ne disposera pas du support Perl. Bref, dans un nombre important de cas de figure, les binaires fournis par la Fondation sont simplement inexploitables. Mais faut-il alors se résoudre à compiler sans cesse ?

Oui, mais non.

2. J'veux des binaires

Dans l'épisode 3 d’« à la découverte du système NetBSD », nous vous faisions les éloges de pkg_comp couplé au non-moins excellent pkg_chk. Ces deux outils utilisés conjointement permettent par le biais d'un environnement de compilation chrooté de compiler, préparer, archiver les paquets tout neufs sans pour autant rendre votre environnement réel instable. pkg_comp et pkg_chk ayant été abordés plusieurs fois dans ce magazine, et les articles en question étant disponibles sur UnixGarden [3], nous ne nous attarderons pas sur leur fonctionnement.

Comme nous l'évoquions plus haut, l'une des principales raisons pour laquelle les paquets binaires issus du Projet NetBSD sont obsolètes nous concernant, c'est que l'ensemble des modules tiers des divers outils que nous utilisons en production sont désactivés par défaut lors de la génération des paquets. Fort heureusement, pkgsrc propose une méthode simple et élégante pour activer des fonctionnalités supplémentaires dans les paquets générés, par le biais du fichier /etc/mk.conf.

Nous allons réaliser ce travail dans une prison pkg_comp, que nous admettrons se trouver dans le répertoire /home/pkg_comp/amd64-5.0. Voici le contenu de ce fichier, notez en particulier les options relatives aux logiciels que nous allons packager :

Ces premières directives sont destinées à la configuration des paramètres globaux de pkgsrc. Comme nous nous trouvons dans une arborescence particulière, un chroot, mais que nous souhaitons exporter le résultat de notre packaging dans l'arborescence réelle, pkg_comp procède à un paramétrage particulier.

Activons maintenant quelques directives spécifiques à notre environnement. En premier lieu, nous souhaitons nettoyer l'ensemble des dépendances lorsqu'un make clean est effectué :

pkgsrc refuse de compiler les paquets soumis à des licences comprenant des clauses restrictives, ce comportement est contrôlé par la variable ACCEPTABLE_LICENSES :

ccache permet un gain de vitesse lors de la compilation, nous l'activons :

Nous souhaitons que les scripts rc soient installés, et que lors de la mise à jour d'un paquet ainsi que de ses dépendances, des paquets binaires soient générés :

Enfin, nous spécifions les particularités que nous souhaitons apporter à nos paquets. La première variable indique à pkgsrc que nous ne souhaitons pas utiliser la libiconv fournie par le système, mais bien celle disponible dans pkgsrc, plus à jour. La liste des options suivantes est assez explicite.

Notez que la liste complète des options supportées par un paquet est visible par le biais de la commande make show-options. Par exemple :

Notre pkg_comp prêt à l'emploi, il reste à spécifier à pkg_chk la liste des paquets que nous souhaitons compiler. Comme nous l'avons déjà vu dans un numéro précédent et qu'il est désormais consultable en ligne, vous savez que cette opération est réalisée grâce à la commande pkg_chk -g. Voici un exemple de rendu de la commande en question :

Toutes les briques sont maintenant opérationnelles, reste à orchestrer tout ce petit monde afin de toujours disposer de paquets frais, prêts à l'emploi.

3. V'la la tête de cron

Nous vous en parlions dans la série « à la découverte du système NetBSD », pkgsrc est soumis à des règles strictes de releases. Il est évidemment dangereux de baser l'évolution de sa plateforme sur la version current, on lui préférera la version du dernier trimestre, pkgsrc-2010Q4 à l'heure ou j'écris ces lignes.

Le premier checkout s'effectue comme suit :

À la prochaine release, il conviendra de rafraîchir cette arborescence, par exemple par le biais de la commande :

Mais pkgsrc, comme tout système de packaging, est un arbre mouvant, aussi il est nécessaire de rendre l'opération de rafraîchissement automatique. Ceci est bien entendu effectué grâce à une tâche cron :

Ainsi, tous les matins à 4h30, votre arbre pkgsrc intégrera les mises à jour de sécurité ou des mises à jour mineures, mais influant de manière importante.

Maintenant que notre arbre est à jour, nous allons pouvoir nous lancer dans la construction régulière de paquets binaires, alors disponibles pour l'ensemble des machines NetBSD de notre parc. Pour mener cette opération à bien, nous nous fendrons d'un petit script shell très simple :

Dans l'ordre :

- On efface les anciens paquets.

- On installe les mises à jour l'aide de pkg_chk.

- On reconstruit l'ensemble des paquets grâce à pkg_tarup.

- On régénère un fichier pkg_summary qui servira à notre package manager.

Ce script devra à son tour être placé en cron, évidemment après la mise à jour de l'arbre :

On comprend à la lecture de cette ligne que l'ensemble des logs de construction sont visibles dans le fichier pkg_chk-status.log.

Une fois nos paquets compilés, ils seront placés par défaut dans le répertoire /usr/pkgsrc/packages, ne vous reste plus alors qu'à configurer une entrée dans le fichier de configuration de votre serveur web favori afin de pouvoir accéder à ce repository à distance. Par exemple, avec le serveur lighttpd :

4. pkgin lave plus blanc

Alors ouiii, ouiii, je vous entends hurler à l'autopromotion, à l'article dont l'unique objectif est de faire mousser son auteur, mais il n'en est rien, promis. Si même il existait un outil (autre qu'un machin écrit en shell qui embarque tout pkgsrc-wip) qui permette proprement la gestion des binaires, j'en parlerais sans l'ombre d'un regret dans ces colonnes, mais voilà, la raison même qui m'a poussé à écrire pkgin, c'est celle-ci : il n'y en avait pas.

Passés ces enfantillages, nous allons pouvoir bosser. Comme vous l'avez lu précédemment, nous avons sciemment généré un fichier pkg_summary lors de la création de nos packages binaires, et ce précisément pour qu'il soit lu par pkgin.

Ainsi, sur nos machines cibles, les machines de production donc, nous configurerons le fichier /usr/pkg/etc/pkgin/repositories.conf pour qu'il contienne l'URL de votre serveur de paquets flambant neuf. Par exemple, dans mon cas :

Astuce : pkgin supporte les « schemes » http:, https:, ftp: et file:, ce dernier permettant de spécifier un repository local.

Un pkgin up (raccourci pour update) plus loin, votre base de packages disponible contient désormais les entrées issues du fichier pkg_summary contrôlé par vos soins, et aucune surprise liée à l'humeur du packageur officiel ne viendra troubler vos mises à jour. Reste à upgrader votre système via la commande pkgin fug (raccourci pour full-upgrade).

Il ne me viendrait pas à l'idée de mettre à jour tout autre système sans avoir un œil expert sur les opérations menées, aussi, je déconseille fortement au lectorat que cette procédure aura séduit de lancer des pkgin -y fug en aveugle, ne serait-ce que pour observer les messages de mise à jour.

Un dernier mot concernant pkgin (iMil vil prosélyte), à l'heure où j'écris ces lignes, la version 0.3.3.4 est disponible dans pkgsrc-2010Q4 et la version 0.4.0 devrait être disponible lorsque vous lirez cet article. Cette dernière version intègre entre autres modifications le support natif du système MINIX, l'intégration de SQLite via son code source « Amalgamation » (celui-là même qui est intégré dans moult projets libres), ainsi qu'une foule de petits ajouts tels que l'option chroot (merci bapt) ou encore le download only. S'il vous fait des misères, vous savez où frapper.

Et encore, t'as pas tout vu

Pkgsrc a ceci de magique qu'il supporte un nombre impressionnant de systèmes d'exploitation. Citons parmi eux NetBSD évidemment, mais aussi SunOS/Solaris, DragonFly BSD, FreeBSD, OpenBSD, GNU/Linux ou encore OSX. Aussi, si d'aventure vous souhaitiez pousser à l’extrême la notion de « standard », il ne tiendrait qu'à vous de mettre en place des repositories tout à fait synchronisés en termes de logiciels, de configuration et d'options. Notez par ailleurs que de par la simplicité de création des paquets, vous pourriez tout à fait envisager de maintenir votre propre branche de logiciels maison, je me suis d'ailleurs laissé dire qu'un article récemment paru dans un certain magazine [NDLR : celui-là même que vous tenez dans vos mains pour tout dire] avait pour sujet la création d'un paquet pkgsrc à partir de zéro…

Liens

[1] http://www.netbsd.org/gallery/research.html#internet2-landspeed

[2] http://www.netbsdfr.org/

[3] http://www.unixgarden.com/index.php/administration-reseau/netbsd-s01e03-gestion-des-paquets