La branche « default » est la branche de développement qui est toujours la plus à jour (HEAD dans le monde svn).

La branche « stable » est la branche contenant uniquement des versions stables. Le contenu de la branche « stable » correspond à la dernière release officielle. On utilise cette branche pour la correction de bugs urgents (hotfix).

Les actions Mercurial sont réalisées au moyen de la commande « hg ». Certaines actions concernent le dépôt local (interactions entre les sources et le dépôt local),  d’autres concernent le dépôt central (interactions entre le dépôt local et le dépôt central). Les commandes locales seront indiquées en bleu et les autres en rouge.

Pour l’exemple, le projet s’appelle « HelloWorld ». Le but est de commencer avec les 2 dépôt (local et central) synchronisés.

Cas 1 : le projet est totalement nouveau, il n’y a ni dépôt local, ni dépôt central

Créer un dépôts « HelloWord » central sur Bitbucket

On obtient l’url d’accès au dépot : ssh://hg@bitbucket.org/bejean/helloworld

Créer un dépôt local

$ mkdir /Projects/HelloWord
$ cd /Projects/HelloWord
$ hg init

Cas 2 : le projet existe dans un dépôt central

Créer un dépôt local et récupérer les sources du dépot central.

$ mkdir /Projects/HelloWord
$ cd /Projects/HelloWord
$ hg init

$ hg clone ssh://hg@bitbucket.org/bejean/helloworld

(cette commande met à jour à la fois le dépôt local et les sources, elle devrait être bleue et rouge)

Cas 3 : le projet existe dans un dépôt local

Créer un dépôt central.
On obtient l’url d’accès au dépôt : ssh://hg@bitbucket.org/bejean/helloworld

Se placer dans le dépôt local et envoyer les sources dans le dépôt central.

$ cd /Projects/HelloWord
$ hg push ssh://hg@bitbucket.org/bejean/helloworld

Pour la suite de cet article, nous supposons que l’on est dans le cas 1. On a alors nos dépôts créés mais vides.

Configuration

Afin de ne pas devoir spécifier l’url du dépôt central pour toutes les commandes qui interagissent entre le dépôt local et le dépôt central (en rouge), nous allons commencer par configurer notre dépôt local.

On édite le fichier « hgrc » du dépôt.

$ cd /Projects/HelloWord
$ vi .hg/hgrc

et on ajoute la section suivante :

[paths]
default = ssh://hg@bitbucket.org/bejean/helloworld

Début de développement

Commençons à travailler dans notre environnent local. On créer un fichier en local

$ cd /Projects/HelloWord
$ touch readme.txt

hg status indique que le fichier est inconnu dans le dépôt local

$ hg status
? readme.txt

On ajoute le fichier dans le dépôt local

$ hg add readme.txt

hg status indique que le fichier est connu dans le dépôt local mais pas à jour

$ hg status
A readme.txt

On met a jour le fichier dans le dépôt local

$ hg commit -m "Premiere version du fichier" readme.txt

hg status n’indique plus de fichier inconnus ou non à jour.

hg branches indique maintenant qu’il existe une branche « default »

$ hg branches
default                        0:621365c7850a

Le dépôt central n’est toujours pas au courant du contenu du dépôt local. On envoi nos modifications dans le dépôt central.

$ hg push
pushing to ssh://hg@bitbucket.org/bejean/helloworld
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files
remote: bb/acl: bejean is allowed. accepted payload.

La copie d’écran si dessous montre que le dépot central est à jour avec une branche « default »

Publication d’une première version stable (v1.0) : branches et tags

On considère que cette version des sources du projet est la première version stable. Il faut donc maintenant :

1/ tagger la version

$ hg tag v1.0

2/ créer une branche « stable » qui soit le reflet de la branche « default »

$ hg branch stable
$ hg commit -m "branch stable"

Afficher les tags, les branches et la branche active.

$ hg tags
tip                                2:88b63958bb97
v1.0                               0:621365c7850a

$ hg branches
stable                         2:88b63958bb97
default                        1:6d1c947c8a95 (inactive)

$ hg branch
stable

On met à jour le dépôt central avec la nouvelle branche.

$ hg push --new-branch

Voici un schéma qui récapitule les différentes actions et les différents flux.

Attention, à cette étape, la branche active est « stable ». Il faut revenir à la branche « default », pour coder de nouvelles fonctionnalités.

$ hg update default
$ hg branch
default

Le développement continu …

On modifie le fichier readme.txt et la commande hg status nous le confirme.

$ hg status
M readme.txt

on commit les modifications dans le dépôt local

$ hg commit -m "Ajout d'une fonction"

On peut vérifier les modifications locales transférables dans le dépôt central.

$ hg outgoing
comparaison avec ssh://hg@bitbucket.org/bejean/helloworld
searching for changes
changeset:   3:2b9ef639a08b
tag:         tip
parent:      1:6d1c947c8a95
user:        Dominique Bejean <dominique.bejean@eolya.fr>
date:        Sat Nov 19 20:16:49 2011 +0100
summary:     Ajout d'une fonction

Si ces modifications sont terminées, on peut les mettre à disposition des autres développeurs dans le dépôt central

$ hg push

De même on peut vérifier les modifications faites dans le dépôt central (par d’autres développeurs) et pouvant être récurées. Dans notre cas, il n’y en a pas.

$ hg incoming
comparaison avec ssh://hg@bitbucket.org/bejean/helloworld
searching for changes
aucun changement trouvé

Régulièrement, on récupère dans notre dépôt local les modifications faites par les autres développeurs et disponibles dans le dépôt central.

$ hg pull
$ hg update

Publication d’un nouvelle version (v2.0)

La publication d’une nouvelle version implique de :

1/ tagger la branche active (default)

$ hg tag v2.0

2/ mettre à jour la stable (merger default dans stable)

$ hg update stable
$ hg merge default

(gérer les conflits. il ne devrait pas y en avoir si les hotfixs fait dans stable ont systématiquement été mergés dans default)

$ hg commit -m "merge from default"

3/ revenir dans la branche de développement

$ hg update default

Le diagramme suivant illustre les séquences de commandes durant le cycle de production d’une nouvelle version :

Correction d’un bug dans la version stable

1/ se placer dans la version stable

$ hg update stable

2/ corriger le bug

$ vi readme.txt

