SPIP & apache : gestion des droits... qui peut faire un point précis ?

Général
1

Bonsoir,
Qui pourrait nous faire un topo précis des exigences de SPIP face à apache ? Je crois que cette personne sauverait du suicide un paquet de spipeurs qui se cotiseraient très certainement pour lui dresser une statue à son effigie dans son jardin, place de la concorde ou ailleurs où il voudra !

je galère depuis plusieurs jours maintenant sur un point que je ne suis apparement pas le seul à rencontrer si j'en crois mes recherches google ou forums !

Je rencontre en effet un certain nombre de dysfonctionnements dont la manifestation la plus claire est un message du type : ce répertoire n'est pas accessible en écriture (alors qu'il l'est : chmod 777) et présence de fichiers .plat en veux-tu en voilà un peu partout.
Par ailleurs, un certain nombre d'autres dysfonctionnements apparaissent du type impossibilité de vider le cache depuis l'interface privée (SPIP semble le faire mais en fait il n'y a pas de recalcul de squelette). le recalcul des squelettes ne fonctionne pas non plus !
Il semblerait qu'il y ait en fait plus un problème de propriétaire et/ou groupe plus que de droits de type chmod dans la mesure où même à 777, certains sous répertoires continuent d'être identifiés par SPIP comme inaccessible en écriture.

Autre symptôme, certainement dû même raisons, sur cette machine l'installation via spip_loader n'est pas possible car un problème de droit en écriture apparaît qqs secondes après l'appel à spip_loader.php.
En lisant le code de spip_loader.php, mes très faibles notions en php me laissent toutefois comprendre qu'un certain nombre de tests (création d'un répertoire, dun fichier, constat des droits/propriétés etc...) sont effectués et qu'en fonction des résultats obtenus, spip_loader continue la procédure ou jette l'éponge en invitant le webmestre à uploader manuellement les fichiers.

Quelqu'un a-t-il les idées claires sur les "besoins" de SPIP en terme de configuration d'apache, les droits et les appartenances que doivent avoir les différents répertoires ? Quid de ceux créés à la volée par SPIP durant l'utilisation (les caches/ vignettes etc...) ? et les contrôles internes qu'il effectue ?

Parce que là, il y a visiblement un sacré sac de noeuds sous certaines configurations...

Du reste, je précise que j'ai des sites hébergés sur d'autres machines chez ce même hébergeur qui fonctionnent sans broncher, machines sur lesquelles est implanté "suPHP", outil permettant d'éxécuter les scripts PHP avec les permissions de leurs propriétaires...

Manu

PS : la version de SPIP est la 192d
PS 2 : j'ai commencé à casser ma tirelire (pour la statue... !)

2

manu wrote:

Qui pourrait nous faire un topo précis des exigences de SPIP face à apache ?

est-ce que ceci débroussaille un peu la jungle de tes interrogations ?

http://www.spip-contrib.net/Permissions

3

La jungle... j'aime bien l'expression !
Merci pour le lien. Cela dit, ça me laisse perplexe devant la conduite à tenir...
Dans mon cas de figure, pour que SPIP "marche", quand un message: le répertoire xxx n'est pas accessible en écriture, la solution consiste à effacer via FTP ce répertoire en question et à le recréer via FTP pour que le propriétaire (ou groupe) change. ET là, notre petit écureuil redevient content.
Ce n'est pas tenable, bien sûr, comme façon de faire.
Mes notions Unix/apache sont maigrichonnes et ne me permettent pas vraiment de raisonner la situation, mais j'imagine qu'il doit bien y avoir une façon de faire, de régler la configuration d'apache pour permettre un fonctionnement dans lequel l'écureuil ne tousse pas ans arrêt !

4

manu a écrit :

La jungle... j'aime bien l'expression !
Merci pour le lien. Cela dit, ça me laisse perplexe devant la conduite à tenir...
Dans mon cas de figure, pour que SPIP "marche", quand un message: le répertoire xxx n'est pas accessible en écriture, la solution consiste à effacer via FTP ce répertoire en question et à le recréer via FTP pour que le propriétaire (ou groupe) change. ET là, notre petit écureuil redevient content.
Ce n'est pas tenable, bien sûr, comme façon de faire.
Mes notions Unix/apache sont maigrichonnes et ne me permettent pas vraiment de raisonner la situation, mais j'imagine qu'il doit bien y avoir une façon de faire, de régler la configuration d'apache pour permettre un fonctionnement dans lequel l'écureuil ne tousse pas ans arrêt !

_______________________________________________
Bonjour,
  

j ai pas les reponses, mais tres exactement les memes questions...
et je dois moi aussi recreer pas mal de dossiers en ftp pour que ca marche, ce qui est assez dommage car ca limite pas mal les possibilites de mutualisation du noyau et d automatisation.
J etais justement en train d essayer de creer un batch permettant d attribuer les bons droits et les bons proprietaires aux dossiers et fichiers, mais ne connaissant pas les droits a attribuer, je tatonne enormement.

cordialement
triton

5

Hello,

Il n'y a pas vraiment de réponse à la question... mais des réponses possibles :wink:

Cela dépend en fait de la configuration du serveur HTTP (Apache), et des groupes d'utilisateurs, en particulier dans le cas d'un hébergement mutualisé.

Quelques indications pour comprendre le problème :

- Tout ce qui est créé via le web (fichier ou répertoire), comme par exemple une installation avec le Spip Loader, appartient à l'utilisateur et au groupe sous lesquels tourne Apache. Par exemple : nobody, apache ou www.

- Tout ce qui est créé via FTP, appartient à l'utilisateur et à son groupe (c'est déterminé par le serveur).

En toute logique on peut imaginer qu'il y a compatibilité entre les droits d'accès (lecture, écriture, exécution) du groupe de l'utilisateur et celui sous lequel tourne Apache.

En règle générale, il faut savoir que Spip gère plutôt bien les questions de droits sur les fichiers et répertoires qui dépendent de lui... pour peut que l'on l'aide un peu :))

Le répertoire où Spip est installé (par exemple public_html/) doit être accessible en lecture et écriture au minimum pour l'utilisateur et le groupe. On lui donnera donc des droits de type 775 ou voir 777 (tous les droits pour tout le monde).

Les répertoires où Spip doit écrire (IMG/ ou tmp/ par exemple) doivent aussi être accessibles (à priori donc en 777).

Deux dernières remarques :

- Avec une installation à partir du Spip Loader il ne devrait (!) pas y avoir de problèmes de droit... Parce que la première chose que fait le Loader c'est de vérifier qu'il a les bons droits pour s'exécuter !

- L'affaire peut se compliquer un peu si votre hébergeur fait tourner PHP en "safe mode", ou s'il a bridé Apache (par exemple chez Free)... Et là je ne sais pas trop ce qui est possible.

A+
Aris

triton a écrit :

manu a écrit :

La jungle... j'aime bien l'expression !
Merci pour le lien. Cela dit, ça me laisse perplexe devant la conduite à tenir...
Dans mon cas de figure, pour que SPIP "marche", quand un message: le répertoire xxx n'est pas accessible en écriture, la solution consiste à effacer via FTP ce répertoire en question et à le recréer via FTP pour que le propriétaire (ou groupe) change. ET là, notre petit écureuil redevient content.
Ce n'est pas tenable, bien sûr, comme façon de faire.
Mes notions Unix/apache sont maigrichonnes et ne me permettent pas vraiment de raisonner la situation, mais j'imagine qu'il doit bien y avoir une façon de faire, de régler la configuration d'apache pour permettre un fonctionnement dans lequel l'écureuil ne tousse pas ans arrêt !

_______________________________________________
Bonjour,
  

j ai pas les reponses, mais tres exactement les memes questions...
et je dois moi aussi recreer pas mal de dossiers en ftp pour que ca marche, ce qui est assez dommage car ca limite pas mal les possibilites de mutualisation du noyau et d automatisation.
J etais justement en train d essayer de creer un batch permettant d attribuer les bons droits et les bons proprietaires aux dossiers et fichiers, mais ne connaissant pas les droits a attribuer, je tatonne enormement.

cordialement
triton

6

Merci ...
ça s'éclaire dans la mesure où mon hébergeur vient d'installer suphp pour que les droits attribués par apache ne le soient pas sous son nom à lui, mais sous le nom de l'utilisateur;
Donc, plus de soucis, sauf qu'il faut faire la chasse aux répertoires et fichiers à qui on avait un peu forcé la main en leur attribuant des droits 777, ce qui conduit à quelques erreurs 500 de temps en temps, mais tout rentre peu à peu dans l'ordre... cool
! :wink:

Cela dit, pour mon information, en deux mots, qu'est-ce que le mode safe mode à on ou off a comme conséquence sur cet aspect des droits ? Comment SPIP se comporte-t-il de ce côté-là ?

Merci d'avance et bon soleil qui est enfin revenu chez nous en Bretagne !

7

Bonjour,
merci pour la reponse detaillee qui permet de clarifier mes conclusions empiriques...
Quand j utilise le spip_loader il faut quand meme que je recree par ftp certains fichiers pour que spip puisse ecrire dedans (tmp, cache-..)
Par contre, en ce moment je bute sur un probleme...
je suis en train de mettre en place un systeme permettant de synchroniser ma plateforme locale de dev avec le serveur de prod en utilisant capistrano, ssh, svn et rsync.... la synchronistaion et l export svn se passe bien, mais les fichiers que je propulse sur le serveur de prod ne sont pas tous accessibles par spip... il faut que je continue mes investigations la dessus, tes precisions vont me permettre d y voir plus clair.
Merci bien
cordialement
triton
Aris a écrit :

Hello,

Il n'y a pas vraiment de réponse à la question... mais des réponses possibles :wink:

Cela dépend en fait de la configuration du serveur HTTP (Apache), et des groupes d'utilisateurs, en particulier dans le cas d'un hébergement mutualisé.

Quelques indications pour comprendre le problème :

- Tout ce qui est créé via le web (fichier ou répertoire), comme par exemple une installation avec le Spip Loader, appartient à l'utilisateur et au groupe sous lesquels tourne Apache. Par exemple : nobody, apache ou www.

- Tout ce qui est créé via FTP, appartient à l'utilisateur et à son groupe (c'est déterminé par le serveur).

En toute logique on peut imaginer qu'il y a compatibilité entre les droits d'accès (lecture, écriture, exécution) du groupe de l'utilisateur et celui sous lequel tourne Apache.

En règle générale, il faut savoir que Spip gère plutôt bien les questions de droits sur les fichiers et répertoires qui dépendent de lui... pour peut que l'on l'aide un peu :))

Le répertoire où Spip est installé (par exemple public_html/) doit être accessible en lecture et écriture au minimum pour l'utilisateur et le groupe. On lui donnera donc des droits de type 775 ou voir 777 (tous les droits pour tout le monde).

Les répertoires où Spip doit écrire (IMG/ ou tmp/ par exemple) doivent aussi être accessibles (à priori donc en 777).

Deux dernières remarques :

- Avec une installation à partir du Spip Loader il ne devrait (!) pas y avoir de problèmes de droit... Parce que la première chose que fait le Loader c'est de vérifier qu'il a les bons droits pour s'exécuter !

- L'affaire peut se compliquer un peu si votre hébergeur fait tourner PHP en "safe mode", ou s'il a bridé Apache (par exemple chez Free)... Et là je ne sais pas trop ce qui est possible.

A+
Aris

triton a écrit :

manu a écrit :

La jungle... j'aime bien l'expression !
Merci pour le lien. Cela dit, ça me laisse perplexe devant la conduite à tenir...
Dans mon cas de figure, pour que SPIP "marche", quand un message: le répertoire xxx n'est pas accessible en écriture, la solution consiste à effacer via FTP ce répertoire en question et à le recréer via FTP pour que le propriétaire (ou groupe) change. ET là, notre petit écureuil redevient content.
Ce n'est pas tenable, bien sûr, comme façon de faire.
Mes notions Unix/apache sont maigrichonnes et ne me permettent pas vraiment de raisonner la situation, mais j'imagine qu'il doit bien y avoir une façon de faire, de régler la configuration d'apache pour permettre un fonctionnement dans lequel l'écureuil ne tousse pas ans arrêt !

_______________________________________________
Bonjour,
  

j ai pas les reponses, mais tres exactement les memes questions...
et je dois moi aussi recreer pas mal de dossiers en ftp pour que ca marche, ce qui est assez dommage car ca limite pas mal les possibilites de mutualisation du noyau et d automatisation.
J etais justement en train d essayer de creer un batch permettant d attribuer les bons droits et les bons proprietaires aux dossiers et fichiers, mais ne connaissant pas les droits a attribuer, je tatonne enormement.

cordialement
triton

.