SPIP-Contrib

SPIP-Contrib

عربي | Deutsch | English | Español | français | italiano | Nederlands

286 Plugins, 197 contribs sur SPIP-Zone, 188 visiteurs en ce moment

Accueil > Administration et BDD > Mutualisation > Témoignage sur la mutualisation du noyau SPIP en 1.9.2

Témoignage sur la mutualisation du noyau SPIP en 1.9.2

25 février 2007 – par Trois singes – 23 commentaires

3 votes

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

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] :

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 :

... 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

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é :

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

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

Voir en ligne : La documentation officielle sur le sujet

P.-S.

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

Notes

[1Nouvelle 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

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

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

[4Je 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.

Dernière modification de cette page le 6 janvier 2010

Retour en haut de la page

Tout afficher

Vos commentaires

  • Le 14 novembre 2008 à 14:57, par amdt En réponse à : Comment placer tmp/ et config/ en dehors de la racine du site web ?

    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

  • Le 21 décembre 2007 à 17:52, par AlainF En réponse à : Problème mutualisation et multi-domaines OVH

    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

  • Le 8 décembre 2007 à 07:08, par Bruno En réponse à : Plugin FCKEditor, filtres d’images et mutualisation

    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

  • Le 12 octobre 2007 à 12:24, par Moniqueb En réponse à : Petit problème avec les squelettes spécifiques

    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

  • Le 27 février 2007 à 08:07, par Aris En réponse à : Témoignage sur la mutualisation du noyau SPIP en 1.9.2

    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 ?

    • Le 27 février 2007 à 11:31, par Trois singes En réponse à : Script Perl

      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.

    • Le 11 août 2007 à 00:12, par ? En réponse à : Script Perl

      Bonjour,

      Quand ce script sera ajouté à l’article ?

      Merci.

    Répondre à ce message

  • Le 22 mars 2007 à 16:42, par Jean En réponse à : Témoignage sur la mutualisation du noyau SPIP en 1.9.2

    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 2nde 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 :-)

    • Le 22 avril 2007 à 00:26, par Matthieu Marcillaud En réponse à : Témoignage sur la mutualisation du noyau SPIP en 1.9.2

      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 !

    • Le 4 mai 2007 à 23:42, par Jead wellor En réponse à : Témoignage sur la mutualisation du noyau SPIP en 1.9.2

      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é !

    • Le 15 mai 2007 à 14:09, par Matthieu Marcillaud En réponse à : Témoignage sur la mutualisation du noyau SPIP en 1.9.2

      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

  • Le 25 mars 2007 à 09:56, par ? En réponse à : La question des URL de documents.

    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.

    • Le 25 mars 2007 à 13:15, par Trois singes En réponse à : La question des URL de documents.

      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.

    • Le 11 mai 2007 à 14:34, par lgra En réponse à : La question des URL de documents.

      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]
    • Le 12 mai 2007 à 21:02, par Matthieu Marcillaud En réponse à : La question des URL de documents.

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

    Répondre à ce message

  • Le 18 mars 2007 à 19:01, par jl En réponse à : Témoignage sur la mutualisation du noyau SPIP en 1.9.2

    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

  • Le 28 février 2007 à 16:23, par suzanne En réponse à : Problème sécurité sur multisites

    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 !!

    • Le 8 mars 2007 à 09:36, par suzanne En réponse à : Problème sécurité sur multisites

      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

  • Le 1er mars 2007 à 22:23, par nico En réponse à : Témoignage sur la mutualisation du noyau SPIP en 1.9.2

    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 :

    test/spip-mutualise>
    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

    • Le 2 mars 2007 à 14:16, par Trois singes En réponse à : Témoignage sur la mutualisation du noyau SPIP en 1.9.2

      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/.

    • Le 6 mars 2007 à 09:04, par nico En réponse à : Témoignage sur la mutualisation du noyau SPIP en 1.9.2

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

      Bien à vous

    • Le 6 mars 2007 à 17:08, par nico En réponse à : Témoignage sur la mutualisation du noyau SPIP en 1.9.2

      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

Répondre à cet article

Qui êtes-vous ?

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 Les choses à faire avant de poser une question (Prolégomènes aux rapports de bugs. )
Ajouter un document

Retour en haut de la page

Ça discute par ici

  • Champs Extras 3

    16 janvier 2012 – 523 commentaires

    Ce plugin permet de créer et/ou de gérer des champs supplémentaires dans les objets éditoriaux de SPIP. Il permet donc de prendre en compte et d’afficher de nouveaux éléments dans n’importe quel objet éditorial de SPIP. Screencast Vous n’aimez pas (...)

  • Réservation d’événements

    16 mars 2015 – 188 commentaires

    Ce plugin permet d’offrir aux visiteurs de s’inscrire pour un évènement du plugin Agenda et de gérer les réservations enregistrées. Installation Le plugin s’installe comme n’importe quel plugin. il nécessite : Agenda API de vérification (...)

  • Les crayons

    23 avril 2008 – 815 commentaires

    Ce plugin permet d’éditer les contenus sur les pages publiques du site, sans passer par l’espace privé de SPIP.

  • LESS pour SPIP : Less-CSS (anciennement LESSpip)

    5 novembre 2010 – 43 commentaires

    Less-CSS (Anciennement LESSpip) est un plugin intégrant facilement le logiciel LESS dans SPIP. LESS est une extension de CSS ajoutant les variables, les classes, les opérations, les imbrications au langage. Facilitant ainsi l’écriture de (...)

  • Recommander

    3 avril 2011 – 16 commentaires

    Ce plugin propose une manière simple de suggérer de recommander par email un article à un ami. Fonction « recommander un article à un ami ». On l’ajoute dans n’importe quel squelette sous la forme : #RECOMMANDERtitre de la page,url de la page,intro (...)

Ça spipe par là