[TUTO] [Docker - macvlan] Pi-Hole

[.Shad.]

Non pas besoin de redémarrer le NAS, tu peux faire :

ip link delete mac0

Sinon attention, je pense que tu l'avais remarqué, mais ovs_eth0 c'est le nom de ton interface principale seulement si tu utilises Virtual Machine Manager.

[DaG33K]

Hello, 

Au top le tuto, j'ai pu mettre en place un PiHole ! 
J'avais dans l'espoir cependant de réussir à bloquer les annonces dans l'interface de Gmail, mais ça ne change rien, ou alors j'ai oublié un truc à faire.

J'ai trouvé deux sites qui référencient une bonne partie des "AdList" et je les ais toutes rajoutées à mon PiHole, j'ai fais "update gravity" qui m'as fait passé à "2 798 891 domains on blocklist", et j'ai même fait redémarrer le PiHole, mais rien n'y fait, j'ai toujours ces foutues annonces qui se glisse dans mes mails sur gmail ... 

Quelqu'un aurais une idée svp ?

[.Shad.]

Je ne pense pas que ces annonces soient blocables via DNS.

[Dimebag Darrell]

Bonjour tout le monde,

une question, j'essaie de comprendre la signification de l'outil audit ? comment fonctionne-t-il concrètement ?

Belle journée,

 

Modifié le 30 juillet 2022 par Dimebag Darrell

[anorec]

Bonjour à tous,

Je viens d'essayer de mettre à jour mon conteneur avec la dernière image 'latest' (2022.8) et Pihole ne fonctionne plus sur mon système.

Voici l'erreur dans l'interface web pihole: (PHP error (2): fsockopen(): unable to connect to 127.0.0.1:4711)

Certains d'entre vous auraient ils rencontré le même soucis?

[.Shad.]

Hello @anorec,

Je viens de mettre à jour Pihole en 2022.8 sur mon serveur Debian et mon NAS (pour la redondance) et je n'ai aucun problème.
J'ai regardé le log FTL par acquis de conscience et je vois des erreurs datant du 19, par contre depuis la màj à l'instant pour l'instant pas d'erreur :

2022-07-19 22:32:10: server.c.1513) server started (lighttpd/1.4.59)
2022-07-19 22:32:10: gw_backend.c.475) unlink /run/lighttpd/php.socket-0 after connect failed: Connection refused
2022-08-10 18:55:36: server.c.1513) server started (lighttpd/1.4.59)
2022-08-10 18:55:36: gw_backend.c.475) unlink /run/lighttpd/php.socket-0 after connect failed: Connection refused
2022-08-10 18:57:55: server.c.1513) server started (lighttpd/1.4.59)
2022-08-10 18:57:55: gw_backend.c.475) unlink /run/lighttpd/php.socket-0 after connect failed: Connection refused
2022-08-13 13:48:42: server.c.1513) server started (lighttpd/1.4.59)
2022-08-13 13:48:42: gw_backend.c.475) unlink /run/lighttpd/php.socket-0 after connect failed: Connection refused
2022-08-15 21:00:55: server.c.1513) server started (lighttpd/1.4.59)
2022-08-15 21:00:55: gw_backend.c.475) unlink /run/lighttpd/php.socket-0 after connect failed: Connection refused
2022-08-16 20:03:24: server.c.1513) server started (lighttpd/1.4.59)
2022-08-16 20:03:24: gw_backend.c.475) unlink /run/lighttpd/php.socket-0 after connect failed: Connection refused
2022-08-19 21:04:07: server.c.1513) server started (lighttpd/1.4.59)
2022-08-19 21:04:07: gw_backend.c.475) unlink /run/lighttpd/php.socket-0 after connect failed: Connection refused
2022-08-23 05:03:41: server.c.1513) server started (lighttpd/1.4.59)
2022-08-23 05:55:22: server.c.1513) server started (lighttpd/1.4.59)
2022-08-23 06:00:16: server.c.1513) server started (lighttpd/1.4.59)

Vu que l'erreur est liée à localhost au sein du conteneur, je ne pense pas que ce soit un problème de configuration.

Modifié le 23 août 2022 par .Shad.

[anorec]

@.Shad. Merci de ton retour.

Je suis repassé en 2022.07.1 en attendant et j'avoue ne pas savoir où chercher...

Je pensais trouver les logs dans les volumes montés mais ils n'y sont pas. Normal?

Bien que l'image 2022.07.1 semble fonctionner le journal indique une erreur fatale S6-svc. Tout n'a pas l'air très propre^^

[.Shad.]

Tu peux afficher ton fichier compose ?

[anorec]

J'en ai pas j'ai créé le conteneur directement dans DSM... J'ai juste l'export .json si ça peut convenir?

[.Shad.]

OK et bien des impressions d'écran plutôt. Avec les variables, les volumes, etc...

