Pour mettre à jour Pi-hole sur mon réseau domestique, je lance une seule commande, mais je ne lui fais jamais confiance seule. Dans ce pas à pas, je décris comment mettre à jour Pi-hole en six étapes. L’étape qui compte le plus vérifie que le blocage fonctionne encore, et pas seulement que les noms se résolvent.
Réponse rapide — mettre à jour Pi-hole et prouver qu’il bloque encore.
pihole -v # versions avant
pihole-FTL --teleporter # sauvegarde de la configuration
PIHOLE_SKIP_OS_CHECK=true pihole -up # mise à jour
dig +short doubleclick.net @192.0.2.19 # doit afficher 0.0.0.0 (bloqué)Les détails, les explications et les vérifications suivent plus bas.
Mon Pi-hole tourne sur un Raspberry Pi avec Debian 12 et sert de seul serveur DNS de la maison. Par conséquent, chaque redémarrage du service DNS provoque une petite coupure. Mon rôle Ansible ne gère pas les versions de Pi-hole, donc je fais la mise à jour à la main. J’envoie les commandes avec une commande Ansible ad hoc depuis ma machine de contrôle, mais je montre ici les commandes elles-mêmes.
Avant de commencer
- Un shell sur la machine Pi-hole avec les droits root.
- L’adresse de votre Pi-hole et celle de votre routeur. Dans cet article, ce sont 192.0.2.19 et 192.0.2.1.
- Quelques minutes de libres. Dans mes notes, le DNS du réseau local redémarre pendant quelques secondes, et le blocage des publicités peut s’arrêter pendant environ cinq minutes (voir l’étape 4).
- Les notes de version de Pi-hole. La page officielle de mise à jour demande de les lire pour chaque composant avant de mettre à jour, surtout pour une version majeure.
Comment mettre à jour Pi-hole, étape par étape
Étape 1 : vérifier les versions
D’abord, je liste ce que j’utilise maintenant. La sortie donne les versions de Core, de Web et de FTL.
pihole -v
Étape 2 : sauvegarder la configuration
Ensuite, je sauvegarde deux fois : avec Teleporter, l’export propre à Pi-hole, et avec une simple copie du fichier TOML. Je travaille dans un dossier daté, pour que les deux restent ensemble.
mkdir -p /root/pre-update-$(date +%Y%m%d) && cd $_ # un dossier daté, puis on y entre pihole-FTL --teleporter # l'archive Teleporter cp -a /etc/pihole/pihole.toml pihole.toml.bak # une copie du fichier de configuration ls -la # vérifier que les deux sont là
La copie du fichier TOML sert encore à l’étape 5.
Étape 3 : lancer la mise à jour
Vient maintenant la mise à jour elle-même. Je garde les 20 dernières lignes de sa sortie, j’affiche à nouveau les versions, et je demande à systemd si le service DNS tourne.
PIHOLE_SKIP_OS_CHECK=true pihole -up 2>&1 | tail -20 # mise à jour, on garde les 20 dernières lignes pihole -v # versions après la mise à jour systemctl is-active pihole-FTL # doit afficher : active
Mes notes utilisent PIHOLE_SKIP_OS_CHECK=true, qui saute le contrôle du système d’exploitation par l’installeur. La page de mise à jour de Pi-hole ne le mentionne pas, donc testez-le sur votre système avant de le copier.
Étape 4 : tester le blocage, pas seulement la résolution
Cette étape est obligatoire pour moi. Le 29 octobre 2026, FTL, le moteur DNS de Pi-hole, a pris de vitesse le remplacement de la base gravity. Le journal affichait no such table: main.gravity dans /var/log/pihole/FTL.log, et Pi-hole n’a rien bloqué pendant environ cinq minutes. Cela s’est arrêté seulement quand FTL a écrit son propre message : Gravity database has been replaced, reloading now.
Pendant ces minutes, les noms se résolvaient toujours. Donc un simple test de résolution m’aurait dit que tout allait bien.
dig +short doubleclick.net @192.0.2.19 # doit afficher 0.0.0.0 (bloqué) dig +short example.com @192.0.2.19 # doit afficher une vraie adresse dig +short doubleclick.net @192.0.2.1 # via le routeur : doit aussi afficher 0.0.0.0
La troisième requête passe par le routeur. Sur mon réseau, le routeur transmet ses requêtes à Pi-hole, donc une réponse bloquée à cet endroit prouve tout le chemin.
Si le blocage ne fonctionne pas après cinq minutes, je recharge la configuration DNS, puis je lis le journal de FTL.
pihole reloaddns
Étape 5 : vérifier que la configuration n’a pas changé
Une mise à jour peut toucher la configuration. Je compare donc ma sauvegarde avec le fichier en place, en écartant les commentaires et les lignes qui contiennent des empreintes de mot de passe.
diff <(grep -vE '^\s*#|pwhash|password|totp' /root/pre-update-*/pihole.toml.bak) \
<(grep -vE '^\s*#|pwhash|password|totp' /etc/pihole/pihole.toml)
Aucune sortie signifie aucune différence.
Étape 6 : synchroniser le mot de passe d’administration s’il a changé
Si le mot de passe d’administration a changé pour une raison quelconque, je mets à jour mon gestionnaire de secrets le jour même. En août 2026, je l’ai oublié une fois, et chaque déploiement de mon rôle Ansible a échoué jusqu’à la correction.
Vérifier que tout a fonctionné
pihole -vaffiche les nouvelles versions.systemctl is-active pihole-FTLafficheactive.- La première et la troisième requête
digaffichent0.0.0.0, et la deuxième affiche une vraie adresse. - Le
diffn’affiche rien.
Si quelque chose se passe mal
- Le blocage ne fonctionne pas après cinq minutes : lancez
pihole reloaddns, puis lisez/var/log/pihole/FTL.log. - Vous voulez revenir en arrière :
pihole -upne peut pas réinstaller une version précédente. À la place, restaurez l’archive Teleporter sur une installation neuve avecpihole-FTL --teleporter <zip>.
Ce que j’en retiens
- Je sauvegarde deux fois avant de mettre à jour Pi-hole, parce qu’il n’existe pas de retour en arrière.
- Je teste le blocage, parce que la résolution seule a caché un trou de cinq minutes.
- Je compare la configuration, parce que je veux savoir ce que la mise à jour a changé.
Sources
- Documentation Pi-hole : mise à jour (en anglais)
- Documentation Pi-hole : configuration de FTL, pihole-FTL –config (en anglais)
- Mon propre manuel de procédure, dernier passage le 29 octobre 2026.
Laisser un commentaire