docker pi hole
2024.07.0
Vous utilisez la Tour de Garde ? Voir la note sur la Watchtower au bas de ce fichier Lisez-moi.
Depuis 2023.01 , si vous avez des modifications pour lighttpd via un fichier external.conf , ce fichier doit maintenant être mappé dans /etc/lighttpd/conf-enabled/whateverfile.conf à la place.
En raison d'un problème connu avec Docker et libseccomp <2.5, vous pouvez rencontrer des problèmes sous 2022.04 et versions ultérieures sur les systèmes hôtes avec une ancienne version de libseccomp2 (telle que Debian/Raspbian buster ou Ubuntu 20.04, et peut-être CentOS 7).
La première recommandation est de mettre à niveau votre système d'exploitation hôte, qui inclura une version plus à jour (et corrigée) de libseccomp .
Si vous ne pouvez absolument pas faire cela, certains utilisateurs ont signalé avoir réussi à mettre à jour libseccomp2 via des rétroportages sur Debian, ou similaire via des mises à jour sur Ubuntu. Vous pouvez essayer cette solution de contournement à vos propres risques (Remarque, vous constaterez peut-être également que vous avez besoin de la dernière version docker.io (plus de détails ici)
Certains utilisateurs ont signalé des problèmes lors de l'utilisation de l'indicateur --privileged sur 2022.04 et versions ultérieures. TL;DR, n'utilisez pas ce mode et soyez plutôt explicite avec les majuscules autorisées (si nécessaire)
# More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/
services :
pihole :
container_name : pihole
image : pihole/pihole:latest
# For DHCP it is recommended to remove these ports and instead add: network_mode: "host"
ports :
- " 53:53/tcp "
- " 53:53/udp "
- " 67:67/udp " # Only required if you are using Pi-hole as your DHCP server
- " 80:80/tcp "
environment :
TZ : ' America/Chicago '
# WEBPASSWORD: 'set a secure password here or it will be random'
# Volumes store your data between container upgrades
volumes :
- ' ./etc-pihole:/etc/pihole '
- ' ./etc-dnsmasq.d:/etc/dnsmasq.d '
# https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
cap_add :
- NET_ADMIN # Required if you are using Pi-hole as your DHCP server, else not needed
restart : unless-stoppeddocker compose up -d pour créer et démarrer pi-hole (la syntaxe peut être docker-compose sur les anciens systèmes)bridge par défaut de Docker. (Cela peut également être réalisé en définissant la variable d'environnement DNSMASQ_LISTENING sur all )Voici un script d'exécution Docker équivalent.
Un projet Docker pour créer un conteneur x86 et ARM léger avec la fonctionnalité Pi-hole.
Ce conteneur utilise 2 ports populaires, le port 53 et le port 80, et peut donc entrer en conflit avec les ports d'applications existants . Si vous n'avez aucun autre service ou conteneur Docker utilisant le port 53/80 (si c'est le cas, continuez à lire ci-dessous pour un exemple de proxy inverse), les arguments minimaux requis pour exécuter ce conteneur se trouvent dans le script docker_run.sh
Si vous utilisez une distribution basée sur Red Hat avec une politique d'application SELinux, ajoutez :z pour aligner les volumes comme ceci :
-v "$(pwd)/etc-pihole:/etc/pihole:z"
-v "$(pwd)/etc-dnsmasq.d:/etc/dnsmasq.d:z"
Les volumes sont recommandés pour conserver les données dans les recréations de conteneurs afin de mettre à jour les images. Les variables de recherche IP peuvent ne pas fonctionner pour tout le monde, veuillez revoir leurs valeurs et coder en dur IP et IPv6 si nécessaire.
Vous pouvez personnaliser l'emplacement de stockage des données persistantes en définissant la variable d'environnement PIHOLE_BASE lors de l'appel docker_run.sh (par exemple PIHOLE_BASE=/opt/pihole-storage ./docker_run.sh ). Si PIHOLE_BASE n'est pas défini, les fichiers sont stockés dans votre répertoire actuel lorsque vous appelez le script.
Mises à jour automatiques de la liste d'annonces - depuis la version 3.0+, cron est intégré dans le conteneur et récupérera les versions les plus récentes de vos listes et videra vos journaux. Définissez votre variable d'environnement TZ pour vous assurer que la rotation du journal de minuit se synchronise avec minuit de votre fuseau horaire.
Il existe plusieurs façons différentes d'exécuter DHCP à partir de votre conteneur Docker Pi-hole, mais elle est légèrement plus avancée et une taille unique ne convient pas à tout le monde. Les multiples modes réseau de DHCP et Docker sont traités en détail sur notre site de documentation : Docker DHCP et modes réseau
Il existe d'autres variables d'environnement si vous souhaitez personnaliser diverses choses à l'intérieur du conteneur Docker :
| Variable | Défaut | Valeur | Description |
|---|---|---|---|
TZ | UTC | <Timezone> | Définissez votre fuseau horaire pour vous assurer que les journaux tournent à minuit local plutôt qu'à minuit UTC. |
WEBPASSWORD | aléatoire | <Admin password> | Mot de passe http://pi.hole/admin. Exécuter docker logs pihole | grep random pour trouver votre passe aléatoire. |
FTLCONF_LOCAL_IPV4 | désarmé | <Host's IP> | Définissez l'adresse IP LAN de votre serveur, utilisée par les modes de blocage Web. |
| Variable | Défaut | Valeur | Description |
|---|---|---|---|
PIHOLE_DNS_ | 8.8.8.8;8.8.4.4 | IP délimitées par ; | Serveur(s) DNS en amont vers lequel Pi-hole transmet les requêtes, séparés par un point-virgule (prend en charge les ports non standard avec #[port number] ) par exemple 127.0.0.1#5053;8.8.8.8;8.8.4.4(prend en charge les noms et liens de service Docker au lieu des adresses IP) par exemple, upstream0;upstream1 où upstream0 et upstream1 sont les noms de service ou les liens vers les services DockerRemarque : L'existence de cette variable d'environnement suppose qu'il s'agit de la seule gestion du DNS en amont. Le DNS en amont ajouté via l'interface Web sera écrasé lors du redémarrage/de la recréation du conteneur |
DNSSEC | false | <"true"|"false"> | Activer la prise en charge DNSSEC |
DNS_BOGUS_PRIV | true | <"true"|"false"> | Ne transférez jamais de recherches inversées pour des plages privées |
DNS_FQDN_REQUIRED | true | <"true"|"false"> | Ne transférez jamais de noms de domaine non FQDN |
REV_SERVER | false | <"true"|"false"> | Activer le transfert conditionnel DNS pour la résolution du nom de l'appareil |
REV_SERVER_DOMAIN | désarmé | Domaine réseau | Si le transfert conditionnel est activé, définissez le domaine du routeur du réseau local |
REV_SERVER_TARGET | désarmé | IP du routeur | Si le transfert conditionnel est activé, définissez l'adresse IP du routeur du réseau local |
REV_SERVER_CIDR | désarmé | DNS inversé | Si le transfert conditionnel est activé, définissez la zone DNS inversée (par exemple 192.168.0.0/24 ) |
DHCP_ACTIVE | false | <"true"|"false"> | Activez le serveur DHCP. Les baux DHCP statiques peuvent être configurés avec un /etc/dnsmasq.d/04-pihole-static-dhcp.conf personnalisé |
DHCP_START | désarmé | <Start IP> | Début de la plage d'adresses IP à distribuer par le serveur DHCP (obligatoire si le serveur DHCP est activé). |
DHCP_END | désarmé | <End IP> | Fin de la plage d'adresses IP à distribuer par le serveur DHCP (obligatoire si le serveur DHCP est activé). |
DHCP_ROUTER | désarmé | <Router's IP> | Adresse IP du routeur (passerelle) envoyée par le serveur DHCP (obligatoire si le serveur DHCP est activé). |
DHCP_LEASETIME | 24 | <hours> | Durée du bail DHCP en heures. |
PIHOLE_DOMAIN | lan | <domain> | Nom de domaine envoyé par le serveur DHCP. |
DHCP_IPv6 | false | <"true"|"false"> | Activez la prise en charge IPv6 du serveur DHCP (SLAAC + RA). |
DHCP_rapid_commit | false | <"true"|"false"> | Activez la validation rapide DHCPv4 (attribution d'adresse rapide). |
VIRTUAL_HOST | ${HOSTNAME} | <Custom Hostname> | Qu'est-ce que « l'hôte virtuel » de votre serveur Web, l'accès à l'administrateur via ce nom d'hôte/IP vous permet d'apporter des modifications à la liste blanche/liste noire en plus de l'adresse par défaut « http://pi.hole/admin/ » |
IPv6 | true | <"true"|"false"> | Pour une compatibilité sans raid, supprime toute la configuration IPv6 des services DNS/Web lorsqu'elle est fausse. |
TEMPERATUREUNIT | c | <c|k|f> | Réglez l’unité de température préférée sur c : Celsius, k : Kelvin ou f Fahrenheit. |
WEBUIBOXEDLAYOUT | boxed | <boxed|traditional> | Utiliser une mise en page en boîte (utile lorsque vous travaillez sur de grands écrans) |
QUERY_LOGGING | true | <"true"|"false"> | Activez ou non la journalisation des requêtes. |
WEBTHEME | default-light | <"default-dark"|"default-darker"|"default-light"|"default-auto"|"high-contrast"|"high-contrast-dark"|"lcars"> | Thème de l'interface utilisateur à utiliser. |
WEBPASSWORD_FILE | désarmé | <Docker secret path> | Définissez un mot de passe administrateur à l'aide des secrets Docker. Si WEBPASSWORD est défini, WEBPASSWORD_FILE est ignoré. Si WEBPASSWORD est vide et que WEBPASSWORD_FILE est défini sur un chemin de fichier lisible valide, alors WEBPASSWORD sera défini sur le contenu de WEBPASSWORD_FILE . |
| Variable | Défaut | Valeur | Description |
|---|---|---|---|
INTERFACE | désarmé | <NIC> | La valeur par défaut fonctionne bien avec nos exemples de commandes d'exécution Docker de base. Si vous essayez d'utiliser DHCP avec le mode --net host , vous devrez peut-être personnaliser ceci ou DNSMASQ_LISTENING. |
DNSMASQ_LISTENING | désarmé | <local|all|single> | local écoute sur tous les sous-réseaux locaux, all permet l'écoute sur les sous-réseaux d'origine Internet en plus des écoutes locales single uniquement sur l'interface spécifiée. |
WEB_PORT | désarmé | <PORT> | Cela brisera la fonctionnalité « page Web bloquée » de Pi-hole, mais cela peut aider les configurations avancées telles que celles exécutant Synology ou l'argument --net=host docker. Ce guide explique comment restaurer la fonctionnalité bloquée d'une page Web à l'aide d'une règle DNAT de routeur Linux : méthode d'installation alternative de Synology |
WEB_BIND_ADDR | désarmé | <IP> | Adresse de liaison de Lighttpd. S'il n'est pas défini, lighttpd se liera à chaque interface, sauf lors de l'exécution en mode réseau hôte où il utilisera FTLCONF_LOCAL_IPV4 à la place. |
SKIPGRAVITYONBOOT | désarmé | <unset|1> | Utilisez cette option pour ignorer la mise à jour de la base de données Gravity lors du démarrage du conteneur. Par défaut, cette variable d'environnement n'est pas définie, donc la base de données Gravity sera mise à jour au démarrage du conteneur. Définir cette variable d'environnement sur 1 (ou quoi que ce soit) entraînera la non mise à jour de la base de données Gravity au démarrage du conteneur. |
CORS_HOSTS | désarmé | <FQDNs delimited by ,> | Liste des domaines/sous-domaines sur lesquels CORS est autorisé. Les caractères génériques ne sont pas pris en charge. Par exemple : CORS_HOSTS: domain.com,home.domain.com,www.domain.com . |
CUSTOM_CACHE_SIZE | 10000 | Nombre | Définissez la taille du cache pour dnsmasq. Utile pour augmenter la taille du cache par défaut ou pour la définir à 0. Notez que lorsque DNSSEC est "true", alors ce paramètre est ignoré. |
FTL_CMD | no-daemon | no-daemon -- <dnsmasq option> | Personnalisez les options avec lesquelles dnsmasq démarre. par exemple no-daemon -- --dns-forward-max 300 pour augmenter le max. nombre de requêtes DNS simultanées sur les configurations à charge élevée. |
FTLCONF_[SETTING] | désarmé | Selon la documentation | Personnalisez pihole-FTL.conf avec les paramètres décrits dans la page de configuration FTLDNS. Par exemple, pour personnaliser LOCAL_IPV4, assurez-vous que la variable d'environnement FTLCONF_LOCAL_IPV4 est définie. |
| Variable | Défaut | Valeur | Description |
|---|---|---|---|
DNSMASQ_USER | désarmé | <pihole|root> | Permet de changer l'utilisateur sous lequel FTLDNS s'exécute. Par défaut : pihole , certains systèmes tels que Synology NAS peuvent vous demander de le changer en root (voir #963) |
PIHOLE_UID | 999 | Nombre | Remplace l'identifiant utilisateur pihole par défaut de l'image pour correspondre à un identifiant utilisateur hôte IMPORTANT : l'identifiant ne doit pas déjà être utilisé à l'intérieur du conteneur ! |
PIHOLE_GID | 999 | Nombre | Remplace l'identifiant de groupe pihole par défaut de l'image pour correspondre à un identifiant de groupe d'hôtes IMPORTANT : l'identifiant ne doit pas déjà être utilisé à l'intérieur du conteneur ! |
WEB_UID | 33 | Nombre | Remplace l'identifiant utilisateur www-data par défaut de l'image pour correspondre à un identifiant utilisateur hôte IMPORTANT : l'identifiant ne doit pas déjà être utilisé à l'intérieur du conteneur ! (Assurez-vous qu'il est différent de PIHOLE_UID si vous l'utilisez également) |
WEB_GID | 33 | Nombre | Remplace l'identifiant de groupe www-data par défaut de l'image pour correspondre à un identifiant de groupe d'hôtes IMPORTANT : l'identifiant ne doit pas déjà être utilisé à l'intérieur du conteneur ! (Assurez-vous qu'il est différent de PIHOLE_GID si vous l'utilisez également) |
WEBLOGS_STDOUT | 0 | 0|1 | 0 journaux vers les fichiers définis, 1 accès redirigé et journaux d'erreurs vers la sortie standard |
Bien que ceux-ci puissent toujours fonctionner, ils seront probablement supprimés dans une prochaine version. Le cas échéant, d'autres noms de variables sont indiqués. Veuillez consulter le tableau ci-dessus pour connaître l'utilisation des variables alternatives.
| Docker Environnement Var. | Description | Remplacé par |
|---|---|---|
CONDITIONAL_FORWARDING | Activer le transfert conditionnel DNS pour la résolution du nom de l'appareil | REV_SERVER |
CONDITIONAL_FORWARDING_IP | Si le transfert conditionnel est activé, définissez l'adresse IP du routeur du réseau local | REV_SERVER_TARGET |
CONDITIONAL_FORWARDING_DOMAIN | Si le transfert conditionnel est activé, définissez le domaine du routeur du réseau local | REV_SERVER_DOMAIN |
CONDITIONAL_FORWARDING_REVERSE | Si le transfert conditionnel est activé, définissez le DNS inversé du routeur du réseau local (par exemple 0.168.192.in-addr.arpa ) | REV_SERVER_CIDR |
DNS1 | Fournisseur DNS principal en amont, la valeur par défaut est Google DNS | PIHOLE_DNS_ |
DNS2 | Fournisseur DNS secondaire en amont, la valeur par défaut est Google DNS, no si un seul DNS doit être utilisé | PIHOLE_DNS_ |
ServerIP | Définissez l'adresse IP LAN de votre serveur, utilisée par les modes de blocage Web et l'adresse de liaison lighttpd | FTLCONF_LOCAL_IPV4 |
ServerIPv6 | Si vous disposez d'un réseau v6 configuré sur le réseau local IPv6 de votre serveur pour bloquer complètement les publicités IPv6 | FTLCONF_LOCAL_IPV6 |
FTLCONF_REPLY_ADDR4 | Définissez l'adresse IP LAN de votre serveur, utilisée par les modes de blocage Web et l'adresse de liaison lighttpd | FTLCONF_LOCAL_IPV4 |
FTLCONF_REPLY_ADDR6 | Si vous disposez d'un réseau v6 configuré sur le réseau local IPv6 de votre serveur pour bloquer complètement les publicités IPv6 | FTLCONF_LOCAL_IPV6 |
Pour utiliser ces variables d'environnement au format d'exécution Docker, stylez-les comme : -e DNS1=1.1.1.1
Voici un aperçu des autres arguments pour votre exécution docker-compose / docker.
| Arguments Dockers | Description |
|---|---|
-p <port>:<port> Recommandé | Ports à exposer (53, 80, 67), le strict minimum de ports requis pour les services HTTP et DNS Pi-holes |
--restart=unless-stoppedRecommandé | (re)démarrez automatiquement votre Pi-hole au démarrage ou en cas de crash |
-v $(pwd)/etc-pihole:/etc/piholeRecommandé | Les volumes pour vos configurations Pi-hole aident à conserver les modifications lors des mises à jour d'images Docker |
-v $(pwd)/etc-dnsmasq.d:/etc/dnsmasq.dRecommandé | Les volumes pour vos configurations Dnsmasq aident à conserver les modifications lors des mises à jour d'images Docker |
--net=hostFacultatif | Alternative aux arguments -p <port>:<port> (ne peut pas être utilisé en même temps que -p) si vous n'exécutez aucune autre application Web. DHCP fonctionne mieux avec --net=host, sinon votre routeur doit prendre en charge les paramètres DHCP-relay. |
--cap-add=NET_ADMINRecommandé | Capacité couramment ajoutée pour DHCP, voir la note sur les capacités ci-dessous pour d'autres fonctionnalités. |
--dns=127.0.0.1Facultatif | Définit les paramètres de résolution de votre conteneur sur localhost afin qu'il puisse résoudre les noms d'hôte DHCP à partir du DNSMasq de Pi-hole, et puisse corriger les erreurs de résolution au redémarrage du conteneur. |
--dns=1.1.1.1Facultatif | Définit un serveur de sauvegarde de votre choix au cas où DNSMasq aurait des problèmes de démarrage |
--env-file .envFacultatif | Fichier pour stocker les variables d'environnement pour Docker remplaçant les paramètres -e key=value . Ici pour plus de commodité |
docker exec -it pihole_container_name pihole -a -p - puis entrez votre mot de passe dans l'invite-p 8080:80 si vous utilisez le mode de blocage par défaut. Si vous utilisez l'ancien mode de blocage IP, vous ne devez pas remapper ce port.DEFAULT_HOST env dans nginxproxy/nginx-proxy et vous devez définir le VIRTUAL_HOST correspondant pour le conteneur du Pi-hole. Veuillez lire le fichier readme de nginxproxy/nginx-proxy pour plus d'informations si vous rencontrez des problèmes.bridge en mode réseau par défaut de Docker isole le conteneur du réseau de l'hôte. Il s'agit d'un paramètre plus sécurisé, mais nécessite de définir l'option DNS Pi-hole pour le comportement d'écoute de l'interface sur « Écouter sur toutes les interfaces, autoriser toutes les origines ». Les versions modernes d'Ubuntu (17.10+) et Fedora (33+) incluent systemd-resolved qui est configuré par défaut pour implémenter un résolveur de stub DNS de mise en cache. Cela empêchera pi-hole d'écouter sur le port 53. Le résolveur de stub doit être désactivé avec : sudo sed -r -i.orig 's/#?DNSStubListener=yes/DNSStubListener=no/g' /etc/systemd/resolved.conf
Cela ne modifiera pas les paramètres du serveur de noms, qui pointent vers le résolveur de stub, empêchant ainsi la résolution DNS. Modifiez le lien symbolique /etc/resolv.conf pour qu'il pointe vers /run/systemd/resolve/resolv.conf , qui est automatiquement mis à jour pour suivre le netplan du système : sudo sh -c 'rm /etc/resolv.conf && ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf' Après avoir effectué ces modifications, vous devez redémarrer systemd-resolved en utilisant systemctl restart systemd-resolved
Une fois pi-hole installé, vous souhaiterez configurer vos clients pour l'utiliser (voir ici). Si vous avez utilisé le lien symbolique ci-dessus, votre hôte Docker utilisera soit tout ce qui est servi par DHCP, soit le paramètre statique que vous avez configuré. Si vous souhaitez définir explicitement les serveurs de noms de votre hôte Docker, vous pouvez modifier le(s) plan(s) réseau trouvé(s) dans /etc/netplan , puis exécutez sudo netplan apply . Exemple de plan réseau :
network :
ethernets :
ens160 :
dhcp4 : true
dhcp4-overrides :
use-dns : false
nameservers :
addresses : [127.0.0.1]
version : 2 Notez qu'il est également possible de désactiver entièrement systemd-resolved . Cependant, cela peut entraîner des problèmes de résolution de noms dans les VPN (voir rapport de bug). Il désactive également la fonctionnalité de netplan puisque systemd-resolved est utilisé comme moteur de rendu par défaut (voir man netplan ). Si vous choisissez de désactiver le service, vous devrez définir manuellement les serveurs de noms, par exemple en créant un nouveau /etc/resolv.conf .
Les utilisateurs d'anciennes versions d'Ubuntu (vers 17.04) devront désactiver dnsmasq.
@ Rikj000 a produit un guide pour aider les utilisateurs à installer Pi-hole sur Dokku
Les balises Docker principales sont expliquées dans le tableau suivant. Cliquez ici pour voir la liste complète des balises. Consultez les notes de version de GitHub pour voir la version spécifique de Pi-hole Core, Web et FTL incluse dans la version.
Les versions basées sur la date (y compris les versions "Patch" incrémentées) ne se rapportent à aucun type de numéro de version sémantique, mais plutôt une date est utilisée pour différencier la nouvelle version de l'ancienne version, rien de plus. Les notes de version contiendront toujours tous les détails des modifications apportées au conteneur, y compris les modifications apportées aux composants principaux de Pi-hole.
| étiqueter | description |
|---|---|
latest | Toujours la dernière version |
2022.04.0 | Sortie basée sur la date |
2022.04.1 | Deuxième version dans un mois donné |
dev | Similaire à latest , mais pour la branche de développement (poussé occasionnellement) |
*beta | Premières versions bêta des versions à venir - voici les dragons |
nightly | Comme dev mais poussé tous les soirs et extrait des dernières branches development des composants de base de Pi-hole (Pi-hole, web, FTL) |
Les capacités de personnalisation standard de Pi-hole s'appliquent à ce docker, mais avec des fonctionnalités de docker telles que l'utilisation de montages de volume de docker pour mapper les configurations de fichiers stockés par l'hôte sur les valeurs par défaut du conteneur. Cependant, le montage de ces fichiers de configuration en lecture seule doit être évité. Les volumes sont également importants pour conserver la configuration au cas où vous auriez supprimé le conteneur Pi-hole, qui est un modèle de mise à niveau typique de Docker.
N'essayez pas de mettre à niveau ( pihole -up ) ou de reconfigurer ( pihole -r ). De nouvelles images seront publiées pour les mises à niveau, la mise à niveau en remplaçant votre ancien conteneur par une nouvelle image mise à niveau est la « méthode Docker ». Les conteneurs Docker de longue durée ne sont pas la solution Docker puisqu'ils visent à être portables et reproductibles, pourquoi ne pas les recréer souvent ! Juste pour prouver que vous le pouvez.
docker pull pihole/piholedocker rm -f piholedocker run <args> pihole/pihole ( <args> étant vos volumes d'exécution et variables d'environnement préférés)Pourquoi ce style de mise à niveau est-il bon ? Quelques raisons : tout le monde part de la même image de base qui a été testée pour savoir qu'elle fonctionne. Ne vous inquiétez pas de la mise à niveau de A vers B, de B vers C ou de A vers C lors du déploiement des mises à jour, cela réduit la complexité et permet simplement un « nouveau départ » à chaque fois tout en préservant les personnalisations avec les volumes. Fondamentalement, j'encourage les principes du serveur Phoenix pour vos conteneurs.
Pour reconfigurer Pi-hole, vous devrez soit utiliser des variables d'environnement de conteneur existantes, soit s'il n'y a pas de variable pour ce dont vous avez besoin, utiliser l'interface utilisateur Web ou les commandes CLI.
Voici quelques pages wiki pertinentes de la documentation de Pi-hole. L'interface Web ou les outils de ligne de commande peuvent être utilisés pour implémenter les modifications apportées à pihole.
Nous installons tous les utilitaires pihole afin que les commandes pihole intégrées fonctionnent via docker exec <container> <command> comme ceci :
docker exec pihole_container_name pihole updateGravitydocker exec pihole_container_name pihole -w spclient.wg.spotify.comdocker exec pihole_container_name pihole -wild example.com Le serveur Web et le service DNS à l'intérieur du conteneur peuvent être personnalisés si nécessaire. Tous les fichiers de configuration que vous montez en volume dans /etc/dnsmasq.d/ seront chargés par dnsmasq lorsque le conteneur démarre ou redémarre ou si vous devez modifier la configuration Pi-hole, il se trouve dans /etc/dnsmasq.d/01-pihole.conf . Les scripts de démarrage du Docker exécutent un test de configuration avant de démarrer afin de vous informer de toute erreur dans le journal du Docker.
De même pour le serveur Web, vous pouvez personnaliser les configurations dans /etc/lighttpd
Tant que votre service système Docker démarre automatiquement au démarrage et que vous exécutez votre conteneur avec --restart=unless-stopped votre conteneur doit toujours démarrer au démarrage et redémarrer en cas de panne. Si vous préférez que votre conteneur Docker s'exécute en tant que service systemd, ajoutez le fichier pihole.service à "/etc/systemd/system" ; personnalisez le nom de votre conteneur et supprimez --restart=unless-stopped de votre exécution de Docker. Ensuite, après avoir initialement créé le conteneur Docker à l'aide de la commande docker run ci-dessus, vous pouvez le contrôler avec "systemctl start pihole" ou "systemctl stop pihole" (au lieu de docker start / docker stop ). Vous pouvez également lui permettre de démarrer automatiquement au démarrage avec "systemctl activate pihole" (par opposition à --restart=unless-stopped et en vous assurant que le service Docker démarre automatiquement au démarrage).
REMARQUE : après l'exécution initiale, vous devrez peut-être arrêter manuellement le conteneur Docker avec "docker stop pihole" avant que systemctl puisse commencer à contrôler le conteneur.
DNSMasq / FTLDNS s'attend à disposer des fonctionnalités suivantes :
CAP_NET_BIND_SERVICE : Permet la liaison FTLDNS aux sockets TCP/UDP inférieurs à 1024 (en particulier le service DNS sur le port 53)CAP_NET_RAW : utiliser des sockets bruts et paquets (nécessaires pour gérer les requêtes DHCPv6 et vérifier qu'une IP n'est pas utilisée avant de la louer)CAP_NET_ADMIN : modifier les tables de routage et autres opérations liées au réseau (notamment insérer une entrée dans la table des voisins pour répondre aux requêtes DHCP à l'aide de paquets unicast)CAP_SYS_NICE : FTL se définit comme un processus important pour obtenir un peu plus de temps de traitement si ce dernier est faibleCAP_CHOWN : nous devons pouvoir changer la propriété des fichiers journaux et des bases de données au cas où FTL serait démarré en tant qu'utilisateur différent de pihole Cette image accorde automatiquement ces fonctionnalités, si disponibles, au processus FTLDNS, même lorsqu'il est exécuté en tant que non root.
Par défaut, docker n'inclut pas la fonctionnalité NET_ADMIN pour les conteneurs non privilégiés, et il est recommandé de l'ajouter explicitement au conteneur en utilisant --cap-add=NET_ADMIN .
Cependant, si les publicités de routeur DHCP et IPv6 ne sont pas utilisées, vous pouvez les ignorer en toute sécurité. Pour les plus paranoïaques, il devrait même être possible de supprimer explicitement la fonctionnalité NET_RAW pour empêcher FTLDNS de l'obtenir automatiquement.
Nous avons remarqué que beaucoup de gens utilisent Watchtower pour maintenir à jour leurs conteneurs Pi-hole. Pour la même raison que nous ne proposons pas de fonctionnalité de mise à jour automatique sur une installation nue, vous ne devriez pas avoir de système mettant automatiquement à jour votre conteneur Pi-hole. Surtout sans surveillance. Même si nous essayons de nous assurer que tout se passe bien, il arrive parfois que les choses tournent mal - et vous devez prévoir du temps pour extraire et mettre à jour manuellement la version du conteneur que vous souhaitez exécuter. Le processus de mise à niveau doit suivre le modèle suivant :
Pi-hole fait partie intégrante de votre réseau, ne le laissez pas tomber à cause d'une mise à jour inopinée en pleine nuit.
Veuillez signaler les problèmes sur le projet GitHub lorsque vous soupçonnez quelque chose lié à Docker. Il est préférable de répondre aux questions Pi-hole ou générales sur les dockers sur nos forums d'utilisateurs.
