Le Journal de Nikrou - Outils

Lancer plusieurs firefox avec plusieurs profils sous debian

Nicolas — Fri, 27 Nov 2009 16:19:00 +0100

Avant la version 3.5.5, il me semble, lorsque je tappais les commandes suivantes :

iceweasel -P profil1
iceweasel -P profil2

J'avais deux firefox (et oui iceweasel est le petit nom de firefox sous debian) avec deux profils différents. Depuis cette version, la deuxième commande provoque l'ouverture d'une nouvelle fenêtre mais avec le premier profil. Cette régression est très pénible. Heureusement, il y a une parade : il suffit d'exécuter chaque commande en ajoutant le paramètre -no-remote :

iceweasel -P profil1 -no-remote
iceweasel -P profil2 -no-remote

Mettre en place un dépôt central git

Nicolas — Sat, 28 Feb 2009 21:04:00 +0100

Cela peut sembler quelque peu paradoxal étant donné le mode distribué et décentralisé de ce gestionnaire de version qu'est git mais on peut vouloir utiliser git un peu comme subversion et avoir un dépôt qui servirait de dépôt "officiel". Pour ce faire nous allons utiliser gitosis qui va énormément nous faciliter la vie.

L'installation est des plus simples (en supposant que vous utilisez une debian) :

apt-get install gitosis

Cela devrait ramener les packages suivants s'ils ne sont pas déjà installés : git-core, adduser, sudo.

Première étape : configuration de gitosis

Il faut commencer par créer un utilisateur à qui vont appartenir tous les dépôts présents sur le serveur. On ne va pas être très original et on va appeler cet utilisateur git et on va le mettre dans le groupe git. La commande qui va bien :

adduser --home /home/git git

Mettez le mot de passe que vous voulez. Nous n'utiliserons pas ce compte directement mais tous les accès aux dépôts se feront à travers lui. Il faut maintenant déposer sur le serveur votre clé publique générée avec

ssh-keygen -t rsa

si jamais vous n'en avez pas. Le fichier à déposer est ~/.ssh/id_rsa.pub. On va maintenant générer un premier dépôt git :

 /tmp/id_rsa.pub

ou si vous faîtes un su - git ,tout simplement :

gitosis-init > /tmp/id_rsa.pub

Si l'opération se passe bien, vous devriez avoir un message de ce genre : Initialized empty Git repository in ./. Vérifiez que le script /home/git/repositories/gitosis-admin.git/hooks/post-update est exécutable sinon donnez lui les droits :

chmod +x /home/git/repositories/gitosis-admin.git/hooks/post-update

Et voilà, nous avons un dépôt git ! Vérifiez vous même en tapant sur votre machine locale :

git clone git@VOTRE_SERVEUR:gitosis-admin.git

Cela créé une copie du dépôt que l'on a créé sur le serveur. Le répertoire gitosis-admin nouvellement créé ne contient que deux fichiers : un fichier de configuration gitosis.conf et un répertoire keydir contenant une copie de votre clé publique. Désormais nous n'avons plus à nous connecter sur le serveur : l'ajout de dépôts, le changement de permissions sur les dépôts et toute la configuration de nos dépôts se fait à partir du dépôt gitosis-admin que l'on a cloné. Pour que les modifications soient effectives sur le serveur, il suffira de les envoyer sur le servuer (git push).

Deuxième étape : création de notre premier dépôt

C'est bien joli gitosis mais nous n'avons toujours pas de dépôt pour créer notre super projet helloWord. Pour créer un nouveau, rien de plus simple. Il faut ouvrir le fichier de configuration gitosis.conf dont le contenu est à l'origine :

[gitosis]
[group gitosis-admin]
writable = gitosis-admin
members = VOTRE_NOM@YOUR_HOSTNAME

Ajoutons un groupe hello-group et créons le dépôt hello_world :

[group hello-group]
writable = hello-world
members = VOTRE_NOM@YOUR_HOSTNAME

Sauvegardons le nouveau fichier de configuration et envoyons les modifications sur le serveur (commit et push) :

