[SPIP Zone] Quelques remarques sur la mutualisation

Bonjour,

Ci-après quelques remarques sur la mutualisation concernant :

- la mise à jour des sites mutualisés,
- la surcharge de mes_options.php du site maître par un site mutualisé
- la simplification des liens vers les documents (de type IMG/ au lieu de /sites/domain.tld/IMG/)

1/ Mise à jour des sites
-----------------

J'ai testé hier l'upgrade des sites via un appel à ?exec=mutualisation depuis le site maître.

mutualisation/exec/mutualisation.php :

  // S'il faut upgrader, creer un bouton qui permettra
  // de faire la mise a jour directement depuis le site maitre
  // Pour cela, on cree un bouton avec un secret, que mutualiser.php
  // va intercepter (pas terrible ?)

Le secret s'appuie sur alea_ephemere. Lorsque pour un site mutualisé cela fait un moment qu'on ne s'est pas rendu dans l'interface privé, le bouton de mise à jour envoie vers /ecrire/index.php?exec=mutualisation du site mutualisé, ce qui a pour effet de renouvelle l'alea_ephemere qui est donc différent de celui du formulaire, et renvoie vers une page accès interdit. Dans ce cas là il faut recliquer une seconde fois sur le bouton de mise à jour pour que l'alea_ephemere utilisé par le formulaire corresponde à celui qui est en BD. [ Problème déjà soulevé par http://www.mail-archive.com/spip-zone@rezo.net/msg04875.html ]

En outre, je ne vois pas trop l'intérêt de mettre à jour les sites un par un. A partir du moment où on met à jour le noyau mutualisé, on est de toute manière bien obligé un moment ou à un autre de mettre à jour les BD des sites mutualisés. Il faudrait sans doute envisager une procédure de type mettre à jours tous les sites, non ? En effet avec une cinquantaine de sites mutualisés, cliquer une cinquantaine de fois (dont souvent deux fois de suite) sur un bouton "mise à jour" s'avère très fastidieux... :wink:

2/ config/mes_options d'un site mutualisé

Comme indiqué dans le commentaire de mutualisation/mutualiser.php

  if (is_readable($f = $e._NOM_PERMANENTS_INACCESSIBLES._NOM_CONFIG.'.php')) include($f); // attention cet include n'est pas en globals

l'include n'est pas en global et donc la surchage de mes_options.php du site maître par un site mutualisé ne marche pas à moins de déplacer l'include dans mes_options.php du site maitre.

3/ Liens simplifiés vers les documents

Je suis un peu gêné par la forme des liens des documents et je recherche des liens de la forme http://toto.domain.tld/IMG/jpg/image.jpg au lieu de http://toto.domain.tld/sites/toto.domain.tld/IMG/jpg/image.jpg :

- pour avoir des liens plus courts et plus simples;
- dans un second temps, pour interdire par Rewrite tous les accès de type http://truc.domain.tld/sites/machin.domain.tld/IMG/

Pour un accès direct à des liens /IMG/ au lieu de /sites/toto.domain.tld/IMG/, la règle de ré-écriture suivante suffit :

RewriteCond %{REQUEST_URI} ^/IMG/ RewriteRule ^/IMG/(.*)$ /var/www.spip/sites/%{HTTP_HOST}/IMG/$1 [L]

Coté spip, j'ai naïvement modifié l'appel à spip_initialisation de la fonction demarrer_site de mutualiser.php : en remplaçant $e . _NOM_PERMANENTS_ACCESSIBLES par _NOM_PERMANENTS_ACCESSIBLES pour supprimer la mention de sites/$_SERVER['HTTP_HOST']/

Ca ne marche que partiellement du fait que _DIR_IMG correspond à la fois à un chemin d'url à une arborescence. Ok pour les liens ko par exemple lorsqu'on vérifie l'existence du fichier sur le disque. J'ai essayé de modifier generer_url_document et get_spip_doc mais on se retrouve dans le même problème. Envisager de différencier l'obtention de l'url d'un document de son chemin (arghh) ? Autre idée ?

Amicalement,
Philippe

* Philippe Drouot tapuscrivait, le 22/09/2007 11:16:

Bonjour,
1/ Mise à jour des sites
En outre, je ne vois pas trop l'intérêt de mettre à jour les sites un par un. A partir du moment où on met à jour le noyau mutualisé, on est de toute manière bien obligé un moment ou à un autre de mettre à jour les BD des sites mutualisés. Il faudrait sans doute envisager une procédure de type mettre à jours tous les sites, non ? En effet avec une cinquantaine de sites mutualisés, cliquer une cinquantaine de fois (dont souvent deux fois de suite) sur un bouton "mise à jour" s'avère très fastidieux... :wink:

Mais c'est déjà tellement plus rapide.
Et surtout, ça permet de mettre à jour même si on n'est pas admin sur le site en question.

2/ config/mes_options d'un site mutualisé

Comme indiqué dans le commentaire de mutualisation/mutualiser.php l'include n'est pas en global et donc la surchage de mes_options.php du site maître par un site mutualisé ne marche pas à moins de déplacer l'include dans mes_options.php du site maitre.

Meuh non !
Il suffit juste de déclarer les variables explicitement en global.
Exemple :
$type_urls = 'propres2';
devient
$GLOBALS['type_urls'] = 'propres2';

--
RealET

Il faudrait sans doute envisager une procédure de type mettre à jours tous les sites,
non ? En effet avec une cinquantaine de sites mutualisés, cliquer une cinquantaine
de fois (dont souvent deux fois de suite) sur un bouton "mise à jour" s'avère
très fastidieux... :wink:

c'est clair, je suis d'accord avec toi et je ne voyais au départ pas
l'intérêt de le faire
site par site ... mais l'argument suivant m'a convaincu : " faire
l'upgrade sur un ou deux
sites et bien vérifier que tout va bien " ... Bon c'est vrai qu'en
suite un bouton "upgrader tous les sites" serait bien utile pour tes
48 autres :wink:

Le secret s'appuie sur alea_ephemere. Lorsque pour un site mutualisé cela fait un moment qu'on ne s'est pas rendu dans l'interface privé, le bouton de mise à jour envoie vers /ecrire/index.php?exec=mutualisation du site mutualisé, ce qui a pour effet de renouvelle l'alea_ephemere qui est donc différent de celui du formulaire, et renvoie vers une page accès interdit.

Il suffirait peut-être d'ajouter dans la console un hit vers chacun
des sites, par exemple vers le action=cron (dans une image) ? A
tester.

3/ Liens simplifiés vers les documents

Je suis un peu gêné par la forme des liens des documents et je recherche des liens de la forme http://toto.domain.tld/IMG/jpg/image.jpg au lieu de http://toto.domain.tld/sites/toto.domain.tld/IMG/jpg/image.jpg :

- pour avoir des liens plus courts et plus simples;
- dans un second temps, pour interdire par Rewrite tous les accès de type http://truc.domain.tld/sites/machin.domain.tld/IMG/

Pour un accès direct à des liens /IMG/ au lieu de /sites/toto.domain.tld/IMG/, la règle de ré-écriture suivante suffit :

RewriteCond %{REQUEST_URI} ^/IMG/
RewriteRule ^/IMG/(.*)$ /var/www.spip/sites/%{HTTP_HOST}/IMG/$1 [L]

Coté spip, j'ai naïvement modifié l'appel à spip_initialisation de la fonction demarrer_site de mutualiser.php : en remplaçant $e . _NOM_PERMANENTS_ACCESSIBLES par _NOM_PERMANENTS_ACCESSIBLES pour supprimer la mention de sites/$_SERVER['HTTP_HOST']/

Ca ne marche que partiellement du fait que _DIR_IMG correspond à la fois à un chemin d'url à une arborescence. Ok pour les liens ko par exemple lorsqu'on vérifie l'existence du fichier sur le disque. J'ai essayé de modifier generer_url_document et get_spip_doc mais on se retrouve dans le même problème. Envisager de différencier l'obtention de l'url d'un document de son chemin (arghh) ? Autre idée ?

Il y a un problème potentiel dans ton approche : un "site" de
mutualisation n'est pas forcément défini par HTTP_HOST ; donc c'est
difficile dans le cas général.

Mais il existe un mécanisme "pur SPIP" qui fait ça, c'est quand on
active l'accès restreint aux documents ; et comme le problème se pose
aussi pour les url_propres quand on veut les passer en urls
arborescentes, la solution sera peut-être commune.

-- Fil

RealET a écrit :

2/ config/mes_options d'un site mutualisé

Comme indiqué dans le commentaire de mutualisation/mutualiser.php l'include n'est pas en global et donc la surchage de mes_options.php du site maître par un site mutualisé ne marche pas à moins de déplacer l'include dans mes_options.php du site maitre.

Meuh non !
Il suffit juste de déclarer les variables explicitement en global.
Exemple :
$type_urls = 'propres2';
devient
$GLOBALS['type_urls'] = 'propres2';

Bien évidemment mais le problème c'est que les utilisateurs ont l'habitude de se contenter d'un $type_urls et non pas d'un $GLOBAL['type_urls'] d'autant que la doc de spip le mentionne comme cela. Donc après ils ne comprennent pas pourquoi ça ne marche pas.

Il suffit sans doute de mettre à jour la doc Utiliser des URLs personnalisées - SPIP "utiliser des URLs personnalisés"... :wink:

Philippe

Bien évidemment mais le problème c'est que les utilisateurs ont l'habitude de se contenter d'un $type_urls et non pas d'un $GLOBAL['type_urls'] d'autant que la doc de spip le mentionne comme cela. Donc après ils ne comprennent pas pourquoi ça ne marche pas.

Il suffit sans doute de mettre à jour la doc Utiliser des URLs personnalisées - SPIP "utiliser des URLs personnalisés"... :wink:

tu peux aussi indiquer global $type_urls juste avant le include

Mais il y a une contradiction assez profonde entre la mutualisation et
la capacité des utilisateurs à bidouiller leur propre mes_options. Ne
serait-ce qu'en termes de sécurité (dans le cas de la mutu, il n'y en
a aucune d'un site à l'autre).