3/ commiter la correction

$ hg commit -m "v2.0 fixe"

4/ revenir à la branche default

$ hg update default

5/ merger la correction de la branche stable et résoudre les potentiels conflits

$ hg merge stable
$ vi readme.txt
$ hg resolve -m readme.txt
$ hg commit -m "merge resolve"
$ rm readme.txt.orig

Comme référence, on trouve les 2 diagrammes suivants sur le site ivy.fr (licence Creative Commons Attribution 3.0 Unported).

Un autre diagramme (trouvé sur le site secretGeek) qui indique un workflow basic. Le point 6 (qui n’est pas systématique) doit être suivi d’un « hg up ».

Afin de gérer les sources du plugin et de travailler en équipe, on peut utiliser un outil de gestion de source tel que Git et utiliser Github comme repository central. Pour la passerelle Git vers SVN, on utilise alors la commande git svn et ses différentes actions.

Je ne décrirai pas ici comment fonction SVN et Git. Par contre, je souhaite expliquer comment j’ai pu résoudre un problème de mise à jour du repository SVN de WordPress lors de la livraison d’une nouvelle version d’un plugin.

Donc, après des modifications du plugin, je commit et je mets à jours github. Les commandes successives sont en simplifiant :

git commit ...
git push origin master

Jusque là tout va bien !

Après ceci, je veux mettre à jour le repoitory svn de WordPress puis tagger une nouvelle version du plugin et là patatra !

git svn dcommit
    Committing to http://plugins.svn.wordpress.org/browse-content-by-my-solr-server/trunk ...
    Merge conflict during commit: File or directory 'browse-content-by-my-solr-server.php' is
    out of date; try updating: resource out of date; try updating at
    /usr/local/git/libexec/git-core/git-svn line 579

Que ce fichier soit « out of date », je n’en doute pas car je l’ai bien modifié en local et après avoir mis à jour le repository github, c’est le repository SVN que je veux mettre à jour avec la commande « git svn dcommit » . J’ai l’impression que j’ai manqué quelque chose comme une opération « pull » en provenance de SVN et d’un « rebase » dans la foulée. Mais, étant le seul à travailler sur ce plugin, personne d’autre n’a fait évoluer le repository SVN parallèlement à mes modifications locales. Mystère !

Après de longues recherches sur cette erreur et aucune solution qui ne me permette de commiter et tagger dans svn, je trouve cet article qui me permet de repartir de zéro: http://danielbachhuber.com/2010/09/29/how-to-properly-use-git-with-wordpress-org-subversion/

La manipulation décrite rétablie le répertoire de travail local avec le contenu du SVN WordPress qui contient toujours la version précédente du plugin, puis, réinjecte les modifications qui sont dans le repository sur github. En gros, les étapes sont :

1. sauvegarder les derniers developpements locaux (tar …) et mettre tout cela de coter au cas où …
2. recloner le repository svn en local dans un répertoire travail vierge
3. récupérer la dernière version github qui est à jour avec les dernières modifications (mais sauvegardées par ailleurs au cas où)
4. commiter sous svn et tagger

Et dans la pratique, cela donne :

* Recréer le répertoire local de travail

cd <wordpress plugin dir>
rm -rf browse-content-by-my-solr-server
mkdir browse-content-by-my-solr-server

* Récupérer dans SVN le numéro de révision correspondant au dernier commit fait.

svn log https://plugins.svn.wordpress.org/browse-content-by-my-solr-server/

------------------------------------------------------------------------
 r436435 | dbejean | 2011-09-11 20:06:54 +0200 (Dim, 11 sep 2011) | 1 line

Create tag 1.1.0
 ------------------------------------------------------------------------
 r436432 | dbejean | 2011-09-11 19:58:50 +0200 (Dim, 11 sep 2011) | 1 line

template 3
...

On ne retient pas r436435 qui a été créé par une commande « git svn tag », mais r436432.

* Cloner le repository SVN dans le répertoire local de travail :

git svn clone -s -r436432 https://plugins.svn.wordpress.org/browse-content-by-my-solr-server/
cd browse-content-by-my-solr-server
git svn fetch

Note : « -s » est un raccourci pour   « -t tags -b branches -T trunk »

* Ré-associer le répertoire local de travail au repository Github

git remote add -f origin git@github.com:bejean/browse-content-by-my-solr-server.git
git checkout origin/master *
git add *
git commit -m "Updated from GitHub"

* Commiter et tagguer la nouvelle version du plugin dans le SVN WordPress

git svn rebase
git svn dcommit
git svn tag "x.x.x"

Et voilà le plugin est livré !

Il ne me reste plus qu’à trouver ce qui a provoqué cette erreur afin quelle ne se reproduise plus.

La première chose a vérifier avent de se lancer dans l'installation de Vmware vSphere Hypervisor, c'est la compatibilité matérielle de votre serveur. Par exemple, les 2 cartes réseaux de la carte mère ASUS P6T Deluxe V2 ne sont pas compatibles. J'ai du les désactiver et utiliser à la place une carte réseau Intel PRO 1000 GT PCI. 

Les étapes de la migration sont:

• télécharger vSphere Hypervisor sur le site Vmware et récupérer une clé de licence gratuite
• récupération de toutes les vm hébergées sur le serveur OpenSuse sur un disque de backup. Ce disque doit être accessible depuis un poste Windows XP ou Seven car les images qui s'y trouvent serviront pour leur réinstallation sur le serveur vSphere Hypervisor.
• installation de vSphere Hypervisor. Suivre ce guide sur le site Tuto-IT. Apres l'étape impérative du choix d'un mot de passe (le client vSphere ne peut pas se connecter au serveur sans mot de passe), il faut absolument en profiter pour autoriser les accès SSH à ESXi. Pour cela, aller dans le menu "Troubleshooting options".
• installation du client vSphere sur un poste Windows
• installation Vmware vCenter Converter Standalone sur un poste Windows
• importation des machine virtuelles

Problèmes rencontrés lors de l'importation de mes machines virtuelles

Dans le récapitulatif pré-conversion, bien vérifier que le disque dure est de type "Léger" et non pas "Plat". En mode "Plat", la totalité de l'espace disque est pré-alloué dans le datastore.

