SPIP - Contrib

[ar] [en] [es] [fr] [it]



Accueil du site > Administration > Mutualisation

Témoignage sur la mutualisation du noyau SPIP en 1.9.2

dimanche 25 février 2007, par Trois singes. Dernier ajout samedi 3 mai 2008


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

Voir en ligne : La documentation officielle sur le sujet

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

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

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


Répondre à cet article

  • Problème mutualisation et multi-domaines OVH

    21 décembre 2007 17:52, par 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-poito... fonctionnent parfaitement (mutualisation opérationnelle).

    Mais les multi-domaines d’OVH ne trouvant pas les sous dossiers comme www.tourisme-charentes-poito... 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

    Retour au début des forums

  • Plugin FCKEditor, filtres d’images et mutualisation

    8 décembre 2007 07:08, par 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

    Retour au début des forums

  • Petit problème avec les squelettes spécifiques

    12 octobre 2007 12:24, par 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

    Retour au début des forums

  • 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 ?

    Répondre à ce message

    • Script Perl 27 février 2007 11:31, par 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.

      Répondre à ce message

    Retour au début des forums

  • 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 :-)

    Répondre à ce message

    • Témoignage sur la mutualisation du noyau SPIP en 1.9.2 22 avril 2007 00:26, par 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/e... ...

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

      Bons essais !

      Répondre à ce message

    • Témoignage sur la mutualisation du noyau SPIP en 1.9.2 4 mai 2007 23:42, par 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é !

      Répondre à ce message

      • Témoignage sur la mutualisation du noyau SPIP en 1.9.2 15 mai 2007 14:09, par 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

    Retour au début des forums

  • La question des URL de documents.

    25 mars 2007 09:56

    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.

    Répondre à ce message

    • La question des URL de documents. 25 mars 2007 13:15, par 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.

      Répondre à ce message

      • La question des URL de documents. 11 mai 2007 14:34, par 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]

        Répondre à ce message

    Retour au début des forums

  • 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

    Retour au début des forums

  • Problème sécurité sur multisites

    28 février 2007 16:23, par 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 !!

    Répondre à ce message

    • Problème sécurité sur multisites 8 mars 2007 09:36, par 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

    Retour au début des forums

  • 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

    Répondre à ce message

    • Témoignage sur la mutualisation du noyau SPIP en 1.9.2 2 mars 2007 14:16, par 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/.

      Répondre à ce message

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

        Bien à vous

        Répondre à ce message

        • 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

    Retour au début des forums

  • Témoignage sur la mutualisation du noyau SPIP en 1.9.2

    28 février 2007 10:09, par Renyon Paris

    Bonjour,

    Actuellement, mon site (templedeparis.com) est dans un répertoire (/mag/). C’est le seul actuellement qui utilise SPIP. Mais je voudrais faire en sorte que SPIP devienne l’outil générique pour tous les autres sites de TdP. Je n’ai pas envie que les adresses des autres sections soient : templedeparis.com/mag/site_1 ou templedeparis.com/mag/site_2 mais
    templedeparis.com/site_1 et templedeparis.com/site_2

    Donc, est-ce qu’il est possible en laissant SPIP dans le dossier mag de mutualiser les autres sites ? Voyez-vous mon soucis ?...

    Répondre à ce message

    Retour au début des forums



Suivre la vie du site RSS 2.0 | Plan du site | Espace privé | Charte et vie SPIP-Contrib | SPIP | L'autre.net