asyd's blog

Appel à conférences, sysadmin #4

asyd — Wed, 29 Feb 2012 08:44:54 +0000

Bonjour à tous,

la quatrième édition des séminaires sysadmins se tiendra les 26 et 27 avril sur Paris. Comme les précédentes éditions, une journée sera dédiée à un thème particulier et cette fois c’est autour du monitoring et métrologie. La deuxième journée n’a pas de thème spécifique, donc toute proposition est la bienvenue !

Du modèle EAV, ou comment s’arracher les cheveux, pour plein de raisons

asyd — Mon, 02 Jan 2012 11:27:20 +0000

Dans le cadre du projet SOIF (qui fera l’objet d’un prochain billet), je travaille actuellement sur un job de transformation d’une base Puppet facts pour injecter dans iTop.

Avant tout, un peu de contexte : Puppet intègre la commande facter qui renvoie tout un ensemble d’informations sous la forme attribut=valeur, et qui est facilement extensible, bref c’est très intéressant. Là où le bat blesse, c’est que – logiquement – ces informations sont stockées en base de données en utilisant le modèle de conception EAV pour Entity Attribute Value.

Ce qui donne :

+------------+--------------+------+-----+---------+----------------+
| Field      | Type         | Null | Key | Default | Extra          |
+------------+--------------+------+-----+---------+----------------+
| id         | int(11)      | NO   | PRI | NULL    | auto_increment |
| name       | varchar(255) | NO   | MUL | NULL    |                |
| updated_at | datetime     | YES  |     | NULL    |                |
| created_at | datetime     | YES  |     | NULL    |                |
+------------+--------------+------+-----+---------+----------------+

mysql> desc fact_values;
+--------------+----------+------+-----+---------+----------------+
| Field        | Type     | Null | Key | Default | Extra          |
+--------------+----------+------+-----+---------+----------------+
| id           | int(11)  | NO   | PRI | NULL    | auto_increment |
| value        | text     | NO   |     | NULL    |                |
| fact_name_id | int(11)  | NO   | MUL | NULL    |                |
| host_id      | int(11)  | NO   | MUL | NULL    |                |
+--------------+----------+------+-----+---------+----------------+

Donc, pour obtenir par exemple la fact serialnumber pour un hôte donné, cela donne quelque chose du genre :

select fact_values.value FROM fact_values LEFT JOIN hosts ON fact_values.host_id = hosts.id LEFT JOIN fact_names ON fact_values.fact_name_id = fact_names.id WHERE hosts.name = 'xxx' AND fact_names.name = 'serialnumber';

Mais maintenant, retour à mon objectif : travailler par lot, c’est à dire pour tous les enregistrements de la table hosts. Se pose donc la question de comment faire pour obtenir la liste de tous les hôtes, avec la valeur serialnumber, à froid, pour l’expert SQL que je ne suis pas, mon premier jet à donné :
SELECT hosts.id, fact_values.value FROM hosts LEFT JOIN fact_values ON hosts.id = fact_values.host_id LEFT JOIN fact_names ON fact_names.id = fact_values.fact_name_id WHERE fact_names.name = 'serialnumber';
qui semble fonctionné à priori, mais, MAIS, cela ne renvoie que les enregistrements pour lesquels il existe la valeur serialnumber.

Après de nombreuses recherches, il semblerait que la seule solution à mon problème soit :

SELECT
  hosts.id,
  (SELECT fact_values.value
    FROM fact_values
    JOIN fact_names
     ON fact_names.id = fact_values.fact_name_id
    WHERE fact_names.name = 'serialnumber'
     AND fact_values.host_id = hosts.id) as serialnumber,
FROM hosts;

et là, on le voit tout de suite, ça devient compliqué. Pourquoi ? parce que je n’ai pas seulement besoin du serialnumber mais de nombreux autres champs, et pour chaque champ que je veux, je dois donc rajouter un nouveau SELECT, je vous laisse deviner l’impact sur les performances.