-- Fil

Fil a écrit :

Pour un accès direct à des liens /IMG/ au lieu de /sites/toto.domain.tld/IMG/, la règle de ré-écriture suivante suffit :

RewriteCond %{REQUEST_URI} ^/IMG/
RewriteRule ^/IMG/(.*)$ /var/www.spip/sites/%{HTTP_HOST}/IMG/$1 [L]

Coté spip, j'ai naïvement modifié l'appel à spip_initialisation de la fonction demarrer_site de mutualiser.php : en remplaçant $e . _NOM_PERMANENTS_ACCESSIBLES par _NOM_PERMANENTS_ACCESSIBLES pour supprimer la mention de sites/$_SERVER['HTTP_HOST']/

Ca ne marche que partiellement du fait que _DIR_IMG correspond à la fois à un chemin d'url à une arborescence. Ok pour les liens ko par exemple lorsqu'on vérifie l'existence du fichier sur le disque. J'ai essayé de modifier generer_url_document et get_spip_doc mais on se retrouve dans le même problème. Envisager de différencier l'obtention de l'url d'un document de son chemin (arghh) ? Autre idée ?

Il y a un problème potentiel dans ton approche : un "site" de
mutualisation n'est pas forcément défini par HTTP_HOST ; donc c'est
difficile dans le cas général.

