Témoignage sur la mutualisation du noyau SPIP en 1.9.2

Publié le : 25 février 2007 – Dernière modification le 21 décembre 2021 – par Trois singes – 23 commentaires

1
2
3
4
5
3 votes

Attention, cette contribution est EN CHANTIER : elle n’est peut-être pas fonctionnelle.

Avec SPIP 1.9.2 et ses améliorations la mutualisation devient plus robuste, permettant la mise en place d’un partage du noyau de SPIP. En voici un exemple...

Le but de cet article n’est pas de refaire la documentation sur le sujet mais plutôt d’en donner un exemple d’application pour une configuration précise.

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 ;-)

Notes

[1] Nouvelle distribution des répertoires pour clarifier la mutualisation, correction des problèmes de logins et de noms de sites qui se mélangeaient parfois entre les sites mutualisés, fonction d’initialisation d’un site à mutualiser plus claire

[2] Il est possible de factoriser les /test/ en écrivant RewriteRule (/test/(site1|site2|site3))/(.*)$ /test/spip-mutualise/$3

[3] cf. Note sur les sauvegardes et les restauration de la documentation.

[4] Je compte réécrire un script en PHP, à mettre dans le répertoire du noyau de SPIP, et qui mettra automatiquement les urls des documents à jour. Je l’ajouterai à cet article dès qu’il sera opérationnel.

Nota SPIP-Contrib : cette contribution, encore en chantier mais déjà utilisable, est issue d’un message sur la liste spip-user, une démarche à encourager ;-) .

Discussion

5 ans 1 an 3 mois Sans limite
par date
Filtrer

