Saturation du serveur suite à un défaut du module calendrier

Jacques

Décembre 2010

Bonjour,

Mon hébergeur, Infomaniak, vient de me signaler que mon site, www.varapiloisir.com, plantait le serveur d’hébergement et qu’il avait donc dû l’installer temporairement sur un serveur privé.
Voici les informations données par mon hébergeur :

Le problème est permanent et semble lié à un défaut de la partie "Calendrier" de SPIP que vous utilisez. Les moteurs de recherche viennent indexer les pages de votre site et font des requêtes avec des années très anciennes (1850 par exemple) et cela "plante" le module calendrier, et donc sature le serveur.

Nous avons déjà eu un autre client avec un problème similaire. Il ne l’a pas corrigé en contactant SPIP pour obtenir un correctif ou faire une mise à jour mais à retiré le module calendrier, pour votre information.

Merci de nous tenir au courant dès que vous aurez trouvé une solution qui permette de mutualiser à nouveau votre site.

Quelqu’un a-t-il déjà rencontré ce problème ? Comment le résoudre ?

La solution de désactiver le calendrier ne me convient pas car un des buts de ce site est de communiquer de dates de réunions ou de conférences.
Néanmoins, si aucune solution n’est trouvée, cela peut constituer une solution temporaire pour éviter l’exclusion. Comment donc désactiver le module Calendrier de Spip ?

Mon site est actuellement sous Spip 2.1.2 avec Sarka-Spip 3.0.4
J’envisage de le mettre à jour sous la dernière version 2.1.5 de Spip pour voir si cela améliore la situation.

Merci d’avance pour votre réponse.

Par note Par date Par date chronologique

Indiquez l’intérêt que vous portez à cette réponse

0

Julienpit

Décembre 2010

Je confirme cette erreur, j’ai deja eu ce probleme et j’ai été dans l’obligation de descativer l’utilisation du calendrier car il me generait un cache impressionnant. C’est effectivement un bug a corriger. Il serait peut etre bon d’ouvrir un ticket tant que vous avez ce probleme de maniere a ce que l’equipe de dév se penche sur ce probleme au plus vite car il s’avere bloquant.
Indiquez l’intérêt que vous portez à cette réponse

0

b_b

Décembre 2010

Salut, le bug n’est pas dans SPIP ou dans le calendrier. Le problème vient du fait que les robots d’indexation des moteurs de recherche suivent tous les liens de vos sites comme des "bourrins".

Il y a déjà eu des discussions sur des sujets similaires, la plus récente est ici :

http://thread.gmane.org/gmane.comp.web.spip.devel/59475/focus=59476

Pour régler ce problème vous pouvez installer l’écran de sécurité de SPIP.

Outre la sécurité, l’écran a la capacité de moduler les accès des robots d’indexation aux scripts php, de manière à leur dire de « revenir plus tard » lorsque le serveur est saturé.

++
Indiquez l’intérêt que vous portez à cette réponse

0

Jacques

Décembre 2010

Bonjour,

Merci beaucoup pour vos réponses. J’ai installé l’écran de sécurité et j’attends un retour de mon hébergeur pour savoir si cela résout le problème.
J’ai lancé le test et il est bien actif.
Est-il nécessaire de faire une configuration particulière de l’écran de sécurité pour ce type de problème ?

Je vous tiens au courant dès réception d’une réponse de mon hébergeur.

@+
Indiquez l’intérêt que vous portez à cette réponse

0

Jacques

Décembre 2010

Malheureusement le problème n’est pas résolu avec l’écran de sécurité. Par exemple, la recherche de la page suivante http://www.varapiloisir.com/v2.0/Bu... que l’on voit apparaître dans les logs réclame un temps de réponse de plusieurs minutes. Naturellement l’utilisation d’autres dates donne le même résultat.

Merci de m’aider car mon hébergeur demande que le problème soit résolu sous peine de voir mon site banni.

Cordialement.
Indiquez l’intérêt que vous portez à cette réponse

0

b_b

Décembre 2010

Salut, je crois que le plus simple dans ce cas est d’ajouter des nofollow à tous les liens du calendrier...

++
Indiquez l’intérêt que vous portez à cette réponse

0

Jacques

Décembre 2010

Bonjour b_b,

Merci pour tes réponses.
Peux-tu me dire à quel niveau je dois insérer le nofollow ?

Merci.
@+
Indiquez l’intérêt que vous portez à cette réponse

0
b_b

Décembre 2010
Une astuce trouvée dans la discussion que je citais plus haut sur la liste spip-dev :

http://permalink.gmane.org/gmane.comp.web.spip.devel/59476

Dans ton mes_options, tu peux utiliser la constante _IS_BOT qui vaut true quand c’est un robot qui parcours la page.

En adaptant à ton cas ça donnerait ça :
if (_IS_BOT){ if (_request('calendrier_mois') OR _request('calendrier_annee')){ header("HTTP/1.0 403 Forbidden"); die("<html><title>Error 403: Forbidden</title><body><h1>Error 403</h1><p>You are not authorized to view this page</p></body></html>"); } }
Si un bot demande une page avec un de ces deux paramètres dans l’url on le bloque et hop :p

++
Indiquez l’intérêt que vous portez à cette réponse

0

Jacques

Décembre 2010

Merci encore b_b pour ton aide.

Je pense que la balise nofollow est déjà insérée dans les liens vers le calendrier (aussi bien dans Spip que dans Sarka-Spip). Je la vois bien dans le code source des pages.

J’ai également rajouté les lignes que tu mentionnes dans mon fichier mes_options.php. Sais-tu s’il est possible de simuler un robot pour en vérifier le fonctionnement correct ?

