L'Antre d'un poulpe

AdGuard ne démarre plus

· Grishka

Sur mon réseau, j’utilise Pi-Hole depuis des années. Pour faire très simple, c’est un bloqueur de publicité à l’échelle de tous mes appareils. J’en suis très content : il est léger et fonctionne très bien sur un Raspberry Pi.

Mais voilà, de temps à autre j’aime bien refaire un tour du côté des concurrents pour voir ce que ça donne. L’un d’entre eux est AdGuard Home. Je l’avais déjà essayé il y a quelques années, avant de revenir à Pi-Hole, je ne sais même plus pourquoi !

J’ajoute donc un conteneur LXC dédié dans Promox, sur une base Debian, lui file une IP fixe sur le réseau puis lance l’installation de AdGuard Home avec l’une des commandes proposées. Tout se passe bien, j’accède rapidement à l’interface pour créer un compte utilisateur, ajouter les listes de blocages déjà utilisées sur Pi-Hole (l’un de mes objectifs avec ce test est de comparer les résultats et les performances des deux solutions avec une base similaire), puis j’ajoute l’IP du service comme DNS primaire sur mon ordi. Tout. fonctionne. au. poil.

Et ça pourrait très bien s’arrêter là…

À force d’ajouter des services sur le serveur, je commence à me dire que la quantité de RAM est un peu légère. Je commande donc quelques Go supplémentaires et les installe ce soir en rentrant du taf. Extinction des feux sur la machine, ouverture du panneau, dépoussiérage au passage et installation des barrettes.

On redémarre, la mémoire est correctement détectée, les conteneurs se relancent, yopupi. Sauf AdGuard.

Plus de connexion sur l’ordi, il n’arrive pas à joindre le serveur. L’interface web est injoignable. Le temps de remettre Pi-Hole en DNS primaire, je me connecte sur la machine pour regarder ça de plus près. Première étape, vérifier le statut du service. Il faut se rendre dans /opt/AdGuardHome et lancer la commande $ ./AdGuardHome -s status : ça semble OK.

Étape suivante, je vérifie l’état du service avec $ systemctl status AdGuardHome.service et là c’est déjà moins réjouissant : (code=exited, status=1/FAILURE). Pour commencer, j’essaye plusieurs manipulations : 

  • Désinstaller le service puis le réinstaller : HS
  • Relancer manuellement le service ($ ./AdGuardHome -s start & ./AdGuardHome -s run) : HS

Toujours pas de résolution des requêtes, toujours pas d’interface web, je tombe sur la page Apache2 Debian Default Page.

Après quelques recherches pour savoir où sont les logs, je les consulte avec $ journalctl -u AdGuardHome.service (l’argument -u permet de filtrer sur un service spécifique) et je tombe sur cette erreur : [fatal] listen tcp 0.0.0.0:80: bind: address already in use. Il semble que le service se lance, puis échoue parce que le port 80 est déjà utilisé. Curieux.

Je n’ai pas netstat sur la machine, donc j’utilise $ ss -tunlp pour voir quels sont les ports ouverts et quels services les utilises. En l’occurrence, c’est apache2 qui squatte le port 80. Pour une raison qui m’échappe encore, tout allait bien avant de relancer le serveur, et plus après. Est-ce qu’une configuration par défaut s’est retrouvée chargée par erreur ? J’ai redémarré plusieurs fois le conteneur et le souci persiste, donc ça semble improbable.

Bref, à défaut d’en connaitre l’origine, la cause est identifiée. Pour régler ça : 

  1. Éditer la configuration apache : $ nano /etc/apache2/ports.conf (sous une base Debian) ;
  2. Commenter la ligne Listen 80 vers le début du fichier ;
  3. Ajouter une ligne Listen 81 (n’importe quel port non utilisé fera l’affaire) et enregistrer ;
  4. Vérifier si un virtualhost doit changer de port également : $ nano /etc/apache2/sites-enabled/000-default.conf. Si besoin, remplacer par le même port que dans le fichier précédent et enregistrer ;
  5. Au cas où, vérifier dans la configuration de AdGuard que l’interface web est bien paramétrée sur le port 80 avec $ nano /opt/AdGuardHome/AdGuardHome.yaml :
http:
	pprof:
	port: 6060
	enabled: false
address: 0.0.0.0:80. # ICI

  1. Redémarrer le service avec $ ./AdGuardHome -s start puis $ ./AdGuardHome -s run

  2. Tout semble OK. Vérifier l’état du statut avec $ systectl status AdGuardHome.service :

* AdGuardHome.service - AdGuard Home: Network-level blocker
     Loaded: loaded (/etc/systemd/system/AdGuardHome.service; enabled; preset: enabled)
     Active: active (running) since Tue 2024-10-15 18:40:46 UTC; 9min ago

Victoire !

Une solution alternative aurait été de changer le port de l’interface web d’AdGuard. C’est sans conséquence sur le fonctionnement du résolveur DNS sur le port 53, et sans conséquence sur un éventuel accès externe qui passerait de toute façon par un reverse proxy.

Je m’attendais pas à ce souci et comme souvent c’est l’occasion d’apprendre des trucs, ce qui est presque plus sympa que juste faire fonctionner le service.