11 discussions

  • amdt

    Bonjour,

    Merci tout d’abord pour votre contrib,

    Je souhaite sécuriser au maximum mon site SPIP, et il est écrit dans l’article http://www.spip.net/fr_article3514.html sur la mutualisation du noyau SPIP, que « Les deux répertoires inaccessibles par http », donc tmp/ et config/, « seront protégés par un .htaccess installé automatiquement par SPIP (les administrateurs du serveur pourront même mettre ces répertoires en dehors de l’arborescence servie par http). »

    Quelle est la procédure à suivre pour déplacer ces 2 répertoires hors de l’arborescence ? (chemin à changer en dur dans un fichier de conf ?)

    Merci d’avance,

    Amdt

    Répondre à ce message

  • AlainF

    Merci pour votre article, mais je ne penses pas avoir vu mon problème :

    un seul spip : SPIP 1.9.2b [9381], un site spip à la racine tourisme-charentes-poitou.fr avec /IMG/ /squelettes/ etc.. et six sites dans /sites/ (ctt_fr, ctt_en, rsp_fr, rsp_en, thf_fr, thf_en) avec chacun /IMG/, /squelettes/ ...

    les 6 adresses du type www.tourisme-charentes-poitou.fr/thf_en/ fonctionnent parfaitement (mutualisation opérationnelle).

    Mais les multi-domaines d’OVH ne trouvant pas les sous dossiers comme www.tourisme-charentes-poitou.fr/thf_en/, renvoie une « Internal server error »

    Comment résoudre ce problème, car nous souhaitons avoir pour chaque dossier une url avec l’extension correspondante : .co.uk pour xxx_en, .fr pour xxx_fr

    Si vous souhaitez plus d’informations, je suis à votre service.

    Par avance, merci à tous les spipeurs

    Répondre à ce message

  • Bruno

    Bonjour,

    J’écris afin de partager mon expérience sur la mutualisation. J’utilise SPIP 1.9.2c [10268]
    Les sites mutualisés sont en particuliers ceux des paroisses du Saint Mont et de Notre dame des chênes.

    J’ai utilisé les tutoriels postés sur ce site (modification des vhost dans apache, du .htaccess et de config/mes_options.php ). Néamoins j’ai été confronté à deux problèmes que voici :
    Lorsque spip doit écrire dans un fichier, que ce soit avec FCKEditor ou les filtres d’image, il ne cherchait pas le fichier ou le dossier au bon endroit.

    J’ai du ajouter

            $host = explode('.',$_SERVER["SERVER_NAME"]);
        $fichier = $host[0].'/'.$fichier;

    dans ecrire/inc/filtres_images.php pour pouvoir utiliser les filtres d’images, vers la ligne 70.

    Néanmoins spip est bien codé et on s’aperçoit seulement de l’erreur ainsi :
    -  dans le fichier spip.log, la ligne image_reduire_src:pas de version locale de apparait,
    -  on a l’impression que le site est lent parce que les images ne sont pas réduites à l’aide de vignettes, mais l’image originale est affichée redimensionnée avec des attributs dans le tag img. On est hébergé sur de l’ADSL, donc le filtre image_reduire est très important pour nous ;-)

    Et pour FCKEditor, au début de plugins/fckeditor/fckeditor_maconfig.php :

            $host = explode('.',$_SERVER["SERVER_NAME"]);
        $fckeditor_basedir = '/var/www/saint-deodat.net/spip/'.$host[0];

    Peut être que j’ai raté quelque chose...

    J’hésitais à passer à PlumeCMS pour mutualiser les sites, bravo pour cette nouvelle possibilité de SPIP !

    En espérant que mon retour d’expérience puisse servir à d’autres...

    Répondre à ce message

  • Moniqueb

    Bonjour,

    J’ai mis en oeuvre un site mutualisé dans un sous-répertoire d’un site spip 1.9.2 existant.
    ça marche impeccable, à un détail près.

    Le site racine utilise des squelettes spécifiques pour certaines rubriques, du type article-14.html ou rubrique=7.html.

    Le site mutualisé utllise bien ses propres squelettes pour les rubriques standard. Mais dès qu’il s’agit d’une rubrique qui a des squelettes spécifiques à la racine du site, il utilise ces derniers, ce qui crée une vaste pagaille.

    Provisoirement, j’ai dupliqué les squelettes du site mutualisé en les renommant du nom des squelettes racine (article-14.html etc.) et ça dépanne.

    Y a-t-il une ligne à rajouter au .htaccess pour résoudre le problème ?

    Merci de vos lumières

    Monique

    Répondre à ce message

  • 2
    Aris

    Merci ! Beau témoignage sur une fonctionnalité particulièrement intéressante du « nouveau » Spip.

    Sinon, le script en Perl pour régler le pb de l’accès aux documents est-il disponible quelque part ? Intervient-il directement sur la base ou sur un dump de celle-ci ?

    • Trois singes

      Merci pour tes encouragements !

      Le script Perl n’est pas disponible (il était très spécifique à mon cas, car il faisait aussi d’autres modifications en même temps), mais je travaille sur un script PHP qui va automatiquement mettre la base de données à jour (sans passer par un dump) lors du passage à la mutualisation. Dès qu’il est prêt et testé, je le rajouterai dans mon article.

    • Bonjour,

      Quand ce script sera ajouté à l’article ?

      Merci.

    Répondre à ce message

  • 3
    Jean

    Bonjour, merci d’avoir pris le temps de partager votre témoignage.

    Je suis dans des tests de mise en place de la mutualisation du noyau spip en 1.9.2, j’utilise pour cela la doc de spip.net, votre article, et toutes les ressources trouvées sur le net (peu !).

    J’ai dû lire et relire 10 ou 20 fois chaque explication, ça se précise, mais je n’y suis toujours pas. Si une âme éclairée pouvait me suggérer sur quelques points ... grand merci d’avance.

    Voici ma démarche en détails, ce qui peut permettre de déceler déjà une incompréhension éventuelle de ma part :

    Objectif : disposer de tous les répertoires dans le noyau - si un répertoire existant dans le noyau existe aussi dans un des sites, celui du site écrase celui du noyau, comme promis dans la documentation.

    Chaque site doit ici avoir sa propre BD, pas de préfixage pour plusieurs spip dans une seule BD.

    Cad qu’un site « vide » : /mutubeta/sites/mutu4/ dans lequel il n’y a aucun répertoire va utiliser /mutubeta/config/, etc.

    Automatiquement, un site /mutubeta/sites/mutu3/ qui dispose du répertoire squelettes/ va utiliser la BD (et le reste) du site noyau, mais il prendra les squelettes de /mutubeta/sites/mutu3/squelettes/ puisque le répertoire existe.

    Etc., idem pour tous les répertoires, ce qui offre de nombreuses combinaisons.
    La principale à mettre en place :
    -  partager /mutubeta/ecrire/
    -  partager /mutubeta/dist/
    -  partager /mutubeta/squelettes/ seulement si /mutubeta/sites/siten/squelettes/ n’existe pas
    -  l’adresse /mutubeta/ peut donner accès au « site 0 », je crois qu’il y a des démarches supplémentaires pour le protéger, si c’est le cas elles ne sont pas utiles au départ ici

    Voici l’arborescence créée :

    • /mutubeta/
      • /mutubeta/config/
      • /mutubeta/dist/
      • /mutubeta/ecrire/
      • /mutubeta/IMG/
      • /mutubeta/local/
      • /mutubeta/oo/
      • /mutubeta/sites/
        • /mutubeta/sites/mutu1/
          • /mutubeta/sites/mutu1/config/
          • /mutubeta/sites/mutu1/IMG/
          • /mutubeta/sites/mutu1/local/
          • /mutubeta/sites/mutu1/tmp/
        • /mutubeta/sites/mutu2/
          • idem que mutu1
        • [abstrait] /mutubeta/sites/mutu...[n]/
      • /mutubeta/tmp/

    A savoir :
    -  un noyau avec tous les répertoires de spip, cad un site spip fonctionnel comme l’évoque la documentation, ici /mutubeta/
    -  un répertoire /mutubeta/sites/ pour les sites
    -  des répertoires /mutubeta/sites/mutu1/, /mutubeta/sites/mutu2/ pour les sites

    /mutubeta/config/mes_options.php :

    <?
