NPDS : Gestion de contenu et de communauté

Sujet
Merci  

Votre Système d'Exploitation -: Linux  
Votre Package Web -: Apache + Php + MySql  
Votre version de PHP -: Php 8.x  
Version NPDS (voir statistiques du site)-: NPDS RÉvolution 16.8  

Type de problème -: Autre(s) Erreur(s)  
Votre hébergeur -: OVH  
Votre Priorité OK, j'attends  
Description du problème
Durant quelques jours l'admininistration de mon site est restée muette, cela faisait tout juste 2 ans que le déploiement de ma migration à "révolution" avait été effectuée suivie donc de deux années sans le moindre soucis.

Le ticket ouvert chez l'hébergeur ne m'a pas aidé cette fois.
Mes tatonnements m'ont révélé mon incapacité à établir un diagnostic précis.
Mon signalement sur ce forum a été suivi d'une prise en charge immédiate, bravo !

Après plusieurs allers et retours de messages, un contournement du blocage OVH a été apporté, l'administration du site est à nouveau opérationnelle, un grand, un très grand merci aux inconnus de NPDS.

cheval29
webmestre d'un site NPDS depuis août 2001 
Inclure la signature Oui 
Notification par Email

Mais as tu plus de détails sur ce qui a provoqué cette panne et qu'est ce qu'a bricolé ton hébergeur ? Puisque cela fonctionnait pendant deux ans et subitement la panne ?

Bonjour,

Sur le conseil de Nicolas j'ai insisté auprès d'OVH pour obtenir une réponse, ci-dessous le retour que je reçois ce jour
Je ne vois pas du tout comment poursuivre, je reste disponible pour aider, effectuer des essais avec votre expertise
Là, je ne suis pas de taille pour debugger NPDS

Réponse OVH à ma relance (lire ci-sessous)
Pour des commandes CRUL mentionnées, vous ne pourrez les execturer que par script PHP avec appel via un navigateur. Il n'y a qu'une liste très restreinte de domaine compatibles avec CURL via shell pour les hébergement mutualisés et nous n'effectuons pas de whitelistage.

Pour les Time Out indiqués, afin de poursuivre le diagnostic, je vous invite à indiquer :
- URL concernée
- Horodatage
- IP publique
- Erreur avec capture d'écran
- Indication de si l'erreur survient via un autre réseau

Je vous souhaite une bonne journée.

Ma relance effectuée ce matin
Un soutien du CMS que j'héberge chez OVH m'a sorti de l'impasse et me transmet le message ci-dessous
Pouvez-vous l'analyser et me faire retour de votre diagnostic

Codialement

JL breton

____________________________________________________
J'ai fait un test sur ton site. le problème vient bien de chez OVH.

errno: 7
error: Failed to connect to raw.githubusercontent.com port 443: Connection timed out
http_code: 0
content:

false

C'est très clair, errno 7 avec un vrai timeout de connexion TCP (pas une erreur HTTP puisque http_code: 0, donc la connexion n'a jamais été établie) — ça confirme que c'est bien un blocage réseau côté OVH sur cet hébergement mutualisé, et pas un rejet de GitHub/Fastly. Si c'était GitHub qui bloquait, on aurait un http_code (403, 429...) avec errno: 0.

Donc le diagnostic est confirmé : les connexions HTTPS sortantes vers raw.githubusercontent.com sont bloquées par l'infrastructure OVH sur ce mutualisé, indépendamment de la méthode (fsockopen ou cURL, IP fixe ou nom de domaine).

Dans ce contexte, il n'y a pas grand-chose à corriger côté code — le fallback fait exactement son travail (éviter la page blanche). Les options réelles sont :

Ouvrir un ticket support OVH pour demander pourquoi cette destination précise est bloquée (rare qu'ils bloquent un domaine par défaut, ça peut être un blocage récent ou lié à l'offre d'hébergement — parfois ils restreignent les sorties vers certains CDN/IP ranges).