Vmware vCenter Converter ne reconnait pas automatiquement les distributions Debian. J'ai du manuellement modifier le type de distribution en indiquant Debian 5.0 64 bits (pour Lenny et Squeeze). Plus tard, dans le client vSphere, la mise à jour automatique des Vmware tools se passera sans aucun soucis dans le mode automatique.

Je n'ai pas réussi à importer 2 clients Windows XP Pro qui étaient dans Vmware Server 2.0. J'ai du utiliser une machine virtuelle Windows XP qui tourne sous Vmware Fusion. J'y ai remplacé le fichier vmdk par ceux des VM que je ne réussissais pas à importer. 

Les backups

Dans vSphere Hypervisor, il n'y a pas de solution de backup intégrée. Je vous conseille les scripts ghettoVCB disponibles sur le site de Vmware (du sérieux donc) :

• sauvegarde
• restauration

Templates

Il n'y a pas non plus de solution de VM Template que l'on peut cloner pour mettre en place rapidement un nouveau serveur.

Pour contourner ce problème, j'ai importé ma VM Debian 6.0 de base et je l'ai nommée "_TEMPLATE_DEBIAN_60_64B". Cette VM n'a pas vocation à être allumée sauf une fois pour la mettre à jour ("aptitude update" et "aptitude upgrade") et mettre à jour les Vmvare tools.  

Pour déployer un nouveau serveur, je me connecte en ssh à ESXi, je copie le répertoire de la VM template sous un autre nom dans le même datastore ou dans un autre. Puis, j'enregistre la nouvelle VM dans ESXi avec la commande suivante :

/bin/vim-cmd solo/registervm <chemin_complet_du_fichier_vmx_de_la_vm_a_activer>

Depuis quelques semaines je collabore à un projet qui nécessite un travail en équipe et qui impose donc un outil de gestion de sources. N’ayant pas le choix, j’ai bien du m’y mettre et avec l’assistance de mes partenaires de travail, ça c’est finalement passé vite et plutôt facilement. Cet outil, c’est Mercurial (également appelé Hg).

Je ne vais pas vous faire ici une étude comparée de Subversion et de Mercurial car ceci est déjà très bien fait sur le blog PilotSystems. Je dirai juste que contrairement à Subversion qui utilise un dépôt unique centralisé par tous les développeurs, Mercurial utilise 2 types de dépôt : un dépôt local et un dépôt central. L’avantage de ce système dans mon cas est que pour la plupart de mes projets, le dépôt local me suffit car je travail seul. Le dépôt local permet toutes les opérations dont on a besoin au minimum : commit, update revert, diff, tags, branch, …

Un autre point à l’avantage de Mercurial est que le dépot local est constitué d’une arborescence de fichiers simples à sauvegarder et que les sources ne sont pas pollués par des fichiers cachés dans chaque répertoires des sources.

Je n’utilise par Mercurial depuis Eclipse mais soit en ligne de commandes (il n’y a pas tant de commandes que ça) soit avec l’interface graphique MacHG.

Tutoriaux et arcticles

Voici les bons tutoriaux que j’ai trouvé (par ordre de préférence) :

• HGInit : a Mercurial tutorial
• Un tutorial en français sur l’utilisation de Mercurial
• Mercurial : the definitive guide
  

Une très bonne série d’articles par Steve Losh sur l’utilisation des branches :

• A Guide to Branching in Mercurial
• Mercurial Workflows: Branch As Needed
• Mercurial Workflows: Stable & Default
• Mercurial Workflows: Translation Branches
  

Outils de Merge et de Diff

Tout d’abord, configurer l’outil de comparaison (diff) et d’assistance au merge. En ligne de commande, par défaut, il n’y a pas d’outil de diff et de merge actif et avec MacHg par défaut, c’est Filemerge qui est utilisé si XCode est installé. Le problème avec Filemerge, c’est qu’il ne réussi pas toujours à afficher les différences et qu’il ne peut pas comparer simultanément 3 versions d’un même fichier pour gérer efficacement les merges.

J’ai donc choisi d’installer Diffmerge. La procédure d’installation est bien documentée et simple (dans le fichier Readme). Il faut bien aller jusqu’au bout en installant les scripts de lancement en ligne de commande. Pour l’intégration à Mercurial, cela se passe dans le fichier ~/.hgrc et c’est également bien documenté sur le wiki de Mercurial. Pour une utilisation avec MacHg, il faut aller sur l’onglet « Advanced » des préférences de MacHg. Positionner les options de la zone « Merge and Diff Tool » comme indiqué dans la copie d’écran ci-dessous.

Gestion des mots de passe par dépot

Lors d’un accès aux dépôts centralisés, il est demandé un login. Il est possible de stocker ces login par dépôt dans le fichier ~/.hgrc. Tout se passe dans la section « [auth] » comme indiqué dans cet exemple.

[auth]
bb1.prefix = https://sources.depot1.org/
bb1.username = dominique
bb1.password = xxxx

bb2.prefix = https://sources.depot2.net/
bb2.username = dom
bb2.password = yyyy

...

bbN.prefix = https://sources.depotNN.fr/
bbN.username = domi
bbN.password = zzzz

Mise à jour du 19 septembre 2011 :

Depuis l’écriture de cet article, j’ai également travaillé avec Git un autre outils de gestion de source. Tout comme Mercurial, Git est une solution comportant un  dépôt local et et un dépôt central. Bien que le principe soit le même, les commandes varient sensiblement et je trouve finalement Git plus complexe à utiliser que Mercurial. Je suis entre autre perturbé par l’absence de commandes simples similaire à hg incoming et hg outgoing.

Le but est de pouvoir développer sous Mac OX (Snow Leopard) des applications AMP (Apache / MySQL / PHP) et des applications Java (dont des servlets dans Tomcat). Dans cet article sont abordées les installations de Apache, PHP, MySQL, Java, Tomcat et Eclipse.

Xcode

