Témoignage sur la mutualisation du noyau SPIP en 1.9.2

Quinze sites avec un seul noyau

Je viens de mettre en place la mutualisation du noyau de SPIP 1.9.2 pour une quinzaine de sites, avec Apache 2.2.4 et PHP 5.2.1, grâce à la nouvelle documentation officielle.

Extrait de celle-ci :

La mutualisation du noyau de SPIP est possible depuis SPIP 1.9. Il s’agit de pouvoir gérer plusieurs sites SPIP sur un seul serveur ou hébergement en n’utilisant qu’une seule fois les fichiers du noyau de SPIP. Cela permet un gain d’espace disque important, ainsi qu’une possibilité de mise à jour de SPIP simple de l’ensemble des sites en ne mettant à jour que le noyau.

Les évolutions de SPIP 1.9.1 simplifiaient un peu la procédure, mais c’est avec SPIP 1.9.2 et ses améliorations [1] que la mutualisation devient plus robuste permettant la mise en place d’un partage du noyau de SPIP.

Mise en Œuvre

Le noyau SPIP est dans un sous-répertoire de mon arborescence web, genre /test/spip-mutualise, et les sites sont donc dans /test/spip-mutualise/sites/site1, /test/spip-mutualise/sites/site2, etc.

Il n’est pas possible pour l’instant (après tests) d’avoir les sites mutualisés hors du répertoire d’installation du noyau de SPIP.

Si l’organisation des répertoires correspond parfaitement à un cas de la documentation, ce n’est pas tout à fait le cas des URLs que j’ai choisies. En effet, la documentation propose que SPIP soit appelé par http://example.org/test/spip-mutualise et que les sites mutualisés le soient par http://example.org/test/spip-mutualise/site1. Ceci n’a pas été mon choix :

-  SPIP est bien appelé par http://example.org/test/spip-mutualise ;
-  mais les sites mutualisés sont appelés par http://example.org/test/site1 (ce qui masque l’URL du noyau de SPIP). Il n’est dont pas possible d’utiliser directement un fichier « .htaccess ».

La configuration de mon fichier de configuration Apache est la suivante [2] :

RewriteRule ^(/test/site1|/test/site2|/test/site3)$ $1/ [R,L]
RewriteRule ^(/test/site1|/test/site2|/test/site3)/(.*)$ /test/spip-mutualise/$2 [QSA,L] 

Les sites existaient déjà, tous sauf un utilisant une instance de SPIP 1.9.2. J’ai donc créé les répertoires /test/spip-mutualise/sites/siteX, puis copié à l’intérieur IMG/ et squelettes/ issus du site original. J’y ai enfin créé local/ et tmp/.

Le fait qu’il s’agisse d’une migration a posé le problème prévu par la documentation [3] : dans la base de données, dans la table spip_documents, il a fallu que je remplace tous les IMG/ par sites/site1/IMG/. Ça a été la manipulation la plus pénible (automatisée par script Perl [4]).

L’un des sites cumulait deux difficultés : il était en version 1.9.1 et n’était pas mutualisé. Le passage direct en mutualisation s’est
parfaitement déroulé, la mise à jour de la base a été effectuée et l’interface m’a bien demandé de créer admin_XXXXXXXXX dans le répertoire
/sites/site12/tmp.

Cas particulier de l’usage de htpassword

J’ai ensuite testé un cas non prévu par la documentation : comment faire pour protéger l’accès de chaque site en utilisant les « .htpassword » générés par SPIP (et donc situés dans /sites/siteX/tmp/) ? Là, pas de mystère, j’ai été obligé d’utiliser la directive LocationMatch d’Apache, soit :

<LocationMatch ^/test/siteX>
        AuthType Basic
        Authname "Repertoire sous protection"
        AuthUserFile /var/www/test/spip-mutualise/sites/siteX/tmp/.htpasswd
        require valid-user
        Satisfy all
</LocationMatch> 

... et ainsi de suite pour chaque site.

Il faut aussi penser à protéger les URLs du genre http://example.org/test/spip-mutualise car sinon, un petit malin pourrait accèder aux documents attachés en contournant la protection précédente... en demandant http://example.org/test/spip-mutualise/sites/siteX/IMG/pdf/machin.pdf plutôt que http://example.org/test/siteX/IMG/pdf/machin.pdf. Ceci avec

<LocationMatch ^/test/spip-mutualise>
        Order deny,allow
        Deny from all
</LocationMatch> 

Cette solution permet d’avoir une authentification web différente suivant le site demandé.

Et les URLs propres ?

L’un des sites originaux (disons site3) utilisait les URLs propres ; les autres non. Voulant conserver ce fonctionnement pour les sites mutualisés, j’ai appliqué la méthode traditionnelle :

-  dans /test/spip-mutualise/sites/site3/config/mes_options.php, j’ai précisé :

<?php>
$type_urls = "propres" ;
?> 

-  j’ai renommé /test/spip-mutualise/htaccess.txt en /test/spip-mutualise/.htaccess, puis j’y ai modifié la ligne de la directive RewriteBase :

RewriteBase /test/ 

Et c’est tout ! Il est donc possible d’utiliser les URLs propres, sélectivement sur chacun des sites mutualisés.

Bilan de la mutualisation

Résultat de la mutualisation : j’ai 15 sites parfaitement opérationnels. La migration est transparente pour les rédacteurs et le public, et je ne
mets plus à jour SPIP qu’une seule fois (grâce à SVN et à la branche 1.9.2, bien sûr) pour tous les sites.

J’espère que ce témoignage vous donnera envie de sauter le pas, et d’enfin mutualiser le noyau de SPIP pour vos centaines de sites ;-)