• Bah ! ça marche bien comme ça, je toucherais plus de toute façon !
• Pff ! ça me broute de commenter mon installation dans un wiki !

(Pour le second argument, le fait est qu’à chaque modification d’un fichier de configuration, il faudrait le remettre à jour sur le Wiki… très contraignant pour un informaticien qui se doit d’être flemmard !)

Après en avoir discuté avec les rigolos de Gnoulibre.org, je me suis laissé convaincre de tester une de leurs solutions à ce problème.

Git + Redmine

Je pensais ce genre de solution destinée exclusivement aux affreux développeurs d’applications, alors que non, un administrateur système peut également y trouver son compte !

Berk ! un développeur Web !

Note : La combinaison Git + Redmine n’est pas la seule solution. Il est possible de faire globalement la même chose en combinant au choix, SVN/Git/Mercurial avec Trac/Redmine/GForge.
SVN, Git et Mercurial sont des systèmes de gestion de versions.
Trac, Redmine et GForge sont des applications Web de gestion de projets capables de fonctionner avec les systèmes de gestion de versions.

Le but n’est pas ici d’expliquer en détail le fonctionnement de ces outils qui servent normalement à des projets de développement de logiciels, mais globalement :

• Les fichiers sources sont affichés sur l’application web.
• Tous les collaborateurs peuvent participer à la rédaction d’un Wiki pour expliquer le fonctionnement du programme.
• Les utilisateurs peuvent poster des tickets pour signaler des problèmes ou faire des demandes d’ajout de fonctionnalités.
• L’avantage de ces outils étant que les fichiers sources sont toujours à jour à l’aide du système de gestion de version.
• …

Les raisons d’utiliser Git pour vos fichiers de configuration :

• « Sauvegarde » des fichiers
• Versionning des fichiers avec possibilité d’afficher les modifications entre deux versions d’un même fichier
• Possibilité de propager les fichiers de configuration sur une autre machine

Git

L’installer à l’aide du gestionnaire de paquet.
Ensuite les commandes de base :
Se mettre dans le répertoire contenant les fichiers à suivre puis :

Initialiser le dépôt Git :

$ git init

Ajouter des fichiers à l’index du dépôt :

$ git add nom_fichier

Faire un commit :

$ git commit -a -m "commentaire décrivant le commit"

Puisqu’il s’agit de surveiller des fichiers de configuration, il peut être bon de lancer un commit régulièrement. Un p’tit cron, ça fait pas de mal :

$ crontab -e

Dans l’éditeur de texte qui s’ouvre, sous la ligne de commentaire, entrer la ligne :

00 05 * * * cd /chemin/vers/le/rep && git commit -a -m "Cron autocommit"

Enregistrer et quitter.
Comme ça, quoi qu’il arrive, un commit des fichiers sera fait quotidiennement à 5h du matin (à condition que le PC soit allumé).

Redmine

Maintenant, il faut mettre en place Redmine, je ne détaillerais pas la mise en place car d’autres s’en chargent mieux que moi. Une note tout de même, j’ai pour l’instant abandonné temporairement l’idée de le faire tourner avec Apache en utilisant Mongrel, Passenger ou Fast-CGI, n’ayant pas réussi à obtenir de résultat digne de ce nom après deux journées de bidouillage. (Oui, je suis mauvais !)

Personnellement je me contente de lancer Redmine avec Webrick :
Depuis le répertoire d’installation de Redmine :

$ ruby script/server -e production

Commande à lancer dans un screen ou en mode daemon.

J’accède ensuite à l’application en entrant l’adresse http://ADRESSE_DE_MON_SERVEUR:3000 sur mon navigateur Web.

Il peut être sympa de rendre cette page disponible depuis l’extérieur histoire de ne pas y avoir accès qu’en local. Il faut bien sur pour cela ajouter une règle sur le firewall du serveur pour autoriser le port 3000 en TCP et faire de même sur la box qui relie votre serveur à Internet.

