Différences

Ci-dessous, les différences entre deux révisions de la page.

--- tutoriaux:docker-related:stacks-pi-hole [2024/07/09 09:42] – frater
+++ tutoriaux:docker-related:stacks-pi-hole [2024/07/31 09:59] (Version actuelle) – frater
@@ Ligne 3: / Ligne 3: @@
 Il n'est plus nécessaire de présenter [[https://pi-hole.net|pi-hole.net]] tant cet outil rends le contrôle et la réduction des trackers/publicité facile.
-En migrant mon instance pi-Hole vers docker, je me suis heurté à un soucis imprévu, l'[[https://github.com/pi-hole/docker-pi-hole/#running-pi-hole-docker|image officielle]] ne contient pas de serveur "upstream" intégré; elle est parfaitement fonctionnelle avec des DNS upstream tel que google, quad9, cloudflare, mais si l'on veut réellement être indépendant, il manque son propre référentiel.
+En migrant mon instance pi-Hole vers docker, je me suis heurté à un soucis imprévu, l'[[https://github.com/pi-hole/docker-pi-hole/#running-pi-hole-docker|image officielle]] ne contient pas de serveur "upstream" intégré (c'est en discussion pour une future révision); elle est parfaitement fonctionnelle avec des DNS upstream tel que google, quad9, cloudflare, mais si l'on veut réellement être indépendant, il manque son propre référentiel.
+il existe des images [[https://hub.docker.com/search?q=pihole-unbound|Pihole modifiées]], mais celle-ci peuvent ne pas suivre la cadence d'update ou contenir des packages en plus que l'on ne désire pas.
 Avec docker, il est très facile d'ajouter un container "unbound" et de le configurer en serveur upstream, pour ensuite faire pointer pi-Hole sur ce container.
@@ Ligne 9: / Ligne 11: @@
 ===== Cahier de charges =====
-Le stack doit être basé sur des images officielles et maintenues, pour l'image de pi-hole, c'est facile, ca sera l'image officielle, pour ce qui est unbound, il y a un peu plus de choix; j'ai choisis celle de [[ 	https://github.com/MatthewVance/unbound-docker|Matthew Vance]].
+Le stack doit être basé sur des images officielles et maintenues, pour l'image de pi-hole, c'est facile, ça sera l'image officielle, pour ce qui est unbound, il y a un peu plus de choix; j'ai choisis celle de [[ 	https://github.com/MatthewVance/unbound-docker|Matthew Vance]].
 J'ai décidé de composer mon propre "stack" pour lier les deux containers tout en gardant une configuration un peu particulière: je veux que le serveur unbound soit sur un port différent : 5335 du serveur dns.
@@ Ligne 22: / Ligne 24: @@
   * pi-hole web admin sur le port http#8053
   * recursive dns root query (no forwarder)
-  * recursive dns serveur interne sur le port udp#5335
+  * recursive dns serveur interne sur le port udp#53
 ===== Architecture =====
@@ Ligne 61: / Ligne 63: @@
 Je me suis inspiré de la documentation de pi-Hole concernant l'usage de [[https://docs.pi-hole.net/guides/dns/unbound/|unbound]] comme résolveur.
-on va surtout modifier les paramètres d'écoute du serveur, en remplaçant le binding localhost ''127.0.0.1'' par tout les interfaces ''0.0.0.0'' et le port d'écoute ''53'' par notre port ''5335''
+on va surtout modifier les paramètres d'écoute du serveur, en remplaçant le binding localhost ''127.0.0.1'' par tout les interfaces ''0.0.0.0'' et en vérifiant le port d'écoute ''53''
 <code yaml>
@@ Ligne 67: / Ligne 69: @@
     # and port.
     interface: 0.0.0.0
-    port: 5335
+    port: 53
     do-ip4: yes
     do-udp: yes
@@ Ligne 79: / Ligne 81: @@
 <code yaml>
     healthcheck:
-      test: drill @127.0.0.1 -p 5335 cloudflare.com || exit 1
+      test: drill @127.0.0.1 -p 53 cloudflare.com || exit 1
       interval: 30s
       timeout: 30s
@@ Ligne 133: / Ligne 135: @@
   * Désélectionner tout les serveurs par défaut (de google dans mon cas)
-  * Définir notre "Upstream DNS Servers" en pointant vers notre containter unbound : ''172.20.0.200#5335''; (le format de cette configuration est très important).
+  * Définir notre "Upstream DNS Servers" en pointant vers notre containter unbound : ''172.20.0.200''; (si vous changer le port de ''unbound'' le format devient ''x.x.x.x#port'', ce format est très important).
   * Autoriser le serveur a répondre à tout nos client, pour ce faire, nous devons préciser l'option :''Permit all origins'', (''Respond only on interface eth0'' est sans doute suffisant, à vous de tester).
@@ Ligne 147: / Ligne 149: @@
 services:
   unbound:
-    cap_drop:
-      - "AUDIT_CONTROL"
-      - "BLOCK_SUSPEND"
-      - "DAC_READ_SEARCH"
-      - "IPC_LOCK"
-      - "IPC_OWNER"
-      - "LEASE"
-      - "LINUX_IMMUTABLE"
-      - "MAC_ADMIN"
-      - "MAC_OVERRIDE"
-      - "NET_ADMIN"
-      - "NET_BROADCAST"
-      - "SYSLOG"
-      - "SYS_ADMIN"
-      - "SYS_BOOT"
-      - "SYS_MODULE"
-      - "SYS_NICE"
-      - "SYS_PACCT"
-      - "SYS_PTRACE"
-      - "SYS_RAWIO"
-      - "SYS_RESOURCE"
-      - "SYS_TIME"
-      - "SYS_TTY_CONFIG"
-      - "WAKE_ALARM"
     command:
@@ Ligne 177: / Ligne 154: @@
     healthcheck:
-      test: drill @127.0.0.1 -p 5335 cloudflare.com || exit 1
+      test: drill @127.0.0.1 cloudflare.com || exit 1
       interval: 30s
       timeout: 30s
@@ Ligne 228: / Ligne 205: @@
   dns-pihole:
-    cap_drop:
-      - "AUDIT_CONTROL"
-      - "BLOCK_SUSPEND"
-      - "DAC_READ_SEARCH"
-      - "IPC_LOCK"
-      - "IPC_OWNER"
-      - "LEASE"
-      - "LINUX_IMMUTABLE"
-      - "MAC_ADMIN"
-      - "MAC_OVERRIDE"
-      - "NET_ADMIN"
-      - "NET_BROADCAST"
-      - "SYSLOG"
-      - "SYS_ADMIN"
-      - "SYS_BOOT"
-      - "SYS_MODULE"
-      - "SYS_NICE"
-      - "SYS_PACCT"
-      - "SYS_PTRACE"
-      - "SYS_RAWIO"
-      - "SYS_RESOURCE"
-      - "SYS_TIME"
-      - "SYS_TTY_CONFIG"
-      - "WAKE_ALARM"
     container_name: dns_pihole

Nox-Rhea WiKi

Outils pour utilisateurs

Outils du site

Différences

Outils de la page