Un fichier compose est bien plus pratique pour debugger des situations.  😃

[anorec]

Oui du coup, j'en ai fait un en suivant ton tuto mais j'obtiens le même résultat.

Dans le journal du conteneur, j'ai cette erreur en boucle: failed to raise ambient [CAP_CHOWN=0]

Ça ressemble à un problème de droit et j'ai bien tenté d'ajouter des cap_add et/ou lancer le docker avec privilèges élevés mais sans succès...

Voici le contenu du docker-compose

version: '2.1'
services:

   pi-hole:
      image: pihole/pihole
      container_name: pihole
      hostname: pihole
      networks:
         pihole_lan:
            ipv4_address: 192.168.1.100
      environment:
         - TZ=Europe/Paris
         - PIHOLE_DNS_=192.168.1.200#53;192.168.1.200#53
         - DNSSEC=false
         - DNS_BOGUS_PRIV=true
         - DNS_FQDN_REQUIRED=true
         - DNSMASQ_LISTENING=all
         - INTERFACE=eth0
         - FTLCONF_REPLY_ADDR4=192.168.1.100                 # IP du conteneur Pi-hole
         - WEBPASSWORD=xxx
         - WEB_PORT=8888
         # Personnalisation de l'interface
         - TEMPERATUREUNIT=C
         - WEBTHEME=default-darker
         - WEBUIBOXEDLAYOUT=boxed
      volumes:
         - /volume1/docker/pihole/etc/config:/etc/pihole
         - /volume1/docker/pihole/etc/dnsmasqd:/etc/dnsmasq.d
      cap_add:
         - NET_ADMIN
         - SYS_NICE
         - CHOWN
      dns:
         - 127.0.0.1
         - 80.67.169.12
      restart: unless-stopped

networks:

   pihole_lan:
      external: true

 

[.Shad.]

@anorecRécemment, Pihole est exécuté par l'utilisateur "pihole", et ils ont mis à disposition des variables pour mapper cet utilisateur interne au conteneur à un utilisateur de l'hôte :

