NetBSD S01e03 : Gestion des paquets

Magazine
Marque
GNU/Linux Magazine
Numéro
122
|
Mois de parution
décembre 2009
|


Résumé
Chers lecteurs, nous revoilà dans un nouvel épisode de cette saga consacrée à l'OS à la serviette orange. Ce mois-ci, nous allons entrer un peu plus encore dans les profondeurs. Après l'historique, l'installation, place au peuplement de notre disque dur avec les programmes que l'on désire. Car installer un OS alternatif c'est bien, s'en servir c'est mieux[1]. Le mois dernier, je vous ai parlé de pkgin, qui permet l'installation de paquets binaires. Nous allons y revenir très brièvement car ce programme a déjà eu sa consécration dans GLMF N°118.

Body

1. Binaires or not binaires, that's the question

Un dilemme se présente (qui donne souvent lieu à de grands débats) : dois-je utiliser les paquets binaires ou compiler moi-même mes logiciels ? Le premier cas a déjà été évoqué ; pour le deuxième, on ne partira pas de rien. En effet, nous utiliserons pkgsrc ! Mais cela ne répond pas à la question, me direz-vous. En fait, j'aurais tendance à dire que ça dépend (une vraie réponse de Normand ;) ). Dans le cas où vous utilisez votre système de manière standard, que vous ne voulez pas perdre du temps à compiler en permanence, le choix des binaires s'impose à vous. En revanche, dans le cas où vous avez besoin d'un logiciel dont la licence ne permet pas sa diffusion sous forme de paquets binaires (flash au hasard, …) ou que vous ayez besoin d'options de configuration non standard, ou que le logiciel ne soit pas disponible déjà compilé, la compilation sera de mise.

Bon, le décor est posé, place à l'action !

2. Pkgin, suite et fin

Lors de la parution de l'article dans GLMF N°118, iMil[2] nous expliquait le fonctionnement de pkgin[3]. Or depuis, bien des suggestions et évolutions plus tard, une des fonctionnalités intéressantes est l'utilisation possible de multiples repositories. Il s'agit en fait de la possibilité de spécifier à pkgin les sources possibles de récupération des paquets binaires. A première vue, rien d'extraordinaire, si ce n'est simplement la possibilité de spécifier en plus d'une ou plusieurs sources distantes, une source locale ! Exemple :

# more /usr/pkg/etc/pkgin/repositories.conf

ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/5.0/All

file://blahblahblah

Ici, mon $LOCALBASE est /usr/pkg/ mais nous pourrions changer cette directive. Nous verrons plus loin toute l'importance de cette nouvelle fonctionnalité de pkgin ainsi que la directive LOCALBASE.

3. Pkgsrc

3.1 Petite intro

pkgsrc[4] (package source) est le framework de packaging de NetBSD. Il vous permettra d'ajouter, d'enlever, bref de gérer les logiciels sur le système. Comme pour l'OS à la serviette orange, il a été destiné dès le départ à être portable, et de ce fait, d'autres OS l'utilisent en en ayant fait leur système de packaging par défaut comme DragonFlyBSD[5], Draco Linux[6], … Ce framework a été écrit par Alistair G. Crooks[7] (récemment interviewé par l'équipe de NetBSDfr) et a vu le jour en août 1997.

3.1.1 En quoi consiste-t-il ?

pkgsrc est organisé sous forme de répertoires regroupant en catégories les logiciels. Dans ces catégories, nous trouvons d'autres répertoires, nommés du nom de leur programme et contenant ainsi les fichiers nécessaires à leur compilation au sein du framework. 1 répertoire = 1 application. Exemple :

pkgsrc

Nous allons regarder un peu plus en détail, mais sans rentrer dans de grandes explications, le contenu d'un répertoire, par exemple, le logiciel bunzip :

# cd ./bunzip/ && ls -al

/usr/pkgsrc/archivers/bunzip

total 16

drwxr-xr-x   4 root wheel   512 Sep 26 03:02 .

drwxr-xr-x 95 root wheel 2048 Sep 26 03:02 ..

drwxr-xr-x   2 root wheel   512 Sep 26 03:02 CVS

-rw-r--r--   1 root wheel   716 Oct 31 2001 DESCR

-rw-r--r--   1 root wheel   598 Mar 3 2008 Makefile

-rw-r--r--   1 root wheel    74 Oct 31 2001 PLIST

