Lorsque vient le temps de mettre à jour Drupal ou ses modules, c'est un peu la panique. Il faut aller vite car la faille de sécurité est généralement là, mais il ne faut pour autant pas se précipiter sous peine de finir avec un beau plantage. Voici dons mes recettes de cuisine pour mettre Drupal à jour sans risque avec un minimum d'efforts.

Se tenir informé

Pour commencer, être à jour c'est avant tout être informé. Pour cela un client RSS comme liferea ou Akregator est un outil indispensable sur lequel il faut ajouter le flux http://drupal.org/security/rss.xml ou de manière plus générale http://secunia.com/information_partner/anonymous/o.rss qui annonce toutes les failles pour tous les logiciels connus.

Le coeur modifié

Dans un monde idéal, la mise à jour de Drupal consiste juste à décompresser la nouvelle archive, et lancer la commande magique :

# On vérifie déjà ce qui change (notez le --dry-run )

gaston$rsync --dry-run -av --progress --delete --exclude .svn --exclude /sites --exclude /files --exclude /tmp drupal_6.666/ chemin/vers/mon_drupal/

bla bla...

bla.

 

# Et lorsque l'on a exhaustivement vérifié que tout est bon, on relance "pour de vrai"

gaston$rsync -av --progress --delete --exclude .svn --exclude /sites --exclude /files --exclude /tmp drupal_6.666/ chemin/vers/mon_drupal/

bla bla...

bla.

gaston$ 

synchronisation des sources

Mais il faut être un peu honnête, garder sur un site un tant soit peu évolué avec une version de Drupal pur-jus, sans aucune modification du coeur, est pour le moins chimérique. On a tous, à un moment ou à un autre, besoin d'adapter la gestion des commentaires, d'assouplir le cache de page ou que sais-je encore, en fonction des besoins du client.

Mais comme nous sommes des gens prudents et organisés, toutes ces modifications ont été soigneusement documentée avec nom de l'auteur du patch, explication et ancien code.

/* Gaston: Modification de cette fonctionnalité en faisant bla bla
 * parce que bla bla.
 * if ( $comments ) {
 */
 if ( $comments && $condition_magique ) {
 // Gaston: Fin du patch

documentation d'un patch

Les plus valeureux pourront garder dans un dossier spécial tous les patchs isolés en mettant une modification par fichier, mais là cela devient presque excessif.

Toujours est-il qu'à se stade, synchroniser les sources à la mode "Monde idéal" n'est pas une option. C'est ici qu'intervient la technique de génération de patch.

Génération d'un patch de mise à jour

Le principe est en soit très simple. Il s'agit de créer un fichier .patch qui contiendra toutes les différences entre la version courante de officielle Drupal et la version cible. Attention, il ne s'agit pas de faire un patch entre les sources de votre site et ceux de la nouvelle version mais bien de récupérer les sources officiels sur drupal.org correspondant à la version qui est actuellement sur votre site.

De manière générale cette technique peut être aussi utilisée sur un coeur non modifié, car le patch présente l'immense avantage de servir de mémoire. Vous pouvez ainsi sauvegarder chacun des patchs appliqués, les étudier pour comprendre ce qui a changé (très instructif pour les mise à jour de sécurité) et aussi pouvoir revenir en arrière car un patch peut être appliqué dans les deux sens.

Prenons un exemple. Vous êtes actuellement sur Drupal 6.8 (c'est très mal !!) que vous avez copieusement modifiée et vous allez faire évoluer vers la version 6.12. Vous allez donc récupérer la version 6.12 ET 6.8 sur drupal.org et faire votre patch avec ces deux versions. Ensuite ce patch va être appliqué à votre version 6.8 modifiée pour la mettre à jour vers une 6.12 elle aussi modifiée. Si vous avez de la chance, les mises à jour ne porteront pas sur du code que vous avez modifié, et l'application du patch se fera sans encombre, dans le cas contraire, il faudra gérer chaque confit à la main, mais nous verrons cela plus tard.

Pour l'heure commençons par créer notre patch en utilisant la commande diff :

gaston$cd ~

gaston$mkdir patchs

gaston$cd patchs

 

# récupération de la version actuelle non modifiée et décompression

gaston$wget http://ftp.drupal.org/files/projects/drupal-6.8.tar.gz

gaston$tar -zxvf drupal-6.8.tar.gz

drupal-6.8/

drupal-6.8/includes/

drupal-6.8/includes/actions.inc

...

 

# récupération de la nouvelle version

gaston$wget http://ftp.drupal.org/files/projects/drupal-6.12.tar.gz

gaston$tar -zxvf drupal-6.12.tar.gz

drupal-6.12/

drupal-6.12/includes/

drupal-6.12/includes/actions.inc

...

 

# Création d'un patch entre la 6.8 et la 6.12

diff -Naur drupal-6.8/ drupal-6.12/ > drupal-6.8-6.12.patch

gaston$ 

Le patch est maintenant créé, il ne reste plus qu'à l'appliquer sur le code.

gaston$cd /chemin/vers/drupal

 

# D'abord on vérifie que tout passe bien avec l'option --dry-run

gaston$patch --dry-run -p1 < ~/patchs/drupal-6.8-6.12.patch

 

# Si l'on a AUCUN "FAILLED", on peut appliquer le patch "pour de vrai"

gaston$patch -p1 < ~/patchs/drupal-6.8-6.12.patch

gaston$ 

application du patch

Gestion des conflits

Si vous avez obtenu des "FAILLED" lors de l'application du patch en mode "dry-run", vos modifications du coeur sont donc en confit avec les mises à jour.

1. Commencer par sauvegarder le fichier incriminé dans un coin.
2. Avec un outil de comparaison de fichier comme meld, comparer la version "canonique" du fichier qui se trouve dans le dossier ~/tmp/drupal-6.8/chemin/vers/monfichier.php avec le fichier modifié qui pose problème.
3. Si la modification n'est sans intérêt comme de simples retours chariots ou un mauvais formatage, il faut noter dans un coin la modification
4. Lorsque la modification a été notée, écraser le fichier avec la version originale.
5. Appliquer à nouveau le patch en mode dry-run et recommencer à l'étape (1) si ça coince autre part.
6. Lorsque tout passe, appliquer le patch sans dry-run
7. Enfin, ré-écrire toutes modifications qui ont été notées.

Généralement cette dernière étape est un bon moment pour se demander s'il est intelligent de faire cette modification à cet endroit, ce qui finir 9 fois sur 10 par le constat d'une grosse flemme un vendredi soir à 19h alors que la même modification faite à 8h un lundi matin aurait donné lieu à la création d'un module....

Mise à jour de la base

Voilà, si tout c'est bien passé, il ne reste plus qu'à mettre à jour la base de données (update.php), tester exhaustivement, puis synchroniser avec la production.

Mise à jour des modules

La mise à jour des modules peut passer par la même procédure de génération de patch, avec les mêmes bénéfices que pour le coeur, que ces modules aient été modifiés ou pas. Cependant, autant mettre à jour le coeur n'arrive pas, et heureusement, tous les quatre matins, il n'en est pas de même des modules. Plus il y en a, plus les mises à jours sont régulières.