Bonjour,
Alors que je tentais de créer un nouveau service dans NPM (Nginx Proxy Manager) ce vendredi soir, tout a bloqué des suites d’un incident sur les serveurs de production de lets’ Encrypt 1.
Après que leur service soit rétabli, j’ai voulu reprendre mon travail normalement et là, patatras !
Plus rien ne fonctionnait comme il faut.
J’ai dû ouvrir le capot et rentrer dans le moteur pour rétablir le bon fonctionnement de mon système :
- supprimer les certificats créés après la panne dans les dossiers
archive, sans oublier les liens danslive; - supprimer leurs fichiers de configuration dans
renewal; - rentrer dans la base
database.sqlitepour vérifier les tables et supprimer les enregistrements orphelins ou mal configurés.
Pour accéder à la base de données sqlite, j’ai utilisé un sqlite3 installé sur le serveur hôte car le conteneur n’en proposait pas.
Pour mémoire, voici quelques commandes utiles à connaître une fois dans la base via sqlite3 database.sqlite :
| |
Addendum : 9 mai 2026#
Je pensais avoir tout mis au propre en « purgeant » tout ce que je pouvais trouver d’incohérent et postérieur au plantage de Let's Encrypt, que nenni !
Je m’aperçois que les indices de host et des noms de dossiers pour le stockage des certificats sont décalés.
Quand NPM crée un certificat en l’identifiant #666 dans l’interface, il crée un dossier npm-667.
On peut vivre comme ça, mais c’est franchement pénible.
Comme je ne connais pas suffisamment l’intérieur de l’engin, je suis coincé pour le moment.
La seule solution viable que je vois à l’horizon va être de refaire une installation propre et de tout remettre en place ex nihilo.
Avis aux développeurs·ses#
Quand on travaille sur des processus multi-tâches couches basses, on peut effectivement laisser chacun faire sa popote dans son coin, mais le « best effort » n’est pas suffisant pour bien faire. À un moment donné, il faut contrôler et resynchroniser tous ses petits. C’est mieux.
Au plaisir,
Marc JESTIN
https://marcjestin.fr