C'est la première étape incontournable pour disposer d'un environnement de développement sous Mac OS. Xcode est disponible sur le DVD de Snow Leopard, mais la dernière version à jour est disponible gratuitement sur le site de Apple (http://developer.apple.com/products/membership.html). Xcode inclut les outils minimums pour créer et debugger des applications pour Mac (ou iPhone).

Java

Pour Java, il n'y a rien à faire puisque le JDK 1.6 est inclus dans Snow Leopard.

MySQL

Pour installé MySQL, j'ai suivi la procédure décrite dans cette page "Installing MySQL on Mac OS X". Je l'ai juste appliquée à une version 5.0.88.

A noter cette article également qui décrit en plus la création d'un user mysql "Compiling and Installing MySQL 5 on Mac OS X Leopard"

Apache

Comme pour Java, il n'y a rien à faire puisque Apache 2.2 est installé avec Snow Leopard (Partage web).

PHP

Apache est installé avec Snow Leopard donc en toute logique PHP l'est également (mais n'est pas actif dans Apache par défaut). Le problème (pas forcément pour tout le monde) est qu'il s'agit de la version 5.3 et que j'ai besoin de la version 5.2.x. Il faut donc downgrader PHP.

Activation de Php 5.3 dans Apache

Il suffit de décommenter la ligne suivante dans /etc/apache2/httpd.conf.

#LoadModule php5_module        libexec/apache2/libphp5.so

Downgrader Php en version 5.2.x

Pour cela, soit on utilise une distribution 5.2.x pour Mac OS toute prête, soit on compile soit même Php. Pour utiliser une distribution toutes prête de Php 5.2.9 pour Mac OS, on se rend sur le site de Marc Liyanage. Outre la page sur les distributions de Php pour Mac OS, ce site fournit des informations sur Mac OS en général, MySQL, Java et Perl.

J'ai choisi de compiler moi même Php afin de disposer d'une version à jour (5.2.11). Pour cela, je me suis principalement basé sur cet article "Reverting PHP 5.3 to 5.2.10 on Snow Leopard". Le seul changement que j'ai apporté à la procédure décrite concerne la configuration de la compilation de Php. J'ai utilisé cette ligne de commande afin d'activer entre autres l'option sockets.

./configure
    --prefix=/usr/local/php5
    --with-apxs2
    --enable-pdo
    --enable-ftp
    --enable-mbstring
    --enable-mbregex
    --enable-soap
    --enable-sockets
    --enable-gd-native-ttf
    --enable-cli
    --with-freetype-dir=/usr/local/lib
    --with-t1lib=/usr/local/lib
    --with-gd
    --with-zlib
    --with-jpeg-dir=/usr/local/lib
    --with-png-dir=/usr/local/lib
    --with-curl
    --with-mcrypt
    --with-pdo_mysql=/usr/local/mysql
    --with-mysql=/usr/local/mysql/
    --with-mysqli=/usr/local/mysql/bin/mysql_config
    --without-iconv

Je regrette de n'avoir pas réussi à installer et activer la librairie iconv à cause d'une erreur de compilation. Normalement, la solution est dans cette page, mais pour moi, cela n'a pas (encore) fonctionné.

Durant mes recherches, j'ai également trouvé ces articles intéressants :

• Enabling, Compiling and Installing PHP 5 on Mac OS X Leopard
• Installing AMP (Apache, MySQL, PHP) on Mac OS X 10.6 Snow Leopard

Note : pour l'installation de soap.so, voir http://www.bdoran.co.uk/2010/08/03/installing-php-soap-on-osx-leopard-10-6-4/

Tomcat

On trouve beaucoup d'articles décrivant l'installation de Tomcat sous Mac OS. Pour des raisons de compatibilités avec les serveurs Tomcat que je gère et pour lesquels je développe, je souhaite installer une version 5.5. Je me suis basé sur cet article : Apache Tomcat 5.5 Installation on Mac OS-X Leopard 10.5.x.

De mon coté, j'ai installé Tomcat dans /opt/apache-tomcat-5.5.28. J'ai également changer le port d'écoute de Tomcat de 8080 à 8180 comme sous Debian. La version de Java installée avec Snow Leopard est la 1.6 donc dans startup.sh, les variables JAVA_HOME et CATALINA_HOME sont les suivantes :

export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/
export CATALINA_HOME=/opt/apache-tomcat-5.5.28

Durant mes recherches, j'ai également trouvé ces articles intéressants :

• Installing Apache Tomcat 6 on Mac OS X Leopard
• Running Tomcat on Macintosh OS X

Dans ce dernier article est expliqué comment faire afin que Tomcat démarre automatiquement comme un demon. Il y plusieurs solutions et j'ai choisi la suivante :

1. Positionner les variables d'environnement JAVA_HOME et CATALINA_HOME au début du script /opt/apache-tomcat-5.5.28/bin/catalina.sh

2. Créer un fichier /Library/LaunchDaemons/org.apache.tomcat.plist qui contient ceci.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>Disabled</key>
        <false/>
        <key>Label</key>
        <string>org.apache.tomcat</string>
        <key>ProgramArguments</key>
        <array>
                <string>/opt/apache-tomcat-5.5.28/bin/catalina.sh</string>
                <string>run</string>
        </array>
        <key>RunAtLoad</key>
        <true/>
</dict>
</plist>

et lui affecter le bon propriétaire :

sudo chown root:wheel /Library/LaunchDaemons/org.apache.tomcat.plist

Le démarrage et l'arrêt manuel de Tomcat se font ainsi :

sudo launchctl load /Library/LaunchDaemons/org.apache.tomcat.plist

sudo launchctl unload /Library/LaunchDaemons/org.apache.tomcat.plist

Eclipse pour Java et Php

Pour l'installation de Eclipse, ma source d'informations est cet article Installing Eclipse Galileo on Mac OS X, mais on peut également regarder du coté de la distribution Pulse.

Java

La procédure est simple :

1. Sur la page de téléchargement de Eclipse,  récupérer la version Cocoa 32 bits de "Eclipse IDE for Java EE Developers" ou de "Eclipse IDE for Java Developers" et décompresser l'archive récupérée. Un répertoire "eclipse" est créé.

2. Créer un répertoire /Applications/Dev et y copier le répertoire "eclipse" issue de la décompression de l'archive.

Php

Pour la version Php de Eclipse (Eclipse for PHP Developers), la procédure est exactement la même. Avant de copier dans /Applications/dev le répertoire créé par la décompression de l'archive, je le renomme "eclipse php".

Xdebug pour Php

Pour Eclipse Php, il est nécessaire d'installer le composant de debuggage Xdebug.

Sur la page http://aspn.activestate.com/ASPN/Downloads/Komodo/RemoteDebugging/, on télécharge dans la section "Komodo 5.2 Remote Debugging Packages" le module "PHP Remote Debugging" pour Mac OS X. Une fois décompressé, l'archive contient la librairy xdebug.so pour différentes versions de Php.