-rw-r--r--   1 root wheel   284 Aug 2 2007 distinfo

drwxr-xr-x   3 root wheel   512 Aug 2 2007 patches

#

Explications :

- CVS : je passe - ce sont les informations de contrôle de CVS ;

- DESCR : ce fichier contient le descriptif détaillé du logiciel et de ses fonctions ;

- Makefile : LE fichier clé qui contient de nombreux renseignements tels le nom programme, sa catégorie, …, mais surtout toutes les spécifications nécessaires au bon déroulement de sa compilation et installation comme les dépendances, … ;

- PLIST : ce fichier contient la liste des fichiers et leurs emplacements après installation. Il renseignera la base des logiciels installés : var/db/pkg ;

- distinfo : contient les sommes de contrôle SHA1 et RMD160 des sources du logiciel ainsi que des patchs nécessaires, le cas échéant ;

- patches : ce répertoire contient les patches nécessaires à la bonne compilation du logiciel. Un fichier patch sera généré par paramètre à modifier.

Voici donc à quoi ressemble le contenu d'un logiciel au sein de l'arbre pkgsrc.

3.2 Récupérer pkgsrc

3.2.1 Récupération de l'arbre

Une fois de plus, je vais vous décrire UNE méthode parmi tant d'autres. On peut récupérer l'arbre pkgsrc par CVS, FTP, csup et même git[7]. Au départ, je préfère récupérer l'archive current de pkgsrc sur FTP pour la décompresser ensuite. Cette méthode me parait rapide, simple et efficace :

# cd /usr

# ftp ftp://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc.tar.bz2

# tar xvjf pkgsrc.tar.bz2

Et voilà, simple, n'est-il pas ?

3.2.1.1 Maintenir son arbre toujours vert

Notre package current l'a été de manière éphémère. En effet, l'arbre est en perpétuelle mouvement par des modifications suite à des corrections de bugs, faille de sécurité ou autres, qui pourraient corrompre l'intégrité de notre OS. Il convient donc de le maintenir à jour. Pour cela, nous avons à nouveau plusieurs choix :

- via CVS :

export CVS_RSH=ssh

export CVSROOT=anoncvs@anoncvs.NetBSD.org:/cvsroot

cd /usr/pkgsrc

cvs update -A -dP

- via csup : avant tout il va falloir installer csup via pkgin ou simplement en récupérant le paquetage binaire directement sur un FTP :

# ftp ftp://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/5.0.1_2009Q2/All/csup-20070216.tgz

# pkg_add csup-20070216.tgz

Remarque : vous l'aurez compris, l'utilitaire à mettre en œuvre pour installer un binaire est pkg_add et s'utilise de la façon suivante : pkg_add mon_binaire.

Puis nous allons créer un fichier qui permettra à csup d'aller récupérer les changements de l'arbre et de répercuter ces changements sur notre arbre local :

# vi netbsd-supfile

*default tag=.

*default release=cvs

*default delete use-rel-suffix

*default umask=002

*default host=cvsup.se.netbsd.org

*default prefix=/usr

*default compress

netbsd-pkgsrc

Ce fichier mérite quelques explications :

- *default tag=. : permet de spécifier la branche que l'on suit, ici : la branche current de pkgsrc ;

- *default prefix=/usr : on indique l'endroit où se trouve notre arbre, ici dans /usr (on verra plus loin ce paramètre) ;

- netbsd-pkgsrc : on veut synchroniser pkgsrc.

On a installé csup, on a notre fichier de configuration qui va bien, go go go pour la synchro :

moustik# csup -L 2 /etc/netbsd-pkgsrc-wip

Parsing supfile "/etc/netbsd-pkgsrc-wip"

Connecting to cvsup.se.netbsd.org

Connected to cvsup.se.netbsd.org (130.236.254.164)

Server software version: SNAP_16_1h

Negotiating file attribute support

Exchanging collection information

Establishing multiplexed-mode data connection

Running

Updating collection netbsd-pkgsrc/cvs

Checkout pkgsrc/Makefile

Checkout pkgsrc/README

SetAttrs pkgsrc/archivers/9e/DESCR

Checkout pkgsrc/archivers/9e/Makefile

Checkout pkgsrc/archivers/9e/PLIST

Checkout pkgsrc/archivers/9e/distinfo

Checkout pkgsrc/archivers/9e/patches/patch-aa

