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

Magazine
Marque
GNU/Linux Magazine
Numéro
136
Mois de parution
mars 2011


Résumé
Lorsque l'on possède un parc de machines important, il peut s'avérer judicieux de multiplier (mais pas trop) les systèmes d'exploitation (propres). En effet, une faille touchant un service transversal qui possède une dépendance forte au système, au hasard OpenSSH, pourrait compromettre l’intégralité de votre plateforme en un coup un seul. D'autre part, un bon OS, c'est comme une vinaigrette, il est meilleur lorsqu'il accompagne la salade adéquate, comprendre qu'il n'est pas déraisonnable de penser qu'un NAS utilisant ZFS serait mieux géré par SunOS, ou d'opter pour NetBSD pour un équipement dont le rôle serait de router du traffic [1] ou encore de s'interfacer proprement avec des réseaux IPv6 natifs.

Body

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 :

$ cat /home/pkg_comp/amd64-5.0/etc/mk.conf

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.

#

# /etc/mk.conf

# File automatically generated by pkg_comp on Sat Dec 18 13:11:05 CET 2010

#

.ifdef BSD_PKG_MK

WRKDIR_BASENAME ?= default

MKOBJDIRS ?= yes

BSDSRCDIR ?= /usr/src

WRKOBJDIR ?= /pkg_comp/obj/pkgsrc

DISTDIR ?= /pkg_comp/distfiles

PACKAGES ?= /pkg_comp/packages

PKG_DEVELOPER ?= no

CLEANDEPENDS ?= yes

LOCALBASE ?= /usr/pkg

PKG_SYSCONFBASE ?= /usr/pkg/etc

CFLAGS ?=

CPPFLAGS ?=

CXXFLAGS ?=

USE_AUDIT_PACKAGES ?= yes

PKGVULNDIR ?= /usr/pkg/share

USE_XPKGWEDGE ?= yes

PKGSRC_COMPILER ?= gcc

LIBKVER_STANDALONE_PREFIX ?= /libkver

PKG_DBDIR ?= /var/db/pkg

CFLAGS +=

CPPFLAGS +=

CXXFLAGS +=

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é :

# clean dependencies when the "clean" target is called

CLEANDEPENDS=yes

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

# everybody likes vim

ACCEPTABLE_LICENSES+=vim-license

ACCEPTABLE_LICENSES+= socks5-license

ACCEPTABLE_LICENSES+= sendmail-license

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

PKGSRC_COMPILER=ccache gcc

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 :

PKG_RCD_SCRIPTS=        yes

UPDATE_TARGET=package-install

DEPENDS_TARGET=package-install

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.

USE_BUILTIN.iconv=      no

PKG_OPTIONS.dovecot=    ssl ldap dovecot-sieve dovecot-managesieve

PKG_OPTIONS.nagios-nrpe=    ssl tcpwrappers

PKG_OPTIONS.apr-util=    ldap

PKG_OPTIONS.php=    fastcgi

PKG_OPTIONS.lighttpd=    ssl inet6 ldap

PKG_OPTIONS.irssi=    perl inet6

PKG_OPTIONS.mplayer=    oss

DSPAM_STORAGE_DRIVER=    mysql

PKG_OPTIONS.dspam+=    graphs

.endif # BSD_PKG_MK

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 :

(imil@coruscant)

[~/netbsd-cvs/pkgsrc/mail/dovecot] make show-options

Any of the following general options may be selected:

        dovecot-managesieve     

        dovecot-sieve   

        gssapi   Enable gssapi support.

        kqueue   Enable support for kernel event notification mechanism.

        ldap     Enable LDAP support.

        mysql    Enable MySQL support.

        pam      Enable PAM support.

        pgsql    Enable PostgreSQL support.

        sqlite   Enable SQLite support.

At most one of the following ssl options may be selected:

        gnutls   Enable GNU TLS support.

        ssl      Enable SSL support.

These options are enabled by default:

        kqueue ssl

These options are currently enabled:

        kqueue ssl

You can select which build options to use by setting PKG_DEFAULT_OPTIONS

or PKG_OPTIONS.dovecot.

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 :

$ head -10 /usr/pkgsrc/pkgchk.conf

# Generated automatically at Sun Jan 30 00:30:00 CET 2011

archivers/bsdtar

archivers/libarchive

archivers/lzo

archivers/php-zlib

archivers/unzip

chat/eggdrop

converters/p5-MIME-Base64

converters/p5-Text-Iconv

converters/php-mbstring

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 :

# cd /usr

# cvs -d anoncvs@anoncvs.fr.netbsd.org:/cvsroot co -rpkgsrc-2010Q4

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

# cd /usr/pkgsrc && cvs up -dP -rpkgsrc-2011Q1

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 :

$ sudo crontab -e

30 4 * * * cd /usr/pkgsrc && /usr/bin/cvs up -Pd >/dev/null 2>&1

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 :

#!/bin/sh

