Suspension pour des interfaces utilisant des fichiers locaux comme base de données/log

Les Pages Perso Chez Free

Par Al, le , dans En cas de problème. / Dernière modification : le par Al (merci à mithril94 et Lionel).
Tags : MySQL, PostgreSQL, Sécurité, Stockage, PHP, Console de gestion, Erreur 403

C'est la raison de suspension qui englobe le plus grand nombre de cas de suspension possible, des compteurs de visite aux CMS sans base de données SQL en passant par les scripts « fait main », les moteurs de wiki ou les livres d'or. C'est aussi l'une des raisons de suspension parmi les plus simple à éviter. Risquerez-vous une suspension ?

Grâce aux langages de programmation actuels, de nombreux scripts, gestionnaires de contenus (CMS) ou compteurs de visite utilisent des fichiers locaux en lieu et place d'une base de données SQL. Si cette implémentation ne pose techniquement pas de problème sur des infrastructures avec peu d'utilisateurs, elle est à proscrire sur les serveurs d'hébergement de Free en raison de la très forte mutualisation des ressources disponibles. Les pages web dynamiques affichées aux visiteurs de votre site sont générées principalement par trois « niveaux » de serveurs de manière totalement transparente pour le visiteur : le premier (les « frontaux » web) fournit les ressources statiques (images, page html statiques, etc.), le « second », partagés entre plusieurs serveurs du premier niveau exécute le code des scripts PHP de votre site, en s'appuyant sur les données fournies par les serveurs hébergeant votre base SQL (le « troisième » niveau). On comprend donc aisément qu'il est important de partager le traitement de vos pages dynamiques entre les trois « niveaux » de serveurs pour bénéficier des meilleurs performances.

Que se passe-t-il lorsque vos pages web sont générées dynamiquement à partir de fichiers « textes » ? Les serveurs de premier niveau « transmettent » le contenu des scripts PHP aux serveurs d’exécution et sont sollicités, en parallèle, pour lire ou écrire des données contenues dans d'autres fichiers textes, contenant les données à afficher ou écrire. Les accès aux disques durs des serveurs frontaux sont donc fortement sollicités, et cela ralentit l'ensemble des taches qu'ils doivent exécuter pour votre site, et ceux de vos colocataires. Si votre site web à recours à l'un de ces procédés, il risque la suspension car « Les interfaces utilisant des fichiers locaux comme base de données/log sont interdites. »

Les motifs de suspension

Passons maintenant en revue les principales causes de suspension et leurs alternatives autorisées sur les pages perso de Free. Cette liste s'enrichira progressivement, sur vos recommandations ou en raison de nouveaux motifs de suspension apparaissant sur le forum Usenet.

1. Les statistiques, compteurs de visites, historiques, logs, etc.

Si vous avez installé sur vos pages un système de log, d'historique, de statistiques qui écrit dans un fichier texte les données qu'il collecte, il suffit de lire un autre billet de ce site pour suivre les bonnes pratiques à adopter.

Il en est de même pour certains système de sauvegarde, comme Akeeba, qui enregistrent dans un fichier texte l'ensemble des opérations de sauvegarde. Il importe donc de supprimer ce composant et d'utiliser une autre méthode de sauvegarde (ou les méthodes autorisées par Free).

2. Les CMS, livres d'or, moteurs de wiki et de blog, etc. n'utilisant pas de base de données SQL

Un certains nombre de CMS légers ou d'extensions (également connus sous les noms de plugins/add-ons/composants/modules externes…) de certains CMS n'utilisent pas de base de données, ils stockent les informations dans des fichiers textes de type TXT, XML, PHP, LOG… sans avoir recours a des bases de données SQL. Il faut impérativement éviter de les utiliser sur les serveurs de Free, sous peine de voir son compte suspendu.

Pour éviter la suspension, il faudra migrer vos données vers un CMS, un livre d'or, un moteur de Wiki ou de blog utilisant une base de données SQL, après avoir demandé l'activation d'une base MySQL ou PostgreSQL dans votre interface de gestion.

Parmi les CMS à éviter, tous les « Guppy like » (Guppy, Phortail, PmWiki, DokuWiki, PluXml…), livre d'or, moteurs de wiki sans base de données SQL.

Moteurs de wiki avec base de données SQL (autorisés chez Free) : MediaWiki, XWiki, WikkaWikiWakoWiki, WikiNi, YesWiki, Wikyblog, Phpwki, TikiWiki, Wiclear, WikiNi MST. Voir aussi : https://fr.wikipedia.org/wiki/Liste_de_logiciels_wiki#PHP.