Dans un terminal exécuter la commande qui suit (sur une seule ligne) en remplaçant les "x" par les valeurs correspondants à la version que vous aurez téléchargée :

sudo cp ~/Downloads/Komodo-PHPRemoteDebugging-5.2.x-xxxxx-macosx/5.2/xdebug.so
/usr/local/php5/include/php/ext/

Dans php.ini (/usr/local/php5/lib/php.ini), ajoutez les lignes suivantes à la fin du fichier :

zend_extension=/usr/local/php5/include/php/ext/xdebug.so

[Xdebug]
xdebug.remote_enable=1
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.remote_autostart=1
xebug.remote_handler=dbgp

Redémarrez Apache (Préférences Système -> partage -> partage web).

Sites utiles

• http://www.entropy.ch/home/welcome.php
• http://blog.zvikico.com/

Dans ce nouvel article, je vais expliquer plus en détail les points suivants :

• Le contenu de la distribution
• Les fichiers de configuration
• Comment gérer plusieurs indexes ?
• Comment gérer plusieurs applications ?

Le contenu de la distribution

Une fois récupérée et décompressée dans un répertoire, la distribution de Solr contient différents répertoires.

Mettre en place un environnement d’exécution de Solr à partir des éléments de la distribution est très simple. Il faut :

1. créer un  environnement d’exécution en copiant le répertoire « /example/solr », sous par exemple « /opt/solr » sous Linux ou « c:/solr » sous windows
2. copier le fichier solr.war contenu dans le répertoire webapps des exemples vers le répertoire approprié du serveur d’application (répertoire webapps par exemple pour Tomcat)
3. configurer le serveur d’application pour qu’il soit lancé avec la variable d’environnement solr.home.home pointant vers le répertoire  d’exécution (par exemple : -Dsolr.solr.home=/opt/solr) et le redémarrer

Dans le répertoire pointé par la variable d’environnement « solr.solr.home », on retrouve donc les répertoires « bin » (scripts utilitaires pour un environnement Linux), « conf » (fichiers de configuration) et « data » (y sera entre autres localisés l’index Lucene des données indexées).

Les fichiers de configuration

Les fichiers de configuration sont localisés dans le répertoire « /conf ». Il s’agit principalement de solrconfig.xml et schema.xml.

solrconfig.xml

Il s’agit du fichier qui contient l’essentiel des paramètres liés au fonctionnement de Solr et plus particulièrement des paramètres de l’API Lucene qu’utilise Solr (longueur maximale d’une champs, taille des buffer mémoire, fréquence de commit, …) . Ce fichier est très bien auto-documenté et fait l’objet d’un document a part entière dans le wiki Solr.

schema.xml

Il s’agit du fichier qui décrit comment seront indexées les données dans Solr. Il définit les types de données, les champs, les manipulations sur les données lors de l’indexation, les champs obligatoires, le champ de requête par défaut, …

Ce fichier est très bien auto-documenté et fait l’objet d’un document a part entiere dans le wiki Solr.

Exemple de déclaration d’un type

<fieldType name=”string” class=”solr.StrField” sortMissingLast=”true” omitNorms=”true”/>

Ce type a pour nom « string », il sera pris en charge lors de l’indexation par la classe « solr.StrField », lors d’un tri du résultat sur ce champ, les documents ne le possédant pas seront positionnés en dernier (sortMissingLast= »true ») et lors de l’indexation les informations de normalisation basées sur la taille du champ seront calculées et stockées (omitNorms= »true »).

Exemple de déclaration d’un champ

Les données indexées dans Solr par le service d’indexation sont contenues dans un datagramme de type XML. Lorsque Solr traite ce datagramme, il rapproche le nom de chaque élément XML avec le nom d’un champ. Il manipule alors la donnée associé à cet élément comme cela est défini par la définition du champ.

<field name=”word” type=”string” indexed=”true” stored=”true”/>

Ce champ est du type « string » (donc il hérite des propriétés de ce type). Il est indexé (donc les recherches peuvent porter sur son contenu) et les données de ce champs sont stokées (donc elles peuvent être récupérées au moment de l’affichage d’une liste de résultats par exemple).

D’autres paramètres importants peuvent également être définis lors de la déclaration d’un champ. Il s’agit de la méthode d’analyse lors de ‘indexation ou de la recherche. La méthode d’analyse permet de définir comment seront traitées les données du champ, à savoir son mode de découpage en mots (tokenizer) et les filtres qui lui seront appliqués (filter). Les filtres permettent par exemple de supprimer les mots vides, de mettre tous les mots en minuscule, de convertir les mots accentués en leurs équivalents sans accent, …

Exemple de déclaration d’un champ dynamique

Une déclaration de champ dynamique permet d’associer un traitement à des éléments du datagramme XML même si ces derniers ne sont pas spécifiquement déclarés comme champs.

<dynamicField name=”*_s”  type=”string”  indexed=”true”  stored=”true”/>

Tout élément du datagramme XML dont le nom se termine par « _s », est considéré comme un élément de nom « string ».

Comment gérer plusieurs indexes ?

Par défaut, une instance Solr ne peut manipuler qu’un index. Comment faire si mon application doit permettre l’indexation de plusieurs types de données comme par exemple un annuaire de personnes et les messages d’un forum de discussion ?

Jusqu’à la version de 1.2 de Solr, il existait 2 solutions : associer un type à chaque document dans l’index (personne, message, …) ou utiliser plusieurs webapps dans le serveur J2EE et les faire pointer vers des environnements différents (-D=solr.solr.home=…). L’association d’un type à chaque document permet lors de la recherche de filtrer la liste de résultats en se limitant aux documents d’un ou plusieurs types. Utiliser plusieurs webapps permet d’utiliser un index distinct pour chaque type de documents.

Avec la version 1.3 de Solr est apparue la notion de « SolrCore » multiples. Un « SolrCore » est un environnement complet Solr (configuration et index) qui est exécuté par une webapps du serveur j2EE. Il est donc possible au moyen d’une seule webapps Solr de gérer plusieurs « SolrCore ». les SolrCore sont déclarés dans un fichier XML « solr.xml » localisé dans le répertoire solr.solr.home associé à la webapp.

