Pb de configuration serveur ?

Bonjour,

Je rencontre régulièrement des pbs d'accès au site avec Falcon sur Ubuntu. A chaque fois, j'ai droit à ce message :

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator at contact@hisse-et-oh.com to inform them of the time this error occurred, and the actions you performed just before this error.

More information about this error may be available in the server error log.

Apache/2.4.25 (Debian) Server at Port 80

En général, un rechargement de la page suffit mais ce matin, je suis obligé de passer par firefox (beaucoup plus gourmand que Falcon).

Philippe

L'équipage
13 août 2020
13 août 2020
0

Pour moi aussi, c'est fréquent (Safari).


13 août 2020
0

Meme probleme sur smartphone et tablet.
La page d’accueil hisse-et-oh.com/ est en faute car si l’on passe par une page interne directement (bookmarquée ou historique) le problème n'existe plus.


13 août 2020
0

Idem pc et smartphone.


14 août 2020
0

Idem, Firefox et Xubuntu, en page interne, aucun problème lorsqu'on est déjà sur l'un des onglets.
Il m'est arrivé d'avoir des blocages inexpliqués alors que mon bookmark Firefox est www.hisse-et-oh.com[...]okmarks


14 août 2020
0

Juste a l’instant a partir d’un Ipad.
Nous avons aussi essaye avec un iphone Xr et un iphone 6S Plus, sous Chrome, meme problème.
En général ce probleme est lié à la config:
docs.ovh.com[...]-error/
Ce qui est étonnant c’est que ce n’est pas une erreur permanente, ce matin 10h, avec les memes terminaux, ca marchait impec.
Voir ce qui plante dans le log , bonne pèche au webmaster :-)
Pour info, La version ordi fonctionne


21 août 202021 août 2020
0

06:50 UTC-4 ce matin, même symptôme = ticket non clos

Philippe


21 août 2020
0

Salut,
Moi aussi prbs depuis cet été...(W8,1 et firefox)
Comme par hasard , si je mets mon bloqueur de publicité ("Ad Block") en pause et que je re-essaie : ca fonctionne !
Je suis une "bille" en informatique: je ne sais pas si c'est en relation avec le prb soulevé !.
Mamita


21 août 2020
0

Rien à voir avec la pub, c'est une erreur classique sur serveur web. Ça peut venir de plein de choses, pb d'adressage, de droits, de lien symbolique, problème de synchro, d'une page en train d'être déménagée,...
N'oublions pas que le passage à la nouvelle version est toujours en cours (on ne bouge pas autant de pages par magie), et que c'est l'été et que chez en plus chez ovh c'est des chèvres...;-)
Mais cela n'a en tout ça rien à voir avec du racisme anti Linux(ça la foutrait mal pour un serveur web), ni anti bloqueur de pub.


