docker pi hole
2024.07.0
Wachtturm nutzen? Siehe den Hinweis zum Wachtturm am Ende dieser Readme-Datei
Wenn Sie ab 2023.01 Änderungen für lighttpd über eine external.conf -Datei vornehmen, muss diese Datei nun stattdessen in /etc/lighttpd/conf-enabled/whateverfile.conf zugeordnet werden
Aufgrund eines bekannten Problems mit Docker und libseccomp <2.5 können beim Ausführen 2022.04 und höher auf Hostsystemen mit einer älteren Version von libseccomp2 (z. B. Debian/Raspbian Buster oder Ubuntu 20.04 und möglicherweise CentOS 7) Probleme auftreten.
Die erste Empfehlung besteht darin, Ihr Host-Betriebssystem zu aktualisieren, das eine aktuellere (und korrigierte) Version von libseccomp enthält.
Wenn Sie dies absolut nicht tun können, haben einige Benutzer von Erfolgen bei der Aktualisierung libseccomp2 über Backports unter Debian oder ähnlichem über Updates unter Ubuntu berichtet. Sie können diese Problemumgehung auf eigenes Risiko ausprobieren (Beachten Sie, dass Sie möglicherweise auch die neueste Version docker.io benötigen (weitere Details finden Sie hier).
Einige Benutzer haben Probleme mit der Verwendung des Flags --privileged in 2022.04 und höher gemeldet. TL;DR, verwenden Sie diesen Modus nicht und verwenden Sie stattdessen explizit die zulässigen Großbuchstaben (falls erforderlich).
# 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 aus, um Pi-Hole zu erstellen und zu starten (Syntax kann auf älteren Systemen docker-compose sein)bridge -Netzwerkeinstellung von Docker verwenden. (Dies kann auch erreicht werden, indem die Umgebungsvariable DNSMASQ_LISTENING auf all gesetzt wird)Hier ist ein entsprechendes Docker-Ausführungsskript.
Ein Docker-Projekt zur Erstellung eines leichten x86- und ARM-Containers mit Pi-Hole-Funktionalität.
Dieser Container verwendet zwei gängige Ports, Port 53 und Port 80, daher kann es zu Konflikten mit vorhandenen Anwendungsports kommen . Wenn Sie keine anderen Dienste oder Docker-Container haben, die Port 53/80 verwenden (wenn ja, lesen Sie weiter unten für ein Reverse-Proxy-Beispiel), sind die zum Ausführen dieses Containers mindestens erforderlichen Argumente im Skript docker_run.sh
Wenn Sie eine Red Hat-basierte Distribution mit einer SELinux Enforcing-Richtlinie verwenden, fügen Sie :z hinzu, um die Volumes wie folgt auszurichten:
-v "$(pwd)/etc-pihole:/etc/pihole:z"
-v "$(pwd)/etc-dnsmasq.d:/etc/dnsmasq.d:z"
Volumes werden zum Beibehalten von Daten über Containerneuerstellungen hinweg zum Aktualisieren von Bildern empfohlen. Die IP-Suchvariablen funktionieren möglicherweise nicht für alle. Bitte überprüfen Sie ihre Werte und codieren Sie IP und IPv6 bei Bedarf fest.
Sie können anpassen, wo persistente Daten gespeichert werden sollen, indem Sie beim Aufruf von docker_run.sh die Umgebungsvariable PIHOLE_BASE festlegen (z. B. PIHOLE_BASE=/opt/pihole-storage ./docker_run.sh ). Wenn PIHOLE_BASE nicht festgelegt ist, werden Dateien in Ihrem aktuellen Verzeichnis gespeichert, wenn Sie das Skript aufrufen.
Automatische Anzeigenlisten-Updates – seit der Version 3.0+ ist cron in den Container integriert und greift auf die neuesten Versionen Ihrer Listen zu und leert Ihre Protokolle. Legen Sie Ihre TZ-Umgebungsvariable fest , um sicherzustellen, dass die Protokollrotation um Mitternacht mit der Mitternacht Ihrer Zeitzone synchronisiert wird.
Es gibt mehrere verschiedene Möglichkeiten, DHCP in Ihrem Docker Pi-Hole-Container auszuführen, aber es ist etwas fortgeschrittener und es gibt keine Einheitslösung, die für alle passt. Die verschiedenen Netzwerkmodi von DHCP und Docker werden ausführlich auf unserer Dokumentationsseite behandelt: Docker DHCP und Netzwerkmodi
Es gibt weitere Umgebungsvariablen, wenn Sie verschiedene Dinge im Docker-Container anpassen möchten:
| Variable | Standard | Wert | Beschreibung |
|---|---|---|---|
TZ | koordinierte Weltzeit | <Timezone> | Legen Sie Ihre Zeitzone fest, um sicherzustellen, dass die Protokolle um Mitternacht vor Ort und nicht um Mitternacht in UTC rotieren. |
WEBPASSWORD | zufällig | <Admin password> | http://pi.hole/admin-Passwort. Führen Sie docker logs pihole | grep random aus docker logs pihole | grep random um Ihren zufälligen Pass zu finden. |
FTLCONF_LOCAL_IPV4 | nicht gesetzt | <Host's IP> | Stellen Sie die LAN-IP Ihres Servers ein, die von den Webblockierungsmodi verwendet wird. |
| Variable | Standard | Wert | Beschreibung |
|---|---|---|---|
PIHOLE_DNS_ | 8.8.8.8;8.8.4.4 | IPs getrennt durch ; | Upstream-DNS-Server, an die Pi-hole Anfragen weiterleiten soll, getrennt durch ein Semikolon (unterstützt nicht standardmäßige Ports mit #[port number] ), z. B. 127.0.0.1#5053;8.8.8.8;8.8.4.4(unterstützt Docker-Dienstnamen und -Links anstelle von IPs) z. B. upstream0;upstream1 wobei upstream0 und upstream1 die Dienstnamen oder Links zu Docker-Diensten sindHinweis: Das Vorhandensein dieser Umgebungsvariablen geht davon aus, dass es sich hierbei um die alleinige Verwaltung des Upstream-DNS handelt. Über die Webschnittstelle hinzugefügtes Upstream-DNS wird beim Neustart/Neuerstellung des Containers überschrieben |
DNSSEC | false | <"true"|"false"> | Aktivieren Sie die DNSSEC-Unterstützung |
DNS_BOGUS_PRIV | true | <"true"|"false"> | Leiten Sie niemals Reverse-Lookups für private Bereiche weiter |
DNS_FQDN_REQUIRED | true | <"true"|"false"> | Leiten Sie niemals Nicht-FQDNs weiter |
REV_SERVER | false | <"true"|"false"> | Aktivieren Sie die bedingte DNS-Weiterleitung für die Auflösung von Gerätenamen |
REV_SERVER_DOMAIN | nicht gesetzt | Netzwerkdomäne | Wenn die bedingte Weiterleitung aktiviert ist, legen Sie die Domäne des lokalen Netzwerkrouters fest |
REV_SERVER_TARGET | nicht gesetzt | IP des Routers | Wenn die bedingte Weiterleitung aktiviert ist, legen Sie die IP des lokalen Netzwerkrouters fest |
REV_SERVER_CIDR | nicht gesetzt | Reverse-DNS | Wenn die bedingte Weiterleitung aktiviert ist, legen Sie die Reverse-DNS-Zone fest (z. B. 192.168.0.0/24 ). |
DHCP_ACTIVE | false | <"true"|"false"> | Aktivieren Sie den DHCP-Server. Statische DHCP-Leases können mit einer benutzerdefinierten /etc/dnsmasq.d/04-pihole-static-dhcp.conf konfiguriert werden |
DHCP_START | nicht gesetzt | <Start IP> | Beginn des Bereichs der vom DHCP-Server zu vergebenden IP-Adressen (obligatorisch, wenn der DHCP-Server aktiviert ist). |
DHCP_END | nicht gesetzt | <End IP> | Ende des Bereichs der vom DHCP-Server zu vergebenden IP-Adressen (obligatorisch, wenn der DHCP-Server aktiviert ist). |
DHCP_ROUTER | nicht gesetzt | <Router's IP> | Vom DHCP-Server gesendete IP-Adresse des Routers (Gateways) (obligatorisch, wenn der DHCP-Server aktiviert ist). |
DHCP_LEASETIME | 24 | <hours> | DHCP-Lease-Zeit in Stunden. |
PIHOLE_DOMAIN | lan | <domain> | Vom DHCP-Server gesendeter Domänenname. |
DHCP_IPv6 | false | <"true"|"false"> | Aktivieren Sie die IPv6-Unterstützung des DHCP-Servers (SLAAC + RA). |
DHCP_rapid_commit | false | <"true"|"false"> | Aktivieren Sie DHCPv4 Rapid Commit (schnelle Adresszuweisung). |
VIRTUAL_HOST | ${HOSTNAME} | <Custom Hostname> | Was auch immer der „virtuelle Host“ Ihres Webservers ist: Wenn Sie über diesen Hostnamen/diese IP-Adresse auf den Administrator zugreifen, können Sie zusätzlich zur Standardadresse „http://pi.hole/admin/“ Änderungen an der Whitelist/Blacklist vornehmen |
IPv6 | true | <"true"|"false"> | Aus Gründen der Unraid-Kompatibilität wird bei „false“ die gesamte IPv6-Konfiguration aus DNS/Webdiensten entfernt. |
TEMPERATUREUNIT | c | <c|k|f> | Stellen Sie die bevorzugte Temperatureinheit auf c : Celsius, k : Kelvin oder f Fahrenheit ein. |
WEBUIBOXEDLAYOUT | boxed | <boxed|traditional> | Verwenden Sie ein Box-Layout (hilfreich beim Arbeiten auf großen Bildschirmen) |
QUERY_LOGGING | true | <"true"|"false"> | Aktivieren Sie die Abfrageprotokollierung oder nicht. |
WEBTHEME | default-light | <"default-dark"|"default-darker"|"default-light"|"default-auto"|"high-contrast"|"high-contrast-dark"|"lcars"> | Zu verwendendes Benutzeroberflächenthema. |
WEBPASSWORD_FILE | nicht gesetzt | <Docker secret path> | Legen Sie mithilfe von Docker-Geheimnissen ein Administratorkennwort fest. Wenn WEBPASSWORD festgelegt ist, wird WEBPASSWORD_FILE ignoriert. Wenn WEBPASSWORD leer ist und WEBPASSWORD_FILE auf einen gültigen lesbaren Dateipfad gesetzt ist, wird WEBPASSWORD auf den Inhalt von WEBPASSWORD_FILE gesetzt. |
| Variable | Standard | Wert | Beschreibung |
|---|---|---|---|
INTERFACE | nicht gesetzt | <NIC> | Die Standardeinstellung funktioniert gut mit unseren einfachen Docker-Run-Beispielbefehlen. Wenn Sie versuchen, DHCP mit --net host zu verwenden, müssen Sie diesen oder DNSMASQ_LISTENING möglicherweise anpassen. |
DNSMASQ_LISTENING | nicht gesetzt | <local|all|single> | local lauscht auf allen lokalen Subnetzen, all ermöglichen das Abhören auf Internet-Ursprungssubnetzen zusätzlich zu lokalen, single Lauschvorgängen nur auf der angegebenen Schnittstelle. |
WEB_PORT | nicht gesetzt | <PORT> | Dadurch wird die Funktion „Webseite blockiert“ von Pi-hole unterbrochen, es kann jedoch bei erweiterten Setups hilfreich sein, z. B. bei denen, auf denen Synology oder das Docker-Argument --net=host ausgeführt wird. In dieser Anleitung wird erläutert, wie Sie die Funktionalität blockierter Webseiten mithilfe einer DNAT-Regel eines Linux-Routers wiederherstellen: Alternative Synology-Installationsmethode |
WEB_BIND_ADDR | nicht gesetzt | <IP> | Die Bindungsadresse von Lighttpd. Wenn nicht festgelegt, bindet sich lighttpd an jede Schnittstelle, außer bei Ausführung im Host-Netzwerkmodus, wo stattdessen FTLCONF_LOCAL_IPV4 verwendet wird. |
SKIPGRAVITYONBOOT | nicht gesetzt | <unset|1> | Verwenden Sie diese Option, um die Aktualisierung der Gravity-Datenbank beim Hochfahren des Containers zu überspringen. Standardmäßig ist diese Umgebungsvariable nicht festgelegt, sodass die Gravity-Datenbank beim Starten des Containers aktualisiert wird. Wenn Sie diese Umgebungsvariable auf 1 (oder einen anderen Wert) setzen, wird die Gravity-Datenbank beim Starten des Containers nicht aktualisiert. |
CORS_HOSTS | nicht gesetzt | <FQDNs delimited by ,> | Liste der Domänen/Subdomänen, auf denen CORS zulässig ist. Platzhalter werden nicht unterstützt. Beispiel: CORS_HOSTS: domain.com,home.domain.com,www.domain.com . |
CUSTOM_CACHE_SIZE | 10000 | Nummer | Legen Sie die Cachegröße für dnsmasq fest. Nützlich, um die Standard-Cache-Größe zu erhöhen oder auf 0 zu setzen. Beachten Sie, dass diese Einstellung ignoriert wird, wenn DNSSEC „true“ ist. |
FTL_CMD | no-daemon | no-daemon -- <dnsmasq option> | Passen Sie die Optionen an, mit denen dnsmasq gestartet wird. zB no-daemon -- --dns-forward-max 300 um max. zu erhöhen. Anzahl gleichzeitiger DNS-Abfragen bei Hochlast-Setups. |
FTLCONF_[SETTING] | nicht gesetzt | Laut Dokumentation | Passen Sie pihole-FTL.conf mit den auf der FTLDNS-Konfigurationsseite beschriebenen Einstellungen an. Um beispielsweise LOCAL_IPV4 anzupassen, stellen Sie sicher, dass die Umgebungsvariable FTLCONF_LOCAL_IPV4 festgelegt ist. |
| Variable | Standard | Wert | Beschreibung |
|---|---|---|---|
DNSMASQ_USER | nicht gesetzt | <pihole|root> | Ermöglicht das Ändern des Benutzers, unter dem FTLDNS ausgeführt wird. Standard: pihole , einige Systeme wie Synology NAS erfordern möglicherweise, dass Sie dies auf root ändern (siehe Nr. 963). |
PIHOLE_UID | 999 | Nummer | Überschreibt die Standard-Pihole-Benutzer-ID des Bildes, um sie an eine Host-Benutzer-ID anzupassen WICHTIG : ID darf nicht bereits im Container verwendet werden! |
PIHOLE_GID | 999 | Nummer | Überschreibt die Standard-Pihole-Gruppen-ID des Bildes, um sie an eine Host-Gruppen-ID anzupassen WICHTIG : ID darf nicht bereits im Container verwendet werden! |
WEB_UID | 33 | Nummer | Überschreibt die Standard-WWW-Data-Benutzer-ID des Bilds, damit sie mit einer Host-Benutzer-ID übereinstimmt WICHTIG : ID darf nicht bereits im Container verwendet werden! (Stellen Sie sicher, dass es sich auch von PIHOLE_UID unterscheidet, wenn Sie es verwenden.) |
WEB_GID | 33 | Nummer | Überschreibt die Standard-WWW-Data-Gruppen-ID des Bildes, damit sie mit einer Host-Gruppen-ID übereinstimmt WICHTIG : ID darf nicht bereits im Container verwendet werden! (Stellen Sie sicher, dass es sich auch von PIHOLE_GID unterscheidet, wenn Sie es verwenden.) |
WEBLOGS_STDOUT | 0 | 0|1 | 0 Protokolle zu definierten Dateien, 1 Umleitungszugriff und Fehlerprotokolle zu stdout |
Auch wenn diese möglicherweise noch funktionieren, werden sie wahrscheinlich in einer zukünftigen Version entfernt. Gegebenenfalls werden alternative Variablennamen angegeben. Bitte überprüfen Sie die obige Tabelle zur Verwendung der alternativen Variablen
| Docker-Umgebungsvariante. | Beschreibung | Ersetzt durch |
|---|---|---|
CONDITIONAL_FORWARDING | Aktivieren Sie die bedingte DNS-Weiterleitung für die Auflösung von Gerätenamen | REV_SERVER |
CONDITIONAL_FORWARDING_IP | Wenn die bedingte Weiterleitung aktiviert ist, legen Sie die IP des lokalen Netzwerkrouters fest | REV_SERVER_TARGET |
CONDITIONAL_FORWARDING_DOMAIN | Wenn die bedingte Weiterleitung aktiviert ist, legen Sie die Domäne des lokalen Netzwerkrouters fest | REV_SERVER_DOMAIN |
CONDITIONAL_FORWARDING_REVERSE | Wenn die bedingte Weiterleitung aktiviert ist, legen Sie den Reverse-DNS des lokalen Netzwerkrouters fest (z. B. 0.168.192.in-addr.arpa ). | REV_SERVER_CIDR |
DNS1 | Primärer Upstream-DNS-Anbieter, Standard ist Google DNS | PIHOLE_DNS_ |
DNS2 | Sekundärer Upstream-DNS-Anbieter, Standard ist Google DNS, no , wenn nur ein DNS verwendet werden soll | PIHOLE_DNS_ |
ServerIP | Stellen Sie die LAN-IP Ihres Servers ein, die von den Webblockierungsmodi und der Lighttpd-Bindungsadresse verwendet wird | FTLCONF_LOCAL_IPV4 |
ServerIPv6 | Wenn Sie ein v6-Netzwerk haben, ist das LAN Ihres Servers auf IPv6 eingestellt, um IPv6-Werbung vollständig zu blockieren | FTLCONF_LOCAL_IPV6 |
FTLCONF_REPLY_ADDR4 | Stellen Sie die LAN-IP Ihres Servers ein, die von den Webblockierungsmodi und der Lighttpd-Bindungsadresse verwendet wird | FTLCONF_LOCAL_IPV4 |
FTLCONF_REPLY_ADDR6 | Wenn Sie ein v6-Netzwerk haben, ist das LAN Ihres Servers auf IPv6 eingestellt, um IPv6-Werbung vollständig zu blockieren | FTLCONF_LOCAL_IPV6 |
Um diese Umgebungsvariablen im Docker-Run-Format zu verwenden, formatieren Sie sie wie folgt: -e DNS1=1.1.1.1
Hier ist eine Übersicht über weitere Argumente für Ihren Docker-Compose/Docker-Lauf.
| Docker-Argumente | Beschreibung |
|---|---|
-p <port>:<port> Empfohlen | Offenzulegende Ports (53, 80, 67), die unbedingt erforderlichen Ports für Pi-holes HTTP- und DNS-Dienste |
--restart=unless-stoppedEmpfohlen | Starten Sie Ihr Pi-hole beim Booten oder im Falle eines Absturzes automatisch (neu). |
-v $(pwd)/etc-pihole:/etc/piholeEmpfohlen | Volumes für Ihre Pi-Hole-Konfigurationen helfen dabei, Änderungen über Docker-Image-Updates hinweg beizubehalten |
-v $(pwd)/etc-dnsmasq.d:/etc/dnsmasq.dEmpfohlen | Volumes für Ihre dnsmasq-Konfigurationen helfen dabei, Änderungen über Docker-Image-Updates hinweg beizubehalten |
--net=hostOptional | Alternative zu -p <port>:<port> -Argumente (kann nicht gleichzeitig mit -p verwendet werden), wenn Sie keine andere Webanwendung ausführen. DHCP läuft am besten mit --net=host, andernfalls muss Ihr Router DHCP-Relay-Einstellungen unterstützen. |
--cap-add=NET_ADMINEmpfohlen | Häufig hinzugefügte Funktion für DHCP. Weitere Funktionen finden Sie im Hinweis zu den Funktionen weiter unten. |
--dns=127.0.0.1Optional | Setzt die Auflösungseinstellungen Ihres Containers auf „localhost“, damit er DHCP-Hostnamen aus Pi-holes DNSMasq auflösen kann. Möglicherweise werden Auflösungsfehler beim Neustart des Containers behoben. |
--dns=1.1.1.1Optional | Legt einen Backup-Server Ihrer Wahl fest, falls DNSMasq Probleme beim Starten hat |
--env-file .envOptional | Datei zum Speichern von Umgebungsvariablen für Docker, die die Einstellungen -e key=value ersetzen. Hier der Einfachheit halber |
docker exec -it pihole_container_name pihole -a -p – geben Sie dann Ihr Passwort in die Eingabeaufforderung ein-p 8080:80 , wenn Sie den Standardblockierungsmodus verwenden. Wenn Sie den alten IP-Blockierungsmodus verwenden, sollten Sie diesen Port nicht neu zuordnen.DEFAULT_HOST env in nginxproxy/nginx-proxy sein und Sie müssen den passenden VIRTUAL_HOST für den Pi-hole-Container festlegen. Bitte lesen Sie die Readme-Datei zu nginxproxy/nginx-proxy für weitere Informationen, wenn Sie Probleme haben.bridge von Docker isoliert den Container vom Netzwerk des Hosts. Dies ist eine sicherere Einstellung, erfordert jedoch die Einstellung der Pi-hole-DNS-Option für das Schnittstellen-Abhörverhalten auf „Auf allen Schnittstellen abhören, alle Ursprünge zulassen“. Moderne Versionen von Ubuntu (17.10+) und Fedora (33+) enthalten systemd-resolved , das standardmäßig für die Implementierung eines Caching-DNS-Stub-Resolvers konfiguriert ist. Dadurch wird verhindert, dass Pi-Hole Port 53 überwacht. Der Stub-Resolver sollte deaktiviert werden mit: sudo sed -r -i.orig 's/#?DNSStubListener=yes/DNSStubListener=no/g' /etc/systemd/resolved.conf
Dadurch werden die Nameserver-Einstellungen nicht geändert, die auf den Stub-Resolver verweisen und somit die DNS-Auflösung verhindern. Ändern Sie den /etc/resolv.conf so, dass er auf /run/systemd/resolve/resolv.conf zeigt, das automatisch aktualisiert wird, um dem netplan des Systems zu folgen: sudo sh -c 'rm /etc/resolv.conf && ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf' Nachdem Sie diese Änderungen vorgenommen haben, sollten Sie systemd-resolved mit systemctl restart systemd-resolved neu starten systemctl restart systemd-resolved
Sobald Pi-Hole installiert ist, möchten Sie Ihre Clients für die Verwendung konfigurieren (siehe hier). Wenn Sie den oben genannten Symlink verwendet haben, verwendet Ihr Docker-Host entweder das, was von DHCP bereitgestellt wird, oder die von Ihnen konfigurierte statische Einstellung. Wenn Sie die Nameserver Ihres Docker-Hosts explizit festlegen möchten, können Sie die unter /etc/netplan gefundenen Netzpläne bearbeiten und dann sudo netplan apply ausführen. Beispielnetzplan:
network :
ethernets :
ens160 :
dhcp4 : true
dhcp4-overrides :
use-dns : false
nameservers :
addresses : [127.0.0.1]
version : 2 Beachten Sie, dass es auch möglich ist systemd-resolved vollständig zu deaktivieren. Dies kann jedoch zu Problemen bei der Namensauflösung in VPNs führen (siehe Fehlerbericht). Es deaktiviert auch die Funktionalität von Netplan, da systemd-resolved als Standard-Renderer verwendet wird (siehe man netplan ). Wenn Sie den Dienst deaktivieren möchten, müssen Sie die Nameserver manuell festlegen, indem Sie beispielsweise eine neue /etc/resolv.conf erstellen.
Benutzer älterer Ubuntu-Versionen (ca. 17.04) müssen dnsmasq deaktivieren.
@Rikj000 hat eine Anleitung erstellt, die Benutzern bei der Installation von Pi-hole auf Dokku hilft
Die primären Docker-Tags werden in der folgenden Tabelle erläutert. Klicken Sie hier, um die vollständige Liste der Tags anzuzeigen. In den GitHub-Versionshinweisen finden Sie die spezifische Version von Pi-hole Core, Web und FTL, die in der Version enthalten ist.
Die datumsbasierten Versionen (einschließlich inkrementierter „Patch“-Versionen) beziehen sich nicht auf irgendeine semantische Versionsnummer, sondern es wird ein Datum verwendet, um zwischen der neuen Version und der alten Version zu unterscheiden, mehr nicht. Versionshinweise enthalten immer vollständige Details zu Änderungen im Container, einschließlich Änderungen an den Kernkomponenten von Pi-hole
| Etikett | Beschreibung |
|---|---|
latest | Immer neueste Version |
2022.04.0 | Datumsbasierte Veröffentlichung |
2022.04.1 | Zweite Veröffentlichung in einem bestimmten Monat |
dev | Ähnlich wie latest , aber für den Entwicklungszweig (gelegentlich gepusht) |
*beta | Frühe Beta-Veröffentlichungen kommender Versionen – hier sind Drachen |
nightly | Wie dev , aber jede Nacht gepusht und greift auf die neuesten development der Pi-Hole-Kernkomponenten zurück (Pi-Hole, Web, FTL). |
Für diesen Docker gelten die standardmäßigen Pi-Hole-Anpassungsfunktionen, jedoch mit Docker-Änderungen wie der Verwendung von Docker-Volume-Mounts, um auf dem Host gespeicherte Dateikonfigurationen den Container-Standardeinstellungen zuzuordnen. Es sollte jedoch vermieden werden, diese Konfigurationsdateien schreibgeschützt bereitzustellen. Volumes sind auch wichtig, um die Konfiguration beizubehalten, falls Sie den Pi-Hole-Container entfernt haben, was ein typisches Docker-Upgrade-Muster ist.
Versuchen Sie nicht, ein Upgrade durchzuführen ( pihole -up ) oder neu zu konfigurieren ( pihole -r ). Neue Images werden für Upgrades freigegeben. Das Upgrade durch Ersetzen Ihres alten Containers durch ein neues, aktualisiertes Image erfolgt auf die „Docker-Methode“. Langlebige Docker-Container sind nicht die Docker-Methode, da sie darauf abzielen, tragbar und reproduzierbar zu sein. Warum also nicht oft neu erstellen? Nur um zu beweisen, dass du es kannst.
docker pull pihole/piholedocker rm -f piholedocker run <args> pihole/pihole (wobei <args> Ihre bevorzugten Ausführungsvolumes und Umgebungsvariablen sind)Warum ist diese Art des Upgrades gut? Ein paar Gründe: Jeder geht von demselben Basis-Image aus, das getestet wurde, um sicherzustellen, dass es funktioniert. Bei der Einführung von Updates müssen Sie sich keine Gedanken über ein Upgrade von A auf B, B auf C oder A auf C machen, es reduziert die Komplexität und ermöglicht einfach jedes Mal einen „Neuanfang“, während Anpassungen mit Volumes erhalten bleiben. Grundsätzlich empfehle ich die Phoenix-Server-Prinzipien für Ihre Container.
Um Pi-hole neu zu konfigurieren, müssen Sie entweder eine vorhandene Container-Umgebungsvariable verwenden oder, falls keine Variable für das, was Sie benötigen, vorhanden ist, die Web-Benutzeroberfläche oder CLI-Befehle verwenden.
Hier sind einige relevante Wiki-Seiten aus der Dokumentation von Pi-hole. Um Änderungen an Pihole umzusetzen, können das Webinterface oder Kommandozeilentools genutzt werden.
Wir installieren alle Pihole-Dienstprogramme, damit die integrierten Pihole-Befehle über docker exec <container> <command> wie folgt funktionieren:
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 Der Webserver und der DNS-Dienst im Container können bei Bedarf angepasst werden. Alle Konfigurationsdateien, die Sie per Volume in /etc/dnsmasq.d/ bereitstellen, werden von dnsmasq geladen, wenn der Container startet oder neu startet. Wenn Sie die Pi-hole-Konfiguration ändern müssen, befindet sie sich unter /etc/dnsmasq.d/01-pihole.conf . Die Docker-Startskripte führen vor dem Start einen Konfigurationstest durch, damit Sie über etwaige Fehler im Docker-Protokoll informiert werden.
Ebenso können Sie für den Webserver die Konfigurationen in /etc/lighttpd anpassen
Solange Ihr Docker-Systemdienst beim Booten automatisch startet und Sie Ihren Container mit --restart=unless-stopped ausführen, sollte Ihr Container immer beim Booten starten und bei Abstürzen neu starten. Wenn Sie Ihren Docker-Container lieber als systemd-Dienst ausführen möchten, fügen Sie die Datei pihole.service zu „/etc/systemd/system“ hinzu; Passen Sie den Namen Ihres Containers an und entfernen Sie --restart=unless-stopped aus Ihrem Docker-Lauf. Nachdem Sie den Docker-Container zunächst mit dem oben genannten Docker-Run-Befehl erstellt haben, können Sie ihn mit „systemctl start pihole“ oder „systemctl stop pihole“ (anstelle von docker start / docker stop ) steuern. Sie können den automatischen Start beim Booten auch mit „systemctl enable pihole“ aktivieren (im Gegensatz zu --restart=unless-stopped und sicherstellen, dass der Docker-Dienst beim Booten automatisch startet).
HINWEIS: Nach der ersten Ausführung müssen Sie den Docker-Container möglicherweise manuell mit „docker stop pihole“ stoppen, bevor systemctl mit der Steuerung des Containers beginnen kann.
DNSMasq/FTLDNS erwartet, dass die folgenden Funktionen verfügbar sind:
CAP_NET_BIND_SERVICE : Ermöglicht die FTLDNS-Bindung an TCP/UDP-Sockets unter 1024 (insbesondere DNS-Dienst auf Port 53)CAP_NET_RAW : Raw- und Paket-Sockets verwenden (erforderlich für die Bearbeitung von DHCPv6-Anfragen und zur Überprüfung, ob eine IP nicht verwendet wird, bevor sie vermietet wird)CAP_NET_ADMIN : Ändern von Routing-Tabellen und anderen netzwerkbezogenen Vorgängen (insbesondere Einfügen eines Eintrags in die Nachbartabelle, um DHCP-Anfragen mithilfe von Unicast-Paketen zu beantworten)CAP_SYS_NICE : FTL stellt sich als wichtigen Prozess dar, um etwas mehr Verarbeitungszeit zu erhalten, wenn diese zur Neige gehtCAP_CHOWN : Wir müssen in der Lage sein, den Besitz von Protokolldateien und Datenbanken zu ändern, falls FTL als ein anderer Benutzer als pihole gestartet wird Dieses Image gewährt dem FTLDNS-Prozess automatisch diese Funktionen, sofern verfügbar, auch wenn es als Nicht-Root-Benutzer ausgeführt wird.
Standardmäßig enthält Docker nicht die NET_ADMIN Funktion für nicht privilegierte Container und es wird empfohlen, sie explizit mit --cap-add=NET_ADMIN zum Container hinzuzufügen.
Wenn DHCP- und IPv6-Router-Ankündigungen jedoch nicht verwendet werden, sollte es sicher sein, sie zu überspringen. Für die meisten Paranoiker sollte es sogar möglich sein, die NET_RAW -Fähigkeit explizit zu löschen, um zu verhindern, dass FTLDNS sie automatisch erhält.
Wir haben festgestellt, dass viele Leute Watchtower nutzen, um ihre Pi-Hole-Container auf dem neuesten Stand zu halten. Aus dem gleichen Grund, aus dem wir bei einer Bare-Metal-Installation keine Funktion zur automatischen Aktualisierung bereitstellen, sollte Ihr Pi-Hole-Container nicht automatisch vom System aktualisiert werden. Besonders unbeaufsichtigt. So sehr wir auch versuchen sicherzustellen, dass nichts schief geht, manchmal geht etwas schief – und Sie müssen sich Zeit nehmen, um die Version des Containers, den Sie ausführen möchten, manuell abzurufen und zu aktualisieren. Der Upgrade-Prozess sollte wie folgt ablaufen:
Pi-Hole ist ein integraler Bestandteil Ihres Netzwerks. Lassen Sie es nicht wegen eines unbeaufsichtigten Updates mitten in der Nacht zusammenbrechen.
Bitte melden Sie Probleme im GitHub-Projekt, wenn Sie vermuten, dass etwas mit Docker zu tun hat. Pi-Hole- oder allgemeine Docker-Fragen werden am besten in unseren Benutzerforen beantwortet.