Exemple d’un environnement mono-core

solr.solr.home=/opt/solr

Les répertoires d’installation sont organisés comme ceci :

/opt
    /solr
        /bin
        /conf
        /data
        /webapps
            solr.war

Pour un paramétrage de Tomcat au moyen de JNDI, on place dans le répertoire conf/Calalina/localhost de Tomcat, le fichier solr.xml suivant :

<Context docBase="/opt/solr/webapps/solr.war" debug="0" crossContext="true" >
    <Environment
        name="solr/home"
        type="java.lang.String"
        value="/opt/solr/" override="true" />
</Context>

Les urls d’accès à l’administration et aux web service Solr sont :

Exemple d’un environnement multi-core

solr.solr.home=/opt/solr

Les répertoires d’installation sont organisés comme ceci :

/opt
    /solr
        solr.xml
        /core0
            /bin
            /conf
            /data
        /core1
            /bin
            /conf
            /data
        /webapps
            solr.war

Pour un paramétrage de Tomcat au moyen de JNDI, on place dans le répertoire conf/Calalina/localhost de Tomcat, le fichier solr.xml suivant :

<Context docBase="/opt/solr/webapps/solr.war" debug="0" crossContext="true" >
    <Environment
        name="solr/home"
        type="java.lang.String"
        value="/opt/solr/" override="true" />
</Context>

Dans le répertoire pointé par solr.solr.home, on place de féchier solr.xml suivant :

<solr persistent="true" sharedLib="lib">
    <cores adminPath="/admin/cores">
        <core name="core0" instanceDir="core0" />
        <core name="core1" instanceDir="core1" />
    </cores>
</solr>

Les urls d’accès à l’administration et aux web service Solr des cores 0 et 1 sont :

Comment gérer plusieurs applications ?

Imaginons que vous souhaitez indexer des données issues de différentes applications, pour l’exemple, un outil de gestion de contenu (ECM) et un forum de discussion. Chacune de ces applications nécessitant l’indexation de 2 types de données totalement différentes, pour l’exemple, des utilisateurs et des documents (ECM) ou des messages (forum).

Dans ce cas, je propose d’utiliser une webapp par application et un core par type de données.

On a donc un environnement comme celui-ci :

solr.solr.home=/opt/solr

Les répertoires d’installation sont organisés comme ceci :

/opt
    /solr
        /ecm
            solr.xml
            /utilisateurs
                /bin
                /conf
                /data
            /documents
                /bin
                /conf
                /data
        /forum
            solr.xml
            /utilisateurs
                /bin
                /conf
                /data
            /messages
                /bin
                /conf
                /data
        /webapps
            solr.war

Pour un paramétrage de Tomcat au moyen de JNDI, on place dans le répertoire conf/Calalina/localhost de Tomcat, le fichier ecm.xml suivant :

<Context docBase="/opt/solr/webapps/solr.war" debug="0" crossContext="true" >
    <Environment
        name="solr/home"
        type="java.lang.String"
        value="/opt/solr/ecm" override="true" />
</Context>

et le fichier forum.xml suivant :

<Context docBase="/opt/solr/webapps/solr.war" debug="0" crossContext="true" >
    <Environment
        name="solr/home"
        type="java.lang.String"
        value="/opt/solr/forum" override="true" />
</Context>

Dans le répertoire « /opt/solr/ecm », on place de féchier solr.xml suivant :

<solr persistent="true" sharedLib="lib">
    <cores adminPath="/admin/cores">
        <core name="utilisateurs" instanceDir="utilisateurs" />
        <core name="documents" instanceDir="documents" />
    </cores>
</solr>

Dans le répertoire « /opt/solr/forum », on place de féchier solr.xml suivant :

<solr persistent="true" sharedLib="lib">
    <cores adminPath="/admin/cores">
        <core name="utilisateurs" instanceDir="utilisateurs" />
        <core name="messages" instanceDir="messages" />
    </cores>
</solr>

Les urls d’accès à l’administration et aux web service Solr de l’application ECM sont :

Les urls d’accès à l’administration et aux web service Solr de l’application Forum sont :

Sous Linux, une optimisation peut être de factoriser le répertoire « bin » de chaque core car il contient exactement les mêmes scripts. On place un répertoire « bin » dans « /opt/solr » et dans chaque core, on créer un lien symbolique nommé « bin » et qui pointe sur « /opt/solr/bin ».

Pour synthétiser les différents cas de figure lors du choix d’une configuration de Solr, voici un tableau récapitulatif.

Je suis alors tombé sur ce graphique qui montre l’évolution dans le temps du pourcentage d’annonces qui contiennent le nom d’un de ces frameworks. Si le but est de trouver un emploi ou des prestations, pourquoi ne pas choisir le Framework le plus demandé sur le marché de l’emploi ?

Le graphique est fourni par le site indeed.com qui est un moteur de recherche sur un grand nombre de sites spécialisés dans les offres d’emploi. Il montre l’évolution des citations dans les offres d’emplois des Frameworks suivants : dojo, extjs, jquery, mootools, scriptaculous et yui. Le framework Prototype n’est pas cité mais cela n’aurait pas de sens puisque ce terme générerait beaucoup de bruit de par son utilisation dans bien d’autres domaines que les frameworks Javascript. Pour évaluer la popularité de ce dernier, je pense qu’il faut considérer le courbe de scriptaculous car ce dernier est basé sur Prototype et généralement utilisé en complément de ce dernier.

D’après les différents commentaires que j’ai pu lire la préférence des utilisateurs semble être : 1) jQuery et 2) Prototype. Le graphique confirme cette tendance.

Ce graphique est issue de la fonction « Job trends » de indeed.com (malheureusement non disponible pour les offres purement françaises). Vous pouvez utiliser cette fonction pour bien d’autres termes que ceux relatifs au Frameworks javascripts.

Et pour ceux que ça intéresse de savoir qui sont les auteurs ou inventeurs de certains de ces frameworks, c’est ici.

Dans cet article, j’explique la mise en place d’une configuration puissante afin d’héberger des serveurs virtuels sous Vmware server 2.0. Les points abordés sont :

• Choix d’un système d’exploitation pour le serveur Vmware
• Installation de Linux sur le serveur vmware
• Installation de Vmware server 2.0
• Installation des Vmware tools dans les machines invités (guest)
• Sauvegardes des machines virtuelles
• Réduction de la taille (shrink) des disques virtuels vmdk

