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


Par le même auteur

Amazon <3 Linux

Magazine
Marque
GNU/Linux Magazine
Numéro
207
|
Mois de parution
septembre 2017
|
Domaines
Résumé
Qui d'entre vous n'a jamais entendu parler de AWS (Amazon Web Services), LE cloud public qui domine le marché, la panacée du DevOps, le destructeur de toute une industrie, l'hébergeur qui soutient désormais un bon 40% du Web mondial ? Si tu réponds « moi » à cette question, tu devrais visiter autre chose que des sites en HTML v2 et cesser d’éditer tes fichiers de conf à la main.La triple pique d'entrée de jeu c'est gratos, ça me fait plaisir. AWS, c'est le rouleau compresseur, et cette position de leader n'est pas liée à la chance, puisque comme nombre de solutions disruptives, les analystes les plus pointus proféraient à son lancement que « ça marchera jamais » ©®™ ; non, le succès de ce cloud réside en grande partie dans son API, ses outils, le plus souvent libres, et la puissante communauté qui s'est construite autour. Ce que je vous propose dans cet article, c'est de faire connaissance avec ces outils, et en particulier l'AWS cli [1] basée sur boto3[2], tous les deux sous licence Apache 2[3].

Des bits comme s'il en pleuvait : une appliance SAN/NAS sous NetBSD

Magazine
Marque
GNU/Linux Magazine
Numéro
181
|
Mois de parution
avril 2015
|
Domaines
Résumé
À Noël, je suis le désespoir de ma famille. En effet, là où d'autres demandent des Blu-ray, de quoi s'habiller en hiver ou encore une nouvelle poêle à frire, moi je demande des composants. Des disques, des cartes, des trucs super pas excitants pour les personnes qui vous les offrent. Cette année, je voulais plus de place sur mon NAS [1], plein de bits pour y coller des documents à haute teneur multimédia.

NetBSD, le système du futur du subjonctif

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
74
|
Mois de parution
septembre 2014
|
Domaines
Résumé
« The Original UNIX », c'est pour cette punchline que j'avais voté lorsque le groupe chargé du marketing chez NetBSD cherchait une approche différente du classique « of course it runs NetBSD » ; néanmoins, s'il est l'héritier le plus direct des travaux du CSRG [1] et l'un des plus grands défenseurs de la portabilité du code, le projet NetBSD n'est certainement pas un système d'exploitation du passé, loin s'en faut. Bénéficiant des avancées standards d'autres OS, NetBSD dispose en outre d'avantages uniques dont l'administrateur système aguerri saura faire usage. Dans cet article, nous allons monter un serveur web articulé autour de briques modernes, et allons dans notre périple découvrir l'ensemble des éléments nécessaires au déploiement d'un système aussi réactif que respectueux des standards.

Préface

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
74
|
Mois de parution
septembre 2014
|
Résumé

Huit ans. Huit ans se sont écoulés depuis les deux derniers numéros hors-séries BSD et le mook que vous tenez entre les mains. Il y a huit ans, il est probable qu'une bonne partie d'entre vous n'avait même jamais touché un système UNIX/Linux, et réalisait plutôt son grand œuvre Lego(c)(tm).

Pendant ces huit années, le monde du Libre a proprement explosé, il est partout, omniprésent sur vos mobiles, vos tablettes, votre télé ou votre point d'accès Wi-Fi ; et si des sociétés telles que Google ne se cachent pas d'utiliser le système GNU/Linux comme socle entre l'espace utilisateur et le matériel, d'autres, sans totalement le masquer, ne font pas étalage des technologies libres constituant la pierre angulaire de leurs systèmes. En tête de liste notons particulièrement la société Apple, dont l'espace utilisateur du système d'exploitation Mac OS X est directement issu de FreeBSD.

Les différents BSD

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
74
|
Mois de parution
septembre 2014
|
Domaines
Résumé

« Salut, je voudrais installer *BSD, vous me conseillez quoi ? »Cette phrase, lue et relue des centaines, des milliers de fois, est fondamentalement incorrecte. *BSD n'existe pas. Plus important, lorsque l'on souhaite mettre le pied à l'étrier d'un système BSD, un minimum de contexte est nécessaire, car chacun des héritiers de BSD UNIX suit une philosophie bien définie, et si chacun d'entre eux s'avère éminemment versatile, certains seront plus adaptés et faciles d'accès fonction de l'utilisation souhaitée. Nous allons ici faire connaissance avec les trois systèmes BSD les plus connus, NetBSD, FreeBSD et OpenBSD et évoquer leurs forces et faiblesses afin de guider votre choix de façon la plus objective possible.

Demandez la Lune à nginx !

Magazine
Marque
GNU/Linux Magazine
Numéro
172
|
Mois de parution
juin 2014
|
Domaines
Résumé
Nginx n'est plus un logiciel à la marge, avec près de 20% de parts de marché du top un million des sites les plus fréquentés au monde, il représente même un acteur sur lequel on peut (et doit !) compter.