Une liste des CMS interdits et autorisés est disponible sur ce site, avec toutes les réserves possibles.

3. Les systèmes de cache

Certains scripts et CMS archivent les données issues de la génération dynamiques des pages de votre site pour les présenter plus rapidement à vos visiteurs. Cette méthode possède l'avantage d'optimiser le temps de réponse de votre site. Il faut toutefois veiller à ce que le système de cache soit correctement configuré et ne surcharge pas les serveurs en cas d'accès disque constant. Certains CMS sont correctement optimisés pour cela, d'autres non. Il faut donc veiller à activer le cache de vos pages dynamiques que si votre CMS gère correctement celui-ci. Dans le cas contraire, il est préférable de le désactiver, puis de supprimer les fichiers cache éventuellement présent sur le serveur.

Les exceptions autorisées

Nous venons de le voir, la règle générale sur les serveurs des Pages Perso de Free est « aucun fichier utilisé comme base de données ». Cette règle est valable si les fichiers en question sont sujets à modification (écriture, mise-à-jour, suppression) via vos scripts PHP (à l'image d'une véritable base de données). Nous venons également de voir pour quelles raisons cela était interdit (consommation de ressource excessive notamment).

Il est cependant possible d'utiliser des fichiers avec des scripts PHP pour les utiliser dans vos applications sans risquer les foudres de l'administrateur du service. Pour cela, vous devez suivre quelques règles concernant la manière dont ces fichiers seront traités et utilisés par vos scripts.

Si les fichiers, une fois déposés ou uploadés sur votre site (par FTP ou par HTTP), sont quasi exclusivement accédés en lecture (pas de modifications sur le disque des dits fichiers par un script quelconque), alors il est tout à fait possible de conserver ces données dans des fichiers et de réaliser des lectures directes depuis vos scripts.

En outre, vous devez organiser vos fichiers logiquement, et ne pas les laisser « en vrac » dans un seul répertoire où leur nombre pourrait éventuellement demander d'importantes ressources pour les lister.

Enfin, la taille des fichiers doit être limitée. Le poid des fichiers ne devraient pas dépasser quelques centaines de kilo-octets chacun.

L'utilisation de PHP 5.6.x est fortement recommandée dans ce cas, pour des questions techniques et évitez les veilles versions PHP 4.4.3 et 5.1.3.

Les pré-requis pour lever la suspension

Comme vous pouvez vous en douter à la lecture de cette page, les pré-requis varient selon le motif de suspension. Toutefois, voici une liste présentant les principaux points à suivre.

  1. Changer et diversifier l'ensemble des mots de passe de tous les comptes : email, ftp et (éventuellement SQL) ;
  2. Vérifier que l'ensemble des (éventuels) autre(s) compte(s) est conforme aux règles des pages perso de Free (ce site ou le forum Usenet des pages perso de Free). Si ce n'est pas le cas, indiquer ce qui a été modifié sur tel ou tel compte pour le rendre conforme, car Lionel ne regardera la suite des pré-requis que si ce point spécifique est réalisé ;
  3. Vérifier qu'aucun des (éventuels) autre(s) compte(s) est « orphelin », c'est à dire que tous les comptes doivent être rattachés à un compte principal et que aucun d'entre-eux ne retourne une erreur 500 lors de la connexion a l'interface de gestion ;
  4. Mettre à jour la copie locale du site (et éventuellement de la base sql) : mise à jour des CMS, installation de captcha pour limiter le spam sur les formulaires accessibles sans identification, etc. ;
  5. Préparer la stratégie de remise en ligne du site (par exemple, « j'ai fais telle mise-à-jour du script php fait à la main et passage du CMS XXX sans base de données vers le CMS ZZZ disposant de base de données SQL », préparation de la suppression des fichiers et des données des CMS, compteurs, moteurs de wiki, etc.) ;
  6. Demander la levée du blocage à Lionel sur le forum Usenet, de manière claire, courte et précise en présentant les aspects techniques, ce qui a été fait, ce qui sera fait une fois l'accès ftp rétabli… ;
  7. Une fois l'acces ftp rétabli, mettre en place la nouvelle version du site depuis la copie locale (et de la base SQL éventuellement) ;
  8. Supprimer les dossiers et fichiers à l'origine de la suspension ;
  9. Ré-ouvrir l'accès public HTTP en modifiant correctement le fichier .htaccess une fois que vous êtes sûr que est tout est corrigé (sinon la suspension sera de nouveau très vite de retour).