Choix d’un système d’exploitation

Pour ce serveur hôte Vmware, j’ai choisi d’utiliser openSUSE 11.1 64 bits comme système d’exploitation.

Pourquoi Linux ?

Tous mes serveurs Vmware précédents utilisaient Windows XP ou Windows 2003. J’ai remarqué que les performances des serveurs virtuels avaient tendance a se dégrader tres vite. Je mets ce phénomène sur le compte des systèmes  de fichiers NTFS ou Fat32 qui ne sont sans doute pas idéals pour héberger les fichiers vmdk (disques virtuels) de Vmware. De son coté, les systèmes de fichiers Linux ne nécessitent pas de défragmentations régulières d’où moins d’opérations de maintenance futures.

Pourquoi openSUSE ?

J’utilise généralement Debian comme serveur Linux. Malheureusement, il m’a été impossible d’installer la derniere version stable (Lenny) avec le processeur core i7 et la carte mère ASUS P6T DELUXE V2 qui équipe mon serveur Vmware. J’ai donc essayé avec une distribution openSUSE 11.1 et là, aucun problème !

Je ne regrette pas du tout car je trouve cette distribution très agréable à utiliser avec un environnement graphique KDE.

Pourquoi une distribution 64 bits ?

Pour les performances bien sur, mais surtout pour la possibilité de disposer de plus de 3,5 Go de Ram et ainsi faire tourner un grand nombre de serveurs virtuels simultanément.

Installation de Linux

Je ne vais pas décrire l’installation de openSUSE car une fois la distribution au format DVD récupérée ici et gravée, il suffit de démarrer le serveur avec le DVD dans le lecteur et d’enchainer les écrans de la procédure d’installation. Les seuls points délicats peuvent être le partitionnement du ou des disques durs et le choix entre utiliser une interface graphique (KDE ou GNOME) ou ne pas utiliser d’interface graphique. Personnellement, j’ai installé l’interface KDE, mais afin de rendre cet article indépendant des outils disponibles avec les interfaces graphiques, je ferai tout dans un terminal (ou console) en mode texte. Pour faciliter les futures installations de certains packages, j’installe l’outil zypper.

Installation de Vmware server 2.0

Il faut tout d’abord récupérer ici le fichier rpm d’installation pour un Linux 64 bits et la clé d’installation.

L’installation se déroule en 3 étapes :

• L’installation des prérequis
• L’installation du package rpm
• La configuration de Vmware

Pour la configuration, c’est un peu plus compliquer car il est nécessaire d’installer certains pré-requis comme entre autres un compilateur,  l’outil make et les sources du kernel Linux. Voici la commande qui installe un ensemble minimale d’outils de développement :

zypper install autoconf automake binutils cpp gcc gcc-c++ linux-headers-$(uname -r) make psmisc kernel-source kernel-sym

Avec Debian, on ferait juste :

apt-get install build-essential linux-headers-$(uname -r)

L’installation du package rpm est tout ce qu’il y a de plus simple. Il suffit d’exécuter la commande suivante :

rpm -ivh VMware-server-2.0.1-156745.x86_64.rpm

Lancer la configuration de Vmware et répondez aux questions :

/usr/bin/vmware-config.pl

On répond toujours avec la réponse par défaut sauf pour :

Your kernel was built with « gcc » version « 4.3.2″, while you are trying to use
« /usr/bin/gcc » version « 4.3″. This configuration is not recommended and VMware
Server may crash if you’ll continue. Please try to use exactly same compiler as
one used for building your kernel. Do you want to go with compiler
« /usr/bin/gcc » version « 4.3″ anyway? [no]

=> répondre « yes » !

Pour terminer l’installation, il faut éditer le fichier « /etc/sysconfig/boot » et modifier la ligne

RUN_PARALLEL= »yes »

en

RUN_PARALLEL= »no »

Pour démarrer le démon Vmware, la commande est :

/etc/init.d/vmware start

La console d’administration de Vmware est disponible à l’adresse : https://:8333/

Avec Internet Explorer, il faut penser à ajouter cette url dans la zone intranet locale.

Voici quelques liens vers des articles qui m’ont bien aidés :

• How To: Install VMware Server 2 in an openSUSE Host [plus enabling USB support]
• How To Install VMware Server On OpenSUSE Linux 10.3
• Setting up VMware on SUSE Linux

Installation des Vmware tools dans les machines virtuelles (guest)

L’installation des Vmware tools dans les machines virtuelles est indispensable. Mise à part les performances qui seront optimisées, l’intérêt est de pouvoir utiliser l’outils vmrun depuis le serveur hôte afin de stopper proprement en mode « soft » les machines virtuelles.  Sans les Vmware tools, les machines virtuelles ne pourront être stoppées que brutalement sans arrêts préalables de leurs services (guest Windows) ou démons (guest Linux).

L’installation des Vmware tools se fait depuis la console d’administration Vmware, puis se termine dans la machine virtuelle. Si la machine virtuelle est sous Windows, il s’agit d’un setup standard et il faut juste enchainer les écrans. Si la machine virtuelle est sous Linux, la procédure est un peu plus complexe. Voici 2 articles qui expliquent la procédure  :

• Understanding and Installing VMware Tools
• How To Set Up VMware Tools On Various Linux Distributions

Voici dans mon cas, la procédure suivie pour installer les VMware Tools dans une distribution Debian Lenny.

1. Dans VMware Infrastructure Web Access, lancer l’installation des VMware Tools

2. Dans un terminal dans le serveur invité, lancer les commandes suivantes:

sudo apt-get install autoconf automake binutils cpp gcc linux-headers-$(uname    -r) make psmisc
mount /media/cdrom
cp /media/cdrom/VMwareTools-7.7.5-156745.tar.gz /tmp/.
cd /tmp/
tar xvfz VMwareTools-7.7.5-156745.tar.gz
cd vmware-tools-distrib/
./vmware-install.pl

Note : Parfois la commande mount /media/cdrom retourne l’erreur « mount: special device /dev/hda does not exist ». Dans ce cas, essayer la commande suivante :
mount /dev/cdrom /media/cdrom/

Sauvegardes des machines virtuelles