Checkout pkgsrc/archivers/9e/patches/patch-ab

Checkout pkgsrc/archivers/Makefile

SetAttrs pkgsrc/archivers/advancecomp/DESCR

Checkout pkgsrc/archivers/advancecomp/Makefile

[....]

Checkout pkgsrc/x11/zenity/PLIST

Checkout pkgsrc/x11/zenity/distinfo

Shutting down connection to server

Finished successfully

#

Cette opération peut prendre plus ou moins de temps en fonction de votre connexion internet bien sûr, mais également en fonction de la fréquence de mise à jour. Il est donc judicieux de « cronifier » cela.

pkgsrc est le repository maintenu par les commiters NetBSD, mais il existe également un repository nommé wip[8] (Work In Progress), ou quiconque désire s'essayer au packaging pkgsrc peut obtenir très simplement un accès. pkgsrc-wip est également utilisé par les développeurs NetBSD afin de tester un package avant de le commiter dans l'arborescence officielle. Chaque sous-répertoire de wip est un programme, il n'y a donc pas de notions de catégories à ce niveau. Pour l'installation de wip, on procède de la même manière que pour pkgsrc, on récupère un snapshot que l'on décompressera dans /usr/pkgsrc/. La synchronisation est identique à pkgsrc, on ajoutera simplement dans le fichier de configuration de csup (ici netbsd-supfile), une ligne en fin de fichier : netbsd-pkgsrc-wip et le tour est joué.

Remarque : Toute personne voulant contribuer à pkgsrc peut demander son accès à wip. Rendez-vous sur le site de pkgsrc-wip[8] pour obtenir la démarche.

3.3 Le chef de gare annonce le départ

3.3.1 le fichier mk.conf

Bon, notre arbre va se maintenir à jour, très bien, mais que fait-on maintenant ? Avant toute chose, un des fichiers très importants de la configuration de notre système est : mk.conf. J'avais survolé son utilisation lors de l'épisode précédent et ce fichier ressemblait à cela (je ne reviendrai pas sur les explications) :

# more /etc/mk.conf

PKG_RCD_SCRIPTS=YES

PYTHON_VERSION_DEFAULT=25

Nous allons l'enrichir et y ajouter quelques directives :

MASTER_SORT=.fr .uk .de

PKG_RESUME_TRANSFERS=YES

ACCEPTABLE_LICENSES+=vim-license

PKG_OPTIONS.openoffice3+=firefox3 gtk2 lang-fr

Explications :

- MASTER_SORT=.fr .uk .de : voici les serveurs à privilégier lors du téléchargement des fichiers sources ;

- PKG_RESUME_TRANSFERS=YES : si pour une raison ou une autre, le téléchargement du fichier source était interrompu, cette directive permet de spécifier au système de reprendre la récupération là où elle s'était arrêtée ;

- ACCEPTABLE_LICENSES+=vim-license : certains logiciels nécessitent un accord de la part de l'utilisateur, cette directive permet de spécifier une bonne fois pour toutes notre accord (intéressant notamment lors des mises à jour) ;

- PKG_OPTIONS.openoffice3+=firefox3 gtk2 lang-fr : certains logiciels peuvent être compilés avec plusieurs options, les options voulues sont à spécifier dans ce fichier (toujours plus pratique lors de mise à jour). La syntaxe est de la forme PKG_OPTIONS.le_nom_de_mon_logiciel+= mes_options. Ici on demande qu'Open Office 3 (oui, y a des fous qui le compilent !) soit compilé avec la dépendance de Firefox 3, du framework GTK+ 2 et en français.

Nous aurons l'occasion d'enrichir encore ce fichier au cours de l'article.

Remarque : Le fichier mk.conf permet également de spécifier des directives relatives à la compilation du basesys. Cela fera l'objet d'un autre article, soyez patient ;)

3.3.2 l'heure H

Cette fois-ci, ça y est, on est prêt. On va choisir un logiciel relativement simple pour commencer : pkgfind. Cet outil permettra de trouver très rapidement le logiciel que vous souhaitez installer dans l'arbre pkgsrc. La gestion des dépendances est implicite, si un logiciel a besoin d'un autre pour qu'il fonctionne, pkgsrc lancera la compilation de celui-ci.

# cd /usr/pkgsrc/pkgtools/pkgfind

# make install clean clean-depends

[...]

=> Automatic manual page handling

=> Registering installation for pkgfind-20050804

===> Cleaning for pkgfind-20050804

#

La magie s'opère, les lignes de compilation défilent, pas d'erreur, pkgfind est installé ! Un petit test pour en être convaincu :

# pkgfind vim

editors/vim: Vim editor (vi clone) without GUI

[...]

editors/vim-xaw: Vim editor (vi clone) with X11 Athena GUI

#

mais il existe une autre commande pour voir les logiciels installés sur le système :

# pkg_info

pkgfind-20050804    Find packages by package name in pkgsrc

#

Vous obtiendrez un warning lors de la compilation d'un logiciel :

WARNING: No /var/db/pkg/pkg-vulnerabilities file found.

WARNING: To fix run: `/usr/sbin/pkg_admin -K /var/db/pkg fetch-pkg-vulnerabilities'.

On peut clairement ignorer ce message : on ignore simplement la liste des logiciels connus pour avoir eu une faille de sécurité. Dès qu'une faille est repérée au niveau d'un logiciel, celui-ci est mis à jour au niveau de l'arbre pkgsrc, d'où l'importance de le tenir à jour quotidiennement, sinon on lancera la commande comme indiqué dans la 2ème ligne du message.

On peut remarquer, dans la ligne de commande, les flags clean et clean-depends Dans cet exemple, le premier flag a été exécuté et le retour est : ==> Cleaning for pkgfind-20050804. Lors de la compilation d'un logiciel, il crée automatiquement dans le répertoire de celui-ci un répertoire work dans lequel il compile les sources. Ce flag a pour but de nettoyer ce répertoire de travail en le supprimant tout simplement. L'autre flag clean-depends ferait de même avec les répertoires work de toutes les dépendances. Pratique pour ne pas s'encombrer de fichiers inutiles. Mais bon, quand on dit que pkgsrc a bien été pensé, il existe une directive à ajouter dans notre fichier mk.conf, qui nous évitera de le spécifier à chaque installation : CLEANDEPENDS=yes donc :

# echo "CLEANDEPENDS=yes" >> /etc/mk.conf

et le tour est joué.

Il arrive que l'on veuille garder le répertoire work peuplé de ses fichiers (notamment les développeurs, ou alors lors de la compilation d'un logiciel important comme Open Office, Jdk, …) et que si par hasard on avait installé quelques logiciels, la commande suivante permettrait de nettoyer notre arbre :

find /usr/pkgsrc -name work -exec rm -r {} \;

Après pkgfind, prenons un autre exemple plus complexe, le logiciel fetchmail :

# cd /usr/pkgsrc/mail/fetchmail

# make show-options

Any of the following general options may be selected:

        gssapi

        kerberos         Enable Kerberos support.

        kerberos4        Enable Kerberos4 support.

        ssl      Enable SSL support.

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

        socks4   Enable Socks4 support.

        socks5   Enable Socks5 support.

These options are enabled by default:

        ssl

These options are currently enabled:

        ssl

You can select which build options to use by setting PKG_DEFAULT_OPTIONS

or PKG_OPTIONS.fetchmail.

#

L'instruction make show-options permet de nous informer des options disponibles pour compiler fetchmail. Le message est clair, par défaut, l'option ssl est activée mais nous allons également spécifier l'option socks5 afin que le logiciel supporte ce protocole. Une fois de plus, nous allons spécifier ces options dans notre fichier mk.conf afin de ne pas avoir à renouveler l'opération lors d'une mise à jour, par exemple :

echo "PKG_OPTIONS.fetchmail+= ssl socks5" >> mk.conf

puis nous lançons la commande make clean install.

Remarque : si la compilation échoue, il faut parfois lancer la commande make clean pour que le logiciel se compile sans erreur.

Il existe bien d'autres targets à make, je vous invite à consulter le pkgsrc guide[11] pour en connaître davantage et étancher votre soif de curiosité.

3.4 Le processus pkgsrc

Quand on installe un logiciel via pkgsrc, le processus lancé passe par quelques phases :

pkgsrc_process

- fetch : cette phase consiste à récupérer l'archive qui contient les sources du logiciel que l'on souhaite installer ;

- checksum : on est jamais trop prudent, pkgsrc va vérifier l'intégrité de l'archive via un checksum basé sur 2 algorithmes : SHA1 & RMD160 ;

- extract : l'archive étant compressée, on extrait les sources (dans le répertoire work) ;

- patch : les patches sont là pour corriger les sources, par exemple en changeant l'appel d'une bibliothèque qui porterait un nom différent, … ;

- tools : c'est à ce niveau que pkgsrc va analyser les outils dont il aura besoin pour compiler les sources comme bzcat, … ;

- wrapper : le wrapper[10] va être créé afin de faire abstraction du compilateur utilisé (on peut utiliser GCC ou un autre compilateur) ;

- configure : phase classique avant compilation, l'analyse des appels système, des fichiers header, … ;

- build : la compilation proprement dite ;

- test : certains logiciels possèdent une phase de tests incluse dans leur mode de compilation. On peut citer maxima ou php5 par exemple, et donc on peut décider que ce test devienne une sécurité supplémentaire lors de la compilation via pkgsrc ;

- install : les fichiers une fois compilés seront placés au bon endroit, la base des programmes installés mise à jour.

3.4.1 Autres directives intéressantes dans le fichier mk.conf

Maintenant que vous savez utiliser pkgsrc, il convient d'aller un peu plus loin dans la configuration du fichier mk.conf :

- LOCALBASE : par défaut, si rien n'est spécifié, tous les logiciels seront installés dans /usr/pkg mais l'on peut changer cela grâce à la directive : LOCALBASE?=un_autre_repertoire ;

- WRKOBJDIR : par défaut et comme je l'ai dit ci-dessus, quand un logiciel est compilé via pkgsrc, un répertoire work est créé. On peut très bien spécifier un répertoire work pour tous les logiciels que l'on installera avec la directive : WRKOBJDIR=mon_repertoire_work ;

- DISTDIR : j'ai parlé du téléchargement des archives contenant les sources, par défaut le répertoire nommé distfiles se place dans /usr/pkgsrc/ mais avec la directive DISTDIR?=mon_autre_repertoire, on peut changer la destination par défaut. Une purge régulière de ce répertoire peut se faire via la commande make distclean qui aura donc pour conséquence d'effacer toutes les archives qui y sont présentes ;

- FETCH_USING : les habitués de GNU/Linux téléchargent en général les archives via wget mais sous NetBSD, on utilise l'outil ftp par défaut, la directive FETCH_USING?=mon_programme permettra donc de changer le programme de téléchargement par défaut ;

- SKIP_LICENCE_CHECK : vous avez vu ci-dessus que l'on a spécifié la directive ACCEPTABLE_LICENSES. Si cela vous agace de devoir spécifier systématiquement votre accord avec une licence, vous pouvez ajouter la directive SKIP_LICENCE_CHECK=yes afin d'outrepasser cela. Il est à noter que la construction d'un logiciel s'arrête si l'accord avec la licence n'a pas été spécifié. La totalité des licences des logiciels contenus dans l'arbre pkgsrc sont disponibles dans ce répertoire : /usr/pkgsrc/licenses/ ;

- PASSIVE_FETCH : cette directive permet de spécifier que l'on utilisera le mode passif lors de l'utilisation de la commande ftp pour récupérer les archives.

J'arrête ici la liste des directives, je ne vous ai cité que celles qui me paraissaient pertinentes pour débuter avec pkgsrc. Si vous en voulez plus, je vous invite à consulter le fichier suivant : /usr/pkgsrc/mk/defaults/mk.conf qui liste une grande quantité d'autres directives. La documentation du pkgsrc guide[9] vous donnera également des explications plus approfondies.

3.4.2 Mets-moi tout ça au chaud

Après s'être donné la peine de compiler un certain nombre de logiciels, on peut très bien garder tout ça au chaud dans un coin, soit parce qu'on va installer une nouvelle machine avec les mêmes logiciels, en cas de crash d'un disque dur ou pour toute autre bonne raison. Nous allons utiliser pour ça l'utilitaire pkg_tarup. Si vous voulez créer le binaire pour un seul package, la commande sera très simple : pkg_tarup mon_logiciel et le binaire sera généré à l'emplacement où vous vous trouvez. Si vous voulez sauvegarder l'ensemble de vos logiciels[12] :

# cd /home/zat

# mkdir mypackages && cd mypackages

# for PKGNAME in 'pkg_info -e '*' | sort'; do \

# echo "Packaging $PKGNAME" \

# pkg_tarup -d "." "$PKGNAME" || echo "Warning : Packaging $PKGNAME failed." 1>&2 \

# done

La commande pkg_info -e '*' retourne le nom du logiciel sans son descriptif. Le répertoire mypackages contient maintenant tous les logiciels installés via pkgsrc sous forme binaire.

3.4.3 Effacer un logiciel

Comme il est simple d'installer un logiciel, il est encore plus enfantin de le supprimer. La commande pkg_delete est là pour ça. Si l'on revient sur les logiciels que j'ai installés précédemment, cette simple commande supprimera pkgfind :

# pkg_delete pkgfind-20050804

Une des particularités des systèmes BSD est de séparer la couche système de la couche applicative. En effet, lors du précédent article, on a pu se rendre compte que le système fonctionnait parfaitement de base et que nous avions installé le logiciel sudo que par la suite. Dans cet article, nous avons posé l'arbre pkgsrc puis compilé un logiciel. Nous pourrions très bien envisager, pour une raison ou une autre, de supprimer tout ce qui a attrait aux logiciels sur notre système, sans avoir aucun effet sur le système en lui-même (à part bien sûr de ne plus disposer des logiciels installés) :

# rm -Rf /usr/pkg && Rm -Rf /usr/pkgsrc

et voilà, l'OS à la serviette orange se retrouve nu comme au premier jour. C'est un peu radical, mais on va voir dans le chapitre suivant qu'un manque de prudence pourrait nous conduire à cela.

3.5 Mettre à jour les logiciels installés

Le framework pkgsrc est très bien pensé, mais la mise à jour de logiciel peut s'avérer périlleuse. En effet, mettre à jour un logiciel ne pose pas de problème, mais un logiciel dépend très fréquemment d'une multitude d'autres, et c'est là que les choses se corsent. On pourrait imaginer cela sous forme d'une chaîne, si un maillon défaille, la chaîne devient inutilisable. Sous Freebsd, par exemple, chaque port mis à jour à l'aide de portupgrade est d'abord sauvegardé pour être rollbacké si quelque chose se passait mal. Sous NetBSD, ce ne sera pas le cas, le logiciel mis à jour sera d'abord effacé (ainsi que ses dépendances) avant que la compilation de la nouvelle version se lance.

3.5.1 pkg_chk

Cet outil pourrait être comparé à portversion. Il s'agit de comparer la version d'un logiciel installé à celle présente dans l'arbre pkgsrc :

#pkg_chk -u -q

databases/php-pdo - php5-pdo-5.2.10 < php5-pdo-5.2.11

editors/vim - vim-7.2.254 < vim-7.2.262

editors/vim-share - vim-share-7.2.254 < vim-share-7.2.262

lang/php5 - php-5.2.10 < php-5.2.11

misc/rubygems - rubygems-1.3.5 < rubygems-1.3.5nb1

textproc/php5-dom - php5-dom-5.2.10 < php5-dom-5.2.11

www/ap-php - ap22-php5-5.2.10nb1 < ap22-php5-5.2.11nb1

www/apache22 - apache-2.2.13nb1 < apache-2.2.13nb2

Le flag -u est invoqué pour l’upgrade et -q pour ne lister que ce qui va être fait, sans lancer aucune opération. Nous connaissons ainsi les logiciels à mettre à jour.

3.5.2 Make update

La target update va donc lancer le processus de mise à jour du logiciel choisi et de toutes ses dépendances. Il commencera par une première phase qui consistera à désinstaller le logiciel et sa suite. Nous revoilà sur la problématique de tout à l'heure, l'incident de compilation qui rendrait le tout bancal.

3.5.3 Make replace

La target replace peut être un autre choix pour la mise à jour d'un logiciel. Cette commande ne remplacera que le logiciel en question, sans se soucier de ses dépendances. Retour à la case départ, l'accident de compilation nous guette.

3.5.4 pkg_comp

Bon, me direz-vous, mais que faire alors ? Il existe une solution parmi d’autres qui va permettre de construire tranquillement nos mises à jour sous forme de paquets binaires dans un environnement chrooté (vous voyez le lien avec pkgin et les multi repositories ?). Il s'agit de l'utilitaire pkg_comp (son installation via pkgsrc ne devrait pas vous poser de problème si vous avez bien suivi le début de l'article ;) ).

- création du template de pkg_comp : il s'agit d'un fichier qui reprend quelques directives de mk.conf et en comporte d'autres, comme l'emplacement des sets binaires utilisés lors de l'installation de l'OS :

# pkg_comp maketemplate

Le fichier se trouve donc dans ${home}/pkg_comp/default.conf (ici $HOME=root) et nous allons l'éditer afin de changer la directive DISTRIBDIR par :

DISTRIBDIR="/root/pkg_comp/binary"

Le répertoire binary contiendra un répertoire sets avec les sets cités dans default.conf.

Remarque : le répertoire /usr/src (qui contient les sources du système) doit exister même s'il est vide [13].

- création de l'environnement : # pkg_comp makeroot

- entrée dans le chroot :

# pkg_comp chroot

PKG_COMP ==> Installing new `pkg-vulnerabilities' file

/usr/pkgsrc/distfiles/pkg-vulnerabilities not found.

PKG_COMP ==> Mounting sandboxed filesystems

PKG_COMP ==> Entering sandbox `/var/chroot/pkg_comp/default'

pkg_comp:default.conf#

Afin de ne plus avoir le warning : /usr/pkgsrc/distfiles/pkg-vulnerabilities not found, il suffit de télécharger le fichier pkg-vulnerabilities et de le placer dans /usr/pkgsrc/distfiles :

# cd /usr/pkgsrc/distfiles && ftp http://ftp.netbsd.org/pub/NetBSD/packages/vulns/pkg-vulnerabilities

Remarque : pkg_comp va se servir du système principal afin de monter une partie du système de fichiers de l'hôte vers l'environnement chrooté via le système de fichiers nullfs. Cette astuce permettra entre autres de se servir de l'arbre pkgsrc du système hôte.

- génération de la liste des logiciels installés : je vous parlais précédemment de l'utilitaire pkg_chk. Il va également jouer un rôle ici, en générant la liste des logiciels installés dont pkg_comp va se servir pour compiler les mises à jour. Pour générer ce fichier, nous lancerons la commande :

pkg_chk -g

Un fichier nommé pkgchk.conf sera généré dans /usr/pkgsrc/ et contiendra la catégorie du logiciel ainsi que son nom, par exemple : lang/perl5 pour perl 5 qui se trouve dans la catégorie lang (pour language).

- compilation : nous y voilà, on lance la commande qui va construire tout ce petit monde et qui déposera le tout dans le répertoire /usr/pkgsrc/packages/All (pour changer cette destination, il suffit de changer la directive : REAL_PACKAGES=”/usr/pkgsrc/packages” dans le fichier template (default.conf) de pkg_comp) :

for pkgname in 'grep -v ^# /usr/pkgsrc/pkgchk.conf'; do pkg_comp build $pkgname; done

Si vous avez beaucoup de logiciels à mettre à jour, vous pouvez tranquillement lire le GLMF du mois (si ce n'est déjà fait) :).

- mise à jour des logiciels : prudence étant mère de sûreté, il vaut mieux s'assurer que la liste des binaires fraîchement compilés est la même que celle contenue dans pkgchk.conf afin d'éviter de rendre notre système bancal. Après cette petite vérification, on lance la commande :

# pkg_chk -uab

Le flag b pour forcer l'usage des binaires et u et a pour lancer les mises à jour (un man pkg_chk(8) vous donnera plus d'informations sur l'usage et la signification des flags de pkg_chk). Notre système est à jour, pas de mauvaise surprise, tout va bien.

A ce niveau, nous aurions très bien pu lancer pkgin pour qu'il fasse le même travail.

Conclusion

Voilà, déjà la fin de l'article. L'OS à la serviette orange est loin d'avoir livré tous ses secrets. Mais vous pouvez maintenant utiliser l'OS et sa myriade de logiciels disponibles (un peu plus de 10 000). Le site http://pkgsrc.se vous permettra de faire des recherches sur l'arbre, mais également de voir le contenu des logiciels via le Web.

N'hésitez surtout pas à vous lancer dans la création de nouveaux logiciels dans la branche WIP. Plus il y a de contributeurs, plus le nombre de logiciels disponibles va croître. pkgsrc dispose d'un channel officiel que vous pouvez rejoindre sur #pkgsrc@freenode, ou lire/poster sur les mailing lists dédiées à pkgsrc[14]. A bientôt pour le prochain épisode !

Références

[1] http://www.tsgk.net/cowboyz/linux.html

[2] http://imil.net/

[3] http://imil.net/pkgin/

[4] http://www.netbsd.org/docs/software/packages.html

[5] http://www.dragonflybsd.org

[6] http://www.dracolinux.org/

[7] http://leaf.dragonflybsd.org/mailarchive/users/2009-09/msg00053.html

[8] http://pkgsrc-wip.sourceforge.net/

[9] http://www.netbsd.org/docs/pkgsrc/configuring.html

[10] http://www.netbsd.org/gallery/presentations/joerg/eurobsdcon2009/wrapper.html

[11] http://www.netbsd.org/docs/pkgsrc/build.html#build.helpful-targets

[12] http://wiki.netbsd.se/How_to_save_your_packages

[13] « Zone0 : le serveur presque parfait », GNU/Linux Magazine France hors-série n°36, ou http://www.unixgarden.com/index.php/administration-systeme/zone0-le-serveur-presque-parfait

[14] http://mail-index.netbsd.org/index.html


Par le même auteur

Automatisez l'administration de vos serveurs en toute simplicité avec Rundeck !

Magazine
Marque
Linux Pratique
Numéro
86
|
Mois de parution
novembre 2014
|
Domaines
Résumé
Effectuer des tâches répétitives n'est pas source de plaisir en général. En effet, déployer un script, une application, ou toute autre chose plus d'un certain nombre de fois mérite une petite réflexion, un bon outil pour être efficace dans son travail et surtout, ne pas se lasser. Rundeck [1] semble remplir cette mission, du moins pour moi, c'est ce qu'il a fait !

DBeaver, la gestion facile de vos bases de données...

Magazine
Marque
Linux Pratique
Numéro
84
|
Mois de parution
juillet 2014
|
Domaines
Résumé

La plupart des bases de données possèdent toutes des outils pour leur gestion. Mais voilà, la quasi-totalité du temps, il s'agit d'outils propriétaires, ne fonctionnant pas sous GNU/Linux ou *BSD, très lourds, bref on veut s'en passer. DBeaver ne pourra se substituer à ces outils cependant, il offrira une très bonne alternative aux personnes désirant manipuler les bases de données de tout horizon à l'aide de leur OS favori et surtout avec un outil open source !

Areca, une solution de sauvegarde puissante pour tous

Magazine
Marque
Linux Pratique
Numéro
82
|
Mois de parution
mars 2014
|
Domaines
Résumé
On ne dira jamais assez que les données doivent être sauvegardées, que ce soit sur le disque dur (à plusieurs endroits, c'est mieux), sur un serveur, ou dans le cloud. Cela afin d'éviter une catastrophe qui risque de coûter cher, surtout si l'on veut à tout prix récupérer le contenu d'un disque dur et que l'on doit l'envoyer à une société spécialisée.

La facturation facile avec Simple Invoices

Magazine
Marque
Linux Pratique
HS n°
Numéro
26
|
Mois de parution
février 2013
|
Domaines
Résumé
Parmi la pléthore de logiciels du genre permettant de gérer les devis / la facturation, j'ai choisi Simple Invoices. Il est simple, rapide à prendre en main, personnalisable et 100 % web. Que demander de plus... à part des clients ? :)

Collabtive, la gestion de projet facile à prendre en main !

Magazine
Marque
Linux Pratique
HS n°
Numéro
26
|
Mois de parution
février 2013
|
Domaines
Résumé
Je vous avez parlé, dans le numéro de Linux Pratique N°71 (mai/juin 2012), d'une solution full web de gestion de projet nommée Feng Office. Je vous propose aujourd'hui un autre outil, plus simple, tout aussi agréable d'un point de vue fonctionnel et ergonomique : Collabtive.

Zentyal, un serveur pour l'entreprise à mettre entre toutes les mains

Magazine
Marque
Linux Pratique
Numéro
73
|
Mois de parution
septembre 2012
|
Domaines
Résumé
Qui n'a jamais rêvé de déployer une solution complète en entreprise, qui n'utilise que du logiciel libre et qui se configure à coup de clics, comme quand vous passez une commande sur le net en remplissant un formulaire et en cliquant sur un bouton pour valider le tout ? La société Zentyal a voulu concrétiser vos désirs à travers leur solution. En route pour la découverte de ce produit, qui je l'espère, vous donnera la possibilité de mettre en œuvre des solutions toujours mises de côté par crainte de la difficulté, du prix ou autre...