Mais il existe un mécanisme "pur SPIP" qui fait ça, c'est quand on
active l'accès restreint aux documents ; et comme le problème se pose
aussi pour les url_propres quand on veut les passer en urls
arborescentes, la solution sera peut-être commune.

Activer l'accès restreint aux documents ? C'est à dire via la fonction action_acceder_document c'est ça ? Là je vois pas. Je cherchais plutôt à ce que spip me génère par exemple <img src='IMG/jpg/monimage.jpg' ... / > plutôt que <img src='sites/machin.truc.tld/IMG/jpg/monimage.jpg' ... / >

A+
Philippe

Fil a écrit :

Bien évidemment mais le problème c'est que les utilisateurs ont l'habitude de se contenter d'un $type_urls et non pas d'un $GLOBAL['type_urls'] d'autant que la doc de spip le mentionne comme cela. Donc après ils ne comprennent pas pourquoi ça ne marche pas.

Il suffit sans doute de mettre à jour la doc Utiliser des URLs personnalisées - SPIP "utiliser des URLs personnalisés"... :wink:

tu peux aussi indiquer global $type_urls juste avant le include

Mais il y a une contradiction assez profonde entre la mutualisation et
la capacité des utilisateurs à bidouiller leur propre mes_options. Ne
serait-ce qu'en termes de sécurité (dans le cas de la mutu, il n'y en
a aucune d'un site à l'autre).

