Une souris grise de dessin animé court énergiquement avec un grand sac postal beige étiqueté "MAIL" sur son épaule, l'air enthousiaste dans des gants et des chaussures jaunes. En dessous, "POSTFIX" est écrit en gras, ce qui indique une livraison rapide et non une erreur verify_cache.db ou un bogue de la base de données Berkeley.

Postfix : corriger l’erreur verify_cache.db “possible Berkeley DB bug”

En consultant les logs d’un serveur mail Postfix, je suis tombé sur un message qui revenait régulièrement :

close database /var/lib/postfix/verify_cache.db: No such file or directory (possible Berkeley DB bug)Code language: JavaScript (javascript)

À première vue, le message fait un peu peur. On lit Berkeley DB bug, on pense base de données corrompue, puis on commence à imaginer le serveur mail en train de mâcher ses propres fichiers. Bonne nouvelle : dans la plupart des cas, ce n’est pas dramatique.

Cette erreur concerne le cache de vérification d’adresses de Postfix. Lorsque Postfix utilise la vérification d’adresses, il peut stocker les résultats dans une base persistante. Ainsi, il évite de refaire les mêmes vérifications après un postfix reload ou un redémarrage du service.

Le problème survient généralement lorsque Postfix tente d’utiliser le fichier verify_cache.db, mais que la configuration de la map de vérification n’est pas assez explicite. Le démon verify essaye alors de manipuler un cache qui n’existe pas encore, ou auquel le service n’accède pas correctement via proxymap.

À quoi sert verify_cache.db dans Postfix ?

Postfix peut vérifier une adresse expéditeur ou destinataire avant d’accepter définitivement un message. Il effectue alors une sorte de test SMTP, sans livrer réellement le courrier. Le résultat de cette vérification peut ensuite être conservé en cache.

Ce cache évite de solliciter inutilement les mêmes serveurs distants. Il accélère aussi les décisions de Postfix lorsqu’une adresse a déjà été testée récemment.

La documentation Postfix indique que le paramètre address_verify_map définit la base de données persistante utilisée pour ces résultats de vérification. Sans ce paramètre, les informations de vérification sont perdues après un postfix reload ou un arrêt du service.

En clair : le fichier verify_cache.db n’est pas une boîte mail. Ce n’est pas non plus un fichier vital contenant vos messages. C’est un cache technique utilisé par Postfix pour garder en mémoire les résultats des vérifications d’adresses.

Lire la suite

Trois diagrammes en forme de beignets violets étiquetés "MEMOIRE", "TOUCHES" et "HITS" survolent un ordinateur portable affichant le logo "php OPCache". Une main en niveaux de gris soutient l'ordinateur portable, illustrant la mise en cache améliorée sur un serveur dédié, le tout sur un fond clair.

PHP : remplacer APC par OPcache et APCu sur un serveur Linux

À une époque, installer APC depuis SVN sur un serveur dédié pouvait avoir du sens. APC, pour Alternative PHP Cache, servait alors à accélérer PHP en mettant en cache le code compilé, mais aussi à stocker des données applicatives en mémoire.

Ce temps est terminé. Aujourd’hui, il ne faut plus installer APC. Et encore moins depuis SVN, à la main, sur un serveur de production. Là, on n’optimise plus PHP : on invoque l’archéologie système.

La pile moderne est simple : utilisez OPcache pour le cache d’opcode PHP, puis ajoutez APCu uniquement si votre application a besoin d’un cache utilisateur local.

Lire la suite

WordPress : remplacer le vieux code Dailymotion de vos articles par une URL oEmbed photo 1

WordPress : mettre à jour le code Dailymotion

Cet article est le pendant de l’article qui explique comment remplacer le vieux code YouTube de vos articles WordPress par une URL oEmbed, mais cette fois pour Dailymotion.

Sur d’anciens articles WordPress, on peut encore retrouver de vieux codes d’intégration Dailymotion en Flash, avec des balises <object>, <param>, <embed> ou des URL du type /swf/.

Ces intégrations sont obsolètes. Flash a disparu, ces codes ne sont plus propres, et ils compliquent la maintenance du contenu.

La solution moderne consiste à remplacer ces anciens blocs par une simple URL Dailymotion :

https://www.dailymotion.com/video/x123abcCode language: JavaScript (javascript)

WordPress peut ensuite transformer cette URL en lecteur intégré via oEmbed, à condition qu’elle soit seule sur sa ligne ou insérée dans un bloc d’intégration compatible.

Pourquoi remplacer les anciens codes Dailymotion ?

Les anciens codes Dailymotion ressemblaient souvent à ceci :

<object data="http://www.dailymotion.com/swf/video/x123abc" width="300" height="150">
  ...
</object>Code language: HTML, XML (xml)

ou :

<object data="http://www.dailymotion.com/swf/x123abc" width="300" height="150">
  ...
</object>Code language: HTML, XML (xml)

Le problème est triple :

  • ces intégrations reposaient souvent sur Flash ;
  • elles utilisent parfois du HTTP au lieu de HTTPS ;
  • elles enferment l’URL utile dans du HTML difficile à maintenir.

À la place, une URL Dailymotion propre suffit :

https://www.dailymotion.com/video/x123abcCode language: JavaScript (javascript)

Dailymotion prend en charge oEmbed : le principe consiste à fournir une URL de vidéo, puis à récupérer les informations nécessaires pour l’intégrer dans une page.

Lire la suite