git commit -m 'ajout du nouveau dépôt hello-world'
git push

Le dépôt n'a pas été créé mais il est déjà géré par gitosis. Créons-le localement et envoyons le sur le serveur :

mkdir hello-world
cd hello-world
git init
git remote add origin git@VOTRE_SERVEUR:hello-world.git

Il faut créer au moins un fichier, l'ajouter (git add) et faire le commit (git commit) avant de l'envoyer sur le serveur :

git push origin master:refs/heads/master

Et vous obtiendrez un message de ce genre :

Counting objects: 3, done.
Writing objects: 100% (3/3), 214 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@VOTRE_SERVEUR:hello-world.git
* [new branch]    master -> master

S'il n'y a aucune révision dans le dépôt local vous aurez cette erreur :

error: src refspec master does not match any.
fatal: The remote end hung up unexpectedly
error: failed to push some refs to 'git@VOTRE_SERVEUR.net:hello-world.git'

Livrer du html au lieu du xhtml avec symfony

Nicolas — Thu, 17 Apr 2008 11:32:00 +0200

Je n'ai encore fait aucun site en XHTML pour diverses raisons : on doit servir le XHTML avec le type mime application/xhtml+xml. Mais le navigateur au grand E bleu ne gère tout simplement pas ce type mime. Et livrer le XHTML avec le type mime text/html revient à faire du mauvais HTML. Voilà pour la petite intro.

Lorsqu'on utilise un CMS, ou un framework, on se demande si celui-là va respecter notre façon de coder. J'ai adopté symfony et j'ai découvert avec joie que je peux continuer à faire du HTML!

Pour permettre à symfony de livrer du HTML au lieu du XHTML, il suffit de surcharger les quelques fonctions d'affichage. Il faut aussi modifier le fichier layout.php de l'application et remplacer le doctype XHTML par celui qui va bien:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

Il faut aussi supprimer les tags fermants des balises contenues dans la partie head

Les fonctions d'affichages des différents tags HTML sont toutes gérées dans le helper TagHelper.php. J'ai donc récupérer ce fichier dans le répertoire lib/helper/ de symfony et je l'ai placé dans le répertoire lib/helper/ de mon application et j'ai modifié la fonction tag pour livrer du HTML au lieu du XHTML. En fait j'ai simplement supprimé le slash de fin de tag:

sortie de la commande diff:

- return '<'.$name._tag_options($options).(($open) ? '>' : ' />'); + return '<'.$name._tag_options($options).(($open) ? '>' : '>');

Cela fonctionne parfaitement mais cela a deux inconvénients. Il ne faut pas oublier de garder toutes les autres fonctions présentes dans ce fichier. L'autre inconvénient est que si on met à jour symfony on risque de passer à côté de modifications dans ce fichier puisqu'on l'aura surchargé.

Mettre à jour le contenu d'un package debian

Nicolas — Tue, 25 Mar 2008 21:08:00 +0100

Récemment, avec le passage en version 22.1 de mon éditeur favori, j'ai eu un soucis avec le mode php qui permet notament la mise en valeur du code par la coloration syntaxique de celui-ci. La version du mode que j'utilisais était vieille comme mes robes comme dirait ma grand-mère!
J'ai beau avoir ma distribution debian en version instable, la version la plus récente était la 1.1.0 qui datait tout de même du 24 janvier 2004. Depuis sont sorties plusieurs versions. La plus récente date du mois de janvier 2008. Je ne sais pas qui maintient ce paquet mais il a dû partir sur une île déserte et ne donne plus signe de vie. Comme ce mode ne fonctionnait pas avec ma nouvelle version d'emacs j'ai décidé d'utiliser une version plus récente du mode php et j'ai donc mis à jour le package debian.

Faire un package debian à partir des sources d'une application n'est pas très complexe mais en faire un à partir d'un autre est encore plus simple ! J'ai récupéré la version 1.1.0-2 du package debian et la version 1.4 de php-mode. Après il suffit de faire les opérations suivantes:

