Post to Facebook
Tweet about this
Share at LinkedIn
Invite participants
Reference this page
Bernard - La première chose à faire, sur une page blanche, est de dévalider le contrôle des messages PHP dans shared/global.php, en insérant '//' en début de ligne 'error_reporting(...'.
Egide - Bernard : Merci pour ta réponse. En fait cela ne change rien, aucun message ne s'affiche, la page ne va même pas aussi loin... Il n'y a aucune réponse qui provient du serveur. Je suis en train d'éplucher les log d'apache, il n'y aucune erreur recensée. Étant donnée que cela a fonctionné, que je n'ais fait aucune modification dessus et que cela ne fonctionne plus, serait-il possible que CE script (ainsi que celui de la mise à jour) soit bloquer par mon fournisseur ? je pense leur écrire cet après-midi... car je ne vois finalement aucune autre solution. La mise à jour à fonctionné, la création d'utilisateurs aussi... et maintenant ces deux script ne renvoient plus rien. Par contre la création d'articles de rubriques et autre fonctionnent toujours à merveille...
La seule erreur est : [Mon May 01 10:45:11 2006] [error] [client 83.79.41.201] File does not exist: /home/httpd/vhosts/lacral.ch/httpdocs/yacs/skins/skeleton
Egide - Ce qui pour moi est le plus étrange c'est cette impossibilité de naviguer sur le site à partir du client qui a lancé la requête !!! Un example concret, Firefox, avec deux fenêtres ouvertes. Si je ferme la fenêtre avec laquelle j'ai lancé la requête de création d'utilisateur je n'arrive pas à visiter le site à partir d'une autre. Le navigateur me répond toujours qu'il est en attente d'une réponse du serveur. Je dois totalement tuer le process (fermer toutes les fenêtres du navigateur) et le relancer pour pouvoir naviguer sur le site... c'est quand même bizarre non ? Je suis encore une fois certain que ce n'est pas un problème de mon client, j'ai tenté la manoeuvre depuis trois machines, sous trois OS différents et avec 7 navigateurs différents, le résultat est toujours le même. Je sèche totalement, je ne me suis vraiment jamais trouvé confronter à un truc pareil. Je ne sais vraiment pas où chercher l'erreur.
Sur le serveur, tous les fichiers et les dossiers appartiennent à Apache et son en 777... on ne peut plus permissif... Sauf les fichiers créés par yacs qui sont 644.
Nouveauté... je me suis amusé à renommer le script user/edit.php et si je le lanc alors cela fonctionne, mais yacs me répond : "Merci de prouver que vous n'êtes pas un robot". C'est quoi cette histoire là
?
Bernard - Egide: Je me demande si la bonne version de users/edit.php a été installé. Le message anti-robot demande en fait de retaper une chaine aléatoire proposée par le serveur. Il y a un bug autour de cette fonctionnalité sur la 6.3. D'où l'intérêt de tester la 6.4a.
Egide - Bernard : Merci pour ta réponse. J'ai remplacé le fichier, aucun changement. J'ai tenté de le renomé comme j'avais fait pour le précédent, et bien je n'obtient plus rien non plus.
Je suis vraiment désarmé, je ne sais pas par où commencer à chercher... snif
GnapZ - Egide : Bonjour,
Je n'ai pas l'explication de ton problème mais il est déjà arrivé des choses bizarres lorsqu'une mise à jour où un simple upload se passe mal.
Cela touche des scripts non remplacés (time out durant les uploads), des fichiers de paramètres défectueux (parameters.include.php) et aussi des bases de données "corrompues".
Essayez ces quelques propositions:
- Purge du cache YACS
- Optimisation de la base de donnée (contrôle et réindexation)
- Upload manuel des scripts 6.3.1
- Vérification manuelle des "parameters.include.php"
Egide - GnapZ : Merci pour ta réponse.
" - Purge du cache YACS "OK
" - Optimisation de la base de donnée (contrôle et réindexation) "OK
" - Upload manuel des scripts 6.3.1 "OK, petit truc bizare, c'est bien la version que j'avais, j'ai rechargé l'archive sur yacs, et certains fichier n'avaient pas le même poids.
" - Vérification manuelle des "parameters.include.php" "Pas de changement...
Je me retrouve avec le même problème...
Je vais tenter la 6.4a, mais est-elle assez stable pour un serveur de production ? De plus, l'archive zip date déjà un peu, est-ce bien la dernière version ?
Encore merci pour votre aidde.
GnapZ - Egide : Oui, la 6.4a est stable. Nous découvrons quelques petits bugs (faire une recherche sur "feed back") mais rien de bloquant.
Quelques questions:
- Ce problème se présente en local ? En ligne ?
- Y a-t-il un fichier debug.txt dans /agents ?
- La messagerie est-elle configurée ?
- L'erreur "... /skeleton": as-tu testé un autre skin original ?
- Quel est l'âge du capitaine (falcultatif) ?
Egide - GnapZ : Merci pour ta réponse.
" - Ce problème se présente en local ? En ligne ? "En ligne
" - Y a-t-il un fichier debug.txt dans /agents ? "Non... aucun.
" La messagerie est-elle configurée ? "Oui, et testée par un petit script perso avec les mêmes paramêtres.
" L'erreur "... /skeleton": as-tu testé un autre skin original ? "C'est réglé. je ne sais pourquoi, l'uid avait changé...
" - Quel est l'âge du capitaine (falcultatif) ? "36 ::)
Même avec les mises à jour... le résultat est le même. Je vais tenter de faire une installation complète dans un autre dossier, avec une nouvelle base de donnée à partir de la 6.4a. Si cela fonctionne, je peux sans autre importer les données de l'ancien système par sql ?
Merci encore pour l'aide, et pour ce logiciel qui est vraiment génial.
GnapZ - Egide : Ok, si l'UID du skin a changé c'est peut-être dû à la réorganisation de la DB lors de l'optimisation.
Cela ne fonctionne pas après un maj en 6.4a ! Mince alors.
Avant de faire une autre install, teste d'abord avec une DB neuve, vide où tu recrée le strcite nécessaire. D'ailleurs, j'en ferais bien autant pour tester de mon côté. Peux-tu me dire quelles infos de bases sont à créer pour pouvoir me mettre dans le même cas que toi (sections, articles, param système, param utilisateurs, rendu visuel, etc) ? Et quelles manips exactes il faut faire pour reproduire le problème ?
Ensuite, tester une nouvelle install mais en pointant sur l'ancienne DB.
En dernier, faire les copies SQL d'une base à l'autre mais attention aux ID (numérotation auto) qui risquent de ne pas correspondre.
PS: L'âge du capitaine était un joke (idem pour moi) et OUI, Yacs est génial.
Egide - GnapZ : Merci encore, et sympa ton site !
Alors je viens de refaire une installation complète avec 6.4a, et le résultat est le même... je me demande si c'est pas un soucis dû à la configuration du serveur...
Je vais tenter de refaire une installation en mettant l'uid sur l'utilisateur ftp... juste pour voir...
En tout cas merci pour ton aide.
GnapZ - Egide : Merci (je suppose que tu parles de la météo ?).
Si tu cherches du côté apache, vas voir à la racine de ton utilisateur si tu ne trouves pas un "dead.letter" ou des logs d'erreur. J'ai eu des soucis de page blanche avec les mails et le fichier "dead.letter" m'a permi de voir qu'apache (ou php) ne pouvait les envoyer (et bloquait la suite du déroullement de Yacs).
Bernard - Peut-être le problème est-il lié à la coexistence des deux instances YACS sur le même hébergement ? Quelles sont les URLs utilisées ?
GnapZ - Bernard : Pour exemple, j'ai 3 domaines chez le même hébergeur dont 2 on un yacs et le 3ème en a 4. Ca donne donc:
| Appel local | Appel HTTP |
|---|---|
| /home/moncompte/www/domaine1.com/yacs/ | www.domaine1.com |
| /home/moncompte/www/domaine2.com/yacs/ | www.domaine2.com |
| /home/moncompte/www/domaine3.com/yacs/ | www.domaine3.com |
| /home/moncompte/www/domaine3.com/yacs2/ | yacs2.domaine3.com |
| /home/moncompte/www/domaine3.com/yacs3/ | yacs3.domaine3.com |
| /home/moncompte/www/domaine3.com/yacs4/ | yacs4.domaine3.com |
Egide - Bernard : Merci pour ta réponse. En fait ce n'est pas le même hébergement, mais le même serveur. Chacune des deux instances est sur une nom de domaine différent. C'est un système Plesk, il y a deux abonements différents :
/home/httpd/vhosts/domain1.net/httpdocs/yacs/ www.domaine1.net
/home/httpd/vhosts/domain2.ch/httpdocs/yacs/ www.domaine2.ch
J'avais mis le rewrite rule pour que le répertoire yacs n'apparaisse pas dans l'url. Depuis qu'il y a le problème j'ai évidement enlever ce fichier et réinstallé yacs. Mais sans changement...
Bernard - Egide: Mmmm. YACS a des mécanismes de cloisonnement des sessions entre instances différentes. Sur yetanother..., c'est ce qui permet de gérer des utilisateurs différents entre
/yacs/ et /yacs_demo/. Je ne sais pas ce que ça peut donner dans le cas de serveurs virtuels comme chez vous. Une idée serait, pour se rendre compte, de visiter la page de test de chacune de vos deux instances, en tant qu'associé, de copier-coller les pages dans deux fichiers texte et d'attacher ces fichiers ici. Egide - Bernard : Vraiment, mille merci pour l'aide !
Cela voudrait alors dire qu'il peut y avoir des problèmes à mettre deux yacs sur la même machine ?
http://www.yetanothercommunity...es/view.php/110 http://www.yetanothercommunity...es/view.php/109
Sur le deuxième serveur, la version originale de yacs et non les tentatives de réinstallation avec les autres versions
Bernard - Egide: Non, au contraire, le cloisonnement a pour objectif de supporter harmonieusement la coexistence de plusieurs instances logiques sur la même machine physique. Dans votre cas, il me semble que la première instance est une version ancienne de YACS, non ?
Egide - Bernard : Oui. C'est juste un site que j'avais commencé et mis de côté pour en finir d'autres, je pensais le reprendre la semaine prochaine pour le mettre à jour, et le mettre en production. Le problème pourrait-il venir de là ?
Lucrecius - ...un peu l'impression d'arriver après la bataille... mais bon, disons que j'étais en prison.
J'ai installé plusieurs arborescences yacs (pour des URL différents) sur un seul serveur physique (donc un seul apache 2...) et ça fonctionne.
Quelques difficultés au début (voir paramétrage panneau de contrôle/système/chemin d'accès) mais pas de modifs spécifiques dans httpd.conf ou localhost. Attention à la bonne séparation dans la base MySQL.
Pour les accès net....j'ai utilisé Lynx pour la mise au point.
...si ça ne vient pas, il faudra passer à ethereal.
Voilà, c'était pour faire avancer le schmilimimiliblik
-----
Yacsment Vôtre, Lucrecius.. . ~Le pessimisme de l'intelligence et l'optimisme de la volonté~
Yacsment Vôtre,
Lucrecius.. .
~Le pessimisme de l'intelligence et l'optimisme de la volonté~
Egide - Lucrecius : merci pour tes remarques... Non, la bataille n'est pas finie... et plus cela va moins j'y comprends...
J'ai installé aujourd'hui la dernière version beta et là au miracle, ça fonctionne... oui, tout fonctionne bien sûr cette nouvelle installation. Mais si je met l'ancienne installation à jour, le problème persiste... J'ai donc tenté d'importer les données de l'ancienne base dans la nouvelle, et le problème est de nouveau présent... J'en déduis que le problème doit être lié à la base de donnée...
J'ai tout purgé et optimisé... il ne me reste plus qu'à recréer le site au complet ? là je vais faire un diff sur les fichiers sal complet pour voir si j'y trouve quelques choses...
GnapZ - Egide : Je viens de relire (vite fait) ce fil et en regardant vos deux extraits TXT, le serveur1 a une 'URL to root' sur / et non /yacs. Ce n'est pas la solution mais une simple constatation si vous confirmez que les 2 sites sont bien créés sous la forme /home/.../httpdocs/yacs/ .
Sinon, pouvez-vous nous faire un petit récap de la situation actuelle (emplacements des fichiers, versions Yacs, etc) ? Histoire de reprendre tout ça car, pour répondre à votre dernière question, il ne devrait pas être nécessaire de recréer "tout le site".
Egide - GnapZ : Il y avait une réécriture d'url par htaccess affin que l'on puisse entrer sans taper le yacs de l'url...
J'ai supprimé cela, j'ai mis tous les yacs à la dernière version... et le problème subsite...
J'ai gagné juste une petite précision. Cela fonctionne tant que je ne me suis pas délogué après l'installation... je peux créer autant d'utilisateurs que je veux, ou les modifier. Mais une fois que je me relogue, ce script bloque à chaque fois... j'en perds mon latin !
Comme je me fais taper sur les doigts par le comité, j'ai décidé de créer les utilisateurs en local, puis je les importe via sql dans la base de données de production...
Le hic est bien sûr que mes utilisateurs ne peuvent plus modifier quoi que ce soit de leurs profils...
Egide - En fait je viens de me rendre compte de quelque chose de spécial... en local, à chaque fois que le script edit.php de user créé ou modifie un utilisateur, apache tente de joindre cette adresse : ip-64-124-231-223.sea1.polarphase.com
si je bloque cette communication alors j'ai le même effet que sur le serveur, apache ne renvoie rien au client http... et tourne sans fin. par contre si je l'autorise alors la modification et la création de membre se fait...
GnapZ - Egide : On dirait un hébergeur américain. Si ce n'est pas le tiens (ou rattaché à un service de ta structure apache pour d'autres raisons), j'aimerais bien que tu m'envoies ton users/edit.php (ajouter à ton profil) pour voir.
Comme il semble que ce soit une ip fixe, fais une redirection de cette ip vers l'ip de ton yacs en attendant de trouver autre chose.
Egide - GnapZ : Merci pour ta réponse.
user/edit.php
mon hébergeur se trouve en Suisse, ces machines sont disposées dans un datacenter de Zürich. Et je dois dire que jusque là, et depuis deux ans, j'ai été plainement satisfait par celui-ci ! J'ai quantité de script qui tournent, en php, perl et python... des espaces communs et privés... la seule chose que je regrette chez lui est le fait de ne pouvoirs créer ses propres reghex de filtrage de courrier, ainsi qu'il ne soit possible d'y accéder via webdav...
Pour revenir au problème... je ne sais vraiment plus quoi faire... j'ai installé et réinstallé plus d'une quaizaine de fois, en mettant des options différentes, en faisant des variations sur le propriétaire des fichiers, etc. mais rien y faits...
À noter que ce comportement bizarre ne se produit pas que sous easyphp... j'ai la même chose avec zmws... J'ai fouillé tous les fichiers à la recherche de cette ip ou de ce nom de damaine, sans rien trouver
Si j'ai trouvé... en fait c'est tout simplement gravatar... mais cette fonctionnalité est-elle obligatoire ?
GnapZ - Egide : J'ai mis une version modifiée dans ton espace personnel. Merci pour ta persévérance, ça en vaut la peine.
Egide - GnapZ : M E R C I
La sollution était bien là !!!
user/edit.php modiffié
Il suffit donc de commenter la fonctionnalité gravatar ! En fait le blocage se fait lorsque certains serveurs refusent la connection apache. Renseignement pris auprès de mon fournisseur, la plage d'IP visée par gravatar avait été bloquée suite à une avalanche de scan provenant de cette plage d'adresse.
Le mieux, à mon avis, serait de pouvoir disposer d'une option de configuration pour l'activation de cette fonctionnalité. Pour l'instant il suffit de commenter la fonctionnalité dans le fichier user/edit.php (en lien ci-dessus une version modifiée par gnapz).
Soit par "/*" et "*/" en début et fin de bloc, soit par "//" au début de chaque ligne.
Il s'agit de commenter les lignes contenant :Un grand merci à ceux qui ont participés à la résolution du problème, ainsi qu'à ceux qui passent du temps pour faire progresser ce script qui est vraiment génial.
Bernard - Egide: faut-il un paramètre spécifique pour empêcher le test des gravatars, ou pour empêcher tput accès HTTP vers d'autres serveurs ?
Egide - Bernard : Pour moi plus de besoin spécifique. Mais pour les personnes qui risquent de se retrouver confrontées au même problème, il serait peut-être bon de détailler les fonctionnalités faisant un appel vers l'extérieur.
D'un autre côté, je pense que la plupart des hébergeurs ne fignolent pas et soit bloquent totalement soit permettent toutes les connexions http.
Sans oublier que certains fournisseurs autorisent les connexions uniquement en passant par un serveur proxy.
Le plus malheureux dans ces blocages est l'impossibilité de mettre les scripts à jour via les fonctionnalités intégrées...
Donc, je pense qu'un blocage global est suffisant.
Et merci encore pour ton aide.
GnapZ - Egide : Content pour toi car cela fait un moment que tu cherchais.
Pour les hébergeurs avec proxy, Yacs a un paragraphe réservé à cet effet dans les paramètres système du panneau de contrôle.
Pour ce qui est de savoir quoi faire pour l'avenir, il faudrait voir pour centraliser une option concernant tout appel à des serveurs externes pour ce cas de figure.
Si Bernard pose cette question c'est bien évidemment pour les prochaines mises à jour qui vont écraser ton script users/edit.php. Si tu mets à jour Yacs, penses bien à replacer ton users/edit.php modifié tant qu'une option (ou la gestion d'un test d'erreur interne) n'est pas prise en compte pour les versions à venir.
Enjoy.
Egide - GnapZ :
" Si Bernard pose cette question c'est bien évidemment pour les prochaines mises à jour qui vont écraser ton script users/edit.php. Si tu mets à jour Yacs, penses bien à replacer ton users/edit.php modifié tant qu'une option (ou la gestion d'un test d'erreur interne) n'est pas prise en compte pour les versions à venir. "
C'est pour ce genre de situation que je porte toutes mes modifications sur svn qui permet ensuite de fusionner les modifications personnelles avec celles faites par les développeurs. Le seul inconvenient étant qu'il n'est alors plus possible d'utiliser la mise à jour automatique implémentée. Je veux faire un essai qui consiste à faire une copie locale des fichiers fusionnés et de faire la mise à jour des sites sur cette copie... Ou peut être utilisé la fonctionnalité de mise à jour sur un fichier zip ? je n'ai pas encore eu le temps de regarder ces choses... je découvre peu à peu...
Bon comme je débute avec YACS, je n'en ai pas encore fait beaucoup... et c'est juste en essais. Les plus grosses modifications étant bien sûres faites sur les templates... Ce qui est bien avec ce système, c'est qu'il est possible de dériver un template existant, d'en faire quelque chose de totalement différent tout bénéficiant des évolutions portées sur l'original.
Ce que j'apprécie dans YACS, c'est la manière dont il est écrit, on s'y retrouve assez facilement... contrairement à un spip où il faut déjà être très avancé en programmation pour pouvoir pénétrer le code...
Je me réjouis de voir l'été arrivé, je vais pouvoir me plonger dans tous ça... (d'ici pas le temps... je suis en pleine préparation de mariage...). J'envisage de passer tous les sites que je gère sous ce système (actuellement spip 5, npds 3, plume 3, typo3 2, xoops 1, développement personnel 4) enfin presque, j'ai 6 sites qui tournent sous DokuWiki, des sites très statiques pour des utilisateur peu avancé, je pense que YACS serait trop compliqué pour eux quand même.
YACS est encore jeune, il y a certainement des points où il peut évoluer. Cependant ce script me séduit par sa conception, je me réjouis de mettre les doigts dedans !
GnapZ - Egide : Tu vois ce problème d'affichage dans ce fil ? Il est dû à un défaut dans l'utilisation de la balise PHP que tu utilises plus haut. Il faudrait que tu modifies ton post en faisant des [Entrée] manuellement sur les lignes qui ébordent. Cela permettra de ne plus avoir ce débordement sur tout le fil. C'est un problème sur lequel on travaille.
Pourt tes mises à jours et les patchs:
Sauvegarde uniquement les dossiers /images et /files (et les dossiers où tu as des données) puis, dans ta sauvegarde, places-y tes patchs avec leurs dossiers respectifs.
Lances une mise à jour complète et re-transfert ta sauvegarde dessus, c'est simple et rapide.
Avec tous tes sites, tu as du travail en perspective alors n'hésites pas en cas de pb ...
Egide - GnapZ :
" Tu vois ce problème d'affichage dans ce fil ? Il est dû à un défaut dans l'utilisation de la balise PHP que tu utilises plus haut. "
Cela décousait trop les lignes... je l'ai mis dans une boîte... ce n'est pas idéal... je vais regarder comment faire une boîte avec ascenseur horizontal.
Merci pour la remarque.
