Blog Blog

Depuis quelques temps déjà j’observe que l’espace disponible sur le disque dur de mon serveur diminue et diminue… Normal ? Oui mais… pas à ce point.

Je me décide à aller enquêter, la première étape étant de trouver le coupable (si il y a un), je me lance. À grand coup de du -hcs * en partant de la racine je remonte petit à petit vers ce qui occupe le plus de place sur le disque.

Sans surprise, j’arrive jusqu’au dossier /var/mail… qui contient toutes les boites emails du serveur (non c’est vrai ?).
Normal en même que ce dossier soit énorme mais les boites on des tailles énormes surtout certaines qui me font grincer des dents : 486 Mo pour une centaine de mails c’est beaucoup trop !

Alors je vais bien évident voir ce qui occupe toute cette place et à ma grande surprise je découvre que tous les mails supprimés… ne sont pas supprimés ! Les emails marqués pour suppression (en imap) sont très facile à identifier puisqu’il sont marqué d’un T à la fin du nom du fichier.

Alors pourquoi les emails supprimés ne le sont plus ? Il l’était bien avant. Un petit check de ma configuration de courier-imap s’impose.
Tout d’abord les emails marqués comme supprimés doivent aller dans la corbeille IMAP_MOVE_EXPUNGE_TO_TRASH=1 ça c’est ok.
Ensuite la purge de la corbeille : IMAP_EMPTYTRASH=Trash:7 c’est ok aussi.

Alors pourquoi le bouzin bouzine pas bien ? Dans le fichier de configuraton de courier-imap on lit bien que pour purger la corbeille, la date CTIME des emails est vérifié plutôt que la date ATIME. Soit, allons de ce pas vérifier la date de ces emails supprimés qui jouent aux revenants. Un petit ls -l --time=ctime ou ls -lc m’indique très rapidement que tous les fichiers du répertoire (en l’occurrence .Trash/cur/) ont la même date CTIME et cette date c’est aujourd’hui… plus précisément très tôt ce matin.

Comment ce fait-ce ? Je googelise à propos de courier-imap - que j’estime coupable à ce moment là - sans rien trouver de génial dans les mailings-list à part que pas mal d’autre courrier-imapeur qui se plaignent du même problème et pas vraiment de solution visiblement sauf pour ceux qui utiliseai rsync qui modifierai la date CTIME des fichier rsyncé.

Alors moi je ne pratique pas le rsync sur mon dossier mail puisque je backup via FTP je tar. La cause rsync est donc exclue… Mais si c’était tar ? Puisque Rsync créer bien le problème pourquoi pas un simple tar. En même temps ça se saurait, et puis pas possible j’ai mis tous les —preserve-truc qui était existant dans le man - tu sais genre mode parano-bourrin.

Dans le doute je test quand même ma commande de backup… Et paf ! Oh surprise qu’elle ne fut pas, un tar modifie la date de modification des fichier tarés marquer pour suppression qui ne sont pas supprimés (vous suivez ?) Je googlize pour trouver pourquoi tar modifie la date CTIME et rien de rien. Je fouille dans le man de tar pour trouver un —preverve-ctime ou option du genre que je n’aurais pas vu… Et c’est le néant.

Alors je me dit que c’est quand même mal fichu, qui va falloir que je trouve une autre solution de backup ou faire un cp avant qui lui préserve la date ctime et puis que c’est quand même bizarre que tar modifie le CTIME du fichier taré et que ça ne soit pas plus connu que ça visiblement. Alors je test encore tar mais avec un tar -czf tout simple sans option au lieu de ma commande de backup qui ressemble plus à tar -–cz -preserve -–atime-preserve -–exclude..... -f ..... et quel fut mon bonheur de voir que là, avec un tar tout simple, la date de mofication des fichiers (CTIME) n’était pas modifiée. Conclusion simple et rapide : J’ai une option dans mon tar qui ne preserve pas la date de modification et ironie du sort c’est l’option --atime_preserve qui est coupable. En tentant de préserver la date ATIME, tar modifie la date CTIME. sans l’option --atime-preserve c’est l’inverse et si vous voulez préserver les deux… bien je m’en moque parce que la moi je veux que juste que le CTIME soit préservé l’option --atime-time était mise que parce que ça faisait pro de la mettre et que j’avais envie.

Conclusion : Supprimer le --atime-preserve - vos emails (en imap) seront bien purgés et vous économiserez quelques gigas octets qui vous seront sûrement bien utile.

Moralité : Less is more* !!

*ou less is better, je ne sait pas laquelle est l’originale.

EDIT : IMAP_MOVE_EXPUNGE_TO_TRASH=1 Ne déplace pas dans la corbeille les messages marqués comme supprimés mais déplace dans la corbeillle les messages réellements supprimés (purgés).

Réaliser les tests unitaires des futures version de PHP aide l’équipe de développement de PHP à améliorer PHP alors autant les aider. La méthode à suivre est assez simple si vous êtes habituer à la ligne de commande (ou pas). Commençons tout de suite en testant la version PHP-5.2.7RC1 qui sortira prochainement.

Dotclear 2 est sorti il y a peu, j’en ai donc profité pour rafraîchir un peu ce blog en changeant le thème au passage.

Dotclear 2 dans sa version final apporte son lot de nouveautés qui seront toutefois assez subtiles d’une manière générale à l’oeil non aguéri à l’administration de Dotclear mais qui sont bien agréables dans la manipulation de l’administration renforçant sa facilité d’utilisation.
On appréciera la pré visualisation des billets et la possibilité de lier un autre billet aisément.

Petite note rapide :

PDO pour la nième fois m'à fait des misères ce matin. Je devrais préciser PDO + driver Mysql car je ne saurait dire lequel des deux est coupable dans l'histoire.

Si PDO est récent et donc sa manipulation nouvelle. Certes c'est normal que l'on se retrouve confronter à des erreurs " de débutant ". Mais ce matin j'ai passé une heure à cherché le pourquoi ça marche pas.

Il y a peu j'avais été confronter à une requête sql qui ne retournait rien. Après avoir cherché dans la doc PHP. l'instruction PdoStatement->closeCursor() s'avérait être la solution. Autant pour moi c'était clairement indiquer dans la doc.
Aujourd'hui le même BUG se présente. Un select qui ne retourne rien et bien entendu il est éxécuté après une suite de select. Si je le place en tête de liste, il fonctionne mais les suivants ne fonctionnent plus. Ce coup-ci je n'ai pas fait l'idiot et j'avait bien mis des closeCursor() après chaque requête (même celle qui lise la liste complète de résultat).

Alors que faire dans ce cas ? Après plus d'une heure j'ai trouver une solution. faire un unset(pdoStatement) derrière le closeCursor() et comme par magie tout est revenu dans l'ordre.

J'apprécie travailler avec PDO globalement même si certaine fonctionnalité sont abstente oou d'autre parraisse fonctionner étrangement voir certainre qui diverge complètement de la doc. Je doit avoir que je commence un peu à fatiguer de ce genre de mauvaise surprise.

Pourquoi je rale ? Parceque pendant que je cherchait une solution à ce bug j'ai remis en cause réellement l'utilisation de PDO dans mon application. et après avoir trouver la solution j'ai repris tout mon code (quelques dizaine de millier de lignes) afin de rajouter des unset() après chaque requête. J'ai maintenant la crainte qu'un nouveau bug PDO m'oblige à revoir mon architecture ou changer de driver.

Résultat ma confiance en PDO diminue d'un cran et c'est bien dommage.

Bonjour et bonne année à tous !

Je reviens après les fêtes plus reposé que jamais. J'ai en effet quitté mon emploi ce qui me permet de respirer un peu. Pas trop quand même puisque je me lance de facto dans une nouvelle aventure.

Je publie donc cette petite nouvelle pour vous souhaiter à tous bien le bonjour et aussi pour demander à tous une bonne solutions antispam pour Dotclear.

Je m'explique. J'ai il y a quelques mois fermé les commentaire de ce blog (et de ceux que j'héberge) car le nombre de spam par commentaire comme rétrolien est devenue vraiment impressionnant. Au début 30 par jour était fatiguant à traiter mes tolérable. 1000 par jour est devenu impossible. Faute de temps et de moyen j'ai donc bloqué la possibilité pour le spectateur d'effectuer une intervention sur le blog.

Par la suite, en vue du nombre d'intervention par email des lecteurs - ce qui me ravie ! - Je souhaite plus que tous vous offrir de nouveau la parole ici. Je réouvre donc les commentaires. Si les spams vont se faire rare dans un premier temps, je redoute le moment où il vont arriver de nouveau.

Donc si vous passé par là et que vous avez une bonne astuce. Je suis preneur.

Merci à vous !