Bref, EAV, ça pue. Bien évidemment si vous avez une autre solution, n’hésitez pas à commenter !

Astuce : trouver le caractère UTF8 associé à un code hexa

asyd — Thu, 29 Dec 2011 09:24:47 +0000

Dans mes péripéties mod_security, j’ai eu l’erreur suivante :

[Thu Dec 29 08:44:22 2011] [error] [client xx.21.3.31] ModSecurity: Warning. Pattern match "\\W{4,}" at ARGS:typeLibelle. [file "/usr/local/apache2/conf/crs/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "507"] [id "960024"] [rev "2.2.2"] [msg "SQL Character Anomaly Detection Alert - Repetative Non-Word Characters"] [data " \\xc3\\xa0 "] [hostname "dev.xxxx.fr"] [uri "/xxxx"] [unique_id "TvwaVgpArWEAAHu7CtMAAAAG"]

Et la question qui tue : à quoi correspond \\xc3\\xa0 ? Je me doutais que c’était un caractère UTF8, j’ai donc demandé à mon expert jeu de caractères (aka Laurent Blume) qui m’a donné l’astuce suivante :

Avant tout, avoir un système en UTF-8
Lancer vim (pas besoin d’ouvrir un fichier)
Taper un caractère accentué, par exemple é
Convertir en hexadécimal à l’aide de la commande “:%!xxd”, ce qui va donner quelque chose du genre “0000000: c3a9 0a”
Modifier le c3a9 en c3a0
Reconvertir en texte, à l’aide de la commande “:%!xxd -r”, et miracle on obtient le caractère “à” !

Séminaire #3, le programme

asyd — Mon, 03 Oct 2011 09:09:18 +0000

La troisième édition des séminaires sysadmin se tiendra les 20 et 21 Octobre à l’IRILL (merci à eux aux passage).

Le programme (non définitif) est maintenant disponible ! Les inscriptions seront ouvertes d’ici peu.

Premier pas avec mod_security

asyd — Sun, 19 Jun 2011 14:00:18 +0000

Un client m’a demandé récemment si je pouvais jeter un œil à mod_security pour ses besoins de protections d’URL (WAF, en anglais Web Application Firewall, plus d’infos sur l’article Wikipedia). En quelques mots, mod_security est un module Apache – comme son nom l’indique – qui apporte donc une fonctionnalité de filtre relativement avancé, mais avec l’avantage d’être opensource et donc gratuit. De plus, il vient avec un ensemble de règles déjà établies qui sont le fruit du travail du groupe OWASP, qui se définit comme un 501c3 not-for-profit worldwide charitable organization focused on improving the security of application software.

L’objectif de ma première approche de mod_security est relativement simple puisqu’il consiste à logger toutes les tentatives d’authentification avec un nom d’utilisateur qui contient des caractères hormis [a-zA-Z0-9]. Voici un récapitulatif de l’architecture (simple) mise en œuvre :

Distribution : CentOS
un apache (où sera installé le module mod_security) en frontal devant un Tomcat, en utilisant le mod_proxy (en HTTP)
un Tomcat avec une application de test nommée Xebia Travel développée par Xebia
L’authentification des utilisateurs sur l’application Xebia Travel s’effectue via un POST au travers d’un formulaire, avec les variables j_username et j_password

Une fois installé mod_security (depuis le dépôt EPEL), et quelques petites heures de recherche, voici le résultat que j’ai obtenu :

SecAuditLog /var/log/httpd/ecommerce-audit.log SecDebugLog /var/log/httpd/ecommerce-security.log SecDebugLogLevel 3 SecAuditEngine relevantonly


                SecRequestBodyAccess On

SecRule ARGS:j_username "!@rx ^([A-Za-z0-9]+)$" auditlog,id:10000

Quelques explications :

Les directives SecAuditLog, SecDebug, SecDebugLogLevel et SecAuditEngine sont relativement explicites. Elles permettent en effet de configurer les différents fichiers de logs et d’audit, ainsi que leur verbosité
La directive SecRequestBodyAccess est très importante, puisqu’elle permet de dire à mod_security d’analyser non pas seulement les en-têtes des requêtes mais également le corps. Pourquoi est-ce important ? Parce qu’avec les formulaires de type POST, les variables sont passées non pas en en-tête, mais bien dans le corps du message. Sans cette directive, il est donc impossible d’analyser les arguments des formulaires de type POST
et enfin, la directive la plus importante à savoir SecRule qui est exécutée à chaque fois qu’une requête est effectuée avec l’argument j_username (POST ou GET), et je vérifie au travers d’une expression rationnelle (regex) qu’elle contient d’autres caractères que [A-Za-z0-9], auquel cas je lui définie l’action auditlog, en lui demendant d’identifier cette règle avec l’id 10000, ce qui s’avère pratique pour l’analyse du fichier d’audit.

Bien entendu, ce billet ne montre qu’un centième des utilisations possible de mod_security, mais si cela peut aider à commencer, sur ce, à bientôt !

Séminaire #3, appel à conférences

asyd — Wed, 15 Jun 2011 08:20:59 +0000

Bonjour à tous,

courant fin septembre 2011 se tiendra la troisième édition des séminaires de la liste francophone sysadmin (le programme de la deuxième édition est toujours en ligne, et surtout les vidéos et présentations). Cette troisième édition se tiendra sur deux journées, la première consacrée à des sujets autour de la conformité de configuration (tel que Chef, Puppet, etc.), la seconde avec des sujets divers et variés. Si vous êtes intéressé par faire une présentation, je vous invite à me contacter par mail à asyd at asyd dot net, et/ou en laissant un commentaire sur ce présent billet.

Merci de votre participation !

EJBCA Créer un certificat administrateur en ligne de commande

asyd — Wed, 04 May 2011 05:39:37 +0000

De retour chez un client après quelques années d’absences, je me retrouve avec un certificat d’administrateur expiré sur la PKI de test. Voici la procédure de création d’un nouveau certificat, le tout en ligne de commande, forcément :

./bin/ejbca.sh ra adduser bbonfils00 foo123 "cn=Bruno Bonfils,UID=bbonfils,O=Customer,C=FR" NULL AdminCA1 bruno@opencsi.com 1 P12 ENDUSER EE_PKI_ADMINISTRATOR ./bin/ejbca.sh ra setclearpwd bbonfils00 foo123 ./bin/ejbca.sh batch

Bien entendu il faut que le certificat corresponde au profil. Si besoin, vous devez pouvoir utiliser le profil EMPTY en ne spécifiant uniquement le CN. Il faut maintenant obtenir le numéro de série du certificat.

./bin/ejbca.sh ra getusercert bbonfils00

Copier / coller le certificat dans un certificat, puis extraire le numéro de série à l’aide de la commande OpenSSL :

openssl x509 -in /tmp/bbonfils0.pem -noout -serial serial=4AEDB10E68DC69B6

Et finalement, identifier un groupe d’administrateur, puis rajouter l’administrateur dans ce groupe :

./bin/ejbca.sh admins listgroups Using JBoss JNDI provider... PKI CA Administrators (1 admin) Super Administrator Group (2 admins) ./bin/ejbca.sh admins addadmin "Super Administrator Group" "AdminCA" "WITHSERIALNUMBER" EQUALCASEINS 4AEDB10E68DC69B6

Le futur de la sécurité Web, ce n’est pas le https

asyd — Mon, 04 Apr 2011 12:50:47 +0000

Suite aux problèmes récents de divers fournisseurs officiels de certificats, notamment Comodo, on peut croiser ici et là diverses propositions de changement (assez radicaux) quant à la gestion des certificats. Certains parlent d’un Web of Trust (pour faire simple et court, c’est l’utilisateur qui choisi au cas par cas à qui il fait confiance), d’autres encore pensent à sortir du modèle actuel des fournisseurs officiels, en utilisant notamment le DNS pour fournir l’information sur le certificat attendu, ce qui permettrait au navigateur de savoir si le certificat reçu est celui attendu.

Cependant, toutes ces propositions ne sont là que pour corriger le modèle actuel des fournisseurs de certificats, aucune proposition (du moins parmi celle que j’ai lues) ne remet en question le modèle du HTTPs, à savoir de la protection de transport. Pour moi, le vrai problème ne se situe plus à la protection du transport, mais à la protection du contenu. Qu’est ce que je veux dire par là ? Prenons un cas simple, une page d’authentification. Il va de soit que l’identifiant et surtout le mot de passe doit être transmis de manière sécurisé.

Aujourd’hui nous utilisons de plus en plus de sites internets, issus de différents éditeurs, et surtout de plus en plus de portails. Comme je l’avais imaginé il y a déjà plus de 2 ans, de mon avis l’avenir réside dans le fait de sécuriser le contenu, et non plus le contenant. Prenons l’exemple d’un utilisateur qui va sur un site que l’on appellera BLOG, cette personne veut publier un commentaire, mais ne dispose pas d’un compte sur la plateforme BLOG. Peu importe, nous sommes au XXI ème siècle, il est possible de s’identifier via Facebook ! Oui mais… suivant comment est implémentée cette authentification, rien ne garanti que le mot de passe circule de manière chiffrée sur la plateforme BLOG. Cependant, l’authentification est un cas à part, il existe déjà des mécanismes pour éviter ce genre de problème, notamment la fédération d’identité, qui permet à un fournisseur de service (tel qu’un blog wordpress comme celui que vous lisez actuellement) d’être indépendant du fournisseur d’identité (là où on tape son identifiant et son mot de passe).

Le principe est relativement simple, plutôt que de chiffrer le tuyau d’une communication sensible, on chiffre le contenu de la communication, qui peut donc transiter de manière sûre via des canaux non sûrs. Bien entendu, cela ne change en rien la problématique de délivrance des certificats. Mais je pense que plutôt que d’essayer de corriger le problème en bout de chaîne, essayons de corriger la source. Par exemple, la plupart de nos chers voisins belges disposent d’une carte d’identité électronique, qui contient un certificat. Ce dernier, au travers d’un lecteur de carte (avec des drivers qui fonctionnent aussi bien sous Windows que sous Linux, en passant par Mac OS X), peuvent utiliser leur certificat, notamment pour déposer des dossiers légaux de manière purement électronique. En aucun cas je ne suis en train de dire que tous les certificats serveurs doivent être délivrés par l’État ou assimilé (encore que, quand on voit cet article on peut se demander de la pertinence d’une telle solution). Mais l’utilisation massive par les utilisateurs d’un certificat permettrait – je le pense – une meilleure compréhension, et surtout cela imposerait aux éditeurs de logiciels de prendre du temps pour réfléchir à l’ergonomie associée. Car, et je terminerais la dessus, le problème de sécurité des certificats actuels, est surtout lié aux éditeurs des navigateurs.

En effet, bien que l’on puisse reprocher l’aspect monétaire, le modèle actuel pêche surtout par l’absence de renouvellement régulier des certificats racines, certains sont en 1024 bits, d’autres utilisent du MD4 (non, il n’y a pas de typo, je parle bien de MD4 et non MD5, qui de toute manière est tout aussi faible dans le cas de certificats). De plus, bien qu’il existe des mécanismes de vérification des certificats (tel que l’utilisation de CRL, et surtout de l’OCSP) ces mécanismes ne sont pas activés par défaut sur les navigateurs et/ou systèmes d’exploitations. Pour conclure, plutôt que d’essayer de trouver un nouveau modèle, il faudrait utiliser les technologies qui nous sont d’ores et déjà proposées.

Un SI propre avec iTop, RunDeck, Puppet, FusionInventory

asyd — Wed, 23 Mar 2011 12:49:12 +0000

Au vu de mes futures (nouvelles ) activités, et parce qu’au XXI ème siècle, on se doit d’avoir un système d’information propre, j’ai commencé une maquette en n’utilisant que des outils libres. Les objectifs sont multiples :

l’information ne doit être déclarée qu’à un seul endroit
la configuration des serveurs doit être automatisée
disposer d’une CMDB
automatisé toutes les tâches possibles

Une CMDB, cékoidonc ?

Avant de rentrer dans la technique, je me permet un petit rappel sur la définition d’une CMDB (Configuration Management DataBase), qui est un concept né et normalisé par ITIL. Comme le décrit Wikipedia, une CMDB recense les composants d’un système d’information. Par exemple, la liste des serveurs, mais aussi et surtout la liste des serveurs d’applications, des applications, et de tout autre composant structurant. Une fois renseigné ces différentes briques, il est possible de les regrouper, notamment par solutions applications et par processus métier, et surtout, de lier toutes ces briques. L’objectif ? Définir des relations de dépendance, entre le métier (par exemple “Vendre des articles via mon site d’ecommerce”) et les briques techniques (le serveur “LDAP”). D’une part, renseigner ces informations oblige à documenter ces interactions, et éviter qu’elles ne soient que dans la tête de l’administrateur, mais pour un administrateur, cela permet de répondre à la question fatidique “qu’est ce qui se passe si je change mon serveur LDAP”. Bon nombre d’administrateur vont me dire “mais je sais très bien quelles applications utilisent le LDAP” ou bien encore “c’est dans Puppet, donc j’ai pas à m’en occuper”, je leur répondrais alors “oui, toi tu es conscient de l’impact technique. Si je demande à ta direction s’ils mesurent les impacts business de ta migration, ils vont en penser quoi ?” (Et là, je viens de me faire des ennemis, mais c’est une autre histoire).

Jusqu’il y a encore quelques années, je n’avais trouvé aucun logiciel opensource me permettant de créer cette CMDB. En effet, la plupart des logiciels de ce genre viennent avec un modèle déjà tout prêt. Cependant, nous n’avons pas tous les même besoin, et j’irais presque jusqu’à dire pas tous la même manière de les représenter (même si justement ITIL décrit un modèle de référence). Or, il y a quelques mois de cela, j’ai découvert un nouveau logiciel dans ce monde très spécifique, à savoir iTop. C’est un outil GPL, écrit en PHP, et d’origine française. Ses auteurs sont des anciens de HP, pour qui ils ont déjà travaillés sur ces problématiques. Résultat, bien qu’encore jeune, iTop est un outil formidable, car très simple d’utilisation, mais aussi par sa richesse. En effet, il est relativement aisé de modifier le modèle par défaut (au hasard celui d’ITIL) pour l’adapter à ses besoins. Pour citer un des fondateurs de la société Combodo éditrice de ce logiciel, il est tout à fait possible de schématiser une école maternelle avec ses élèves, ses professeurs, ses salles, etc. C’est typiquement le genre de logiciel que j’affectionne, il répond à un besoin, mais via une approche framework que logiciel rigide.

Exemple d’un processus métier

Voici un exemple du processus métier gérer la configuration. Étant administrateur système mon métier reste technique, chez d’autres sociétés, “Gérer la configuration” sera plutôt une solution applicative qu’un processus métier.

iTop : processus métier

La gestion des jobs

Dans un SI, avec plein de serveurs, il peut être intéressant de pouvoir exécuter des jobs, aussi bien à intervalle régulier, que de manière occasionnelle. Bien entendu, chaque UNIX vient avec un daemon CRON, mais celui-ci est mono serveur, à une syntaxe différente entre les différents UNIX, etc. On pourrait très bien imaginer de gérer les fichiers cron via le logiciel de conformité de configuration, mais cela ne répond qu’au besoin de jobs réguliers. Pour cette brique, je me suis tourné vers RunDeck. Cet outil est un job scheduler en Java, encore une fois un projet relativement jeune, mais qui profite d’une grande expérience puisqu’il est issu des même développeurs que ControlTier, autre outil de job scheduling. Avec quelques lignes de développement PHP, RunDeck utilise iTop pour obtenir la liste des nodes (serveurs), et utilise une notion de tags dans iTop, pour rajouter par exemple le tag puppet que je défini sur les serveurs où l’agent est installé.

La conformité de la configuration

Chers lecteurs, étant donné que vous êtes en grande majorité des administrateurs systèmes, je vais passer outre la description de Puppet. Pour les autres, en quelques mots, c’est un outil qui permet de s’assurer que des classes de serveurs soient configurés de la même manière, par exemple en forçant la présence de tel ou tel package, que le fichier /etc/sshd/sshd_config soit identique, et ce à partir d’un fichier maître, etc. Par défaut, un daemon est présent sur chaque nœud, mais pour ma part j’ai choisi de ne pas l’utiliser, et d’exécuter l’agent via un job RunDeck (avec mon fameux tag). Cela me permet de centraliser via la WebUI de RunDeck la sortie des différentes instances des agents, et également de pouvoir exécuter l’agent avant d’attendre le prochain scheduling

La gestion de l’inventaire

Jusqu’ici, j’ai déclaré mes serveurs (grosso modo nom, adresse IP, informations SSH) dans iTop, mais j’aimerais bien avoir un inventaire plus précis, comme par exemple la liste des packages installés, la quantité de mémoire, etc. Ça tombe bien, il existe un outil performant pour faire l’inventaire d’une machine UNIX, à savoir FusionInventory. Et vous allez me demander, comment intégrer tout ça ? (en fait, je me doute que vous l’aurez déjà deviné). Tout simplement en forçant la présence du paquetage via Puppet, et l’exécution d’un inventaire toujours via Puppet (j’aurais pu également le faire via RunDeck cependant). Ensuite, je collecte le XML que génère FusionInventory, je lui applique quelques XSL, et j’intègre le résultat dans iTop, et tout ça de manière automatique. Voila, la boucle est bouclée.

Pour résumer

Les liens entre les composants

Et demain ?

Et bien, demain, je vais coupler de manière plus forte iTop et puppet. Avec un peu de travail, mais rien de bien compliqué, je vais pouvoir faire en sorte que iTop soit l’origine d’une partie de la configuration, notamment celle métier. L’objectif est par exemple, via iTop, de créer une nouvelle instance Tomcat sur un serveur, et que puppet assure son installation (je le fais déjà, mais via les fichiers de configuration puppet).

Makefile et squelette qui va bien pour docbook vers PDF

asyd — Mon, 14 Mar 2011 13:43:52 +0000

Étant donné mon futur changement professionnel (vous en saurez plus dans un futur proche), je me suis confronté au problème de la production des documents (principalement technique). Plusieurs solutions s’offraient à moi, la plus facile, en tant qu’utilisateur de Mac OS X, est d’utiliser Pages, de la suite iWork. Bien que ce dernier soit un produit très adapté pour produire rapidement un joli document, je trouve que la construction d’un thème from scratch n’est pas très facile, et de toute façon, il n’est utilisable que sous Mac, donc difficile en clientèle par exemple. La seconde solution, est d’utiliser OpenOffice ou LibreOffice, cependant, après quelques années d’expériences, je trouve que ce n’est pas très pratique sur le long terme, de plus, l’avenir des deux produits me semble incertain, le premier est devenu payant, le second, communautaire, ne me rassure pas quant à son avenir.

Les deux solutions restantes sont docbook et LaTeX. Le dernier, bien que connu pour être très bien, me parait coûteux en temps, principalement sur la personnalisation du rendu (PDF dans mon cas). Me reste donc docbook (si vous êtes anti XML, passé votre chemin). Pour ma part, il me semble absolument indispensable de différencier le contenu de son style (le rendu). Bien que beaucoup (mais ce n’est probablement pas votre cas, cher lecteur) pensent que mon texte soit équivalent à mon texte, ce n’est pas mon cas. Je peux pouvoir écrire un document (un contenu) à un instant t et le rendre en PDF mais surtout pouvoir modifier le style (couleur du titre, etc.) sans toucher le document d’origine, et ce plusieurs mois après la rédaction du fichier. C’est pourquoi je me suis tourné vers docbook.

Après quelques heures perdues, j’ai réussi à obtenir un squelette de production de mes documents, que je vais décrire dans le présent billet.

Les fichiers

Pour commencer, voici la liste des fichiers impliqués dans la production d’un document :

documentation.xml, c’est mon fichier source docbook, le contenu que je veux produire en pdf ;
default.xsl, ce fichier est une transformation XML (xsl) qui me permet de modifier le fichier docbook d’origine, pour par exemple rajouter automatique la partie sur l’auteur si elle n’est pas présente dans le document d’origine. Autant essayer de ne pas dupliquer l’information autant que faire se peut. ;
monstyle.xsl, c’est le fichier qui me permet de surcharger la transformation docbook vers FO (une étape intermédiaire avant transformation en PDF). C’est là que je vais définir les couleurs (ou tout paramètre disponible par la XSL de Walsh), ou bien encore surcharger un template précis ;
et finalement, un fichier Makefile qui me permet d’automatiser tout cela.

Le Makefile

Comme expliqué précédemment, ce fichier me permet d’automatiser la transformation d’un fichier docbook vers un fichier PDF. Et comme je galère un peu sur Makefile, je vais profiter de ce billet pour me faire un mémo.

DOCUMENTS=documentation.xml

FOP=/Users/bbonfils/tools/fop-1.0/fop
FOP_XSL=xsl/docbook.xsl
FOP_CONF=conf/fop.xconf
DEFAULT_XSL=xsl/default.xsl
XSLTPROC=xsltproc
XMLLINT=xmllint
TMP=tmp
ENV=LC_ALL=en_US.UTF-8
FOP_ENV=FOP_OPTS=-Djava.awt.headless=true

default: $(DOCUMENTS:.xml=.pdf)

%.pdf: %.xml
   $(ENV) $(XSLTPROC) $(DEFAULT_XSL) $? | $(XMLLINT) -format - > $(TMP)/$?
   $(ENV) $(FOP_ENV) $(FOP) -c $(FOP_CONF) -xml $(TMP)/$? -xsl $(FOP_XSL) -pdf $@

clean:
   @rm -f *.pdf

Les premières lignes définissent des variables, notamment DOCUMENTS qui me permet de lister les fichiers docbook à transformer en PDF. Ensuite, je défini la règle implicite suivante: :

%.pdf: %.xml
   $(ENV) $(XSLTPROC) $(DEFAULT_XSL) $? | $(XMLLINT) -format - > $(TMP)/$?
   $(ENV) $(FOP_ENV) $(FOP) -c $(FOP_CONF) -xml $(TMP)/$? -xsl $(FOP_XSL) -pdf $@

qui décrit la manière de compiler (transformer dans mon cas) un fichier XML vers un PDF. La première ligne permet d’appliquer ma XSL default.xsl qui permet de rajouter les informations de l’auteur si elles n’existent pas. La deuxième ligne applique la transformation docbook vers FO puis de FO vers PDF.

Et finalement, je définis la cible par défaut default en lui demande de me transformer la liste des fichiers renseignés par la variable DOCUMENTS en PDF, par substitution de l’extension.

Voilà, voilà, je dois avouer que ce billet est plus un memento personnel, mais tant qu’a faire, autant partager avec le monde. Pour les lecteurs avertis, vous aurez remarque que je traite que des fichiers textes qui sont donc parfaitement adaptés pour un gestionnaire de source tel que Subversion ou Git.