@+
Indiquez l’intérêt que vous portez à cette réponse

0

Jacques

Décembre 2010

J’ai reçu ce matin la réponse de mon hébergeur. Il demande que le problème soit corrigé par la page :

La question n’est pas de savoir si les robots peuvent ou non accéder à la page, il faut que le problème généré par cette page soit corrigé, une fois pour toute, sans quoi le retour en situation mutualisée ne sera pas possible et nous devrons, en fin de compte, vous demander de trouver un autre hébergeur ; ce serait vraiment dommage.

Je suppose que la solution serait de tester la date et de l’ignorer si elle est antérieure à une certaine date (par exemple la date de l’article le plus ancien)

Merci encore pour votre assistance.
Indiquez l’intérêt que vous portez à cette réponse

0

b_b

Décembre 2010

Salut, si aucune de ces solutions ne convient à ton hébergeur je crois qu’il faudrait tout simplement prendre contact avec l’équipe de sarkaspip dans les forums du site pour leur signaler ce problème et trouver un correctif.

As-tu posé ta question sur saka-spip.net ?

Bon courage ++
Indiquez l’intérêt que vous portez à cette réponse

0

Jacques

Décembre 2010

Merci b_b pour tes conseils.

Je viens de poser la question sur le forum Sarka-Spip vu qu’il semble que la solution doit venir du squelette. Je joins le lien pour permettre à ceux qui seraient intéressés de suivre la discussion : http://www.sarka-spip.net/spip.php?...

@+
Indiquez l’intérêt que vous portez à cette réponse

0

IMBERT

Janvier 2011

J’ai personnellement le même problème de saturation chez infomaniak avec le plugin calendrier. En revanche, je n’utilise pas le même squelette puisque mon site tourne sur Eva-web 4.1. Le problème doit donc venir du plugin mini-calendrier que j’ai pourtant mis à jour.
J’ai donc désactiver le plugin et j’attends de voir avec infomaniak.

Mon hébergeur me demande aussi de trouver une solution sous peine de radiation du site.

Merci de publier tout progrès concernant ce pb.
Indiquez l’intérêt que vous portez à cette réponse

0
Jacques

Janvier 2011
Bonjour,

Le problème a pu être résolu grâce au support efficace de b_b (forum Spip) et Christophe (forum Sarka-Spip).

Le problème

Le problème se produit pour des requêtes du calendrier pour les années à partir de 2038. Le même problème survient pour des requêtes avec des années antérieures à une certaine année (que je n’ai pas recherchée).

La solution

La solution consiste à installer l’écran de sécurité disponible http://www.spip.net/fr_article4200.html et à rajouter le code suivant dans le fichier config/mes_options.php
<?php @include_once dirname(__FILE__).'/ecran_securite.php'; /* Bloque les requêtes calendrier_annee < 2000 et > 2029 * AJOUT PERSONNEL POUR EVITER LES ERREURS CPU (saturation serveur) * */ if (_request('calendrier_annee') AND !preg_match(',^([2][0][0-2][0-9]),i', _request('calendrier_annee'))){ header("HTTP/1.0 403 Forbidden"); die("<html><title>Error 403: Forbidden</title><body><h1>Error 403</h1><p>Illegal page call (invalid year)</p></body></html>"); ?>
Toute date située hors de l’intervalle [2000-2029] provoquera l’affichage d’une page d’erreur. Si des requêtes concernant des dates antérieures à 2000 doivent être lancées, il suffit de modifier l’expression régulière.

Apparemment cette solution est correcte car Infomaniak, mon hébergeur, a depuis réintégrer mon site sur un serveur mutualisé et ne m’a plus recontacté.

Le futur

Il serait intéressant que ce problème soit analysé par la core-team de Spip car je pense que tous les utilisateurs du calendrier de Spip sont susceptibles d’être concernés par ce problème.

Bon courage et ...BONNE ANNEE A TOUS
Indiquez l’intérêt que vous portez à cette réponse

0

Vincent Guyot

Août 2011

Bonjour,
J’ai eu exactement le même problème sous spip 2.1.10 et evaweb4.1.

J’ai pu installer l’écran de sécurité 1.0.5 du 26 juil. 2011. Mais le script mes_options.php me retourne une erreur.
Au vu des dates de mise-à-jour, le problème réglé spécifiquement par ce script n’est-il pas réglé directement par l’écran de sécurité. En d’autres termes, le script mes_options.php est-il encore réellement nécessaire ? Si oui, puis-je vous mettre l’erreur renvoyée, pour m’aider à la corriger ?

Merci d’avance.

Vincent Guyot
Indiquez l’intérêt que vous portez à cette réponse

0

Vincent Guyot

Août 2011

Bonjour,
Je me permet de renouveler ma question qui est une suite logique au futur de la solution donnée par Jacques : le problème a-t-il déjà été analysé (et peut-être résolu ?), ou sera-t-il analysé par la core-team de Spip ? En d’autre termes, cela vaut-il la peine d’attendre quelque peu pour que l’écran de sécurité prenne en charge ce problème tout de même très bloquant. Ou faut-il que je trouve une solution à l’erreur produite par le script mes_options.php ?

Merci d’avance. Meilleures salutations.

Vincent Guyot
Indiquez l’intérêt que vous portez à cette réponse

0

Suske

Septembre 2011

Suite de la discussion ici : http://forum.spip.org/fr_237920.html (on va s’attaquer à l’erreur dans le mes_options là je crois...)

Cette discussion a été cloturée par un administrateur. Il n’est pas possible d’ajouter de nouveaux commentaires.