Skip to main content Help Control Panel

 

support «   Archives support «  

Problème après mise à jour à 7.4

Erreur 500 à chaque première visualisation d'une page

WorkflowSupport request
StatusProblem has been recorded
  • Submission on May 7 2007 by Agnès
OwnerAlain Lesage
Progress0%
Je viens de mettre à jour mon site de test à 7.4.

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 - on May 8 2007
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 - on May 8 2007
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 - on May 8 2007
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 - on May 8 2007
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:
  • Une erreur dans le skin utiliser (tester avec un skin original).
  • Un problème temporaire chez l'hébergeur, souvent en ce qui concerne MySql ou une instabilité Appache.
  • Le type Mime dans le .htaccess lorsqu'il y a risque de confusion d'une script PHP d'être assigné à PHP4 ou PHP5 lorsqu'ils sont tous deux présents chez l'hébergeur.


Le fait que ça ne se produit qu'une fois est quand même bizarre.
Lasares - on May 9 2007
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 : 
AddType application/vnd.mindjet.mindmanager .mmp .mmap .mmpt .mmat .mmmp .mmas
AddType x-mapp-php5 .php
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 - on May 9 2007
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 - on May 9 2007
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 :
  • je connais la signification des 3 chiffres (propriétaire-groupe-tous)
  • et celle des codes (de 1 à 7)
  • je sais que j'ai autorisation de changer les permissions chez mon hébergeur
  • et je sais comment faire (où taper les chiffres)
  • mais je ne sais pas quoi faire
  • les répertoires de mes sites ont généralement les permissions établies à 755
  • les fichiers par contre sont généralement "chmodés" à 644


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 :
  • 666 pour cron.php, error.php, panel.php, setup.php et sitemap.php
  • 755 pour privacy.php
  • leur fichier.bak sont à 644
  • j'ai aussi un fichier .ftpquota à 600, mais c'est la même chose pour mes autres sites (est-ce mis là par yacs ou par mon hébergeur ?)
  • je n'ai pas examiné les fichiers à l'intérieur des répertoires (il y en a des milliers, n'est-ce pas ?)


Maintenant, je ne sais pas quoi faire :
  • dois-je mettre à 644 tous les fichiers listés ci-dessus, ou sinon, lesquels d'entre eux ?
  • est-ce que ce sera suffisant, ou sinon quels autres, spécifiquement ?
  • serais-je mieux de refaire l'installation à zéro (yeurk...!) ?


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 - on May 9 2007
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 - on May 9 2007
GnapZ :

J'm'excuz' d'être si obtus. C'est quoi le shell ?
GnapZ - on May 9 2007
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 - on May 9 2007
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 - on May 9 2007
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 - on May 9 2007
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 - on May 9 2007
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 - on May 9 2007
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 - on May 9 2007
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 - on May 10 2007
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...