Avis à tous les spipeurs : avec l'aide de Yannick Patois nous venons
de
passer le développement de spip sous cvs (hébergé par Tuxfamily).
Bravo pour cette initiative.
Maintenant il ne vous reste plus qu'a vous pencher sur les numéros de versions.
Car si vous voulez vraiment gagner en efficacite, il faut imperativement
pouvoir identifier sans anbiguite les versions qui sont dans la nature.
Si j'ai bien compris, toutes les nuits vous allez generer une nouvelle version
Donc si vous introduissez une modification (correction de bug) sur la 1.3 le
paquettage généré sous spip-dev/devel sera toujours 1.3
Lorqu'un utilisataur va vous signaler un anomalie sur la 1.3 vous ne pourrez
même pas connaitre ses sources pour faire l'analyse du bug. Ceci est tres
regretable car maintenant que vous vaez CVS vous etes capable d'avance
l'ensemble des sources de toutes les versions.
Donc s'il vous plait. Ilfaut qu'il n'existe une seule version 1.3
puis si vous corrigé des bug faite passer la version a 1.3.1 puis 1.3.2 etc...
Est ce quelqu'un de l'equipe de developpement a regarder le produit mantis pour
la gestion des anomalies. Si vous êtes interressé, je peux vous creer un espace
de demo sur un site..
Si j'ai bien compris, toutes les nuits vous allez generer une nouvelle
version Donc si vous introduissez une modification (correction de bug) sur
la 1.3 le paquettage généré sous spip-dev/devel sera toujours 1.3
Normalement le nouveau système devrait lever toute ambiguité. Mais la 1.3,
hein, c'est une "vieille" version, donc elle reste ambigue.
Est ce quelqu'un de l'equipe de developpement a regarder le produit mantis
pour la gestion des anomalies. Si vous êtes interressé, je peux vous creer
un espace de demo sur un site..
"Je comprends bien que les directory du cache soient en 777, mais ce n'est
pas indispensable ni même SOUHAITABLE pour les fichiers."
Les fichiers présents dans le fichier CACHE sont du type 666.
(Je suis toujours en version 1.2.1).
Est ce qu'on ne risque rien avec ces fichiers???
Merci
"Je comprends bien que les directory du cache soient en 777, mais ce
n'est pas indispensable ni même SOUHAITABLE pour les fichiers."
Les fichiers présents dans le fichier CACHE sont du type 666.
(Je suis toujours en version 1.2.1).
Est ce qu'on ne risque rien avec ces fichiers???
Heu... c'est ton hébergeur qui t'a contacté spontanément pour ce
genre de trucs ? Que les fichiers soient en 666, cela ne pose a priori
pas problème, sauf si des personnes peu fiables ont accès en shell
à la machine d'hébergement, ou si la sécurité PHP est mise en place
à la mode helvétique (gruyère). Au pire, si ça fait chier quelqu'un,
c'est toi, pas l'hébergeur ;)))
Heu... c'est ton hébergeur qui t'a contacté spontanément pour ce
genre de trucs ? Que les fichiers soient en 666, cela ne pose a priori
pas problème, sauf si des personnes peu fiables ont accès en shell
à la machine d'hébergement
Ceci est possible sur une machine multi-users...
Est-ce qu'un shell est d'ailleurs nécéssaire... Serait il possible de
configurer spip pour modifier des fichier 666 dans le sous répertoire du
voisin plutot que le sien ?
ou si la sécurité PHP est mise en place à la mode helvétique (gruyère).
Donc pas si la sécurité PHP ets correcte, je conclus...
Y'a vraiment pas d'autres moyen que de mettre du 666 ?
Par exemple, sur la machine à la maison, sur lauqelle se trouvent
plusieurs comptes, j'ai du faire du 666 sur ~/public_html/spip...
Est-ce bien raisonable ?
Est-ce qu'un shell est d'ailleurs nécéssaire... Serait il possible de
configurer spip pour modifier des fichier 666 dans le sous répertoire
du voisin plutot que le sien ?
Uniquement si PHP et Apache sont mal configurés, justement. Donc
c'est du boulot de l'hébergeur d'empêcher ce genre de choses.
Free, Altern, Multimania... tous les vrais hébergeurs mutualisés
le font correctement, en entraînant des contraintes plus ou moins
pratiquables. Le 666 est obligatoire car toute autre valeur est
susceptible de faire planter (et fait planter) le script sur
certaines configurations.
Par exemple, sur la machine à la maison, sur lauqelle se trouvent
plusieurs comptes, j'ai du faire du 666 sur ~/public_html/spip...
Est-ce bien raisonable ?
Le problème est commun à tous les serveurs mutualisés sur lesquels
des scripts Web doivent écrire dans des répertoires. Communément,
le serveur Web est lancé sous un utilisateur unique, et cet utilisateur
doit bien avoir au final les droits d'accès aux répertoires dans
lesquels on veut écrire. En général l'utilisateur propriétaire des
scripts doit _aussi_ avoir accès à ces répertoires (et il l'a car
c'est lui qui a installé les scripts) donc à moins d'avoir un groupe
en commun entre le serveur Web et le propriétaire des scripts on se
retrouve avec tous les droits pour "world" (666).
Il est possible que la combinaison suivante marche :
- un user/groupe différent pour chaque utilisateur ayant besoin
d'exécuter des scripts.
- ajouter tous les groupes susmentionnés à l'utilisateur du
serveur Web.
- configurer les répertoires Web en 660.
Cependant, s'il y a beaucoup d'utilisateurs de scripts, ça
risque d'être impraticable (je ne connais pas les limites en
termes de groupes, ni les conséquences sur les performances).
Le problème est commun à tous les serveurs mutualisés sur lesquels
des scripts Web doivent écrire dans des répertoires. Communément,
le serveur Web est lancé sous un utilisateur unique, et cet utilisateur
doit bien avoir au final les droits d'accès aux répertoires dans
Oui Rien à faire
- un user/groupe différent pour chaque utilisateur ayant besoin
d'exécuter des scripts.
- ajouter tous les groupes susmentionnés à l'utilisateur du
serveur Web.
- configurer les répertoires Web en 660.
Cependant, s'il y a beaucoup d'utilisateurs de scripts, ça
risque d'être impraticable (je ne connais pas les limites en
termes de groupes, ni les conséquences sur les performances).
Au moins 30.000 groupes, je pense. En perf, je ne sais pas...
Sinon y'a les ACL (parfois).
Y'aurait encore des solution à base de repertoires g+x http, mais on
s'égare.
La conclusion est: SPIP ne peut pour le moment fonctionner que comme cela,
et on ne voit rien de praticable autrement...
-> Cependant, si l'hébergeur propose qqch faudrait peut etre voir si...
Rien à faire