phil_972:Hey, Juliusse, faut se calmer ! Ais-je évoqué : 1- un racisme anti linux ? 2- un pb de configuration de mon pc ? Je crois être suffisament au jus pour prendre la précaution, quand je fais remonter un pb de donner aux admin la config avec laquelle j'ai rencontré le pb. là, j'avoue avoir fait une erreur, mon navigateur, c'est Falkon, pas Falcon mais si vous relisez mon message vous vous rendrez compte que j'évoque la solution de contournement via Firefox (que je trouve aujourd'hui beaucoup trop gourmand en ressources machine).. Pour votre culture personnelle puisque vous évoquez la compétence professionnelle des gars de chez OVH, recherchez donc l'histoire d'infini.fr, j'en fût longtemps le Président.. Philippe·le 22 août 00:31
juliusse:Philippe, le message ne t'était pas adressé. Je n'ai pas besoin d'aller voir l'histoire d'infini.fr, je sais ce que sont les CHATONS. Par contre, je confirme que tu fais erreur. Une erreur 500, c'est côté serveur. Ça ne se contourne pas en changeant de navigateur, si ça marche pas sur un et qu'après ça marche sur l'autre, c'est que l'erreur n'était que temporaire. Et Firefox ne consomme pas beaucoup plus de ressources que falkon, si le système est efficace.(pas Ubuntu quoi 😜😉😋).·le 22 août 00:41
phil_972:Si tu le dis.. D'façon, maintenat, la seule chose qui soit à espérer c'est que les revenus publicitaires de ce site permettent un jour à son propriétaire de se payer un stage de formation à la communication car créer une section "support" et laisser un message sans réponse plus d'une semaine faut quand même le faire. Bon, il est peut être en vacances le taulier mais aucun des ses sbires ne nous le signale. Fin de mes interventions dans la section "support".. Philippe·le 22 août 14:12
21 août 2020
0

Bonjour
Pour ma part avec Firefox sous kubuntu et xubuntu, jamais eu de problème


21 août 2020
0

Pour la 2e fois, les erreurs 500 sont des erreurs au niveau du serveur, pas du client. Le problème ne vient pas de la configuration de votre PC.


jdmuys:Oui c’est bien le serveur, mais ça peut venir du client quand même, si du code JavaScript fait une requête différente vers le serveur suivant la configuration (par exemple polyfill pas au point)·le 23 août 16:34
llopht:Oulà il y a des mélanges la. Que vient faire un polyfill ici ?·le 23 août 17:06
jdmuys:just un scenario example où une erreur 500 pourrait être provoquée avec un navigateur et pas un autre·le 23 août 19:36
jdmuys:mais bon c'est improbable, je le concède. si c'est à moitié bien fait, je m'attendrai plutôt à une erreur 400 dans un tel scenario·le 23 août 19:38
llopht:Non. Un polyfill c’est émulation de fonction. Quand aux erreurs 4xx ce sont des erreurs cotées clients. Aucun des deux a un rapport avec l’erreur en cours. Ça peut arriver qu’une erreur 500 soit provoquée par un client mais jusque parce que l’erreur en question n’a pas été traitée côté serveur. ·le 23 août 20:45
jdmuys:Je suis d'accord. Mais un polyfill manquant pourra donner un 404, ou s'il généré automatiquement sur le serveur et que quelque chose se passe mal à ce moment sur le serveur, un 500. Le point de ma remarque est juste de constater qu'une erreur serveur (500) peut aussi se produire avec un client et pas un autre. Peu importe ce que c'est qu'un polyfill. je donnais juste un (mauvais) exemple.·le 23 août 21:15
21 août 202021 août 2020
0

Ce sont certainement des serveurs mutualisés avec une répartition de la charge IP.Un pb d'IPLB.
Il y avait il y a très peu de temps un pb affiché de connexion non sécurisé d'où le port 80 et la redirection vers https qui ne se fait pas toujours.


21 août 2020
0

Bonsoir
Je suis chez OVH depuis très longtemps et pour de nombreux sites (B2B) hébergés en mutualisé ou dédié et développés en PHP/MySql ou utilisant des CMS et je n’ai jamais eu ce genre de message, des erreurs 500 oui, mais pas de ce type.
Des plantages oui quand il y avait des bugs dans les scripts ou des plantages généraux d’OVH (que l’on retrouvait par ex sur downdetector)...
C’est toujours très difficile de trouver des plantages intermittents, bonne chance !
Peut être une première approche pourrait être de mettre sous surveillance automatique (monitoring) la page .index ou .default pour avoir une idée de l’occurence du problème.


juliusse:"erreurs 500 oui, mais pas de ce type." Une erreur 500 c'est une erreur 500, il y a pas 36 solutions, faut regarder les logs.·le 22 août 00:09
22 août 2020
0

j'ai ça depuis des mois et de mémoire depuis la v5 et jamais avant.


22 août 202022 août 2020
0

C'est l'infrastructure qui assure la répartition de charge qui est full.Il peut y avoir un serveur en maintenance et ce sont les autres qui supporte la charge d'où dit un "downtime".On parle de frontend (le port d'écoute),de fermes et de serveurs.Début août on pouvait se connecter en http à certains moments et je n'ai pas vérifié si oui mais en tout cas le certificat SSL n'était pas reconnu.C'est le pb d'infogérance,l'infratructure OVH peut-être ou de l'administrateur du site via le panel d'administration et une erreur 500 basique dans ce cas renvoie normalement à un pb de fichier,IP/port mais tout dépend d'un tas de choses (la tolérance des pannes etc).


22 août 202023 août 2020
0

Met avis que c'est plus un soucis d'affinité lié au load balancing que le load balancing lui même.

C'est quoi le mode de distribution ? Le tracking semble par cookie avec aucune date d'expiration, ça explique pourquoi ils ont ce soucis depuis des mois... il suffit au pire d'effacer le cookie "SERVERID" pour corriger (temporairement) le soucis.


23 août 2020
0

Le système d'IPLB est lié à la volumétrie du trafic et le suivi du cookie de session ne se fait plus.


23 août 202023 août 2020
0

Sauf si tu es en round robin ou hashage d’URI (celui la est rare), il y a toujours un cookie de tracking (et non de session) mise à part si tu fais du stickyless (et non ness).

Vu que tu le site ne redemandes pas d’authentification à chaque page tu as forcément une session. Soit par un cookie de session, un SID dans l’URL, de l’evercooking, du LSO (les deux derniers étant ultra ultra ultra rare).

Sauf si tu a un service spécifique pour partager les états de sessions entre serveur, tu es obligé de faire du stickyness.

Je suis sur mon téléphone au moment où je rédige ce message. Mais vu que je ne vois pas de SID, j’aurais tendance à penser qu’il y a un cookie de session ET un cookie de tracking.

Si c’est le cas l’erreur est certainement lié à un soucis d’affinité si l’état s’est perdu à un moment donné.

Si c’est le cas ce n’est pas un gros bug, il suffit de regarder où il se crée dans les logs (généralement au moment de la vérification des droits de l’utilisateur).

Attention par contre le load balancing qu’il soit en niveau 2 ou 7 se fait à la connexion ce n’est pas un réel équilibrage du traffic (au sens volumétrie de bande passante utilisée). D’autres parts de nombreux paramètres jouent dans la configuration d’Apache dans le mode (prefork / worker) utilisé.


23 août 202023 août 2020
0

Est-ce que le suivi de session se fait forcémment par cookie si la 1ére connexion ne répond pas et que la 2éme répond??


23 août 2020
0

Détail un peu plus. Je ne comprends par ce que tu veux dire.


23 août 202023 août 2020
0

On ne peut pas s'authentifier sans activer les cookies sur son navigateur mais on peut se connecter au site sans activer les cookies.Et l'erreur de connexion est parfois retournée dans les deux cas;la première IP ne répond pas la deuxième si.Est-ce que c'est possible d'en déduire quelque chose?


Kaloa12:L'erreur retourné quand on arrive pas à se connecter est sans doute lié au fait que la connexion n'est plus sécurisé et la deuxième ou troisième tentative de connexion fonctionne car en mode sécurisé cette fois çi.·le 23 août 16:20
23 août 2020
0

Quand tu as mécanisme de load balancing, tu as d’abord un frontend qui écoute sur un port donné (ici du TCP/443).

Son rôle est d’équilibrer la charge sur un ensemble de serveur et de vérifier éventuellement leur état.

Quand un client, se connecte pour la première fois sur le port écouté, il tombe sur le frontend. Celui-ci regarde en premier lieu le mode de répartition qui est configuré.

Il y en a de nombreux mais les plus fréquents sont le round robin, le first, le least et le source.

Le round robin est simplement un mécanisme aléatoire. Si tu as 3 serveurs, il va envoyer les requêtes au hasard sur l’un d’eux. Aucune question ne se pose sur la charge éventuelle de l’un des noeuds.

Le first va prendre le premier serveur disponible. C’est donc plus un mécanisme de tolérance de panne que de gestion de charge.

Le least va compter le nombre de connexion actives et va envoyer la charge sur le serveur le moins actif. C’est généralement via pour du streaming ou des services avec des sessions longues.

Enfin le source utilise l’IP pour définir le serveur de destination. L’inconvénient c’est que tu tomberas toujours sur le même serveur.

Le plus simple c’est de faire du round robin.

Par contre si un serveur est HS et qu’aucune sonde n’est déclarée les requêtes tomberont systématiquement sur le serveur même en panne. Ce soucis est identique avec tous les modes, il faut donc déclarer des sondes pour « interdire » au frontend d’envoyer du traffic vers un noeud en panne.

Une fois que tes requêtes arrivent sur un serveur, celui-ci (via un langage tel que PHP, python, dotnet, etc.) va générer un id de session qui sera renvoyée au navigateur (le cookie de session).

Cette session permet au navigateur de reconnaître le client à ses prochaines demandes (une page HTML, des ressources JS, CSS, images, etc.) et de conserver des états.

A chaque fois que le navigateur effectue une demande, il renvoie les cookies dans ses entêtes, le serveur fait ensuite la correspondance avec la valeur qu’il a.

Ce qui amène au tracking. Vu que le serveur et le navigateur partage cet id de session, il faut que l’on puisse à chaque requête retourner vers le même serveur.

Pour ça tu as plusieurs solutions.

Soit par IP. Il utilise l’adresse IP de la connexion internet distante de manière générale) pour savoir si il a déjà « vu » des requêtes de passées.

Soit par cookie de tracking. Auquel cas, l’id du serveur précédemment utilisé est renvoyé par le frontend, stocké en cookie et renvoyé dans les entêtes à chaque requête.

Le fait d’effectuer le tracking par cookie est plus pertinent. Car derrière une IP tu peux avoir un nombre conséquent de périphériques.

Ce suivi que l’on nomme « affinité » permet de conditionner le mode de répartition.

Imaginons maintenant que tu as du round robin et un tracking par cookie.

Tu te connectes la première fois. Tu as 3 serveur. Le round robin t’envoi sur le noeud 2. Le serveur 2 reçoit la requête et crée un id session que l’on va nommé S2. Il renvoi une ressource (ex. une page HTML) et renvoi dans les entêtes le numéro de session (S2) et le id du serveur (2).

Tu te connectes une seconde fois (ou tu obtiens une autre ressource). L’ID de session et de tracking est envoyé. Par l’id de tracking, le frontend sait qu’il doit envoyer vers le serveur 2. Sauf que celui-ci est en panne. Il t’envoi donc vers le 3. Sauf que l’ID de session S2 ça lui parle pas donc bug.

Autre possibilité. Tu connectes normalement sur le serveur 2 mais sauf que l’ID de session n’existe plus. A nouveau bug.

Bon normalement à chaque fois qu’un ID de session n’existe pas un nouveau est créé faut il que le code y soit.


23 août 2020
0

Merci ce que tu écris est très clair.


llopht:Je pense que tu as auras compris que c’est mon job. N’hésite pas si tu as besoin. ·le 23 août 20:49
25 août 2020
0

Merci pour ces infos claires.
Par contre l'intéressé ne se montre pas. Tom serait en vacances ?


Votre réponse

Merci de contribuer aux réponses sur HISSE ET OH !

Merci de vérifier de bien répondre au sujet. Fournisser des détails sur votre réponse et partager votre expérience et vos recherches !

Mais éviter de …

  • Demander de l'aide ou de répondre à une autre question (utiliser les commentaires dans ce cas).
  • Porter un jugement et manquer de respect dans votre réponse.
  • Pour plus d'information, consulter la FAQ et la Charte de HISSE ET OH !

Déposer un fichier ici ou Cliquer pour envoyer