/* si noyau à la racine */
//if ( preg_match(',/([a-zA-Z0-9_-]+)/?,',$_SERVER['REQUEST_URI'],$r)) {

/* dans le cadre de : noyau = /mutubeta/ */
if ( preg_match(',/mutubeta/([a-zA-Z0-9_-]+)/?,',$_SERVER['REQUEST_URI'],$r)) {

   if (is_dir($e = _DIR_RACINE . 'sites/' . $r[1]. '/')) {

    /* default : une seule BD pour tous les sites ? */
       //$cookie_prefix = $table_prefix = $r[1];
       
       /* test : une BD par site ? */
    $cookie_prefix = $r[1];
    $table_prefix='spip';

       define('_SPIP_PATH',
           $e . ':' .
           _DIR_RACINE .':' .
           _DIR_RACINE .'dist/:' .
           _DIR_RESTREINT);

       spip_initialisation(
           ($e . _NOM_PERMANENTS_INACCESSIBLES),
           ($e . _NOM_PERMANENTS_ACCESSIBLES),
           ($e . _NOM_TEMPORAIRES_INACCESSIBLES),
           ($e . _NOM_TEMPORAIRES_ACCESSIBLES)
           );

      $GLOBALS['dossier_squelettes'] = $e.'squelettes';

       if (is_readable($f = $e._NOM_PERMANENTS_INACCESSIBLES._NOM_CONFIG.'.php')) include($f);
   }
}
?>

    Ici :
    -  « if ( preg_match(’,/mutubeta/ » est bien correct puisque le site noyau est dans ce répertoire ?
    -  si j’ai bien compris la doc de spip.net, pour avoir une BD par sites, et non pas une BD pour tous les sites avec tables préfixées, il faut remplacer

    $cookie_prefix = $table_prefix = $r[1] ;

    par

    $cookie_prefix = $r[1] ;
    $table_prefix=’spip’ ;

    J’ai un doute ?

    Le reste du mes_options est je crois fidèle à l’exemple de la doc.

    /mutubeta/.htaccess

    J’essaye de faire fonctionner l’affaire avec 2 sites, et quand tout sera ok je mettrais en place le système qui mutualise automatiquement tous les répertoires /noyau/site1 ... site n

    RewriteEngine On

    RewriteBase /mutubeta/

    #Mutualisation

    RewriteRule ^(mutu1|mutu2)$ /mutubeta/$1/ [R,L]

    RewriteRule ^(mutu1|mutu2)/(.*) /mutubeta/$2 [QSA,L]

    Je pense que le RewriteBase est bon.

    Gros gros doute sur les 2 lignes qui suivent, car j’en trouve des versions différentes dans chaque exemple, et ne sais laquelle peut correspondre à la situation.

    Voici ce que j’ai trouvé :

    # Solution 1

    RewriteRule ^(mutubeta/mutu1|mutubeta/mutu2)$ $1/ [R,L]

    RewriteRule ^(mutubeta/mutu1|mutubeta/mutu2)/(.*) $2 [QSA,L]

    # Solution 1BIS : factoriser le nom du rép., utilisé ci-dessus

    # Sur certains forums, des posts expliquent que pour faire fonctionner la mutualisation,

    # Ils ont changé la solution 1BIS par la solution 1, cad sans factoriser

    # Il est évident qu’il est plus propre de factoriser le nom de ce répertoire,

    # mais est-ce que cela peut poser problème ?

    RewriteRule ^(mutu1|mutu2)$ /mutubeta/$1/ [R,L]

    RewriteRule ^(mutu1|mutu2)/(.*) /mutubeta/$2 [QSA,L]

    # J’ai également vu ceci. Différences : un « / » devant le nom des sites, et le rép. factorisé seulement en 2de ligne. ???

    RewriteRule ^(/mutu1|/mutu2)$ $1/ [R,L]

    RewriteRule ^(/mutu1|/mutu2)/(.*)$ /mutubeta/$2 [QSA,L]

    # Redirection mutualisation

    # Apparemment, ces 2 lignes permettent de mutualiser tous les répertoires,

    # Elles remplacent celles ci-dessus si utilisées (?)

    # Je ne saisis pas encore ce que ça redirige exactement et dans quel sens ;-)

    RewriteCond %REQUEST_URI !^/mutubeta/(config|dist|ecrire|IMG|oo|plugins|sites|squelettes|tmp|local)/(.*)

    RewriteRule ^[^/]+/(.*) /mutubeta/$1 [QSA,L]

    Pour finir, simplement /mutubeta/sites/mutu1/.htaccess

    RewriteEngine On

    RewriteBase /mutubeta/

    Et voilà !

    Tout ça ne donne pas grand chose.

    /mutubeta/ est un site spip qui fonctionne « normalement »,

    /mutubeta/mutu1/ donne sur un spip qui utilise les squelettes mais ne se connecte pas à la BD, squelettes vide sans contenus de BD.

    Enfin, /mutubeta/mutu1/ecrire/ renvoie directement sur l’admin du noyau, /mutubeta/ecrire/.

    Comment ça se passe une fois tout ça mis en place, il faut installer « spip » dans chaque /mutubeta/sites/site, et ça ne va installer que une BD et pas les répertoires, ou ... ?

    Merci d’avoir accordé votre attention, encore un petit effort pour me répondre et je vous remercie grandiloqueusement :-)

    • Matthieu Marcillaud

      Ici :
      -  « if ( preg_match(’,/mutubeta/ » est bien correct puisque le site noyau est dans ce répertoire ?

      Oui.


      -  si j’ai bien compris la doc de spip.net, pour avoir une BD par sites, et non pas une BD pour tous les sites avec tables préfixées, il faut remplacer

      $cookie_prefix = $table_prefix = $r[1] ;
par
$cookie_prefix = $r[1] ; $table_prefix=’spip’ ;

      J’ai un doute ?

      Oui, ou non... en fait, la première ligne permet aussi d’utiliser une bd par site, mais le préfixe de table sera le nom de la mutualisation, et pas ’spip’... Le deuxième exemple ne permet pas de mettre plusieurs sites sur une même base (puisqu’elles auraient le même préfixe).

      C’est à l’installation des sites que l’on choisit la base de donnée, comme pour une installation spip classique.

      RewriteEngine On
RewriteBase /mutubeta/

#Mutualisation
RewriteRule ^(mutu1|mutu2)$ /mutubeta/$1/ [R,L]
RewriteRule ^(mutu1|mutu2)/(.*) /mutubeta/$2 [QSA,L]

      Je pense que le RewriteBase est bon.

      C’est bon si l’url est http://example.org/mutubeta/ pour le noyau et http://example.org/mutubeta/mutuX/ pour les sites

      Si l’url est http://example.org/utilisateur/mutubeta/ , ce sera alors :

      RewriteEngine On
RewriteBase /utilisateur/mutubeta/

#Mutualisation
RewriteRule ^(mutu1|mutu2)$ /utilisateur/mutubeta/$1/ [R,L]
RewriteRule ^(mutu1|mutu2)/(.*) /utilisateur/mutubeta/$2 [QSA,L]

      Maintenant, pour :

      RewriteCond %REQUEST_URI !^/mutubeta/(config|dist|ecrire|IMG|oo|plugins|sites|squelettes|tmp|local)/(.*)

RewriteRule ^[^/]+/(.*) /mutubeta/$1 [QSA,L]

      Effectivement, elles remplacent les deux dernières lignes (rewriterules) et plutot que de tester quels sites sont autorisés ou non à être mutualisés, elles redirigent comme pour faire une mutualisation de site tout répertoire qui n’appartient pas à SPIP...

      En gros, si on tape http://example.org/mutubeta/test99/, le htaccess renvoie sur spip.php comme si le site existait (mais le mes_options.php dira ensuite le contraire si le répertoire /sites/test99 n’est pas présent !)

      Pour l’installation, si le fichier /sites/mutuX/config/connect.php n’existe pas, normalement, spip propose une installation en allant sur http://example.org/mutubeta/mutuX/ecrire/ ...

      Dans le cas contraire, bien... je ne sais pas !

      Bons essais !

    • Jead wellor

      Bonjour,
      j’avais le même problème, c’est à dire un site principal fonctonnel et le reste partant en cacahuète, ceci venait de deux oublis que vous avez peut-être fait vous aussi :

      Je n’avais pas compris qu’il fallait mettre en plus des deux RewriteRule cette portion de code dans le htacess :

      RewriteCond %{REQUEST_URI} !^/mutubeta/(config|dist|ecrire|IMG|oo|plugins|sites|squelettes|tmp|local)/(.*)
RewriteRule ^[^/]+/(.*) /spip/$1 [QSA,L]

      D’autre part, ça peut paraître complètement idiot, mais c’est fatal, j’avais laissé quelques lignes vides après le tag fermant ( ?> ) de mes_options.php.

      Voilà, j’espère vous avoir aidé !

    • Matthieu Marcillaud

      Non ! Ce n’est pas en plus...

      C’est l’une ou l’autre des deux solutions :
      Soit vous connaissez le nom de tous les sites mutualisés et vous mettez les 2 premières rewrite rules :

      #Mutualisation
RewriteRule ^(premier_site|deuxieme_site|troisieme_site)$ /spip/$1/ [R,L]
RewriteRule ^(premier_site|deuxieme_site|troisieme_site)/(.*) /spip/$2 [QSA,L]

      Soit, à la place de ces lignes, vous mettes le code générique qui permet de faire une redirection quelque soit le nom du répertoire appelé :

      RewriteCond %{REQUEST_URI} !^/(config|dist|ecrire|IMG|oo|plugins|sites|squelettes|tmp|local)/(.*)
RewriteRule ^[^/]+/(.*) /$1 [QSA,L]

      Mais c’est bien l’un (qui semble bien fonctionner) OU l’autre des deux bouts de codes qu’il faut utiliser. Pas les deux à la fois...

    Répondre à ce message

  • 3

    Je signale qu’une série de dépots (entre 8918 à 8930) sur la branche de développement de Spip entérine la disparition de IMG/ (ou son équivalent si on a redéfini _DIR_IMG) de la table spip_documents. Avec la version SVN 8930, on peut mutualiser les sources de SPIP en plaçant le répertoire d’image/documents ailleurs que dans des sous-répertoires du code mutualisé.

    Trois singes, pas besoin de transcrire ton script Perl donc, et encore merci pour tout ce que tu as fait.

    • Trois singes

      Voilà une excellente nouvelle ! C’est vrai que cet « inconvénient » lors d’une migration était un point qui pouvait refroidir les administrateurs. À présent, il n’y a plus aucune raison de ne pas franchir le pas.

    • lgra

      Pour ceux qui ne mettent pas en production la version cvs de spip, il y a moyen en attendant de se débrouiller en ajoutant une règle dans le .htaccess comme celle-ci :

      RewriteRule ^(site1|site2|site3)/IMG/(.*) /sites/$1/IMG/$2 [QSA,L]

      en ajoutant le sous répertoire le cas échéant.

      Il faut la placer avant la règle générale :

      RewriteRule ^(site1|site2|site3)/(.*) /$2 [QSA,L]
    • Matthieu Marcillaud

      Merci beaucoup pour cette astuce, simple effectivement (pour SPIP < 1.9.3 dev).

    Répondre à ce message

  • jl

    Je rencontre un problème sur ce type d’installation (mutualisation).

    Voici ma config :

    SPIP 1.9.2 installé

    Noyau :
    /spip/

    Sites mutualisés :

    /spip/mutualise/site1

    /spip/mutualise/site2

    /spip/mutualise/site3

    dans le .htaccess dans le répertoire racine du noyau :

    RewriteBase /spip/

    RewriteRule ^(site1|site2|site3)$ /spip/$1/ [R,L]

    RewriteRule ^(site1|site2|site3)/(.*) /spip/$2 [QSA,L]

    dans le fichier mes_options.php dans le répertoire config du noyau :

    if ( preg_match(’,/spip/([a-zA-Z0-9_-]+)/ ?,’,$_SERVER[’REQUEST_URI’],$r))

    if (is_dir($e = _DIR_RACINE . ’spip/’ . $r[1]. ’/’))

    $cookie_prefix = $table_prefix = $r[1] ;

    define(’_SPIP_PATH’,
    $e . ’ :’ .
    _DIR_RACINE .’ :’ .
    _DIR_RACINE .’dist/ :’ .
    _DIR_RESTREINT) ;

    spip_initialisation(
    ($e . _NOM_PERMANENTS_INACCESSIBLES),
    ($e . _NOM_PERMANENTS_ACCESSIBLES),
    ($e . _NOM_TEMPORAIRES_INACCESSIBLES),
    ($e . _NOM_TEMPORAIRES_ACCESSIBLES)
    ) ;

    $GLOBALS[’dossier_squelettes’] = $e.’squelettes’ ;

    if (is_readable($f = $e._NOM_PERMANENTS_INACCESSIBLES._NOM_CONFIG.’.php’)) include($f) ;

    Lorsque je vais sur l’adresse spip/site1/ecrire/ je me connecte sur l’authentification du site SPIP principal (celui du noyau).

    Lorsque je vais sur l’adresse spip/site1/, je me connecte au site public du SPIP principal.

    Comment « activer » la mutualisation pour différencier les contenus de chaque site ?
    En vous remerciant par avance

    JL

    Répondre à ce message

  • 1
    suzanne

    Bonjour,

    je me suis inspirée de différents articles dont celui-ci pour arriver à ce résultat. Voici différents postes envoyés sur le forum concernant le multisites sur SPIP.

    Cependant, j’ai un problème de sécurité :

    1/ Accès via http://www.mon_site.com/mutualise/ecrire/, http://www.mon_site.com/mutualise/site_1/ecrire/, http://www.mon_site.com/mutualise/site_2/ecrire/ : j’arrive sur l’espace privé.

    2/ Accès via http://www.mon_site.com/mutualise/ecrire, http://www.mon_site.com/mutualise/site_1/ecrire, http://www.mon_site.com/mutualise/site_2/ecrire : lancement du script d’installation !

    Comment résoudre ce problème ? Il se peut que j’ai mal configuré le fichier .htaccess ...

    Merci d’avance !!

    • suzanne

      Voici le contenu de mon fichier .htaccess déposé dans http://www.mon_site.com/mutualise/ :

      RewriteBase /mutualise/
...

## Mutualisation
RewriteRule ^(/mutualise/site_1|/mutualise/site_2)$ $1/ [R,L]
RewriteRule ^(/mutualise/site_1|/mutualise/site_2)/(.*) $2 [QSA,L]

## Redirection
RewriteCond %{REQUEST_URI} !^/mutualise/(config|dist|ecrire|IMG|oo|plugins|sites|squelettes|tmp|local)/(.*)
RewriteRule ^[^/]+/(.*) /mutualise/$1 [QSA,L]

      Quelqu’un pourrait-il m’aider svp ? J’ai fait plusieurs tentatives mais je ne suis pas parvenue à sécuriser /ecrire ... Merci d’avance.

    Répondre à ce message

  • 3
    nico

    Bonjour, je ne comprends pas comment vous pouvez acceder à

    http://monsite.com/test/site1 ou site2 ... avec :

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

    puisque vous n’autorisez par à acceder au dossier qui contient les fichiers du noyau :


    Order deny,allow
    Deny from all

    Pourriez-vous de donner une des deux solutions :

    1) Je voudrais qu’on puisse acceder à http://monsite.com/BBBB/ et http://monsite.com/BBBB/ sans que l’on puisse acceder à http://monsite.com/coeur/.

    2) Je voudrais qu’on puisse acceder à http://monsite.com/coeur/ et à http://monsite.com/BBBB/ sachant que tous les deuxx doivent avoir un htpasswd et que le premier contient le dossier /sites/AAAA/.

    Merci d’avance de vos réponses

    • Trois singes

      Bonjour,

      Je n’interdis pas l’accès au dossier qui contient les fichiers du noyau (ce qui aurait été fait en utilisant la directive Apache Directory) mais l’accès à l’URL http://example.org/test/spip-mutualise (grâce à la directive Apache LocationMatch).

      Cela répond donc exactement à la question 1 :

      Avec les redirections, vous permettez l’accès à l’URL http://monsite.com/BBBB/ (qui va utiliser le code du cœur de SPIP), et avec la partie LocationMatch, vous interdisez l’accès à l’URL http://monsite.com/coeur/.

    • nico

      Merci pour votre réponse, je vais rétenter ce que vous proposez.

      Bien à vous

    • nico

      Voilà j’ai tout refait, et maintenant ça fonctionne.

      Je voulais donc avoir www.monsite.com/site1 et www.monsite.com/site2 tout en ayant www.monsite.com/coeur inaccessible, pour celà au niveau des fichiers et dossiers :

      Créer un dossier « sites » dans /noyau et y créer les dossiers /noyau/site1 et /noyau/site2 ensuite créer dans chacun d’eux (site1 et site2) : tmp, local. Vous devez egalement y copier IMG et squelettes venant de /noyau. Donc dans le /noyau il ne reste plus que les dossiers : config, dist, ecrire, oo, plugins, sites et les fichiers : spip.php, index.php, .htaccess, ...

      Dans chaque dossier /noyau/sites/site1 et /noyau/sites/site2, on a les dossiers : config, local, tmp, squelettes, IMG

      Voici l’arborescence :

      -noyau
|   -config
|   -dist
|   -ecrire
|   -oo
|   -plugins
|   \sites
|       -site1
|       |   -squelettes
|       |   -config
|       |   -local
|       |   -IMG
|       |   \tmp
|       \site2
|           -config
|           -local
|           -tmp
|           -IMG
|           \squelettes

      Dans httpd.conf (le fichier de config apache) :

      RewriteEngine On

RewriteRule ^(/site1|/site2)$ $1/ [R,L]
RewriteRule ^(/site1|/site2)/(.*)$ /noyau/$2 [QSA,L]

      Dans le htaccess de /noyau/.htaccess, rien de plus pour la mutualisation que :

      RewriteEngine On
RewriteBase /noyau

      et ne pas oublier de mettre dans le fichier de config : /noyau/config/mes_options.php :
      le code permettant de mutualiser tous les sites : « Mutualiser selon l’URL grâce à mes_options.php » Lien vers l’article

      Enfin pour la securité j’ajouterais ceci dans le fichier de configuration d’apache :

      <LocationMatch ^/.*/sites|^/.*/IMG>
	Options -Indexes
</LocationMatch>

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom