Plague : une infrastructure de fabrication de paquets RPM

Magazine
Marque
GNU/Linux Magazine
Numéro
137
Mois de parution
avril 2011


Résumé
Quand on organise la distribution d'un logiciel, il est souvent utile de pouvoir créer des paquets RPM pour des distributions multiples. Je n'expliquerai pas ici comment un paquet RPM est constitué ; une abondante documentation est disponible sur Internet. Je me contenterai de rappeler qu'un paquet source est constitué de l'archive des sources d'origine, de patches éventuels et d'un fichier spec qui contient les métadonnées et les instructions permettant de construire des paquets binaires au moyen de l'outil rpmbuild. Je vais par contre me concentrer sur la suite du processus : maintenant qu'on a notre paquet source, comment faire pour en tirer un ensemble de paquets binaires propres, pour des distributions dont on ne dispose pas forcément ?

Body

1. Quelques outils

À une extrémité du spectre, on trouve un outil rudimentaire, Mock (http://mock.fedorahosted.org/). Essentiellement, il installe une distribution minimale dans une cage chroot, y déballe le paquet source, installe ses dépendances et invoque rpmbuild pour générer les paquets binaires. On utilisera, par exemple, l'invocation suivante pour construire le paquet librep pour une Fedora 14 sur i386 :

% mock -r fedora-14-i386 librep-0.91.0-1.fc14.src.rpm

Plus qu'à patienter un petit moment (la création du chroot peut prendre du temps, heureusement un cache permet d'accélérer l'opération à partir de la deuxième fois) et vous finissez par obtenir vos paquets binaires tout neufs :

INFO: Done(librep-0.91.0-1.fc14.src.rpm) Config(fedora-14-i386) 14 minutes 40 seconds

INFO: Results and/or logs in: /var/lib/mock/fedora-14-i386/result

On retrouve effectivement les paquets et les journaux de l'opération dans le répertoire indiqué :

% ls /var/lib/mock/fedora-14-i386/result

build.log                               librep-debuginfo-0.91.0-1.fc14.i686.rpm

emacs-librep-el-0.91.0-1.fc14.i686.rpm librep-devel-0.91.0-1.fc14.i686.rpm

librep-0.91.0-1.fc14.i686.rpm           root.log

librep-0.91.0-1.fc14.src.rpm            state.log

Cette distribution fedora-14-i386 ne sort pas de nulle part ; vous pouvez voir la liste des fichiers de configuration correspondant aux différentes distributions supportées dans le répertoire /etc/mock. Sur une Fedora, il s'agit uniquement des versions supportées de Fedora elle-même et de CentOS avec le dépôt EPEL ; ceci dit, j'ai pu constater que Mock peut aussi fonctionner avec certaines versions d'OpenSUSE. A priori, n'importe quelle distribution utilisant Yum ou un format de dépôts compatible devrait être supportée, quitte à écrire la configuration qui va avec.

Mock dispose de quelques options intéressantes permettant, par exemple, de créer un lot de paquets en une seule commande ; malgré tout, son utilisation intensive demande pas mal de travail et on va assez vite se retrouver à l'entourer d'une batterie de scripts pour se simplifier la vie. C'est d'ailleurs l'approche retenue par les outils dont je vais parler dans la suite : se concentrer sur le contrôle d'accès ou la gestion des files d'attente ou des dépôts Yum et laisser le sale boulot à Mock.

À l'opposé de Mock, donc, on trouve des outils comme Koji (http://koji.fedorahosted.org/), qui sert à construire tous les paquets de Fedora et de son dépôt auxiliaire EPEL. C'est sûrement très adapté à Fedora, avec ses centaines ou milliers de contributeurs qui travaillent sur des milliers de paquets ; pour une structure plus petite (dans mon cas, une ou deux personnes et quelques dizaines de paquets), son déploiement ォ quelque peu complexe サ ne se justifie absolument pas.

Par contre, Fedora a produit un autre outil, moins élaboré mais plus simple à déployer que Koji : Plague (http://fedoraproject.org/wiki/Projects/Plague). Il a longtemps servi à l'élaboration des dépôts Fedora Extras et EPEL, et il est encore utilisé par des projets comme CentOS (pour ses versions 4 et 5) ou Planet CCRMA (http://ccrma.stanford.edu/planetccrma/software/). Même s'il n'est plus réellement développé, ses utilisateurs sont assez nombreux pour le maintenir dans un état utilisable (la version distribuée avec Fedora contient d'ailleurs quelques patches utiles). C'est lui que je vais vous présenter dans la suite.

2. Architecture de Plague

Une installation de Plague se compose d'un serveur (plague-server), d'une ou plusieurs machines de compilation (qui font tourner le démon plague-builder) et d'un ou plusieurs clients (le plus souvent des stations de travail équipées du logiciel plague-client). Ces trois composantes communiquent entre elles par des canaux XML-RPC, éventuellement chiffrés en SSL.

Le serveur tient à jour la liste des machines de compilation actives et un historique des paquets construits. En pratique, elle fait aussi la plupart du temps office de dépôt Yum, au moins pour les machines de compilation.

Un client peut lui soumettre une tâche composée d'un paquet source et d'une distribution. Le serveur va alors faire construire aux machines de compilation les paquets binaires pour toutes les architectures supportées pour la distribution.

Le serveur va ensuite récupérer les paquets binaires nouvellement construits, les déposer dans un répertoire correspondant à la distribution, y construire un dépôt Yum et avertir par courrier électronique l'utilisateur ayant soumis la tâche et l'administrateur du dépôt. Le serveur stocke également les journaux de compilation. Si jamais la tâche échoue, l'utilisateur recevra également un mail comportant un lien vers ces journaux afin de pouvoir diagnostiquer le problème.

Dans l'exemple qui va suivre, nous utiliserons deux machines (virtuelles en l'occurrence, mais ça a peu d'importance) : plague, sous CentOS 5, qui fera tourner plague-server et une instance de plague-builder, et builder, sous Fedora 14, qui fera tourner un deuxième plague-builder. Le plague-builder de la machine plague sera configuré pour construire les paquets pour CentOS 5 uniquement, alors que celui de la machine builder acceptera également de construire des paquets pour Fedora 13 et 14. En effet, le format des fichiers RPM a changé avec la sortie de Fedora 11, et la version de RPM fournie avec CentOS 5 est incapable de manipuler les paquets des versions récentes de Fedora, ce qui empêche le Mock de CentOS 5 d'installer ces versions de Fedora. L'inverse est par contre parfaitement possible.

3. Installation du serveur

Pour installer un serveur Plague sur une CentOS 5 sortie du carton, il va falloir aller chercher quelques paquets dans le dépôt Fedora EPEL. Le plus simple est d'activer purement et simplement le dépôt :

# rpm -Uvh http://mirrors.ircam.fr/pub/fedora/epel/5/x86_64/epel-release-5-4.noarch.rpm

La version 5-4 du paquet epel-release est la dernière en date au moment où j'écris ces lignes, il se peut que ça change à l'avenir. Attention également à la compatibilité pas toujours parfaite entre EPEL et les dépôts CentOS addons et extras (activés par défaut) ; dans le cas présent, tout se passe bien, mais sait-on jamais...

Passons maintenant au vif du sujet : l'installation du serveur. Essentiellement, il s'agit d'un simple paquet :

# yum install plague

C'était la partie facile. Le paquet ne contient pas de configuration par défaut ; plague-server va la créer au premier démarrage. Lançons-le donc (il devrait planter après le premier démarrage, mais c'est sans importance) avant d'éditer la configuration pour l'adapter à nos besoins :

# /etc/init.d/plague-server start

Voici ce que donne le fichier /etc/plague/server/plague-server.cfg une fois édité comme il faut :

[Database]

engine = sqlite

[Directories]

repo_dir = /var/www/html/repodir

server_work_dir = /var/www/html/buildlogs

target_configs_dir = /etc/plague/server/targets

tmpdir = /tmp

[CVS]

use_cvs = no

[General]

hostname = plague.local

[UI]

use_ssl = no

log_url = http://plague.local/buildlogs/

guest_allowed = yes

port = 8887

[sqlite Engine]

timeout = 3

database = /etc/plague/server/jobs.db

[Builders]

use_ssl = no

builders = plague.local:8888 builder.local:8888

[Email]

success_emails = rpms@example.com

email_from = buildsys@example.com

admin_emails = buildsys@example.com

Quelques remarques en vrac :

  • - Il va falloir créer les répertoires mentionnés dans la section Directories. Nous allons reparler de leur contenu un peu plus loin.
  • - Ici, j'utilise une base de données SQLite ; dans le cas d'une installation un peu plus importante, MySQL ou PostgreSQL peuvent s'avérer plus adaptés. Sur mon instance de production, j'ai déjà vu des cas de corruption de la base SQLite après avoir soumis 100 ou 150 tâches d'un coup ; je ne sais pas si ce problème est corrigé dans les versions actuelles.
  • - L'option hostname doit contenir un nom d'hôte ou une adresse IP correspondant à l'interface sur laquelle le démon doit écouter. Si elle est vide, le démon se lancera bien mais ne fonctionnera pas correctement.
  • - Les adresses mails mentionnées dans la section Email doivent bien entendu être remplacées par de vraies adresses de votre domaine. Elles servent juste à construire les courriers que le serveur vous enverra, elles n'ont aucune signification ォ magique サ pour lui.
  • - J'ai soigneusement désactivé l'utilisation de SSL, étant sur un brin de réseau totalement contrôlé. Si ce n'est pas votre cas, il va falloir l'activer et générer les certificats adéquats.
  • - Il est question d'un serveur web dans la section UI ; si vous voulez vous simplifier la vie (et pouvoir distribuer vos paquets RPM directement depuis votre serveur Plague), installer le paquet httpd et activer le service qui va avec est probablement une bonne idée.
  • - Les noms plague.local et builder.local sont de vrais noms d'hôtes, valables uniquement sur le réseau local où ils sont annoncés en mDNS. Le serveur mDNS est configuré comme il faut par défaut tant sous CentOS que sous Fedora ; il s'agit du démon avahi-daemon, qui fait partie du paquet avahi et qui est normalement lancé par défaut. Reste à installer les bibliothèques client qui vont avec sur toutes les machines (elles sont normalement elles aussi bien configurées par défaut) :
  • # yum install nss-mdns

  • Bien entendu vous pouvez préférer le DNS, un fichier /etc/hosts ou toute autre méthode de résolution des noms ; j'ai juste choisi mDNS pour des raisons de simplicité.
  • Plus qu'à lancer le serveur :

# /etc/init.d/plague-server start

Starting plague-server:                                    [ OK ]

# /etc/init.d/plague-server status

plague-server dead but pid file exists

Quid ? Un coup d'?il dans le fichier /var/log/plague-server.log nous apprend que ォ You need at least one target to do anything useful サ. Certes. Il va donc falloir définir quelques cibles dans le répertoire /etc/plague/server/targets dont il a été brièvement question un peu plus haut. Commençons avec une seule, dans le fichier /etc/plague/server/targets/centos-5.cfg :

[General]

distro = centos

target = 5

repo = epel

testing = no

repo_script =

[Arches]

base_arches = i386 x86_64

optional_arches = i586 i686 noarch

[Aliases]

cvs_alias =

user_aliases = epel5

[Additional Packages Arches]

kernel = i686

[CVS]

cvs_root =

cvs_rsh =

Quelques remarques :

  • - Nous n'utiliserons pas CVS, j'ai donc laissé les options correspondantes de côté.
  • - L'option user_aliases permet de définir un ou plusieurs noms courts qui seront bien pratiques vus du client. Ici, l'alias epel5 désigne la cible centos-5-epel (définie dans la section General).
  • - Le sens des différentes architectures mentionnées est assez explicite. Par défaut, cette cible correspond à des versions i386 et x86_64 des paquets ; elle peut aussi servir à générer des versions i586, i686 et noarch si elles sont explicitement définies dans le fichier spec, et le paquet kernel sera automatiquement compilé en version i686 en plus des autres.

Une fois ce fichier et les répertoires mentionnés dans le fichier plague-server.cfg à leur place, on peut enfin lancer le démon :

# /etc/init.d/plague-server start

Starting plague-server:                                    [ OK ]

# /etc/init.d/plague-server status

plague-server (pid 2552) is running...

Reste à automatiser son démarrage au boot de la machine :

# chkconfig plague-server on

Voilà, nous avons maintenant un serveur Plague opérationnel et parfaitement incapable de faire quoi que ce soit d'utile, faute de machines de compilation. Nous allons nous en occuper un peu plus tard, une fois le client installé.

4. Le client

ヌa se passe cette fois-ci sur ma station qui tourne sous Fedora. Le paquet plague-client fait partie de la distribution, on peut l'installer directement ; si vous voulez l'installer sur une machine RHEL (ou un clone genre CentOS), vous devrez au préalable activer le dêpôt EPEL.

# yum install plague-client

Et voilà, c'est prêt ! Enfin, presque, il reste à le configurer. ヌa se passe sur le compte de l'utilisateur, dans un fichier $HOME/.plague-client.cfg dont le contenu doit ressembler à ça :

[User]

email = arnaud@example.com

[Server]

use_ssl = no

upload_user = arnaud

allow_uploads = yes

address = http://plague.local:8887

Bien entendu, vous devrez adapter l'adresse mail et le nom de l'utilisateur. Voyons la récompense :

% plague-client list_builders

Builders:

------------------------------------------------------------------------------------------

plague.local unavailable

builder.local unavailable

On obtient bien une réponse du serveur qui nous dit qu'il n'a aucune machine de compilation disponible.

Une remarque au passage : tout le monde peut consulter l'état du serveur, sans contrôle d'accès. Pour le moment, le compte utilisateur mentionné dans la configuration du client n'existe même pas sur le serveur (il servira, par contre, pour lancer des compilations). Si ça peut poser un problème dans votre contexte, il vous reste deux possibilités : le pare-feu (si c'est possible, c'est-à-dire s'il suffit de restreindre l'accès depuis des machines plutôt que depuis des comptes utilisateurs) ou SSL (ce qui nous entraînerait trop loin pour cet article).

5. Les machines de compilation

Pour commencer, nous allons faire tourner plague-builder sur la machine plague elle-même ; la deuxième machine de compilation aura besoin de quelques fichiers en plus, mais le principe sera très similaire. Commençons donc par installer le paquet idoine :

# yum install plague-builder

Comme pour le serveur, le premier lancement ne fait que préparer le terrain :

# /etc/init.d/plague-builder start

Starting plague-builder: Config file did not exist. Writing /etc/plague/builder/plague-builder.cfg with default values.

No useable mock buildroots configured. Exiting...

[FAILED]

En clair, plague-builder génère lui-même une partie de sa config, mais il va encore falloir travailler un peu. Commençons par jeter un ?il à ce fichier /etc/plague/builder/plague-builder.cfg ; par défaut, son contenu est à peu près correct, nous allons simplement ajouter le nom de la machine et enlever la partie qui concerne SSL. Au final, dans le cas de ma machine plague.local, il doit ressembler à ça :

[SSL]

use_ssl = no

[Directories]

target_configs_dir = /etc/plague/builder/targets

builder_work_dir = /var/lib/plague/builder

[Network]

fileserver_port = 8889

xmlrpc_port = 8888

hostname = plague.local

[General]

debug = yes

builder_cmd = /usr/bin/mock

builder_user = plague-builder

Reste à s'occuper de ces ォ useable mock buildroots サ dont il était question il y a quelques lignes. Comme le fichier de config le laisse entendre, elles doivent se trouver dans le répertoire /etc/plague/builder/targets (que nous allons créer nous-mêmes, puisque le paquet plague-builder ne s'en est pas occupé) ; pour le moment, nous allons en créer deux, qui correspondent à la cible centos-5 du serveur dont nous avons parlé un peu plus haut. Pourquoi deux ? Une par architecture, simplement (c'est-à-dire x86_64 et i386 ; Plague est suffisamment intelligent pour reconnaître, par exemple, i686 comme une variante de i386). Voici donc le contenu du fichier /etc/plague/builder/targets/centos-5-i386-epel.cfg :

[General]

distro = centos

target = 5

basearch = i386

repo = epel

mock_config = epel-5-i386

et celui du fichier /etc/plague/builder/targets/centos-5-x86_64-epel.cfg :

[General]

distro = centos

target = 5

basearch = x86_64

repo = epel

mock_config = epel-5-x86_64

À noter :

- Les variables distro, target et repo correspondent à la configuration de la cible centos-5 du serveur.

  • - La variable mock_config, quant à elle, correspond au nom de la racine Mock correspondante (c'est-à-dire aux fichiers /etc/mock/epel-5-i386.cfg et /etc/mock/epel-5-x86_64.cfg, respectivement).

Nous pouvons maintenant lancer le serveur de compilation :

# /etc/init.d/plague-builder start

Starting plague-builder:                                   [ OK ]

# /etc/init.d/plague-builder status

plague-builder (pid 17351) is running...

Retournons un moment sur le client, pour voir ce que ça donne :

% plague-client update_builders

Nous voyons bien apparaître notre serveur de compilation au bout de quelques secondes :

% plague-client list_builders

Builders:

------------------------------------------------------------------------------------------

plague.local i386 i486 i586 i686 athlon noarch x86_64 amd64 ia32e alive

builder.local unavailable

Reste à configurer notre deuxième serveur de compilation sur la machine builder. Elle tourne sous Fedora, qui fournit directement le paquet plague-builder ; pas besoin de dépôt supplémentaire, donc, contrairement à CentOS. En dehors de ça, ça se passe exactement de la même façon, si ce n'est qu'il va falloir ajouter les cibles correspondant à Fedora. Voici par exemple le fichier /etc/plague/builder/targets/fedora-14-x86_64-base.cfg :

[General]

distro = fedora

target = 14

basearch = x86_64

repo = base

mock_config = fedora-14-x86_64

Une fois les fichiers cibles correspondant à toutes les versions éditées et plague-builder lancé, nous pouvons revenir sur notre client :

% plague-client list_builders

Builders:

------------------------------------------------------------------------------------------

plague.local i386 i486 i586 i686 athlon noarch x86_64 amd64 ia32e alive

builder.local i386 i486 i586 i686 athlon noarch x86_64 amd64 ia32e alive

Voilà, c'est gagné ! Reste à ajouter les nouvelles distributions au serveur plague lui-même ; voici par exemple les sections General et Aliases du fichier /etc/plague/server/targets/fedora-14-base.cfg sur la machine plague :

[General]

distro = fedora

target = 14

repo = base

testing = no

repo_script =

[Aliases]

cvs_alias =

user_aliases = fc14

Le reste du fichier est identique à son homologue pour CentOS 5. Reste à redémarrer le serveur :

# /etc/init.d/plague-server restart

Notre système de compilation est maintenant presque opérationnel ! Il reste à créer le(s) compte(s) utilisateur(s) sur le serveur.

6. Finalisation et première compilation

Dans mon cas, j'ai bêtement créé mon compte à l'aide de la commande useradd et j'y ai déposé ma clé publique SSH. Vous avez le choix de la méthode ; tout ce qui compte, c'est que les utilisateurs puissent utiliser la commande scp. D'ailleurs ils peuvent très bien se contenter d'un shell restreint type scponly.

Encore une parenthèse sur la sécurité du système : pour pouvoir compiler des paquets, il suffit d'avoir le droit de déposer des fichiers par scp dans les sous-répertoires du répertoire /var/www/html/buildlogs/srpm_upload_dir du serveur. Il doit y en avoir un par distribution, et le démon plague-server les crée grands ouverts (en mode 0777) s'ils n'existent pas lors de son démarrage. Vous pouvez par contre fixer les permissions explicitement, si les répertoires en question existent, le démon n'y touchera pas. En pratique, il est souvent plus intéressant d'utiliser une machine dédiée pour le serveur Plague et d'y créer uniquement les comptes des utilisateurs autorisés, ça évite bien des problèmes de contrôle d'accès. Pour ma part, j'utilise un isolateur linux-vserver dédié depuis plusieurs années sans aucun problème. Refermons la parenthèse et continuons, on y est presque !

Voilà, nous allons enfin pouvoir compiler notre premier paquet. En l'occurrence, j'ai téléchargé le paquet source de cfengine depuis le dépôt EPEL 5 et je vais le compiler pour... CentOS 5 avec EPEL, c'est juste pour l'exercice. Il reste une dernière épreuve : la syntaxe de la commande plague-client est un peu spéciale. Un côté rassurant tout de même : il suffit de lancer la commande sans argument pour avoir une aide en ligne spartiate, certes, mais suffisante. Voici donc la commande miracle :

% plague-client build cfengine cfengine-2.1.22-2.el5.src.rpm epel5

En réponse, le client Plague nous montre qu'il exécute scp pour pousser le paquet source, avant de nous renvoyer un numéro de tâche :

Executing: /usr/bin/scp /home/arnaud/cfengine-2.1.22-2.el5.src.rpm arnaud@plague.local:/var/www/html/buildlogs/srpm_upload_dir/centos-5-epel/cfengine-2.1.22-2.el5.src.rpm

cfengine-2.1.22-2.el5.src.rpm                 100% 3607KB   1.2MB/s   00:03

Package cfengine enqueued. Job ID: 1.

On peut ensuite suivre l'évolution de la compilation, toujours avec le client Plague :

% plague-client list

1: cfengine (/var/www/html/buildlogs/srpm_upload_dir/centos-5-epel/cfengine-2.1.22-2.el5.src.rpm) arnaud@example.com   building/in-progress

builder.local(x86_64): 362e100c160b9602f20ce9e9db7dc6f47df6fe73 running/building

plague.local(i386): a8ecea58c2d8c3540edbe16a9fc41b7cf2624b68 running/init

Ici, le paquet pour x86_64 est en cours de construction sur la machine builder, tandis que la machine plague commence à s'occuper de la version i386. Si tout se passe bien, au bout d'un petit moment (ou d'un grand moment si, comme chez moi, tout ça tourne dans des machines virtuelles sur un PC trop chargé), vous recevrez un courrier électronique pour vous avertir que votre paquet est prêt :

1 (cfengine): Build on target centos-5-epel succeeded.

Build logs may be found at http://plague.local/buildlogs/centos-5-epel/1-cfengine-2.1.22-2.el5/

Bien sûr, l'URL n'est valide que si vous avez bien un serveur web qui tourne sur la machine plague ; avec la configuration décrite ici, un Apache sorti du carton convient tout à fait. En cas d'erreur lors de la compilation, vous recevrez également un pointeur vers une URL où vous pourrez lire les logs de compilation.

Vous pouvez également constater que la compilation est terminée en interrogeant le serveur :

% plague-client list

1: cfengine (/var/www/html/buildlogs/srpm_upload_dir/centos-5-epel/cfengine-2.1.22-2.el5.src.rpm) arnaud@example.com   needsign/success

builder.local(x86_64): 362e100c160b9602f20ce9e9db7dc6f47df6fe73 done/done

plague.local(i386): a8ecea58c2d8c3540edbe16a9fc41b7cf2624b68 done/done

Nous allons revenir un peu plus loin sur la signification de cet état needsign. En attendant, maintenant que la compilation a réussi, où trouver les paquets binaires ? Dans le répertoire pointé par l'option repo_dir de la config du serveur Plague. Avec le serveur web dont je parle juste au-dessus, le répertoire en question est accessible à l'URL http://plague.local/repodir/. Notez au passage que ses sous-répertoires contiennent des dépôts Yum directement utilisables, nous allons bientôt voir quoi en faire.

7. Finitions

Il est d'usage de signer (avec GnuPG) les paquets RPM qu'on distribue. Plague ne s'en occupera pas lui-même, il va falloir écrire vous-même un script pour le faire, à moins de vouloir vous en occuper à la main (c'est la signification de l'état needsign dont je parlais au paragraphe précédent). Si vous écrivez un script, il vaut mieux en profiter pour enlever les tâches terminées de la base de données ; un plague-client list sur une base contenant 5000 ou 6000 tâches peut prendre un certain temps, même avec une base MySQL.

J'avoue ne pas avoir de tel script à vous proposer ; vous pouvez trouver ceux qui servaient à publier Fedora Extras et les anciennes versions d'EPEL dans le CVS de Fedora. Pour les télécharger :

% cvs -d :pserver:anonymous@cvs.fedoraproject.org:/cvs/fedora co extras-buildsys

Ce module extras-buildsys contient essentiellement Plague lui-même, mais aussi les scripts de publication dans le sous-répertoire utils/pushscript/ ; toutefois, ne vous attendez pas à pouvoir les utiliser sans un peu d'huile de coude et de lecture de code.

Dans tous les cas, vous pouvez utiliser les dépôts Yum générés par Plague directement sur vos machines de compilation ; pour cela, il va falloir les ajouter aux fichiers de config de Mock. Pour CentOS 5 avec EPEL, par exemple, ça ressemblera à ça (indépendamment de l'architecture) :

[plague-local]

name=plague-local

baseurl=http://plague.local/repodir/centos-5-epel/

enabled=1

gpgcheck=0

Un dernier petit truc bien pratique : pour automatiser au maximum la procédure de compilation, je stocke le contenu du paquet source (mais pas le paquet source lui-même) dans un répertoire avec le Makefile suivant :

SPECS = *.spec

TARGETS = epel5 fc13 fc14

targets: $(TARGETS) clean

srpms: $(SPECS)

rpmbuild -bs --nodeps --define "_source_filedigest_algorithm md5" \

--define "_binary_filedigest_algorithm md5" --define "_srcrpmdir \

$$(pwd)" --define "_sourcedir $$(pwd)" $<

lint: $(SPECS)

rpmlint $(SPECS)

epel% fc%: srpms

for srpm in *.src.rpm ; do name=$$(rpm -qp --queryformat %{NAME} \

$$srpm) ; plague-client build $$name $$srpm $@ ; done

clean:

rm -f *.src.rpm

Plus qu'à taper make dans le répertoire en question pour générer le paquet source, l'envoyer au serveur de compilation et faire le ménage. Les définitions "_source_filedigest_algorithm md5" et "_binary_filedigest_algorithm md5" servent à générer des paquets compréhensibles par la version de RPM installée sur notre serveur sous CentOS 5, même depuis une Fedora récente ; elles sont nécessaires depuis le changement de format des paquets dont je parlais au début de l'article.

Conclusion

Avec ce qui précède, vous avez maintenant à votre disposition une machine à empaqueter les RPM qui marche plutôt bien, à condition de consacrer un minimum de temps à sa maintenance (il s'agit essentiellement de nettoyer la base de données). Je n'ai pas vraiment abordé le sujet de la distribution, mais ça devrait être nettement plus simple ; il suffit de disposer d'un serveur web et d'un bout de script pour y pousser les paquets. Je ne vous proposerai pas mes propres scripts vu leur état déplorable, mais je vous encourage à vous pencher sur ceux de Fedora et à écrire les vôtres si ceux-ci ne vous conviennent pas.




Article rédigé par

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

Les derniers articles Premiums

Les derniers articles Premium

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.

Le combo gagnant de la virtualisation : QEMU et KVM

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

C’est un fait : la virtualisation est partout ! Que ce soit pour la flexibilité des systèmes ou bien leur sécurité, l’adoption de la virtualisation augmente dans toutes les organisations depuis des années. Dans cet article, nous allons nous focaliser sur deux technologies : QEMU et KVM. En combinant les deux, il est possible de créer des environnements de virtualisation très robustes.

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