Ici & Là

01 Société 02 Histoire 03 Science 04 Science fiction 05 SPIP 06 NTIC 07 Sondages 08 Divers
La meilleure façon de réaliser ses rêves est de se réveiller (Paul Valéry)

Accueil > SPIP > Programmation SPIP, Développements > « DestroyTMP » efface les fichiers de /tmp/ car : « Mes articles ont tous (...)

« DestroyTMP » efface les fichiers de /tmp/ car : « Mes articles ont tous disparu ! -> comment surmonter le bug... »

SPIP standard et dans une Ferme à SPIP

mardi 28 juin 2016, par François Daniel Giezendanner

Notez cet article
0 vote

PNG - 1.3 ko

Le but du plugin « DestroyTMP » est d’ajouter un bouton dans la partie admin de SPIP afin de pouvoir vider le dossier tmp quand cela est nécessaire et/ou quand son contenu pose problème. Les fichiers .htaccess .log .lock et les dossiers themes cfg et dump sont conservés.

 En Bref

Auteur : Vincent Mérat, Etat de Genève
Nom du plugin : destroytmp
Fonction : Vide le dossier tmp
Version : 0.1
Licence : GNU GPL
Compatibilité : SPIP 2.1.10


 Voir aussi les articles :

Vider les dossiers /local/ et /tmp/ : Quand et pourquoi

Retrouver les paramètres de connexion à la base de données MySQL d’un SPIP


 Du symptôme aux solutions

Symptômes

Un/des fichier(s) créé(s) dans le répertoire /tmp/ empêch(ent) l’affichage de tous les textes des articles du site dans l’espace publique et dans l’espace privé.

Solution brutale réservée aux administrateurs-systèmes

Effacer tous les fichiers et dossiers du répertoire temporaire (/tmp) du site SPIP à l’exception des fichiers .htaccess, .log, .lock et des dossiers themes, cfg et dump qui sont conservés.

Cette opération n’est possible que pour les administrateurs systèmes des infrastructures en PRODuction.

Solution brutale pour les administrateurs d’un site SPIP

Disposer d’une fonction (par exemple le plugin DestroyTMP qui affiche un bouton dans l’espace d’administration du site pour effacer tous les fichiers et dossiers du répertoire temporaire (/tmp) du site SPIP à l’exception des fichiers .htaccess, .log, .lock et des dossiers themes, cfg et dump qui sont conservés.

Cette opération est possible pour les administrateurs des sites SPIP.

Solution « Ad hoc »

Investiguer lors des dysfonctionnements avant de vider le répertoire /tmp/ afin d’identifier le(s) fichier(s) incriminé(s) et apporter les corrections idoines.


 Un problème déjà identifié sur www.spip.net/f

Si vous avez installé SPIP en version 2.1, un bug [1] introduit il y a 10 mois [2] vient de faire « disparaître » l’ensemble de vos articles sur votre site.

Pas de panique, ce n’est que l’affichage qui est cassé, une simple mise à jour vers la version SPIP 2.1.2 suffira à rétablir la situation.

Le bug porte sur le fichier ecrire/public/quete.php

Dans ce fichier, à la ligne 82, il faut simplement remplacer la valeur 10000 par 365*2 :

bug : (time()+(3600*24*10000))) ;

corrigé : (time()+(3600*24*365*2))) ;

Toutes les méthodes de mise à jour sont possibles :

— éditer le fichier ecrire/public/quete.php sur votre site (cf. le correctif ci-dessus)

— utiliser spip_loader.php pour télécharger et installer SPIP 2.1.2

— télécharger SPIP 2.1.2 et faire la mise à jour complète par FTP.

— télécharger le correctif au format patch : http://trac.rezo.net/trac/spip/changeset/16014

— faire un svn up ecrire/public/quete.php si votre site est sous SVN en branche 2.1

— commande unix : Cette commande, exécutée en root, permet de faire cette correction de façon globale au niveau de tout un serveur :

# for i in $(locate ecrire/public/quete.php); do grep -l 10000 $i &&
perl -pi -e 's/3600\*24\*10000/3600*24*365*2/g;' $i; done

(cette commande affiche les fichiers impactés).

Ensuite videz le cache de votre site, et vous êtes de nouveau sur les rails.

Avec toutes nos excuses pour cette (grosse) boulette !

 Source :

Reproduit sur le site CMS-SPIP ici : SPIP 2.1 : Mes articles ont tous disparu !


 Motivation et disponibilité pour créer ce plugin

Nous constatons soudainement sur quelques sites la disparition de l’affichage de tous les textes des articles du site dans l’espace publique et dans l’espace privé suite à un dysfonctionnement en relation avec des fichiers créés dans le répertoire /tmp/. Les textes des articles ne sont alors visibles que dans l’espace publique en mode édition. Le problème persiste avec et sans le squelette en plugin SARKA 3.04 que nous utilisons (donc avec le squelette dist).

Une solution « brutale » pour résoudre ce problème est très simple : il suffit de vider le répertoire tmp via le ftp. Dès lors tous les textes réapparaissent et le site est à nouveau 100% opérationnel.

Nos sites sont hébergés sur une infrastructure en PRODuction de l’Etat de Genève, et nous n’y avons pas accès directement. Nous devons passer par un administrateur-système de l’infrastructure d’hébergement pour faire effectuer les opérations, en l’occurrence, vider le répertoire /tmp/. Lorsque le problème survient au début d’une période de congé (weekend ou jours fériés), il est utile que l’on puisse disposer d’un bouton pour vider le répertoire /tmp/ et rendre le site à nouveau opérationnel. C’est justement l’objet du plugin DestroyTMP (il faut comprendre que l’on travaille dans une structure et que l’intervention d’un Sys Admin n’est pas immédiate et peut prendre plus de temps que intervention d’un administrateur de site, surtout sur les weekend’s ou jours fériés).

Dès que nous aurons plus de temps nous investiguerons lors de prochains dysfonctionnements de ce type afin d’identifier le(s) fichier(s) incriminé(s), cela nous conduira peut-être à identifier un plugin « conflictuel ».

Patrick Kuchard avait fourni une excellente solution pour procéder à la solution « brutale » de résolution de ce problème, il s’agit du plugin « Reboot : Gestion (fine) de /tmp » :

Malheureusement il n’est compatible qu’avec SPIP 1.9.2. et personne ne l’a mis à jour pour SPIp 2.1.x.

Par chance, Vincent Mérat a eu la gentillesse de créer le plugin DestroyTMP pour nous rendre service. Disposant de peu de temps, il n’a pas adapté Reboot mais a préféré repartir à zéro pour créer rapidement un plugin plus simple.


 DestroyTMP est utile

  • Lorsque tous les textes des articles d’un site ne s’affichent plus dans l’espace publique et dans l’espace privé suite à un dysfonctionnement en relation avec des fichiers du répertoire /tmp/. Les textes des articles ne sont alors visibles qu’en mode édition (dysfonctionnement observé sur quelques sites au DIP de l’Etat de Genève).
  • Lorsqu’un site sous SPIP affiche une page « Site en travaux » alors qu’il n’en est rien.
  • lorsqu’un gros remaniement des squelettes, des fichiers images, des CSS ou encore des scripts est survenu.
  • lorsque l’on désire effectuer une sauvegarde (backup) complète et propre de son site sur un autre.
  • etc.

 Fonctionnalités de DestroyTMP

JPEG - 7.9 ko

DestroyTMP efface tous les fichiers et dossiers du répertoire temporaire (/tmp) de SPIP à l’exception :

  • des fichiers :
    • .htaccess
    • .log
    • .lock
  • et des dossiers :
    • themes/
    • cfg/
    • dump/
    • sessions/

qui sont conservés.

  • DestroyTMP fonctionne aussi bien pour un site SPIP standard (version 0.1) qu’en mutualisation dans une Ferme à SPIP (version 0.2).
  • DestroyTMP n’utilise pas de connexion à la base de données.
  • Seuls les administrateurs du site ont les droits suffisants pour utiliser DestroyTMP.

DestroyTMP permet de passer outre un blocage dû à une gestion défectueuse d’autres plugins qui nettoient mal leur dépôts dans tmp/. Or, certains plugins utilisent à la fois un répertoire spécifique de tmp/ et des informations dans spip_meta... (on notera que « vider le cache » reconstruit le fichier tmp/meta_cache.php). En ce sens, ce plugin Supprime (pour un temps !) le symptôme mais sans guérir vraiment.


 Téléchargement

Zip - 4.2 ko
DestroyTMP pour un site SPIP standard (ver 0.1)
Vide le dossier /tmp/ d’un site standard
Zip - 4.2 ko
desroyTMP pour un site SPIP standard & dans une Ferme à SPIP (ver 0.2)
Vide le dossier /tmp/ d’un site SPIP standard et installé en dans une Ferme à SPIP

 Installation de DestroyTMP

  • Extraire le contenu de l’archive Destroytmp.zip dans le dossier plugins de votre installation SPIP.
  • Activer le plugin via l’administration des plugins. (Consulter la documentation officielle pour plus de détails.)
  • L’icône du plugin DestroyTMP est affichée dans le menu Configuration dans l’espace privé du site.

 Configuration de DestroyTMP

Il n’y a pas de configuration pour ce plugin.


 Compatibilité de DestroyTMP


 Utilisation de DestroyTMP

  • Cliquez sur l’icône Destrytmp
  • Le plugin efface les fichiers et dossiers au sens sus-mentionné
  • Le plugin affiche : « vidange du répertoire TMP effectuée avec succès »
  • Lorsque vous cliquez sur n’importe quel bouton, la page de login s’affiche afin que vous la renseignez puisque les données login et mot-de-passe ont été effacées de /tmp/.

 /tmp/ et ses sous-répertoires

Le dossier /tmp/ contient les fichiers temporaires, de caches et de log, non accessibles par HTTP. On retrouve dedans les dossiers spécifiques suivants :

  • /tmp/cache/ : pour le cache
  • /tmp/dump/ : un autre pour les sauvegardes
  • /tmp/sessions/ : pour les sessions des visiteurs enregistrés
  • /tmp/upload/ : pour les documents envoyés par FTP
  • /tmp/visites/ : pour calculer les statistiques des visites
  • /tmp/themes/
  • /tmp/cfg/
  • /couteau-suisse
  • etc.

Certains plugins créent d’autres dossiers dans /tmp/.

Le dossier /tmp/ peut être vidé à tout moment.


 Problèmes apparentés décrits sur le Web

  • Le répertoire tmp ne se vide pas et bloque le site
    Le site se bloque, affichant une page blanche au lieu de l’index.
    27 octobre 2010 10:25
    http://forum.spip.org/fr_229609.htm

 Remarque

En mode standard, SPIP ne donne pas de possibilité aux administrateurs d’agir directement sur le dossier /tmp/. La seule exception est l’opération de vider le cache. Dans l’espace d’administration, on vide le cache avec les boutons :

  1. Configuration
  2. Vider le cache —> 2 boutons « Vider le cache »

Cette opération ne vide pas le répertoire /tmp/ mais uniquement le répertoire /tmp/cache/


 Informations complémentaires


[1Le bug se produit sur les machines 32 bits, une date trop éloignée dans le futur se trouvant revenir à janvier 1901.