création d'un répertoire pour contenir les sources du package, php-elisp_1.4.0, par exemple, ainsi qu'un sous répertoire DEBIAN contenant les métadonnées.
# mkdir-p php-elisp_1.4.0/DEBIAN
extraction des métadonnées de l'ancien package:
# dpkg-deb -e php-elisp_1.1.0-2_all.deb php-elisp_1.4.0/DEBIAN

extraction des sources de l'ancien package:
# dpkg -x php-elisp_1.1.0-2_all.deb php-elisp_1.4.0

Le contenu du répertoire php-elisp_1.4.0 ressemble à ça (sortie de la commande tree):

.
|-- DEBIAN
|   |-- conffiles
|   |-- control
|   |-- md5sums
|   |-- postinst
|   `-- prerm
|-- etc
|   `-- emacs
|       `-- site-start.d
|           `-- 50php-elisp.el
`-- usr
    |-- lib
    |   `-- emacsen-common
    |       `-- packages
    |           |-- install
    |           |   `-- php-elisp
    |           `-- remove
    |               `-- php-elisp
    `-- share
        |-- doc
        |   `-- php-elisp
        |       |-- README.Debian
        |       |-- changelog.Debian.gz
        |       `-- copyright
        `-- emacs
            `-- site-lisp
                `-- php-elisp
                    `-- php-mode.el

mise à jour du fichier php-mode.el
mise à jour de la version du package dans le fichier DEBIAN/control en remplaçant 1.1.0-2 par 1.4.0
mise à jour de la somme md5 de la nouvelle version de php-mode dans le fichier DEBIAN/md5sums:
# md5sum php-elisp_1.4.0/usr/share/emacs/site-lisp/php-elisp/php-mode.el
reconstruction du package:
# dpkg-deb --build php-elisp_1.4.0
installation du nouveau package:
# dpkg -i php-elisp_1.4.0.deb

Emmener son code en voyage

Nicolas — Sun, 16 Mar 2008 17:18:00 +0100

Lorsque je développe sur un projet, j'utilise subversion et je fais souvent des "commit" pour éviter de garder dans mon répertoire de travail du code modifié et non propagé sur le serveur. Tout va bien lorsqu'on est connecté au serveur central mais si on est dans le train, à la campagne, dans un avion, ou dans les toilettes, cela devient plus problématique.

Le fait que subversion ne soit pas un gestionnaire de version distribué rend la connexion au serveur obligatoire pour faire des mises à jour. J'ai pris l'habitude faire des mises à jours régulières voire très régulières surtout sur des parties du code qui varient beaucoup. De ce fait, lorsque je ne suis pas connecté au serveur, je ne peux suivre cette politique de mise à jour. Mais heureusement svk est là. svk rend la gestion de subversion décentralisée. svk utilise le système de fichiers de subversion mais ajoute des foncitonnalités supplémentaires - surtout la gestion du mode déconnecté-.

Voici comment je l'utilise par exemple sur un projet que nous nommerons HelloWorld. Le dépôt se trouve sur http://svn.central-depot.com/svn/hello_world. Il faut bien évidemment commencer par installer svk, mais apt est mon ami et après le "apt-get install svk" qui va bien, le tour est joué!

Il faut ensuite initialiser le dépôt local:
# svk depotmap --init

Faire un miroir du dépot central, en local:
# svk mirror http://svn.central-depot.com/svn/hello_world //hello_world

Jusque là on n'a toujours aucun code en local! Il faut maintenant faire la synchronisation entre dépôt distant et dépôt local:
# svk sync //hello_world

Désormais on peut travailler en mode déconnecté. On est à jour vis-à-vis du dépôt. On commence par se créer une branche locale:
# svk cp //hello_world/trunk //local/hello_world

Le //local n'est qu'une convention. Vous pouvez évidemment nommer votre branche comme bon vous semble. Après on se crée une copie de travail tout comme on le ferait avec subversion sauf que les commandes sont du type "svk commande" au lieu de "svn commande" :
# svk co //local/hello_world /path/to/my/work/hello_world

On peut ensuite faire des modifications. Pour finir un petit exemple de mise à jour vers le dépôt. Par exemple, pour faire une mise à jour (merge) entre mes modifications locales et le dépôt, je fais:
# svk sync //hello_world (récupération éventuelle de modification) # svk merge -C -rREV1:REV2 //local/hello_world //hello_world/trunk (le -C correspond au dry-run) # svk merge -rREV1:REV2 //local/hello_world //hello_world/trunk

Pour que tout soit parfait, il me manque un mode équivalent à psvn pour svk.

Mise à jour de trac

Nicolas — Sun, 16 Dec 2007 21:04:00 +0100

Suite au passage à la version 0.10.3 de trac, je me suis retrouvé avec une erreur fort peu sympathique : (file is encrypted or is not a database). Je n'ai pas tout compris et la lecture des logs d'apache ne m'a tellement aidé non plus ! Mais ...

Le message semble vouloir dire que soit le fichier .db est encrypté soit trac ne le reconnait pas comme un fichier de base de données. Cela peut faire sourire mais lorsqu'il y a beaucoup d'utilisateurs derrière subversion, cela fait nettement moins rire! Une petite recherche avec mon ami, m'a permis de comprendre que la version de sqlite utilisé par trac dans la version 0.10.3 n'était plus compatible avec celle utilisée précédemment. On est passé de la version 2 à la version 3. Il va falloir convertir la base. Pour cela il suffit de faire : @@mv trac.db trac.orig.db sqlite trac.orig.db .dump|sqlite3 trac.db@@ Evidemment si les exécutables sqlite (version 2) et sqlite3 ne sont pas présents sur le système, il suffit de les intaller : apt-get install sqlite sqlite3

Récupérer un fichier effacé

Nicolas — Wed, 18 Apr 2007 17:15:00 +0000

Le but du "jeu" est de récupérer un fichier sauvegardé dans subversion - que l'on appellera par exemple mon-fichier.php - , que l'on a effacé à une révision donnée. Ce n'est pas aussi simple qu'il n'y parait mais ça reste très abordable. Le plus compliqué est de retrouver à quel moment où il a été éffacé. Pour ce faire on utilise la commande log en mode verbeux: (à coup de grep au besoin.
svn log -v

On se retrouve avec une révision N où le fichier a été supprimé. Donc à la révision précédente, N-1, le fichier était présent. C'est ce fichier que l'on veut récupérer. Il suffit alors de faire:
svn -rN-1 copy http://localhost/svn/PROJET/path/2/file/mon-fichier.php path/2/file/mon-fichier.php

Optimisation de la configuration de trac

Nicolas — Sat, 10 Jun 2006 09:04:00 +0000

trac est un outil formidable pour gérer un projet mais on a l'impression que l'on se complique la vie lorsqu'on veut gérer plusieurs projets sur le même serveur. Avec le nombre de projets augmentant cela devient très rapidement rébarbatif mais heureusement il y a le mod python d'apache pour trac!

Si je garde mon exemple de quatre projets (projet1, projet2, projet3 et projet4) ayant chacun son dépot et son répertoire trac dédié sous le répertoire /var/trac/projets/ alors la configuration d'apache peut se faire de la manière suivante:

<Location /projets>
  SetHandler mod_python
  PythonHandler trac.web.modpython_frontend
  PythonOption TracEnvParentDir /var/trac/projets
  PythonOption TracUriRoot /projets
</Location>

<LocationMatch /projets/[^/]*/login>
  AuthType Basic
  AuthName "Mes projets"
  AuthUserFile /path/2/dav_svn.users 
  Require valid-user
</LocationMatch>

Il faut bien entendu que le mod python soit installé sur votre serveur (package libapache2-mod-python sur debian) pour que cela fonctionne. Pour prendre en compte un nouveau projet dans trac il suffit de créer l'environnement (avec trac-admin) sous le répertoire /var/trac/projets/. C'est tout!

Gestion de plusieurs projets avec trac

Nicolas — Sat, 29 Apr 2006 09:32:52 +0000

Pour ajouter un projet dans trac, voici la marche à suivre:

trac-admin /path/to/projetenv initenv (répertoire où sont placés les pages du wiki entre autre)

Il faut ensuite choisir un nom pour le projet ainsi que le chemin vers le dépôt subversion

Exemple: trac-admin /var/trac/projets/essai (le dépôt subverison correspondant est: /home/nicolas/projets/essai)

Modifier la conf d'apache

Alias /trac /usr/share/trac/htdocs/

AliasMatch /projets/(projet1|projet2|projet3|projet4)(/?.*) /var/trac/projets/$1/trac.cgi$2

<DirectoryMatch "/var/trac/projets/projet1/trac.cgi">
        SetEnv TRAC_ENV "/var/trac/projets/projet1"
        AllowOverride None
        Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
        AddHandler cgi-script .cgi
        Order allow,deny
        Allow from all
</DirectoryMatch>

<DirectoryMatch "/var/trac/projets/projet2/trac.cgi">
        SetEnv TRAC_ENV "/var/trac/projets/projet2"
        AllowOverride None
        Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
        AddHandler cgi-script .cgi
        Order allow,deny
        Allow from all
</DirectoryMatch>

<DirectoryMatch "/var/trac/projets/projet3/trac.cgi">
        SetEnv TRAC_ENV "/var/trac/projets/projet3"
        AllowOverride None
        Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
        AddHandler cgi-script .cgi
        Order allow,deny
        Allow from all
</DirectoryMatch>

<DirectoryMatch "/var/trac/projets/projet4/trac.cgi">
        SetEnv TRAC_ENV "/var/trac/projets/projet4"
        AllowOverride None
        Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
        AddHandler cgi-script .cgi
        Order allow,deny
        Allow from all
</DirectoryMatch>

La configuration d'apache n'est pas optimale. On devrait pouvoir l'améliorer en factorisant les différents DirectoryMatch. De plus on utilise les mêmes fichiers de mots de passe pour tous les projets; on devrait pouvoir les séparer.

Revenir à une version antérieure avec subversion

Nicolas — Fri, 24 Mar 2006 17:54:19 +0000

Cela fait un moment que je travaille sur le même projet en faisant des branches, des tags... Je fais des "commit" réguliers. Et tout à coup, arrivant à la révision 2347 je me suis apperçu que j'avais introduit, par mégarde, un nouveau bug qui n'était pas présent à la révision 2346.

La question qui est sur toutes les lèvres: comment revenir facilement à la révision précédente ? Et bien rien de plus simple, il suffit de taper la commande suivante:

svn merge -r2347:2346 URL .

Deux remarques:

c'est bien la commande merge qu'il faut utiliser; c'est clairement écrit dans la documentation.
je ne me suis pas trompé; les numéros de révisions sont dans l'ordre décroissant contrairement à un merge "classique". Mais en y réfléchissant bien, c'est logique, on veut bien passer de la révision 2347 à la révision 2346

Il ne reste plus qu'à faire un commit.

Gestion des sources

Nicolas — Wed, 22 Mar 2006 21:08:29 +0000

Que l'on travaille seul ou à plusieurs sur un projet, le besoin se fait rapidement sentir de pouvoir garder un historique des modifications que l'on a faites. La méthode, qui consiste à commenter une partie du code pour éventuellement la réutiliser, atteint rapidement ses limites lorsqu'on travaille à plusieurs ou longtemps sur un même projet. En ayant pratiqué cette méthode je me suis retrouvé à un moment avec plus de commentaire que de code!

Pour un projet qui dure ou pour un projet collaboratif, la meilleure façon de travailler est d'utiliser un gestionnaire de versions tel que C.V.S ou Subversion. Ma préférence va à Subversion surtout couplé avec Trac qui est une interface web à Subversion pour parcourir les sources. Trac intègre aussi un wiki, un gestionnaire de bugs, de tickets.

Pour débuter avec Subersion, rien ne vaut la lecture de la documentation, sous licence Creative Commons, publiée par Oreilly.