Pour iptables, rajouter la ligne suivante à votre liste de règle :

iptables -A INPUT -p tcp -i eth0 --dport 3000 -j ACCEPT

Bon, c’est une solution un peu crade « en attendant » de me débloquer avec mon Apache qui semble faché avec tout ce qui est Ruby on Rails…

Mais bon, peu importe, on peut enfin accéder à Redmine ! Joie !
(Si, si : Joie ! Après avoir suivi un tuto d’installation et configuration, quand ça marche, on peut être content !)

Youpi, C'est la fête !

Pour la première connexion, les identifiants par défaut sont :

• login : admin
• mdp : admin

Merci de modifier rapidement le mot de passe dans l’interface de l’application, surtout si Redmine est accessible depuis l’extérieur…

Un test pour se faire la main

Pour se familiariser avec Redmine, je conseille de se créer un dépôt Git de test dans un dossier test avec des fichiers de test (et le mot du jour est…….. TEST !)

$ mkdir test
$ cd test/
$ echo "pouet" > toto.txt # creation des fichiers
$ echo "color : blue" > watchmenbigdong.conf
$ git init
$ git add toto.txt
$ git add watchmenbigdong.conf
$ git commit -a -m "Premier commit"
$ echo "color : red" > watchmenbigdong.conf # modification d'un des fichiers
$ git commit -a -m "Second commit : Watchmen pour daltoniens"

Puis, dans Redmine, créer un projet test. Ensuite dans ce projet, aller sur Configuration, puis Dépôt. Dans SCM, choisir Git et dans le champs en dessous, mettre le chemin complet vers le répertoire .git. Exemple : /home/utilisateurtest/test/.git

Configuration du dépôt dans Redmine

Enfin, cliquer sur Créer.

Explorer au passage tous les onglets du volet Configuration pour bien mettre sa sauce. Puis cliquer sur Dépôt (celui à côté de Configuration) pour voir la liste des fichiers et leurs « commit » respectifs. On voit bien que le fichier watchmenbigdong.conf a été modifié depuis le premier commit mais pas le fichier toto.txt.

Il est possible à partir de cette fenêtre de comparer les différentes versions d’un même fichier.

Pour bien saisir l’intérêt de Redmine, il est bon de farfouiller tous les onglets. Le plus intéressant à mes yeux après l’onglet Dépôt est l’onglet Wiki. Ce wiki permet de s’étendre sur les explications d’installation et configuration de la machine et de différents programmes !

Redmine pour gérer sa configuration

Lors de la création de projets, bien décocher la case « Public » si le projet doit contenir des fichiers de configurations…

Pour l’instant, je me sers de cette solution avec deux projets :

• /home : qui contient les fichiers de conf du dossier /home de l’utilisateur :
  • .gnupg/
  • .irssi/
  • .ssh/
  • .bashrc
  • .vimrc
  • …
• /etc : qui contient les fichiers de conf :
  • /apt/sources.list
  • fstab
  • irssi.conf
  • mpd.conf
  • screenrc
  • …

mon home dans Redmine

En bref, tous les fichiers de configuration que je peux être amené à modifier moi-même ! (et pour lesquels je souhaite un suivi)
Si un logiciel venait à ne plus marcher, je pourrais ainsi rapidement savoir si cela vient d’une mauvaise configuration et je pourrais rapidement revenir en arrière !

Pour finir, il peut être bon de clôner vos dépôt Git sur d’autres PC ou des supports externes. Si le serveur plante complètement et devient incapable de lancer Redmine, il sera possible de voir les modifications depuis un autre PC.

La petite pelle de liens utiles

• Introduction à Git
• Utilisation de Git pour des fichiers de configuration
• Guide sur Git
• Guide sur Redmine
• Pour bien saisir la référence au film Watchmen

Un bon informaticien se doit de faire des blagues de bit(e)… hum, pas tip top après un diplôme Blague+3 en informatique.

Bon versionning à tous !