[ $# -lt 2 ] && echo "usage: $0 <pkg_comp.conf> <pkgchk.conf>" && exit 1

COMP_CONF=$1

PKGCHK_CONF=$2

PKGCHK_UPDATE_CONF=/tmp/pkgchk_update.conf

LC_ALL=C

EXT="tgz"

export PKGCHK_UPDATE_CONF LC_ALL

PATH=${PATH}:/usr/pkg/sbin:/usr/sbin:/sbin

cd /usr/pkgsrc/packages/All

echo -n "removing old packages... "

rm -rf *.${EXT} pkg_summary.bz2

echo "done"

echo -n "buiding missing packages... "

pkg_comp -C ${COMP_CONF} chroot \

        /usr/pkg/sbin/pkg_chk -C ${PKGCHK_CONF} -ua

echo "done"

echo -n "generating packages..."

pkg_comp -C ${COMP_CONF} chroot \

        /usr/pkg/bin/pkg_tarup -a -d /pkg_comp/packages/All/ \'*\'

echo "done"

echo -n "creating pkg_summary..."

pkg_info -X *.${EXT} |bzip2 -c > pkg_summary.bz2

echo "done"

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 :

30 6 * * * /home/pkg_comp/bin/pkg-gen.sh /home/pkg_comp/amd64-5.0.conf /usr/pkgsrc/pkgchk.conf > /home/pkg_comp/pkg_chk-status.log 2>&1

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 :

# [...]

$HTTP["host"] == "pkgsrc.example.com" {

server.document-root = "/usr/pkgsrc/packages"

        dir-listing.activate = "enable"

}

# [...]

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 :

http://yavin.imil.net/NetBSD/5.0/$arch/packages/All

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




Article rédigé par

Par le(s) même(s) auteur(s)

smolBSD : UNIX façon « Ikea »

Magazine
Marque
Linux Pratique
Numéro
141
Mois de parution
janvier 2024
Spécialité(s)
Résumé

Dans les séries américaines, on appelle ce genre d’histoire un crossover, les premières occurrences ont démarré dans Linux Pratique, puis une partie plus profonde sur l’amincissement d’un noyau NetBSD, pas nécessairement utile pour la finalité de notre produit, a fait son apparition dans GNU/Linux Magazine. Aujourd’hui, nous allons apprendre à construire un système BSD UNIX, NetBSD, From Scratch.

SmolBSD : un système UNIX de 7 mégaoctets qui démarre en moins d’une seconde

Magazine
Marque
GNU/Linux Magazine
Numéro
265
Mois de parution
septembre 2023
Spécialité(s)
Résumé

Que de racolage en si peu de mots. Et pourtant si, c’est bien la promesse de cet article, comment parvenir à construire un système d’exploitation fonctionnel en moins de… 10 mégabits. Quelle est cette sorcellerie ? En utilisant une fonctionnalité prévue, mais pas utilisée à cet escient par le noyau NetBSD, nous allons lui faire subir un régime drastique !

Les derniers articles Premiums

Les derniers articles Premium

Petit guide d’outils open source pour le télétravail

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Ah le Covid ! Si en cette période de nombreux cas resurgissent, ce n’est rien comparé aux vagues que nous avons connues en 2020 et 2021. Ce fléau a contraint une large partie de la population à faire ce que tout le monde connaît sous le nom de télétravail. Nous avons dû changer nos habitudes et avons dû apprendre à utiliser de nombreux outils collaboratifs, de visioconférence, etc., dont tout le monde n’était pas habitué. Dans cet article, nous passons en revue quelques outils open source utiles pour le travail à la maison. En effet, pour les adeptes du costume en haut et du pyjama en bas, la communauté open source s’est démenée pour proposer des alternatives aux outils propriétaires et payants.

Sécurisez vos applications web : comment Symfony vous protège des menaces courantes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les frameworks tels que Symfony ont bouleversé le développement web en apportant une structure solide et des outils performants. Malgré ces qualités, nous pouvons découvrir d’innombrables vulnérabilités. Cet article met le doigt sur les failles de sécurité les plus fréquentes qui affectent même les environnements les plus robustes. De l’injection de requêtes à distance à l’exécution de scripts malveillants, découvrez comment ces failles peuvent mettre en péril vos applications et, surtout, comment vous en prémunir.

Bash des temps modernes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les scripts Shell, et Bash spécifiquement, demeurent un standard, de facto, de notre industrie. Ils forment un composant primordial de toute distribution Linux, mais c’est aussi un outil de prédilection pour implémenter de nombreuses tâches d’automatisation, en particulier dans le « Cloud », par eux-mêmes ou conjointement à des solutions telles que Ansible. Pour toutes ces raisons et bien d’autres encore, savoir les concevoir de manière robuste et idempotente est crucial.

Présentation de Kafka Connect

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Un cluster Apache Kafka est déjà, à lui seul, une puissante infrastructure pour faire de l’event streaming… Et si nous pouvions, d’un coup de baguette magique, lui permettre de consommer des informations issues de systèmes de données plus traditionnels, tels que les bases de données ? C’est là qu’intervient Kafka Connect, un autre composant de l’écosystème du projet.

Les listes de lecture

9 article(s) - ajoutée le 01/07/2020
Vous désirez apprendre le langage Python, mais ne savez pas trop par où commencer ? Cette liste de lecture vous permettra de faire vos premiers pas en découvrant l'écosystème de Python et en écrivant de petits scripts.
11 article(s) - ajoutée le 01/07/2020
La base de tout programme effectuant une tâche un tant soit peu complexe est un algorithme, une méthode permettant de manipuler des données pour obtenir un résultat attendu. Dans cette liste, vous pourrez découvrir quelques spécimens d'algorithmes.
10 article(s) - ajoutée le 01/07/2020
À quoi bon se targuer de posséder des pétaoctets de données si l'on est incapable d'analyser ces dernières ? Cette liste vous aidera à "faire parler" vos données.
Voir les 65 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous