J'ai mis en place sur mon LAN personnel il y a quelques mois une machine fort pratique qui remplace avantageusement la Livebox pour plusieurs besoins :
- serveur DHCP
- serveur DNS interne
- relais DNS
- bloqueurs de pub (via DNS)
Cette machine, c'est simplement un Raspberry Pi 2 avec Raspbian et Pi-Hole installés dessus. C'est bougrement efficace et terriblement simple à gérer.
Auparavant, si vous aviez suivi certains articles d'il y a quelques temps, j'utilisais mon serveur maison comme relais DNS. Mais j'ai souvent trouvé que c'était handicapant de devoir compter sur ce serveur déjà fort utilisé pour ce besoin.
Quid quand on fait une mise à jour ? une maintenance ? une bidouille un peu cradingue touchant au réseau ? Ben plus aucun machine ne peut résoudre les DNS, et ça n'aide pas.
Non, ce qu'il faut, c'est une machine dédiée pour ça. Si je poussais la réflexion jusqu'au bout, il faudrait un routeur complet qui remplace la Livebox. Mais hé, on va s'arrêter avant si vous le voulez bien.
Donc mon petit Pi-Hole tournait depuis plusieurs mois tranquillement, et tout marchait bien. Je l'avais même mis une ou deux fois à jour et à chaque fois tout fonctionnait au quart de poil même après un reboot.
Mais là. Non.
Mise à jour des packages Debian (apt ...), mise à jour de Pi-Hole (pihole -up), aucune erreur flagrante. Mais je vois ensuite que les résolutions DNS depuis les autres machines commencent à échouer. Aïe.
Problème n°1 : le rate limit
Bon déjà, les résolutions n'échouaient pas de manière totalement aléatoire. En fait il se trouvait juste que certaines machines ont la main lourde sur les requêtes DNS et arrivaient à atteindre et dépasser une protection anti-DDoS qui a été ajoutée dans la version 5.7 de FTL (le fork de dnsmasq pour Pi-Hole).
OK, donc ça, on désactive. C'est-à-dire qu'on revient au fonctionnement pré-5.7, qui m'allait bien.
Dans le fichier /etc/pihole/pihole-FTL.conf :
RATE_LIMIT=0/0
Voir documentation officielle : https://docs.pi-hole.net/ftldns/configfile/#rate_limit
Problème n°2 : 4 Go pour pihole-FTL.db, c'est trop
J'essaye de redémarrer le service, mais là ça bloque. Puis ça me rend la main après 1 ou 2 minutes avec un timeout.
Ah, v'là aut' chose.
Je relance, puis je consulter en parallèle le log /var/log/pihole-FTL.log et je vois des lignes similaires qui s'ajoutent toutes les secondes environ :
...
[2021-09-29 11:38:55.059 757M] Resizing "FTL-domains" from 659456 to (41472 * 16) == 663552 (/dev/shm: 13.6MB used, 490.3MB total, FTL uses 13.6MB)
[2021-09-29 11:38:56.859 757M] Resizing "FTL-strings" from 1105920 to (1146880 * 1) == 1146880 (/dev/shm: 13.6MB used, 490.3MB total, FTL uses 13.6MB)
[2021-09-29 11:38:57.280 757M] Resizing "FTL-domains" from 663552 to (41728 * 16) == 667648 (/dev/shm: 13.7MB used, 490.3MB total, FTL uses 13.7MB)
...
OK, ça sent pas bon mais j'arrive pas encore à déterminer l'odeur.
Recherche intensive sur le oueb et je tombe sur des issues Github ou des entrées de forums qui semblent parler de ce problème.
- https://github.com/pi-hole/FTL/issues/1081
- https://github.com/pi-hole/FTL/issues/509
- https://discourse.pi-hole.net/t/tip-how-reduce-db-stat-size/26070
Ah tiens il y a donc une base de données SQLite rattachée à pihole-FTL. Voyons sa taille.
ll -h /etc/pihole/pihole-FTL.db
-rw-r--r-- 1 pihole pihole 3,5G sept. 29 10:37 pihole-FTL.db
Ah oui ben trop gros quoi.
On tente la méthode "propre" avec un DELETE + VACUUM comme proposé dans le lien précédent et après une bonne heure d'exécution (!), le fichier .db a perdu du poids et ne fait plus que quelques dizaines de Mo... mais aucune amélioration et le service FTL ne veut toujours pas démarrer.
OK donc je tente la suppression pure et simple. Ah, là ça démarre immédiatement. Y'a du mieux.
En fait, il semblerait que ça ne soit pas un crash en soi, mais seulement une grosse lenteur de démarrage liée au fait qu'il doive charger les requêtes des dernières 24h depuis la base pour faire des statistiques.
Oui bon, donc on s'en fiche un peu quoi.
Donc retour dans le fichier /etc/pihole/pihole-FTL.conf et on y ajoute :
MAXDBDAYS=30
MAXLOGAGE=1.0
Le MAXDBDAYS c'est pour ne plus conserver un historique délirant pour un RPi de 365 jours mais plutôt de 30 jours. Ça évitera à la base SQLite de trop grossir (j'espère).
Le MAXLOGAGE de son côté est destiné au démarrage du service FTL et au chargement très long des requêtes qui génère les logs précédents. Au lieu de charger l'historique sur 24h par défaut, on se limite à 1h.
Et là effectivement, après une re-suppression du fichier .db, le service démarre correctement.
Et 1h plus tard, je tente un redémarrage "pour voir", et ça marche encore. Ouf.
Pareil 24h plus tard. Re-ouf.
Monitoring
Pour éviter les surprises futures, j'ajoute 2 éléments de monitoring à mon système Prometheus+Grafana qui surveille déjà le bon fonctionnement de tout un tas de systèmes :
- La taille du dossier
/etc/pihole(qui contient donc notamment le fichier.db). Je fais ça avec le collectorDiskUsagede mon petit script prometheus-exphporter - Les métriques standards de Pi-Hole, via l'exporter dispo sur Github
Tout ça avec un petit dashboard dédié et des alertes simples.
Note : par contre le dashboard proposé ne fonctionne plus avec la version 8+ de Grafana. Arf.
On croise les doigts pour la prochaine mise à jour...