Problème après mise à jour à 7.4
Issue description
La mise à jour (par le chargement des scripts modifiés à partir de site de yacs, en passant par le panneau de contrôle) s'est bien passée.
Cependant, chaque première demande d'une page génère une erreur 500. Puis, je ré-actulise la page et elle s'affiche comme il se doit. Si par la suite, j'y accède d'un autre ordi, j'y ai accès sans erreur.
En fait, la première demande de visualisation crée une erreur mais aussi, semble-t-il, sa propre correction. IE6 est un peu plus bavard que IE7 et me donne ce message :

Je soupçonne la réécriture d'URL. Pourtant mon hébergeur la supporte et je l'avais déjà activé sur un autre de mes sites à la même place. D'ailleurs, je n'avais pas ce problème en 6.12 ni en 7.1 et je ne l'ai pas en 7.3 sur un autre site.
Comments
| Paul 1 post | J'ai fait une mise à jour automatique vers 7.4, et quand je me loggue sur mon site (http://piebald.lautre.net), j'ai ça : Fatal error: Cannot redeclare class members in /var/alternc/html/p/piebald/yacs/categories/members.php on line 0 Il faut que je mette le chemin complet http://piebald.lautre.net/yacs/index.php pour que ça marche.... Bizarre, non ?? Surtout qu'avant, ça marchait direct... Paul |
| GnapZ from Caribbean 2970 posts |
Paul : Bonjour et bienvenue dans le monde de Yacs. Ce problème a déjà fait l'objet de plusieurs réponses dont l'origine est là: Mise à jour 7.2 vers 7.3. J'espère que cela correspond à votre cas. |
| Lasares from L'Île-Bizard à Montréal, Québec 710 posts |
GnapZ : J'ai bien lu cet article. Je ne crois pas que ça s'applique à mon cas où alors j'y comprends rien du tout. J'aimerais mettre à jour mes sites de production mais je n'ose pas tant que je n'ai pas résolu ce problème. Avez-vous une idée ? |
| GnapZ from Caribbean 2970 posts |
Lasares : Je répondais à Paul qui fait référence à un problème connu. Cette erreur 500 peut être dûe (d'après ce qu'on sait) à 3 cas:
Le fait que ça ne se produit qu'une fois est quand même bizarre. |
| Lasares from L'Île-Bizard à Montréal, Québec 710 posts | Et le fait que le message d'erreur indique également : dangerously writable < script de la page > FIXED donne-t-il une indication supplémentaire ? Ça a peut-être quelque chose à voir avec .htaccess effectivement mais je n'y connais rien. Je n'ai pas touché à l'original qui est contenu dans la distribution et dont toutes les lignes sont commentées. C'est dans un sous-domaine et j'ai un autre fichier .htaccess à la racine, qui ne contient que 2 lignes :
Mon hébergeur a effectivement PHP4 et PHP5. Mais si ça venait de l'hébergeur, n'aurais-je pas le même problème sur mes autres sites ? Et que j'utilise le skin skeleton ou prestec, ça fait le même effet.
|
| GnapZ from Caribbean 2970 posts | Les types sont bons (le 2ème indique bien qu'il faut prendre PHP5 pour les scripts .php). L'erreur me fait penser à autre chose: Dangerously writable ... dangeureusement réinscriptible ... un pb de droits ! Vérifier si les scripts sont bien en 644, il semble que le script en question soit en mode écriture pour tous (777 ?) et ce serait alors qu'un simple avertissement, d'où la présence de cette erreur au premier chargement. A vérifier mais je trouverais ça fort probable. |
| Lasares from L'Île-Bizard à Montréal, Québec 710 posts | GnapZ : J'ai toujours évité de confronter le chmod et je m'en suis tiré jusqu'à maintenant, mais bon, je suis prêt, je plonge. J'aurai besoin d'aide, jai lu Comment résoudre les problèmes de permissions sur les fichiers ? mais ça ne m'a pas avancé.Voici le peu que je sais ou crois savoir :
Après votre réponse, j'ai fait un examen plus approfondi en comparant mon site de test (où il y a ce problème) et un autre de mes sites. J'ai découvert que les permissions de certains fichiers à la racine de mon site de test avaient été changées avec la mise à jour à 7.4 :
Maintenant, je ne sais pas quoi faire :
Je suis preneur de toute l'aide et les conseils qu'on peut me prodiguer pour corriger ça et aussi pour apprendre et ne plus gaffer comme ça. Merci d'avance. |
| GnapZ from Caribbean 2970 posts | Concernant les sous-domaines, j'ai mis un article là dessus: Génération des liens. Pour les Chmod, je préconise l'utlilisation du shell en se positionnant à la racine du yacs avec la commande "chmod -R 644" qui va tout positionner en 644. Voir éventuellement la FAQ de l'hébergeur sur le sujet (certains sont frileux avec ça). .ftpquota est un fichier de l'hébergeur, normalement non modifiable. |
| Lasares from L'Île-Bizard à Montréal, Québec 710 posts |
GnapZ : J'm'excuz' d'être si obtus. C'est quoi le shell ?
|
| GnapZ from Caribbean 2970 posts |
Lasares : Pardon, c'est l'accès au mode 'console' du serveur pour lancer des commandes unix globales bien plus rapides et puissantes que de faire des manips manuelles sur chaque fichier. Ex: "rm -R yacs" pour supprimer tout une arborescence yacs d'un coup. Si l'hébergeur ne propose pas un tel accès, il n'y a que le mode "manuel", pénible et rébarbatif qui peut le faire. |
| Lasares from L'Île-Bizard à Montréal, Québec 710 posts | GnapZ : Hou la la ! Le mode console, j'ai aussi essayé de contourner autant que possible, même si hier j'ai été obligé de faire une incursion pour utiliser ffmepg (pour créer la démo que j'ai postée ici sur WLW). Je peux avoir accès au shell mais pas tout de suite. Il faut que je demande à mon hébergeur ("For security reasons, shell access is not enabled by default.").En attendant, je chmode tous les fichiers listés dans mon post précédent à 644 ? Ça peut aider ? Et y a-t-il une place où trouver des tutoriels ou trucs du genre sur le mode console ? |
| GnapZ from Caribbean 2970 posts |
Lasares : Il n'y a pas d'autre doc que tout ce qu'on peut trouver sur Linux ... ça ira ? Le "mode console" n'est pas un mode spécial aux hébergeurs mais simplement un accès serveur très très souvent basé sur Linux/Free BSD et autres. A chacun son shell et donc sa syntaxe. Une fois de plus, seul l'hébergeur est en mesure d'informer sur le système sur lequel il se base. A chacun ensuite de trouver une doc sur ce système. Bon, une petite liste de commandes courantes peut largement suffir pour la gestion d'un site. |
| Lasares from L'Île-Bizard à Montréal, Québec 710 posts | Et puis, je pense à autre chose : si 644 est approprié, je ne devrais pas avoir de problème avec 666 qui donne davantage de droits, non ?!? à moins que... c'est pour ça que c'est devenu "dnagerously writable" ?!? |
| GnapZ from Caribbean 2970 posts |
Lasares : Là, je crois que c'est plus compliqué que ça car il y a une notion de masque utilisateur. Il y a des risques d'effet de "transparence" entre masque et droits et donc ça peut aboutir à des trucs pas très cohérents. Je ne suis pas assez pointu là dessus pour répondre efficacement. |
| Lasares from L'Île-Bizard à Montréal, Québec 710 posts |
GnapZ : Bon ben... un gros merci en tous cas. Je demande accès au shell à mon hébergeur et je tente la correction en mode console. Après vérification, il y a maintenant plein de fichiers chmodés à 666 un peu partout, je n'en sortirais pas à la mitaine, comme on dit chez nous. Merci de ton temps et de ta patience. |
| GnapZ from Caribbean 2970 posts | Les droits 644 ont été remis sur le comments/edit.php ? Et un upload de ce script ne change rien non plus ? ... des idées, comme ça ... |
| Bernard from nearby-an-airport Associate, 6807 posts |
Lasares: Certains ISP envoient des message d'erreur lorsque les droits sur les fichiers sont plus élevés que prévus. La configuration max varie d'un ISP à un autre. Par d'autre choix que de demander à l'hébergeur quelle est sa policy. Sinon, pour deviner la bonne valeur, ça risque d'être assez long... |
Rate this page
Posted by Lasares on May 7 2007, commented by Bernard on May 10 2007, (popular)