Tu peux ajouter dans le fichier compose la variable DNSMASQ_USER=root pour revenir sur le fonctionnement classique.
Et quand tu as le temps, faire le mapping sur un utilisateur non privilégié de DSM (mieux qu'utiliser root quand on nous en donne la possibilité).
Chez moi je me rends compte que j'ai fait à un moment donné un chmod 777 sur le dossier pihole :

Donc ça explique pourquoi je n'ai pas eu de problème.

Du coup je vais de la semaine repartir sur un nouveau conteneur et dossier, avec le mapping, et vérifier si ça marche bien, et je mettrai le tutoriel à jour.

Dis-moi si ce que j'ai suggéré arrange les choses de ton côté (et pour moi tu peux enlever les autorisations SYS_NICE et CHOWN).

[.Shad.]

@anorec Bon j'ai investigué.

Alors le système de mapping fonctionne bien, même s'ils ne mappent que 2 users et qu'eux en utilisent plus que ça dans le conteneur, d'où le fait qu'on se retrouve avec encore quelques utilisateurs non nommés, mais heureusement ça ne semble pas poser problème pour l'écriture des fichiers.

Optionnel : si tu as configuré des listes, des exceptions, etc... que tu souhaites récupérer, tu peux le faire en 2022.07 via Settings -> Teleporter -> Backup.

Le mieux est donc de partir d'une installation vierge, créer un dossier pihole dans le dossier partagé docker via Filestation, et des sous-dossiers etc et dnsmasq.d. Ensuite on crée un utilisateur dédié à pihole dont les droits se limitent au dossier partagé docker. On donne la propriété du dossier pihole et ses enfants à l'utilisateur dédié (via Filestation) :

Ensuite, ne plus monter comme je le fais dans le tutoriel le volume contenant les logs, en fait c'est inutile car il y a tous les outils nécessaires dans pihole même :

Et on va ajouter les variables d'environnement pour mapper les uid/gid entre conteneur et hôte (je rappelle, en SSH on fait id <utilisateur> pour connaître son UID (>1026) et son GID (100 pour users)

- PIHOLE_UID=1041
- PIHOLE_GID=100
- WEB_UID=1041
- WEB_GID=100

On peut maintenant créer le conteneur, la première fois les logs affichaient une erreur persistante :

Starting lighttpd
Stopping lighttpd
lighttpd: no process found

J'ai arrêté et redémarré le conteneur, pour l'instant plus une erreur, puis j'ai importé tous mes paramétrages via Settings -> Teleporter -> Restore (browse)

J'ai récupéré mes groupes, mes whitelist ainsi que mes réglages (mais tous viennent du fichier compose dans mon cas).

Car oui, pour information, tout (ou quasi) peut être configuré à la création du conteneur via les variables d'environnement mises à disposition, seules les plus importantes sont listées sur Github, mais dans la doc... 😄 : https://docs.pi-hole.net/ftldns/configfile/

Voilà, dis-moi si ça fonctionne bien chez toi, si oui, mon setup est reproductible et je mettrai à jour le tutoriel, en attendant je vais placer un avertissement concernant les risques liés à la 2022.08

Modifié le 24 août 2022 par .Shad.
orthographe

[anorec]

@.Shad. J'ai pu essayer rapidement ce midi mais encore et toujours le même problème.

J'ai bien créé un utilisateur dédié au conteneur Pihole (1046) dans le groupe users(100) et je l'ai mappé dans le docker-compose. J'ai créé 2 nouveaux dossiers pour le montage des volumes et vérifié/modifié droits d'accès/propriétaire/groupe.

J'ai remarqué un truc étrange, après lancement du conteneur le dossier 'etc-config' change de groupe (999) et certains des fichiers créés dans les dossiers ont un propriétaire (999)...

Pour voir j'ai aussi tenté de modifier tous les dossiers/fichiers avec CHMOD 777 et aussi essayé en réglant la variable DNSMASQ_USER=root.

 

[.Shad.]

Il y a 3 heures, anorec a dit :

J'ai créé 2 nouveaux dossiers pour le montage des volumes et vérifié/modifié droits d'accès/propriétaire/groupe.

Il aurait fallu aussi recréer le dossier de tête (pihole).

Perso, en suivant exactement la procédure au-dessus, voilà ce que j'ai :

[anorec]

@.Shad.

Je viens de refaire la procédure en supprimant le dossier de base (pihole2)et en le recréant. Il y a manifestement un truc qui cloche sur mon installation...

Pourtant je retrouve les mêmes permissions que sur ton installation (sauf si un truc m'échappe)

Modifié le 24 août 2022 par anorec

[anorec]

@.Shad. Une mise à jour de l'image (2022.08.1) a été publié aujourd'hui qui semble corriger mon problème!

Tout a l'air OK et semble fonctionner si ce n'est que je ne vois plus les N° versions dans l'interface web.

Je suis tout seul encore ? ^^

Modifié le 25 août 2022 par anorec

[.Shad.]

Et pas d'erreur dans les logs ?

[anorec]

Non tout semble clean.

Pour l'histoire des versions, apparemment il y avait (et il y a peut-être encore) un bug qui empêchait l'affichage pendant les premières 24h.

Il y a moyen de ne pas attendre en lançant les commandes 'piholeupdatechecker' et 'pihole updatechecker remote' sur une installation classique. En docker je ne sais pas si c'est possible?

Modifié le 25 août 2022 par anorec

[.Shad.]

Depuis le NAS tu peux exécuter n'importe quelle commande du conteneur :

docker exec -it pihole pihole updatechecker

Le premier "pihole" étant le nom de ton conteneur pihole, le deuxième faisant partie intégrante de la commande à proprement parler (pihole updatechecker).

Voir 8-B-3 de https://www.nas-forum.com/forum/topic/65309-tuto-docker-introduction/

[anorec]

@.Shad. Merci de l'info. Faudrait bien que je relise ce tuto Docker (mais il y tellement de trucs intéressants à lire ! )

Sinon, en cherchant le chapitre 8-B-3 je n'ai pas compris car c'est le chapitre de gestion des ports.

En fait je me suis aperçu qu'il y avait à la suite un autre chapitre 8-B-3 'commandes utiles', qui devrait plutôt s'appeler 8-B-4 du coup^^ à corriger à l'occasion.

[.Shad.]

Ah merci je n'avais pas vu ! Je corrige 🙂 

[anorec]

Les commandes ont bien réglé le problème. Tout roule!

[MuadDib]

Le 22/04/2021 à 18:40, MilesTEG1 a dit :

@.Shad. Tu penses que le soucis pourrait venir de l'adresse MAC affectée à l'IP virtuelle ?
Demain je tenterais ça quand j'aurais le nouveau switch.
Sinon, sans préciser une adresse MAC, elle sera automatiquement fournie ? Ou il n'y en aura pas ?

Autre question : est-il possible de faire en sorte de ne pas avoir d'IPv6 avec cette IP virtuelle ?

@MilesTEG1: As-tu réussi à solutionner le problème ? De mon coté j'ai du retirer le bond car je n'arrivait pas à faire fonctionner le macvlan avec le link aggregation...

[MilesTEG1]

il y a une heure, MuadDib a dit :

@MilesTEG1: As-tu réussi à solutionner le problème ? De mon coté j'ai du retirer le bond car je n'arrivait pas à faire fonctionner le macvlan avec le link aggregation...

Même chose. J'ai laissé tombé l'idée du bond... ça m'occasionnait davantage de problèmes qu'autre chose...