Oui c'est clair qu'en terme de sécurité, il y a des réflexions qui s'imposent. Mais on doit pouvoir trouver des solutions et j'en profite donc pour rebondir sur la question. :wink:

Pour mettre en place de l'hébergement de masse de sites spip partageant le même noyau, ce qui fait surtout peur actuellement c'est que tous les sites pointent vers un même chemin physique (le noyau partagé) et qu'un script php a 2 balles péché sur internet permettrait à partir d'un site mutualisé de taper dans les fichiers des autres sites mutualisés ou bien pire dans le noyau partagé. Pas glop.

Idéalement, il faudrait :

- un chemin physique différent par site mutualisé : autrement dit, un DocumentRoot apache spécifique à chaque site
- noyau spip fonctionnant comme les librairies pear (on peut inclure mais on y a pas accès directement)
- chaque espace fonctionne avec son propre uid/gid via suphp, suexec ou autres (pour éviter que l'uid1 puisse taper dans les fichiers de l'uid2)

Je viens de tester vite fait un truc du genre noyau spip dans /var/www/mutualisation/spip et sites mutualisés dans /var/www/mutualisation/sites/site1.tld donc dans des arbos séparés entre noyau et sites mutualisés.

au niveau de php.ini : include_path = ".:/usr/share/php:/usr/share/pear:/var/www/mutualisation/spip"

au niveau d'apache, quelques règles de ré-écriture vite fait pour tester :

RewriteEngine On

# Racine d'un site mutualisé
RewriteRule ^/$ /var/www/mutualisation/spip/spip.php [L]

# spip.php d'un site mutualisé
RewriteCond %{REQUEST_URI} ^/spip\.php
RewriteRule ^/spip\.php(.*)$ /var/www/mutualisation/spip/spip.php$1 [L]

# dist d'un site mutualisé
RewriteCond %{REQUEST_URI} ^/dist/
RewriteRule ^/dist/(.*)$ /var/www/mutualisation/spip/dist/$1 [L]

# espace privé d'un site mutualisé
RewriteCond %{REQUEST_URI} ^/ecrire/
RewriteRule ^/ecrire/(.*)$ /var/www/mutualisation/spip/ecrire/$1 [L]

+ centralisation du .htaccess dans spip directement au niveau d'apache (pour les urls html, propres, etc...)

au niveau de mes_options.php du noyau : 'repertoire' => '../sites'
au niveau de mutualiser.php : _NOM_PERMANENTS_ACCESSIBLES au lieu de $e. _NOM_PERMANENTS_ACCESSIBLES dans le second paramètre de spip_initialisation

J'accède ainsi aux différents sites spip et à leurs espaces privés. Mais je me retrouve avec le problème évoqué précédemment sur generer_url_document / get_spip_doc : on ne différencie pas le chemin physique d'un document de son url. Donc tout marche correctement si ce n'est que les images, n'étant pas trouvées, spip essaye de me les générer dans le répertoire local/ !

A+
Phil