Il s’agit du point qui a été le plus compliqué à mettre en place. En Effet, je dispose de plusieurs datastores avec chacun plusieurs machines virtuelles démarrées ou non. Je voulais donc mettre en place une procédure de sauvegarde automatique de toutes les machines virtuelles par copie complète des fichiers (vmx, vmdk, …).

Il ne s’agit pas de sauvegarde à chaud pour les machines virtuelles démarrées mais la procédure de sauvegarde se charge de les éteindre avant la copie des fichiers et de les redémarrer après.

Il existe des scripts pour la sauvegarde à chaud par création de snapshot ou par exploitation de la technologie de gestion de volume LVM, mais trop compliqués pour que je les adapte à mon besoin. Je suis donc parti d’un script disponible dans les forums de discussion de la communauté Vmware. Ce script montre comment utiliser la commande vmrun pour stopper et démarrer une machine virtuelle. Le problème de ce script est qu’il aurait redémarré toutes les machines virtuelles même celles qui étaient éteintes avant la procédure de sauvegarde. Mon script ne redémarre que les machines virtuelles qui étaient démarrées.

Le script principal : backup-vmware-datastore.sh

#!/bin/sh
 
VMDS=$1
VMDS_PATH=$2
BACKUPDIR=$3
USER=$4
PASSWD=$5
 
CURRENT_DIR=$(pwd)
cd $VMDS_PATH
 
find . -type f -name *.vmx -printf '%pn' | sed 's/.// /' | while read VMX
do
    echo ======================================
    echo date
    echo ======================================
    echo VMX=$VMX
 
    VMDIR=$(echo $VMX | sed 's/[^/..]*..*$//')
    echo VMDIR=$VMDIR
 
    VMNAME=$(echo $VMDIR | sed 's/^[^/.]*///' | sed 's//$//')
    echo VMNAME=$VMNAME
 
    VMEM=$(find $VMDS_PATH/$VMDIR -type f -name *.vmem -printf '%pn')
    echo VMEM=$VMEM
 
    # Stop guest if started
    if [ "$VMEM" != "" ]; then
        echo Stoping $VMDS $VMX ...
        vmrun -T server -u $USER -p $PASSWD -h https://127.0.0.1:8333/sdk stop "$VMDS $VMX" soft > /dev/null 2>&1
        vmrun -T server -u $USER -p $PASSWD -h https://127.0.0.1:8333/sdk stop "$VMDS $VMX" hard > /dev/null 2>&1
    fi
 
    # Backup guest
    echo taring $BACKUPDIR/$VMDIR/$VMNAME.tar $VMDIR ...
    mkdir -p $BACKUPDIR/$VMDIR
    rm $BACKUPDIR/$VMDIR/$VMNAME-save.tar > /dev/null 2>&1
    mv $BACKUPDIR/$VMDIR/$VMNAME.tar $BACKUPDIR/$VMDIR/$VMNAME-save.tar > /dev/null 2>&1
    tar cf $BACKUPDIR/$VMDIR/$VMNAME.tar $VMDIR
 
    # Start guest if previously started
    if [ "$VMEM" != "" ]; then
        echo Starting $VMDS $VMX ...
        vmrun -T server -u $USER -p $PASSWD -h https://127.0.0.1:8333/sdk start "$VMDS $VMX" > /dev/null 2>&1
    fi
done
 
cd $CURRENT_DIR

L’appel du script : dobackup.sh

#!/bin/sh
cd /vmware
./backup-vmware-datastore.sh [Datastore_1] /vmware/datastore_1 /backup/vmware/datastore_1 xxxx yyyy

où « xxxx » est a remplacer par le login d’accès à la console Vmware et « yyyy » par son mot de passe.

Dans cet exemple,

« Datastore_1″ est le nom du datastore

« /vmware/datastore_1″ est la localisation du datastore

« /backup/vmware/datastore_1″ est la destination de sauvegarde

Note : Ce script ne supporte pas les espaces dans les noms de répertoire et de fichier, il faut se limiter à l’alphabet, des chiffres et des « - » ou « _ » (bien sur, je suis preneur de toutes améliorations dans ce domaine)

Voici quelques liens vers des articles qui m’ont bien aidés :

• How to Control VMware Virtual Machines from the Command-Line using vmrun
• vmware-server VM backups

Réduction de la taille (shrink) des disques virtuels vmdk

Les disques durs des machines virtuelles sont les fichiers vmdk. Si lors de la création d’un disque dur on indique que le fichier vmdk ne doit pas être pré-dimensionné à la taille totale du disque dur alors le fichier vmdk grossit au fur et à mesure de son utilisation et de la quantité de données qui y est stockée. Lorsque la quantité de données diminue la taille du fichier vmdk ne diminue pas.

Il est cependant possible grâce à l’utilitaire vmshrink disponible sur le site VM Back de réduire la taille du fichier vmdk à la taille des données qui y sont stockées. Cela peut permettre de réduire considérablement la taille des fichiers vmdk et donc de gagner de l’espace disque et du temps lors des sauvegardes. Cet utilitaire s’exécute dans la machine virtuelle et est disponible sous forme de code source et également pre-compilé pour un certain nombre de système d’exploitation (Windows, Linux, FreeBSD,  NetBSD, OpenBSD, Solaris et Minix). La version pour Linux a été compilée sur une distribution Fedora Core 4 mais a très bien fonctionnée pour moi avec un serveur virtuel Debian.

Voici une présentation en Français sous forme de diaporama (j’ai hésité à mettre ce lien car les diapositives ne sont pas de très bonne qualité).

J’espère que cet outil vous sera aussi utile qu’à moi.

Cet outil permet de conserver l’historique de ce que vous avez copié dans le presse-papier (ou clipboard). Pour moi, il répond à un besoin causé par l’utilisation de Vmware. J’ai remarqué que lorsque j’ai un serveur Windows lancé sous Vmware, son presse-papier est tout fou ! En fait, des anciens copier viennent écraser le dernier copier au point que je colle souvent quelque chose qui n’est pas ce que j’attend. Avec Clipboard magic, plus de problème, je visualise en permanence ce qui va être collé et le cas échéant je re-sélectionne dans son historique le bon élément.

Les éléments du presse papier peuvent être supprimés, édités, sauvegardés dans un fichier et rechargés, …

Les options sont nombreuses.

A essayer !