Salut,
je suis en train de faire un script shell sur ma dedibox pour générer des comptes (user systeme + alias FTP + user MySQL + base MysSQL) avec un spip préinitialisé dessus.
Bien sur, j'etais parti sur de la mutualisation et puis comme en 1.9.2 c'est pas top (chemin des documents), j'ai essayé betement avec des liens symboliques et bien sur, ca marche.
bref, sur un compte, je pose juste :
/config
/local
/IMG
/tmp
index.php
spip.php
/ecrire/index.php
et je fais :
ln -s ${SPIPBASE}squelette-dist ${HOMEBASE}www/squelette-dist
ln -s ${SPIPBASE}prive ${HOMEBASE}www/prive
ln -s ${SPIPBASE}ecrire/* ${HOMEBASE}www/ecrire/
ca a l'air de marcher très bien, il y a un piege ?
non, je faisais deja ça en 1.9.0 sans soucis.
Puis j'ai arrête quand j'ai passe mon serveur en gentoo+suphp qui ne permet pas d'executer un script php avec un uid different de l'user.
Cela dit, suPHP ne permet aucune mutualisation, quel qu'en soit le principe.
Cédric
non, je faisais deja ça en 1.9.0 sans soucis.
Puis j'ai arrête quand j'ai passe mon serveur en gentoo+suphp qui ne permet pas d'executer un script php avec un uid different de l'user.
Cela dit, suPHP ne permet aucune mutualisation, quel qu'en soit le principe.
Tiens... on a mis ça en place dans l'académie de Rouen et ça fonctionne (mutualisation classique avec suphp et quelques liens symboliques).
Mais dans ce cas, les utilisateurs ne doivent pas faire de manipulation en FTP, ce qui restreint un peu l'usage...
J'ai d'ailleurs écrit un article à ce sujet pour les utilisateurs ici : http://spip.ac-rouen.fr/?Mises-en-garde-quelques-erreurs-a
non, je faisais deja ça en 1.9.0 sans soucis.
Puis j'ai arrête quand j'ai passe mon serveur en gentoo+suphp qui ne permet pas d'executer un script php avec un uid different de l'user.
Cela dit, suPHP ne permet aucune mutualisation, quel qu'en soit le principe.
Tiens... on a mis ça en place dans l'académie de Rouen et ça fonctionne (mutualisation classique avec suphp et quelques liens symboliques).
Oui, en hebergeant tout le monde sous le meme user ...
Mais dans ce cas, les utilisateurs ne doivent pas faire de manipulation en FTP, ce qui restreint un peu l'usage...
Oui, mais le principe même de suPHP est de cloisonner chaque user : pour chacun php est executé avec son user unix, et qui n'a le droit d'executer que les scripts lui appartenant (dont il est proprietaire). C'est un cloisonnement sécuritaire analogue a suExec pour les cgi.
Du coup, impossible d'executer un script php d'un autre user, ou uploade via une faille sur une autre appli... Et en cas d'intrusion, il est beaucoup plus facile de reperer par quel site le hacker est passé.
Donc du point de vue secu c'est vraiment mieux, mais avec un cout performance important, et des contraintes comme l'impossibilite de faire de la mutu.
Il se trouve que tous les dedies ovh livres avec la distrib par defaut sont dans cette config, et ce n'est donc pas anecdotique ...
Donc du point de vue secu c'est vraiment mieux, mais avec un cout
performance important, et des contraintes comme l'impossibilite de faire de
la mutu.
AlternC va devoir revoir son modèle de toutes façons car il repose sur
le safe_mode de php, abandonné en php6 ; je pense qu'ils vont se
diriger vers suPHP