yannic/blog
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

structure & meta

Browse source
This commit is contained in:
Yax 2019-08-17 18:40:27 +02:00
parent da6d838193
commit b25ce65735
284 changed files with 461 additions and 1000 deletions
Download patch file Download diff file Expand all files Collapse all files

81
posts/2012/2012-01-08-installation-de-jenkins-ci.md Executable file
View file

@ -0,0 +1,81 @@
<!-- title: Installation de Jenkins CI -->
<!-- category: Développement -->
<!-- tag: planet -->
<img src="/images/06x/jenkins-logo.png" alt="Jenkins CI" title="Jenkins
CI" style="float:left; margin: 0px 20px" checked="true" /> L'intégration
continue s'inscrit dans [la méthodologie
Agile](http://fr.wikipedia.org/wiki/M%C3%A9thode_agile) ; Son objectif est de
garantir que le projet est stable tout au long du développement et qu'on peut
livrer le projet à tout moment. <!-- more --> Cela implique que les développeurs ne publient
que des fonctionnalités ou des micro-fonctionnalités complètes (dans le sens
entièrement implémentées et utilisables) dans le dépôt de sources et qu'on
peut à tout moment construire le projet dans son intégralité et le déployer,
généralement sur des environnements de tests pour que l'Assurance Qualité
puisse tester tout au long du cycle de développement, ou bien en tant que
version intermédiaire planifiée (milestone, alpha, beta).
Ici je vais décrire l'installation du logiciel d'intégration continue [Jenkins
CI](http://jenkins-ci.org/) dans le conteneur de Servlet
[Tomcat](http://tomcat.apache.org/) sous Ubuntu Server 10.4. D'abord on installe
Tomcat 6 avec le système de paquets :
``` shell
sudo apt-get install tomcat6
```
Ensuite on installe manuellement le WAR de Jenkins CI :
``` shell
# move to tomcat webapps dir
cd /var/lib/tomcat6/webapps
sudo wget http://mirrors.jenkins-ci.org/war/latest/jenkins.war
```
Si Tomcat était lancé, Jenkins va être déployé et disponible en quelques
secondes. Sinon démarrez Tomcat :
``` shell
sudo /etc/init.d/tomcat6 start
```
Jenkins est accessible ici : [http://&lt;nom du
serveur&gt;:8080/jenkins](http://localhost:8080/jenkins)
Par défaut la sécurité n'est pas activée et tout le monde peut accéder et
administrer Jenkins. Nous allons remédier à cela en modifiant les paramètres
de sécurité dans la partie administration qu'on accède en cliquant sur le
lien *[Administrer Jenkins](http://localhost:8080/jenkins/manage)* puis *[Configurer le système](http://localhost:8080/jenkins/configure)*.
![Sécurité](/images/06x/jenkins-security.png)
Après enregistrement, un bouton *S'identifier* fait son apparition dans la
bannière en haut à droite. Jenkins a délégué à Tomcat la gestion des
utilisateurs, il faut donc créer, au minimum, un administrateur Jenkins. Editez
le fichier /var/lib/tomcat6/conf/tomcat-users.xml avec votre éditeur favori et
ajoutez le rôle 'admin' et un administrateur, par exemple :
```
<role rolename="admin">
<user username="jenkins" password="jenkins" roles="admin">
```
Ensuite redémarrez Tomcat pour prendre en compte la création de l'utilisateur
et identifiez-vous à Jenkins en tant qu'administrateur. Attention,
l'utilisateur anonyme a encore accès à tout. Si votre intégration continue
tourne sur un serveur publique, vous voudrez probablement que l'utilisateur
anonyme n'ait aucune visibilité sur les projets. Modifions à nouveau la
sécurité ; on choisit la sécurité basée sur une matrice de droits, et on
rajoute l'utilisateur **jenkins** avec tous les droits cochés.
![Matrice de sécurité](/images/06x/jenkins-matrix.png)
Si vous avez joué de malchance et que vous n'avez pas affecté de droit à
l'administrateur avant de sauver, vous ne pouvez plus accéder à Jenkins :-)
Heureusement les développeurs ont prévu le coup et il faut réinitialiser la
sécurité en suivant [cette procédure du Wiki](https://wiki.jenkins-
ci.org/display/JENKINS/Disable+security).
A ce stade Jenkins est opérationnel avec une sécurité basique qui suffira
dans beaucoup de cas, prêt à gérer des projets, ce qui fera l'occasion d'un
prochain article.

80
posts/2012/2012-01-22-quelle-distribution-gnome-2-choisir-en-2012.md Executable file
View file

@ -0,0 +1,80 @@
<!-- title: Quelle distribution 'Gnome 2' choisir en 2012 ? -->
<!-- category: Humeur -->
<!-- tag: planet -->
Le titre est un peu provoc mais c'est une vraie question [que je me posais
déjà en Novembre
dernier](http://blogduyax.madyanne.fr/index.php?article60/gnome-3-pour-un-usage-
professionnel). Comment retrouver un niveau de productivité correct après
l'ouragan Gnome 3 / Unity dans le cadre professionnel<!-- more --> avec du matos récent (en
l'occurrence un core i7 avec de la RAM à gogo et une carte NVIDIA Optimus
achetés en décembre) ? J'ai posé deux contraintes : **une stabilité des
paquets sur 1 an** (hors mise à jour de Mozilla et patchs de sécurité bien
sûr) et **une distribution proche de Debian**. Pour ces raisons j'ai écarté
Archlinux, bien ce que soit mon coup de coeur depuis 2 ans.
<img xmlns="http://www.w3.org/1999/xhtml" src="images/06x/gnome-
logo.png" alt="Gnome logo" title="Gnome logo" style="margin: 0px 20px; float:
right; width: 118px; height: 160px;" checked="true" align="right" /> Mon grand
espoir était d'utiliser une [Debian](http://www.debian.org/) stable, ce qui
m'aurait laissé encore 1 an de tranquillité sous Gnome 2. Mais j'ai déchanté
! Après installation à partir des beaux DVD "Squeeze" récemment reçus j'ai
réalisé que la version stable embarque un kernel 2.6.32, trop ancien pour
gérer le chipset Wifi et que les versions de Mozilla sont vraiment anciennes.
Les [backports officiels](http://backports-master.debian.org/) n'ont pas aidé
à résoudre ces points. La perspective de *tweaker* manuellement la
distribution m'a effleuré. J'ai plutôt modifié les dépôts pour passer en
Testing. Ce que j'ai gagné c'est le passage à Gnome 3 et une gestion du Wifi
boiteuse. De plus Testing évolue continuellement. L'objectif initial n'étant
pas de passer à une pseudo-rolling release, j'ai quitté Debian avec quelques
regrets.
Sur le coup, mon raisonnement fut "tant qu'à faire une croix sur Gnome 2,
autant installer une distribution récente". Ce fut donc Ubuntu 11.10 avec Unity
ou Gnome 3. Bon Gnome 3 je connais, je l'ai utilisé presque 1 an à la maison.
C'est mignon, bien pensé mais pas adapté à mon usage où je papillonne toute
la journée parmi une vingtaine d'applications lancées. Du coup, j'ai donné sa
chance à Unity et j'ai tenu 2 semaines :-) Mais le bilan n'est pas si négatif.
J'ai beaucoup apprécié l'espace gagné sur l'écran grâce à la barre de menu
unique (comme dans le monde des pommes). Ce qui me déplait fortement c'est la
difficulté à trouver une application dans le panel. Quelle idée marketing
tordue de mixer les applications installées et celles disponibles dans l'Ubuntu
store!!! On peut contourner le problème en rajoutant le [Classic Menu
Indicator](http://www.webupd8.org/2011/06/use-classic-menu-in-unity-
classicmenu.html) mais le problème de basculement parmi une vingtaine
d'applications lancées reste entier.
Las j'ai transformé mon Ubuntu en Xubuntu. Ce que je peux dire sur XFCE a été
lu ou dit ailleurs : avec des efforts de personnalisation on arrive à recréer
un Gnome 2-like (en moins beau, moins bien intégré). On a une vraie barre des
tâches qui peut regrouper intelligemment les applications lancées et le menu
n'est pas une porte ouverte sur une boutique d'applications. Par contre le
gestionnaire de fichier Thunar est moins bien que Nautilus (notamment il manque
la gestion des onglets) et **on a le goût amer d'avoir quelque chose de presque
aussi bien qu'en... 2010** ;-) L'année 2010 c'est Ubuntu 10.04 juste avant que
Canonical n'entame le grand chantier Unity et que l'équipe Gnome ne démarre sa
révolution pour ouvrir Gnome aux tablettes et aux netbooks (en oubliant les
gens qui utilisent leur machine pour travailler). Bref 2010 c'est l'avant
dernière version "Gnome 2" sortie par Canonical dans [une version LTS maintenue
jusqu'en avril 2013](http://doc.ubuntu-fr.org/lucid). D'un coup il y a eu
déclic ! Serait-il possible que cette version avec un support étendu soit
capable de gérer mon matériel acheté en fin d'année 2011 ?
Et bien la réponse est positive, avec quelques ajustements mineurs :
* l'activation des dépôts officiels "lucid-backports" et "lucid-proposed" pour
passer au plus récent kernel proposé en 2.6.x, à savoir le 2.6.38-13 (si
nécessaire on peut aller jusqu'au 3.0.0-15) et bénéficier de Firefox 9.
* l'ajout du dépôt Ubuntuzilla pour bénéficier de Thunderbird 9 car la version
3.x fournie par défaut ne propose pas l'extension Lightning.
* La désactivation du driver Nouveau (encore expérimental en 10.04) -
blacklisté dans /etc/modprobe.d/blacklist.conf - l'utilisation de la carte
Intel est bien suffisante pour mon usage.
Tous les outils que j'utilise quotidiennement pour le travail fonctionnent
parfaitement (Eclipse, JAVA, VMWare Player, Skype), l'environnement de bureau
est un bonheur retrouvé. Pour info, Ubuntu 10.04 démarre et s'arrête 2 fois
plus vite qu'une version 11.10. Que fait Canonical depuis 3 versions ? - ah oui
ils focalisent sur l'environnement de bureau :-( Après un mois d'errements,
j'ai enfin l'impression d'avoir la distribution qu'il me faut pour cette
machine. J'aurais pu intituler cet article "Retour vers le futur".

103
posts/2012/2012-03-03-surveiller-sa-ligne-adsl-avec-munin.md Executable file
View file

@ -0,0 +1,103 @@
<!-- title: Surveiller sa ligne ADSL avec Munin -->
<!-- category: Hébergement -->
<!-- tag: planet -->
Je me suis intéressé à la supervisition de ma box ADSL afin de grapher la
bande passante montante et descendante ainsi que les valeurs de bruit et
d'atténuation<!-- more -->, ceci dans le but de vérifier la stabilité des valeurs dans le
temps et de corréler des impressions de dégradation avec des mesures
concrètes.
La première étape nécessite de trouver un protocole fournissant les
informations nécessaires. Etant abonné Orange je suis équipé d'une livebox 2
qui fournit un service [HTTP](http://fr.wikipedia.org/wiki/HTTP) et un service
[TELNET](http://fr.wikipedia.org/wiki/TELNET). Sur l'ancienne génération le
mot de passe du compte root était connu et on pouvait tirer les informations
nécessaires depuis le service TELNET. De ce que j'ai lu dans les forums, le mot
de passe est inconnu sur la nouvelle génération et la seule option reste
l'interface HTTP, pas vraiment le protocole idéal pour de la supervision. Fort
heureusement, un script PERL pour piloter la box a été écrit par
[teebeenator](http://www.forum-orange.com/forums/profile.php?id=29572) et
sympathiquement fourni à la communauté des utilisateurs. Ce script est
téléchargeable [ici](http://www.forum-
orange.com/forums/viewtopic.php?id=32420).
<img style="width: 305px; height: 80px;" alt="Munin" src="/images/06x/munin-logo.png" align="right" /> La deuxième étape consiste à choisir un
outil de supervision capable de collecter des valeurs et de créer des graphes,
un outil de la famille [MRTG](http://fr.wikipedia.org/wiki/MRTG) : après un
test de [Cacti](http://www.cacti.net/) qui est un bon outil mais que j'ai jugé
trop complexe par rapport à mon besoin initial, mon choix s'est porté sur
[Munin](http://munin-monitoring.org/) : un outil simple (voire rustique) écrit
en PERL, aucune interface graphique d'administration, une interface Web 1.0
(sans JavaScript) qui présente des graphes à la journée, consolidés à la
semaine, au mois et à l'année générés statiquement en tant qu'images
bitmap. L'installation est triviale et correctement documéntée pour Debian sur
[le Wiki de Munin](http://munin-monitoring.org/wiki/Documentation). Dans mon
cas, je déploie sur mon petit serveur Debian Squeeze et j'utilise
[NginX](http://fr.wikipedia.org/wiki/Nginx) en tant que serveur HTTP. Faire un
lien symbolique de /var/www/... vers le répertoire www de Munin
(/var/cache/munin/www) est suffisant pour lier le serveur Web à Munin.
La troisième et dernière étape consiste à étendre Munin en créant des
plugins. D'abord on collecte les données, c'est réalisé par un shell script
qui appelle le script PERL de teebeenator et qui sauve les donnée dans un
fichier texte. Cette collecte est réalisée toutes les 5 minutes grâce à
CRON.
``` shell
perl livebox.pl --user=admin --pass=<VotreMotDePasse>
-page=infosys_main -v 2>/dev/null | html2text >/adsl_stats.txt
```
Je sauve les données dans un fichier texte car 3 plugins Munin vont les
consommer :
* un plugin qui graphe la bande passante descendante (download) en kb/s
* un plugin qui graphe la bande passante montante (upload) en kb/s
* un plugin qui graphe le bruit montant / descendant ainsi que l'atténuation
montante / descendante en dB.
Un plugin est un exécutable (Bash, Perl, Python, ce que vous préférez) qui
doit répondre à deux types de requêtes :
- avec l'argument 'config' il renvoie la configuration du graphe : titre, les
unités, le libellé de chaque variable graphée
- sans argument il renvoie une nouvelle valeur pour chaque variable du graphe.
Voici shell script du plugin adsl_download qui collecte la valeur de la bande
passante descendante :
``` shell
if [ $# = 1 ]; then
echo "graph_title Bandwidth - Download"
echo "graph_category ADSL"
echo "graph_vlabel kb/s"
echo "down.label download"
else
grep "bit descendant maximum" adsl_stats.txt | cut -s -d: -f2
| sed 's/\s*\([0-9]\+\).*/down.value \1/'
fi
```
L'enregistrement du plugin auprès de Munin est très simple :
- on rajoute l'exécutable ou un lien symbolique dans /etc/munin/plugins
- on configure les droits d'exécutions dans /etc/munin/plugin-conf.d/munin-node
Mes plugins s'appellent adsl_download, adsl_upload et adsl_noise, j'ai donc
rajouté la section suivante à /etc/munin/plugin-conf.d/munin-node :
```
[adsl*]
user root
```
Le séquenceur de Munin appelle chaque plugin toutes les 5 minutes.
Voici le genre de graphe qu'on obtient :
![ADSL Download](/images/06x/download.png)
L'ensemble des fichiers qui composent les plugins sont disponibles [dans cette
archive](/documents/munin.zip).

124
posts/2012/2012-03-25-gerer-un-projet-de-developpement-avec-jenkins-ci.md Executable file
View file

@ -0,0 +1,124 @@
<!-- title: Gérer un projet de développement avec Jenkins CI -->
<!-- category: Développement -->
<!-- tag: planet -->
<img style="width: 96px; height: 96px;" alt="Jenkins CI logo"
src="/images/06x/jenkins-logo.png" align="left" /> Faisant suite à
[l'article décrivant l'installation de Jenkins
CI](http://blogduyax.madyanne.fr/index.php?article63/installation-de-jenkins-
ci), nous allons voir comment gérer un projet en reprenant la configuration
déployée sous Tomcat <!-- more -->avec Ubuntu 10.04 serveur. Pour rappel, [Jenkins
CI](http://fr.wikipedia.org/wiki/Jenkins_%28informatique%29) permet de mettre en
place une intégration continue afin de traquer d'éventuelles régressions d'un
projet logiciel pendant le cycle de développement. En pratique, il sait
accéder à la plupart des gestionnaires de sources et s'interface avec la
plupart des système de build. Son rôle principal consiste à recompiler le
projet périodiquement, dérouler les tests unitaires et produire des
notifications si quelque chose va de travers.
Mon projet d'exemple est représentatif de mes activités de ces derniers mois :
le développement d'un logiciel écrit en Java qui utilise le système de build
[Apache Maven](http://fr.wikipedia.org/wiki/Apache_Maven) pour construire le
projet. D'abord il faut installer Maven
``` shell
$ apt-get install maven2
```
Maven est géré nativement par Jenkins (sans l'ajout de plugin). On accède à
la configuration de l'outil Maven depuis la page d'administration globale :
![Configure Maven tool](/images/06x/configure-maven-tool.png)
A l'exécution, Jenkins cherche les données relatives à Maven dans
/usr/share/tomcat6 car il s'exécute dans le conteneur de servlet Tomcat en tant
qu'application Web. Si le projet nécessite un fichier de configuration Maven
particulier, il faut le copier dans **/usr/share/tomcat6/.m2/settings.xml** et
il faut s'assurer que l'utilisateur tomcat6 possède tous les droits sur le
répertoire.m2.
Maintenant, nous sommes prêts à créer un nouveau Projet. Les projets de type
Maven ont leur propre type de projet :
![New Project](/images/06x/new-project.png)
Peu d'informations sont nécessaires pour définir un projet de type Maven :
* l'interaction avec le gestionnaire de sources,
* le chemin du fichier POM.XML qui contient la description du build Maven,
* les "goals" de compilation du projet.
Dans mon exemple, le gestionnaire de source est Subversion (SVN pour les
proches) et il est supporté en standard, de même que CVS. La liste est
restreinte mais ne paniquez pas, une quantité de plugins permettent de
supporter à peu près tout ce qui existe (Bazaar, GIT, ClearCase,
Mercurial,...). Cerise sur le gâteau la gestion des plugins n'est pas
bidouillesque. Les plugins sont supportés officiellement, listés et
installables depuis l'interface d'administration de Jenkins.
Configurer SVN pour le projet se borne à définir l'URL du projet et configurer
l'authentification.
![Configure SVN](/images/06x/configure-repository.png)
Une section Maven définit les "goals" à exécuter et le chemin du fichier de
build POM.XML. Les "goals" 'clean' 'install' sont les cibles classiques pour
nettoyer puis reconstruire tout le projet.
![Maven Goals](/images/06x/maven-goals.png)
Le build peut être déclenché de plusieurs manières: manuellement ou
automatiquement. Dans ce dernier cas, ce peut être sur changement des sources
dans le gestionnaire de sources, indirectement dans le cas de multi-projets
ayant des dépendances (où l'on recompile le projet B chaque fois que le projet
A est construit). Il y a d'autres cas plus spécifiques, voire très
particuliers :-) gérés par des plugins.
Dans notre exemple je reste simple et je définis un déclenchement de build du
projet sur modification du gestionnaire de source. De manière similaire à
l'outil CRON, on peut définir le mot-clef '@hourly' qui signifie qu'une fois
par heure Jenkins regarde si quelque chose à changé sur SVN (c'est à dire si
un développeur a publié du nouveau code).
![Trigger Build](/images/06x/trigger-build.png)
Dans le cas de mon projet dont la compilation prend une vingtaine de minutes
c'est une valeur sensée. Quand l'intégration continue est présentée aux
développeurs, il prennent rapidement leur marque par rapport au fait que le
projet est vérifié chaque début d'heure et ils évitent quelques pièges :
* morceler des 'commits' qui ne compilent pas (ce qui est une mauvaise pratique en
soi) et pire, publier un peu avant l'heure entière ce qui augmente le risque de
casser le build de l'intégration continue pendant la prochaine heure,
* publier en fin d'heure, ce qui limite les chances de rattraper le coup en cas de
problème inattendu.
Le dernier point restant à voir pour boucler l'exemple, c'est la notification
des développeurs quand l'intégration continue échoue. Là aussi on peut
élaborer un système complexe, toute une catégorie de plugins existe pour
s'interfacer avec des systèmes existants (SCM, Messengers) ou rester basique et
envoyer une notification par email.
![Notification](/images/06x/notify-build-errors.png)
Jenkins CI conserve un certain nombre de builds et il affiche une météo du
build en fonction de la stabilité des derniers résultats. En cas d'erreur, il
envoie les parties pertinentes. Si cela ne suffit pas à identifier la cause de
l'erreur, toutes les traces de console sont conservées et attachées à chaques
build.
Jenkins CI peut être mis en œuvre en moins d'une journée sur un projet simple
et ainsi apporter les bénéfices d'une intégration continue à une équipe de
développeurs et de testeurs. Mais l'outil est d'une telle richesse qu'il peut
apporter beaucoup plus :
* support de projets complexes par une architecture maître/esclave pour
déléguer la construction de sous-parties du projet,
* support de langages / systèmes de builds / gestionnaires de sources très
étendu,
* déclenchement de tâches post-build pour générer des rapports (analyse de la
qualité du code, couverture du code par des tests), déployer les versions
produites automatiquement.
Né du fork de Hudson l'année dernière (suite à un différent avec Oracle),
Jenkins CI est un projet open source (sous licence MIT) en plein essor, ce que
confirme le rythme régulier des sorties et l'activité de son forum.

48
posts/2012/2012-04-15-mes-applications-pour-blackberry.md Executable file
View file

@ -0,0 +1,48 @@
<!-- title: Mes applications pour Blackberry -->
<!-- category: Mobilité -->
Après une longue période sous Android j'ai migré vers Blackberry.<!-- more --> Certes,
Android est ce qui s'approche le plus d'un OS libre (on peut même le
[degoogler](http://blogduyax.madyanne.fr/index.php?article41/syncml) ) mais j'ai
eu envie de découvrir autre chose : d'abord un système non tactile, ça peut
sembler à un retour en arrière mais ça me correspond bien (ça me rappelle
mon Nokia E61), une vraie bouffée d'air frais même après une période à
subir les erreurs de jeunesse d'Android. On dit souvent "terminal Blackberry" et
j'ai compris ce terme à l'utilisation : on est plus face à un téléphone
ultra-communiquant qu'une tablette avec option téléphone. C'est d'ailleurs mon
principal grief contre l'Android d'aujourd'hui : qu'on ait laissé autant de
liberté aux applications de dégrader le système voire le planter. Bon
attention, ce n'est pas un article pro-blackberry Mais j'apprécie la cohérence
de son système (même s'il est rustique), sa stabilité et son autonomie
(grâce à la technologie Push). Le point faible est bien sûr le nombre
d'applications disponibles, ce qui devrait s'améliorer les mois à venir.
Néanmoins, si on a des besoins limités et orientés professionnel on trouve
son bonheur. Voici la sélection des applications qui me sont indispensables :
* Imo Instant Messenger : comme Meebo c'est un service Web 2.0 qui permet de
créer un compte unique chez eux pour accéder à ses comptes Jabber, Skype, et
autres. Mais il permet aussi de se connecter individuellement à ses comptes
multi-protocoles et il propose une application pour Blackberry, officiellement
en bêta mais qui fonctionne très bien et n'inonde pas de publicité. Vu la
pauvreté des clients Jabber dans le BlackBerry Store c'est une aubaine.
* BBSSH : un fabuleux client SSH sous licence GPL.
* mProductive : une applications commerciale de gestion du temps qui centralise
intelligemment les évènements du calendrier, les tâches et les mémos. Après
avoir testé toutes celles du BB Store en essai gratuit je me suis résolu à
investir 5$ dans mProductive Lite et je ne le regrette pas, je l'utilise
quotidiennement.
* Poynt : un classique qui permet de trouver des points d'intérêt proches de
vous (restaurants, pharmacies...)
* FidMe : un autre classique qui existe pour d'autres plateformes, permettant de
stocker vos cartes de fidélité.
* France 24 : une des rares applications permettant de visionner le journal TV. On
la trouve sur le BB Store.
Si vous avez quelques perles à partager n'hésitez pas à laisser un
commentaire.
Je rassure ceux qui me connaissent je nage toujours dans l'Android : j'ai
installé une pre-Cyanogen 9 sur une tablette Nook et Cyanogen 7.1 sur un
Motorola Defy la semaine dernière :-)

23
posts/2012/2012-06-19-chive-passe-en-version-1-1.md Executable file
View file

@ -0,0 +1,23 @@
<!-- title: Chive passe en version 1.1 -->
<!-- category: Archlinux -->
<!-- tag: planet -->
Le gestionnaire de base MySQL alternative crédible et sexy à phpMyAdmin, le
bien nommé [Chive](http://www.chive-project.com/) est sorti en version 1.1.<!-- more -->
C'est une version considérée majeure par ses développeurs qui apporte deux
fonctionnalités :
* la première passe inaperçue pour l'utilisateur lambda que je suis : la
possibilité d'empaqueter Chive en tant qu' archive Phar. C'est utile à ceux
qui déploient Chive le temps d'un développement sur un serveur Web tiers - qui
a dit "squat moderne" ;-) - car on ne déploie qu'une archive et PHP l'exécute
sans l'extraire.
* la seconde est le remplacement de l'éditeur de code SQL "maison" par l'éditeur
ACE, projet soutenu par la fondation Mozilla. C'est un changement qui sera
bénéfique pour le produit en terme de maintenabilité et de qualité du code.
Rajoutez à ces deux changements quelques correctifs et on obtient le
millésimé 1.1 de ce beau projet. J'ai mis à jour le paquet
[AUR](http://en.wikipedia.org/wiki/Arch_Linux#Arch_User_Repository) pour la
distribution [ArchLinux](http://www.archlinux.org/).

32
posts/2012/2012-07-13-ranger-son-cartable.md Executable file
View file

@ -0,0 +1,32 @@
<!-- title: Ranger son cartable -->
<!-- category: Humeur -->
<!-- tag: planet -->
Les vacances approchent ! Avant d'aller construire des châteaux de sable, c'est
le bon moment pour mettre de l'ordre dans ses dossiers, faire le point sur
l'année professionnelle écoulée et... tenir à jour son curriculum vitae.<!-- more --> [La
dernière fois que je m'étais prêté à
l'exercice](http://blogduyax.madyanne.fr/index.php?article25/decouvrir-latex)
avait été l'occasion de me familiariser avec LaTeX, d'apprécier la clarté du
langage et la qualité du rendu en PDF avec pdflatex. J'ai décidé de continuer
sur la même voie, avec l'objectif de produire une mise en page moins austère
à défaut de pouvoir rajeunir le candidat ;-)
<img src="/images/06x/trollface_cv.png" width="50%" height="50%" alt="CV
de Jean Code" style="float:left; margin: 0px 20px;" /> En cherchant des idées
de mise en forme j'ai découvert [moderncv](http://www.ctan.org/pkg/moderncv),
une classe de document LaTeX qui permet de structurer le document par des
commandes supplémentaires (définir les données personnelles, définir une
entrée d'expérience,...) et choisir une mise en forme (casual, classic) en
fonction des goûts.
J'ai utilisé la version 1.0 sortie cette année avec Tex 2012. Sous Fedora 17,
ma nouvelle distribution, les paquets Tex sont anciens. J'ai tenté
l'installation expérimentale de Tex 2012 évoquée sur le Wiki de Fedora mais
elle semble incomplète. Le mieux c'est de se référer à [la distribution Tex
Live](http://www.tug.org/texlive/) et d'utiliser [l'installateur
léger](http://www.tug.org/texlive/acquire-netinstall.html) qui télécharge et
installe Tex depuis le réseau.
Pour inspirer ceux qui se veulent se lancer sans partir de zéro, le CV complet
de Jean Code est téléchargeable [ici](/documents/moderncv.zip).

9
posts/2012/2012-09-23-bonne-rentree.md Executable file
View file

@ -0,0 +1,9 @@
<!-- title: Bonne rentrée -->
<!-- category: Humeur -->
Le blog n'est pas mort même si son auteur passe beaucoup de temps à regarder
la série Walking Dead ces dernières semaines ;-)<!-- more --> Comme chaque année, entre
les vacances et la rentrée, GNU/Linux est passé en priorité basse. Mais
l'envie reste intacte et un récent changement professionnel (oui encore) me
permet d'explorer de nouveaux usages et d'utiliser de nouveaux projets libres
qui devraient inspirer des articles les semaines à venir.

34
posts/2012/2012-09-25-compilation-de-tuxboot-sur-fedora-17.md Executable file
View file

@ -0,0 +1,34 @@
<!-- title: Compilation de Tuxboot sur Fedora 17 -->
<!-- category: GNU/Linux -->
<!-- tag: planet -->
Tuxboot est un fork de Unetbootin qui permet de créer une version USB de
**Clonezilla live** et **GParted live**, <!-- more -->ainsi que DRBL live et Tux2live. C'est
l'outil recommandé par Clonezilla pour créer une clef USB Clonezilla Live. Ils
fournissent des paquets pour Debian et les sources. Etant sur Fedora 17, j'ai
opté pour la compilation à partir des sources :
* Récupérer les sources sur le site de Tuxboot (http://tuxboot.org) :
tuxboot-0.4.src.tar.gz
* Installer les outils de développement QT nécessaires à la compilation : yum
install qt-devel
* Installer les paquets 7z recommandés pour l'exécution : yum install p7zip
p7zip-plugins
* Décompresser l'archive dans un répertoire de travail : tar xvf
tuxboot-0.4.src.tar.gz
* Suivre la procédure du fichier INSTALL fourni en adaptant les noms des
exécutables pour Fedora
Voici le source du fichier INSTALL
``` shell
cp tuxboot.pro tuxboot-pro.bak
sed -i '/^RESOURCES/d' tuxboot.pro
lupdate-qt4 tuxboot.pro
lrelease-qt4 tuxboot.pro
qmake-qt4 "DEFINES += NOSTATIC CLONEZILLA" "RESOURCES -= tuxboot.qrc"
make
mv tuxboot-pro.bak tuxboot.pro
```
Si la compilation se passe bien, l'exécutable tuxboot est créé.

47
posts/2012/2012-09-29-eclipse-juno-sous-gnu-linux.md Executable file
View file

@ -0,0 +1,47 @@
<!-- title: Eclipse Juno sous GNU/Linux -->
<!-- category: Développement -->
<!-- tag: planet -->
La dernière version d'Eclipse, sortie en juin dernier, a pour nom de code
**Juno**. Eclipse c'est un [IDE](http://fr.wikipedia.org/wiki/Environnement_de_d
%C3%A9veloppement_int%C3%A9gr%C3%A9) pour le développement Java <!-- more -->bâti sur une
plateforme ouverte, extensible à au possible par le biais de plugins. Du coup,
Eclipse est livré sous licence EPL (Eclipse Public License), une licence
reconnue libre par la FSF mais moins contraignante que la GPL avec laquelle est
est incompatible d'ailleurs, afin de permettre à des éditeurs de bâtir des
logiciels propriétaires (ou privateurs selon les termes de Richard Stallman) en
s'appuyant sur sa plateforme.
Selon sa distribution (Debian-based, Fedora, Arch ou autre), on peut utiliser le
système de paquets pour installer Eclipse mais je trouve préférable
d'installer manuellement en téléchargeant depuis [le site
officiel](http://www.eclipse.org/) car la plateforme est décomposée en un
certain nombre de sous-projets et différents assemblages peuvent téléchargés
depuis le site (Eclipse for Java EE, Eclipse for Java, Eclipse Classic). En
installant manuellement on s'évitera les problèmes de mise à jour non
maîtrisés et les problèmes de dépendances manquantes entre sous-projets.
Après avoir démarré Juno, deux éléments visuels m'ont choqué : le
dégradé de la barre d'outil et la taille de fonte excessive de certains
titres.
![Juno](/images/07x/eclipse-ui.png)
Personnaliser l'apparence d'Eclipse a toujours été un peu casse-tête. Le menu
apparence dans les préférences regorge d'options pour modifier l'apparence des
différents éditeurs de code (Java, XML,...) mais rien pour certains aspects
globaux comme ceux qui dérangent justement.
Dans ce cas, la solution vient d'une extension qui permet de modifier la CSS
définissant ces aspects de l'interface. Pour cela, il faut installer le plugin
**E4 CSS Editor** depuis le site suivant : [http://download.eclipse.org/e4/updat
es/0.12](http://download.eclipse.org/e4/updates/0.12).
![CSS](/images/07x/css-editor.png)
Une fois l'éditeur CSS installé, il s'active quand on ouvre l'option
Préférences / Apparence dans le menu Windows. Pour diminuer la fonte et
harmoniser le style de la barre d'outils avec le reste de l'interface, il faut
appliquer la modification suivante (la version modifiée est à droite) :
![Diff](/images/07x/css-diff.png)

115
posts/2012/2012-12-04-installer-sabnzbd-derriere-nginx.md Executable file
View file

@ -0,0 +1,115 @@
<!-- title: Installer SABnzbd derrière Nginx -->
<!-- category: Hébergement -->
[SABnzbd](http://sabnzbd.org/), comme son nom ne l'indique pas vraiment, est un
lecteur de news binaires. <!-- more -->Il permet de récupérer des fichiers depuis
[Usenet](http://fr.wikipedia.org/wiki/Usenet). C'est une application serveur,
qu'on héberge derrière un serveur Web, et qui offre une interface de gestion
depuis un navigateur. Il faut bien sûr l'associer à un compte chez un
fournisseur Usenet. Je ne détaille pas plus l'utilisation de l'outil, le site
officiel est suffisamment documenté, mais plutôt son installation dans le
cadre de l'auto-hébergement avec le serveur Web Nginx en frontal et non pas le
traditionnel Apache.
Depuis [la page de téléchargement](http://sabnzbd.org/download/) on peut
télécharger les sources Python. Les manipulations suivantes sont réalisées
sur une Debian 6 avec Python, Nginx et OpenSSH installés.
``` shell
# on installe sous /srv
cd /srv
wget http://sourceforge.net/projects/sabnzbdplus/files/sabnzbdplus/0.7.6/
SABnzbd-0.7.6-src.tar.gz/download -O SABnzbd-0.7.6-src.tar.gz
tar xvf SABnzbd-0.7.6-src.tar.gz && rm -f SABnzbd-0.7.6-src.tar.gz
# on crée un lien symbolique /srv/sabnzbd pour gérer aisément les futures mises à jour
ln -s SABnzbd-0.7.6 sabnzbd
```
L'étape suivante consiste à démarrer SABnzbd pour définir sa configuration
générale et **aussi restreindre l'adresse d'écoute** à l'interface localhost
(127.0.0.1) pour forcer le passage par Nginx et son authentification que nous
allons mettre en place par la suite. On peut automatiser le démarrage en
rajoutant un script sabnzbd sous /etc/init.d tel que celui-ci :
``` shell
### BEGIN INIT INFO
# Provides: sabnzd
# Required-Start: $local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Should-Start: $all
# Should-Stop: $all
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start/stop Sabnzbd
# Description: Start/stop Sabnzbd
### END INIT INFO
PATH=/sbin:/bin:/usr/sbin:/usr/bin
. /lib/lsb/init-functions
if [ "$#" -ne 1 ]; then
log_failure_msg "Usage: /etc/init.d/sabnzd" \
"{start|stop}"
exit 2
fi
case "$1" in
start)
python /srv/sabnzbd/SABnzbd.py -d -f /root/.sabnzbd/sabnzbd.ini
exit $?
;;
stop)
/usr/bin/wget -q --delete-after "http://localhost:7777/sabnzbd/api?mode=shutdown
&apikey;=24be83f61210daad59aa0e90223ccd4f"
exit $?
;;
*)
log_failure_msg "Usage: /etc/init.d/sabnzbd" \
"{start|stop}"
exit 2
;;
esac
log_failure_msg "Unexpected failure, please file a bug."
exit 1
```
On active ce script sous Debian avec update-rc.d sabnzbd defaults. Finalement on
configure Nginx comme proxy. Je me suis borné à un accès HTTP protégé par
une authentification utilisateur / mot de passe mais HTTPS est recommandé.
``` nginx
server {
listen 80;
server_name www.yourserver.yourdomain;
root /var/www/www;
access_log /var/log/nginx/www.access.log;
error_log /var/log/nginx/www.error.log;
location /sabnzbd {
auth_basic "Restricted area";
auth_basic_user_file /var/www/htpasswd;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://127.0.0.1:7777/sabnzbd;
}
}
```
Pour la création du fichier d'authentification **htpasswd** je vous renvoie à
la [FAQ de Nginx](http://wiki.nginx.org/Faq#How_do_I_generate_an_htpasswd_file_w
ithout_having_Apache_tools_installed.3F) car plusieurs méthodes sont possibles.
Gare à sécuriser son accès et à le placer hors des répertoires servis par
Nginx. A ce stade SABnzbd fonctionne à moitié :-) En effet SABnzbd ne va pas
servir toutes les ressources (HTML / CSS) et il faut les lier statiquement à
Nginx.
``` shell
# on lie les ressources statiques du thème Plush
mkdir -p /var/www/www/sabnzbd
ln -s /srv/sabnzbd/interfaces/Plush/templates/static /var/www/www/sabnzbd/static
ln -s /srv/sabnzbd/interfaces/Config/templates/staticcfg /var/www/www/sabnzbd/staticcfg
```

25
posts/2012/2012-12-31-bilan-de-l-annee-2012.md Executable file
View file

@ -0,0 +1,25 @@
<!-- title: Bilan de l'année 2012 -->
<!-- category: Humeur -->
<!-- tag: planet -->
L'année a été bien remplie ! Au niveau de mon implication dans le logiciel
Libre, je n'ai pas réalisé tout ce que j'avais en tête, par manque de temps,
mais je me suis vraiment fait plaisir.<!-- more --> Après un premier semestre où j'avais
carte blanche pour le choix des outils de l'équipe et où j'ai mis en place le
serveur de développement (Debian, Subversion, Redmine, Jenkins, Sonar), j'ai
intégré une nouvelle société avec une double casquette développeur Java /
admin système GNU/Linux qui m'amène à mettre en place des solutions de Haute
Disponibilité.
<img src="/images/07x/calendar.png" style="float:left; margin: 0px 20px;"
/> Sinon ma belle découverte de l'année c'est Fedora que j'utilise au travail et
à la maison depuis 6 mois. Alors que j'ai surtout utilisé des distributions
basées sur Debian hormis ArchLinux par le passé, j'ai été enchanté par le
spin XFCE de Fedora 17. Mon portable relativement récent est correctement
géré *"out of the box"*, les dépôts Fedora sont plutôt complets et
généralement on trouve une version RPM des logiciels moins libres. L'outil de
gestion de paquets Yum est bluffant par sa rapidité grâce à un système de
téléchargement différentiel qui permet d'économiser de la bande passante.
Vivement Fedora 18 :-)
Bonnes fêtes de fin d'année à tous !