[Pi-Hole] Ervaringen & discussie

[Jumpman]

Airw0lf schreef op dinsdag 25 februari 2025 @ 12:12:
@Jumpman - ik weet het niet zeker - maar volgens gaat het met mis op die uid en gid.
Moeten die er wel in staan met gebruik onder root? Want dan zijn beiden 0.

Ik installeer onder mijn eigen gebruikers account dat admin rechten op de Synology heeft. Admin heb ik uitgeschakeld om veiligheidsredenen.

[Airw0lf]

@nero355 - hieronder mijn 0,500 Euro...

Ik heb een L3 switch ingezet als vlan router en default gateway voor alle vlans. De connectivity tussen de vlans wordt bepaald door een ACL in de L3 switch.

De achterliggende Internet router doet alleen mee in het tech-vlan en de DMZ. Die DMZ is tevens de fall-back naar de Fritzbox of de KPN router (Box12) – mocht het ooit nodig zijn. Dit wil zeggen dat ik de huidige router altijd kan vervangen door een van die twee; de rest blijft dan doorlopen.

Schematisch: internet <==> omada router (en dmz) <==> L3-switch (en vlan router) <==> alle andere apparaten
De nat-ing vindt enkel plaats in de omada router. Deze is tevens dhcp- en dns-server voor de dmz.

Een apparaat/systeem/server wat voor meerdere vlans ontsloten moet zijn krijgt in elk van die vlans een “pootje”. De ACL in de L3 switch bepaald welke vlans met elkaar kunnen babbelen. Vraag: waarom zou ik dit *niet* moeten willen?

Alles op het gebied van dhcp, dns en vlans wordt “bestuurd” door de lxc container genaamd morpheus. Daarbinnen draaien een paar docker containers; waaronder pihole en omada. De meeste docker containers maken gebruik van het docker “host”-netwerk; sommige van het docker “bridge”-netwerk. In combinatie met de ACL in de switch kan ik op deze manier per applicatie/container bepalen langs welk vlan deze ontsloten moet worden.

In pihole zie ik inderdaad alleen de interfaces met op het eind 235. Daarnaast is er een lijst met de dns namen van alle apparaten/systemen/servers; waaronder ook die voor morpheus voor elk vlan. Het genoemde probleem speelt alleen bij pihole v6 – niet bij pihole v5. Beiden maken gebruik van dezelfde lijst en zijn “gevoed” met dezelfde dnsmasq config bestandjes.

Om bij een nieuwe v6 versie snel heen-en-weer te kunnen schakelen voor testen heb ik een pihole v5 en een pihole v6 docker container aangemaakt. Uiteraard is er steeds maar een daadwerkelijk actief – ook na een reboot van de lxc.

Eerder vanmorgen nog wat testen gedaan met de nieuwste v6 versie - nog geen verschil/verbetering gezien - problemen blijven - weer terug naar v5.

Voor de volledigheid (enigszins off-topic en wellicht niet relevant): de lxc container morpheus draait op een proxmox server met twee ethernet poorten in bonding mode 6 (d.w.z. balance-alb).

[ Voor 3% gewijzigd door Airw0lf op 25-02-2025 16:29 ]

[Airw0lf]

Jumpman schreef op dinsdag 25 februari 2025 @ 12:16:
[...]

Ik installeer onder mijn eigen gebruikers account dat admin rechten op de Synology heeft. Admin heb ik uitgeschakeld om veiligheidsredenen.

Mja - maar je gaf aan pihole als root te starten. Maar met de ze uid en gid is dat niet het geval.

[Jumpman]

Airw0lf schreef op dinsdag 25 februari 2025 @ 12:22:
[...]


Mja - maar je gaf aan pihole als root te starten. Maar met de ze uid en gid is dat niet het geval.

Maar met pihole i.p.v. root start er niets.

Log met user pi-hole (van onder naar boven lezen):
If you are seeing this error, please set the environment variable 'DNSMASQ_USER' to the value 'root'
[!] ERROR: Unable to set capabilities for pihole-FTL. Cannot run as non-root.
Failed to set capabilities on file '/usr/bin/pihole-FTL': Not supported
* CAP_SYS_TIME
* CAP_SYS_NICE
* CAP_NET_RAW
* CAP_NET_BIND_SERVICE
* CAP_CHOWN
[i] Applying the following caps to pihole-FTL:
[i] Setting capabilities on pihole-FTL where possible
[i] pihole-FTL pre-start checks

[ Voor 71% gewijzigd door Jumpman op 25-02-2025 13:39 ]

[Airw0lf]

Jumpman schreef op dinsdag 25 februari 2025 @ 13:33:
[...]


Maar met pihole i.p.v. root start er niets.

Log met user pi-hole (van onder naar boven lezen):
If you are seeing this error, please set the environment variable 'DNSMASQ_USER' to the value 'root'
[!] ERROR: Unable to set capabilities for pihole-FTL. Cannot run as non-root.
Failed to set capabilities on file '/usr/bin/pihole-FTL': Not supported
* CAP_SYS_TIME
* CAP_SYS_NICE
* CAP_NET_RAW
* CAP_NET_BIND_SERVICE
* CAP_CHOWN
[i] Applying the following caps to pihole-FTL:
[i] Setting capabilities on pihole-FTL where possible
[i] pihole-FTL pre-start checks

Ik weet niet goed waar je zit in je denken-en-doen. Dus misschien schiet ik er naast...

Ik heb een user pihole (met uid en gid 900) aangemaakt.
En vervolgens met chown -R pihole:pihole de rechten aangepast van de volumes die gedefinieerd zijn voor de Docker container. Die volumes zijn bij mij:

code:

-v /opt/docker/pihole/v6/etc-pihole:/etc/pihole
-v /opt/docker/pihole/v6/etc-dnsmasq.d:/etc/dnsmasq.d
-v /opt/docker/pihole/v6/var-log-pihole:/var/log/pihole

Die heb ik vervolgens gecontroleerd met (bijvoorbeeld):
ls -ln /opt/docker/pihole/

De output is dan:
ls -ln /opt/docker/pihole
drwxr-xr-x 5 900 900 4096 Feb 25 06:45 v5
drwxr-xr-x 5 900 900 4096 Feb 24 18:38 v6

En voor de pihole-v6 folder:
ls -ln /opt/docker/pihole/v6
drwxr-xr-x 2 900 900 4096 Feb 24 18:40 etc-dnsmasq.d
drwxr-xr-x 8 900 900 4096 Feb 25 07:24 etc-pihole
drwxr-xr-x 2 900 900 4096 Feb 24 18:38 var-log-pihole

Op deze manier kan ik snel schakelen tussen de v5 en v6.

[nero355]

Airw0lf schreef op dinsdag 25 februari 2025 @ 12:16:
Ik heb een L3 switch ingezet als vlan router en default gateway voor alle vlans.
De connectivity tussen de vlans wordt bepaald door een ACL in de L3 switch.

De achterliggende Internet router doet alleen mee in het tech-vlan en de DMZ. Die DMZ is tevens de fall-back naar de Fritzbox of de KPN router (Box12) – mocht het ooit nodig zijn.
Dit wil zeggen dat ik de huidige router altijd kan vervangen door een van die twee; de rest blijft dan doorlopen.

Dat gaat niet werken denk ik : Frtizje dan wel ExperiaBoxje gaan die extra netwerken niet voor je NAT-ten

Een apparaat/systeem/server wat voor meerdere vlans ontsloten moet zijn krijgt in elk van die vlans een “pootje”.
De ACL in de L3 switch bepaald welke vlans met elkaar kunnen babbelen.

Vraag: waarom zou ik dit moeten willen?

Ehh... beetje verwarrend stukje tekst... :
- Wil je weten waarom je het zo opgezet moet laten ?!
- Of wil je weten waarom je een Pi-Hole zou moeten willen met meerdere VLAN Interfaces naast de Main Interface zelf ?!

IMHO is het laatste gewoon beter/makkelijker en vooral vanuit Pi-Hole zelf veel simpeler, vooral nu met Pi-Hole v6

Alles op het gebied van dhcp, dns en vlans wordt “bestuurd” door de lxc container genaamd morpheus. Daarbinnen draaien een paar docker containers; waaronder pihole en omada. De meeste docker containers maken gebruik van het docker “host”-netwerk; sommige van het docker “bridge”-netwerk. In combinatie met de ACL in de switch kan ik op deze manier per applicatie/container bepalen langs welk vlan deze ontsloten moet worden.

Volgens mij hadden Host en Bridge Docker Networks een of andere beperking die je niet hebt bij MACVLAN of zeg ik nou wat raars

Verder heb ik eigenlijk nooit de behoefte gehad om Pi-Hole de DHCP te laten doen : Dat kan prima de Router zelf doen IMHO en vooral als je iets hebt staan dat niet van een ISP is zeg maar

In pihole zie ik inderdaad alleen de interfaces met op het eind 235.
Daarnaast is er een lijst met de dns namen van alle apparaten/systemen/servers; waaronder ook die voor morpheus voor elk vlan.

Het genoemde probleem speelt alleen bij pihole v6 – niet bij pihole v5.
Beiden maken gebruik van dezelfde lijst en zijn “gevoed” met dezelfde dnsmasq config bestandjes.

Post die ook eens voor de grap tussen Quote en Code tags

Eerder vanmorgen nog wat testen gedaan met de nieuwste v6 versie - nog geen verschil/verbetering gezien - problemen blijven - weer terug naar v5.

"Problemen" of echt serieuze problemen ?!

Voor de volledigheid (enigszins off-topic en wellicht niet relevant): de lxc container morpheus draait op een proxmox server met twee ethernet poorten in bonding mode 6 (d.w.z. balance-alb).

Vanwaar die keuze voor Mode 6

[Airw0lf]

@nero355 - nog wat antwoorden...

De KPN-Box12 kan dit inderdaad niet - klopt - heeft geen static route mogelijkheid. Die zet ik alleen maar in op verzoek van KPN (bij storingen).

De Fritzbox werkt prima - meermalen getest. Bij zowel de L3 switch als de Fritzbox maak ik gebruik van een static route entry.

Inzake het "verwarrende stukje tekst":
In een eerdere post schreef je "Ga die dus niet direkt op het DNS IP adres benaderen vanuit andere VLANs want dat is iets wat je sowieso niet moet willen...". Wat bedoel je hiermee en waarom zou ik dit niet moeten willen?

Een "host"-netwerk heeft bij mijn weten geen beperkingen - niet anders dan geen overlappende tcp/udp poorten. Een "bridge"-netwerk heeft wel beperkingen => als je containers enkel intern via de bridge met elkaar wil laten babbelen kun je beter een eigen "bridge"-netwerk aanmaken. Een mac-vlan is alleen maar lastig en geeft meer administratie - gebruik ik liever niet - alleen als het echt niet anders kan.

Met pihole v6 heb ik geen grote problemen. Alleen dat ik wat content mis die eerder in setupVar.conf en pihole-FTL.conf stond. Tis te zeggen... die content is niet meer voor mij herkenbaar - twee daarvan hadden betrekking op de werking van ipv6.

De keuze voor mode 6 is omdat die loadbalancing doet voor zowel send als receive. En zonder iets met instellingen te doen op de switch.

Als laarste: hieronder wat uitsnedes van verschillende config bestandjes - waaronder die in /etc/dnsmasq.d.

code:

===>>> Uitsnede van /etc/network/interfaces van de lxc container.

######
# tech - vlan 1
auto eth0
iface eth0 inet static
        address 192.168.139.235/24
        gateway 192.168.139.241
        dns-nameserver 192.168.139.235
        dns-domain tech.lan

######
# wired - vlan 210
auto eth0.210
iface eth0.210 inet static
    address 192.168.210.235/24
    gateway 192.168.210.241
    dns-nameserver 192.168.210.235
    dns-domain wired.lan

######
# wifi - vlan 220
auto eth0.220
iface eth0.220 inet static
    address 192.168.220.235/24
    gateway 192.168.220.241
    dns-nameserver 192.168.220.235
    dns-domain wifi.lan

code:

===>>> Uitsnede van /etc/dnsmasq.d/90-vlan.conf in de docker container

######
# Wired - vlan 210
domain=wired.lan,192.168.210.0/24,local
dhcp-range=eth0.210,192.168.210.11,192.168.210.99,168h
dhcp-option=eth0.210,option:router,192.168.210.241
dhcp-option=eth0.210,option:dns-server,192.168.210.235
dhcp-option=eth0.210,option:ntp-server,192.168.210.235
dhcp-option=eth0.210,option:domain-name,wired.lan

######
# WiFi - vlan 220
domain=wifi.lan,192.168.220.0/24,local
dhcp-range=eth0.220,192.168.220.11,192.168.220.99,168h
dhcp-option=eth0.220,option:router,192.168.220.241
dhcp-option=eth0.220,option:dns-server,192.168.220.235
dhcp-option=eth0.220,option:ntp-server,192.168.220.235
dhcp-option=eth0.220,option:domain-name,wifi.lan

code:

===>>> Uitsnede van /etc/pihole/90-static-hosts-list.conf in de docker container
Wordt geladen via /etc/dnsmasq.d/90-addn.conf
Var en content hiervoor is: addn-hosts=/etc/pihole/90-static-hosts.list

######
# tech.lan - vlan 1
192.168.139.201 osiris.tech.lan
192.168.139.233 keymaker.tech.lan
192.168.139.234 cypher.tech.lan
192.168.139.235 morpheus.tech.lan
192.168.139.235 sdn.tech.lan

######
# wired.lan - vlan 210
192.168.210.201 osiris.wired.lan
192.168.210.234 cypher.wired.lan
192.168.210.235 morpheus.wired.lan

######
# wifi.lan - vlan 220
192.168.220.201 osiris.wifi.lan
192.168.220.234 cypher.wifi.lan
192.168.220.235 morpheus.wifi.lan

[strandbal]

Nou, ik draaide dus 6.0.3 met de settings die niet werden overgenomen handmatig opnieuw geconfigureerd... Update naar 6.0.4, is 'ie alsnog allerlei oude settings gaan mergen, staat de NTP server ineens weer aan, en is de interface naar poort 8080 geswitcht terwijl ik lighttpd al had opgeruimd

Poort 80 is dus niet in gebruik, hoe krijg ik 'm weer terug? Reboot van de container helpt iig niet.
edit: Gevonden in pihole.toml config file.

[ Voor 5% gewijzigd door strandbal op 25-02-2025 20:36 ]

[Donstil]

Mijn PiHole blijkt ge-update naar versie 6.0, allemaal leuk en aardig maar nu bemoeid die installatie zich met alle andere "poorten" op de Raspberry pi's waar ook PiHole op draait.

Als ik nu een andere poort opzoek op dat IP, voor een andere webapplicatie dan krijg ik een scherm van PiHole met "Oops! Access denied.", kan ik makkelijk uitzetten dat PiHole zich niet overal mee bemoeid?

Ik had altijd poort 81 voor mijn PiHole installaties, dat werkte prima en staat ook nog ingesteld in mijn lighttpd.conf.

[Pixelmagic]

Donstil schreef op dinsdag 25 februari 2025 @ 21:29:
Mijn PiHole blijkt ge-update naar versie 6.0, allemaal leuk en aardig maar nu bemoeid die installatie zich met alle andere "poorten" op de Raspberry pi's waar ook PiHole op draait.

Als ik nu een andere poort opzoek op dat IP, voor een andere webapplicatie dan krijg ik een scherm van PiHole met "Oops! Access denied.", kan ik makkelijk uitzetten dat PiHole zich niet overal mee bemoeid?

Ik had altijd poort 81 voor mijn PiHole installaties, dat werkte prima en staat ook nog ingesteld in mijn lighttpd.conf.

Ik heb begrepen dat versie 6 geen lighttpd meer gebruikt.

[Donstil]

Pixelmagic schreef op dinsdag 25 februari 2025 @ 22:13:
[...]


Ik heb begrepen dat versie 6 geen lighttpd meer gebruikt.

Ah sad, ik zit het net te googlen.

ChatGPT zegt dat ik dit moet doen:
port = "80,[::]:80,[::]:"

In /etc/pihole/pihole.toml

Dus dat moet ik zo ff proberen.

Edit: Mm de webinterface geeft nu 403 forbidden. Maar ik kan wel weer bij de rest, dus mij wel ff best zo

[ Voor 13% gewijzigd door Donstil op 25-02-2025 22:48 ]

[Jumpman]

Heeft iemand nog een oplossing, dat sinds de update al mijn clients 172.17.0.1 (Bridge?) zijn, voorheen zag ik hier gewoon 192.168.178.1 (clien 1), 192.168.178.5 (client 2) etc. Nu kan ik niet goed zien welk device de meest foute URL's probeert te benaderen (Nu weet ik al dat dit de Google Chromecast With Google TV is ).

Dit

code:

--network=host

toevoegen aan mijn installatie, zorgt voor een onbenaderbare Pi-Hole, denk ik. Want in Docker zie ik dan wel een gezonde service die op is, maar kan ik Pi-Hole niet benaderen.

[ Voor 25% gewijzigd door Jumpman op 25-02-2025 22:57 ]

[Freee!!]

Jumpman schreef op dinsdag 25 februari 2025 @ 22:53:
Heeft iemand nog een oplossing, dat sinds de update al mijn clients 172.17.0.1 (Bridge?) zijn, voorheen zag ik hier gewoon 192.168.178.1 (clien 1), 192.168.178.5 (client 2) etc. Nu kan ik niet goed zien welk device de meest foute URL's probeert te benaderen (Nu weet ik al dat dit de Google Chromecast With Google TV is ).

Dit

code:

--network=host

toevoegen aan mijn installatie, zorgt voor een onbenaderbare Pi-Hole, denk ik. Want in Docker zie ik dan wel een gezonde service die op is, maar kan ik Pi-Hole niet benaderen.

Ik heb mijn Pi-Holes in een macvlan draaien.

[Airw0lf]

Jumpman schreef op dinsdag 25 februari 2025 @ 22:53:
Heeft iemand nog een oplossing, dat sinds de update al mijn clients 172.17.0.1 (Bridge?) zijn, voorheen zag ik hier gewoon 192.168.178.1 (clien 1), 192.168.178.5 (client 2) etc. Nu kan ik niet goed zien welk device de meest foute URL's probeert te benaderen (Nu weet ik al dat dit de Google Chromecast With Google TV is ).

Dit

code:

--network=host

toevoegen aan mijn installatie, zorgt voor een onbenaderbare Pi-Hole, denk ik. Want in Docker zie ik dan wel een gezonde service die op is, maar kan ik Pi-Hole niet benaderen.

Paar vragen:
(1) - Hoe start je pihole op? Als het Docker cli of compose is: hoe ziet het script eruit?
(2) - Wat voor systeem? Als het Linux is: wat is de output van ss -tulpn?
(3) - Wat bedoel je met "clients"? Waar "zie" je die 172.17.0.1 dan precies?

[ed1703]

Jumpman schreef op dinsdag 25 februari 2025 @ 22:53:
Heeft iemand nog een oplossing, dat sinds de update al mijn clients 172.17.0.1 (Bridge?) zijn, voorheen zag ik hier gewoon 192.168.178.1 (clien 1), 192.168.178.5 (client 2) etc. Nu kan ik niet goed zien welk device de meest foute URL's probeert te benaderen (Nu weet ik al dat dit de Google Chromecast With Google TV is ).

Dit

code:

--network=host

toevoegen aan mijn installatie, zorgt voor een onbenaderbare Pi-Hole, denk ik. Want in Docker zie ik dan wel een gezonde service die op is, maar kan ik Pi-Hole niet benaderen.

Een host network driver gebruiken in docker zorgt dat een container alleen gebruik maakt van de softwareomgeving in docker, maar qua netwerk zal het zich gedragen alsof de PiHole software rechtstreeks op de host is geinstalleerd. Dus is je host 10.0.0.1 dan worden alle poorten van je Pihole Docker ook rechtstreeks 1 op 1 gemapped en kan je ook niet veranderen.

[MRE-Inc]

strandbal schreef op dinsdag 25 februari 2025 @ 20:31:
Nou, ik draaide dus 6.0.3 met de settings die niet werden overgenomen handmatig opnieuw geconfigureerd... Update naar 6.0.4, is 'ie alsnog allerlei oude settings gaan mergen, staat de NTP server ineens weer aan, en is de interface naar poort 8080 geswitcht terwijl ik lighttpd al had opgeruimd

Poort 80 is dus niet in gebruik, hoe krijg ik 'm weer terug? Reboot van de container helpt iig niet.
edit: Gevonden in pihole.toml config file.

Ja dat had ik dus ook na de update naar 6.0.4 dat er een andere poort werd gebruikt. Had ik even niet zo snel in de gaten, dus een half uur lopen zoeken. Poorten stonden bij mij van 80 naar 8080 en van 443 naar 8443. Beide aangepast naar 80 en 443 en het werkte weer.

Lighttpd had ik ook al verwijderd, dus vond het vreemd waarom de poorten worden aangepast. Er draait verder niks op mijn pihole, ja wireguard maar die heeft geen webinterface.

[nero355]

Airw0lf schreef op dinsdag 25 februari 2025 @ 19:40:
Inzake het "verwarrende stukje tekst":
In een eerdere post schreef je "Ga die dus niet direkt op het DNS IP adres benaderen vanuit andere VLANs want dat is iets wat je sowieso niet moet willen...".

Wat bedoel je hiermee en waarom zou ik dit niet moeten willen?

Ik heb het idee dat jij de Pi-Hole webGUI vanuit elke VLAN wilt kunnen benaderen op de Host+Domein uit dat VLAN manier en dat is dus naar mijn mening nergens voor nodig en levert je alleen maar gedoe op dus laat die lekker in je Management VLAN

Een mac-vlan is alleen maar lastig en geeft meer administratie - gebruik ik liever niet - alleen als het echt niet anders kan.

Als @Freee!! zegt dat het de beste Docker optie is dan is dat gewoon zo !!!

Met pihole v6 heb ik geen grote problemen. Alleen dat ik wat content mis die eerder in setupVar.conf en pihole-FTL.conf stond.

Die twee bestaan in principe niet meer en zijn dus pihole.toml geworden

Tis te zeggen... die content is niet meer voor mij herkenbaar - twee daarvan hadden betrekking op de werking van ipv6.

Het kan best zo zijn dat ze iets zijn vergeten hoor... Dat moeten we natuurlijk niet uitsluiten!

Als je het echt 100% zeker weet dan moet je effe via Discourse of GitHub een Bug Report dan wel Feature Request aanmaken

Als laarste: hieronder wat uitsnedes van verschillende config bestandjes - waaronder die in /etc/dnsmasq.d.

Enkele vragen van mijn kant :

- Waarom heeft elke Interface ook een Gateway/DNS Server/Search Domain ingesteld staan in /etc/network/interfaces
Ik zou verwachten dat je eth0 dat alleen heeft en de rest "domme takjes" zijn so to speak

Dit kan namelijk ook invloed hebben op je eerdere DNS Resolving problemen waarbij je in feite een ongewenst resultaat kreeg !!
Ik zou eigenlijk voor willen stellen om die weg te halen en dan weer te gaan testen

Wel een kleine sidenote vanwege iets wat ik onlangs heb ontdekt :
Dankzij de switch van Ubiquiti UniFi USG Router naar OPNsense als mijn Router ben ik erachter gekomen dat ik last had van A-Symmetric Routing op mijn Pi-Hole met meerdere VLAN Interfaces en kreeg ik last van een SSH sessie die na 30 seconden of zo bevroor !!

Dit is te fixen en hoe precies kan je in mijn eerdere reacties lezen met het stukje over Policy Based Routing op basis van Source ingevoerd in een SystemD-NetworkD netwerk configuratie
Deze voert in feite enkele ip rule & ip route regeltjes uit als die wordt ingelezen...

- Waarom is je "Local DNS Records" file niet gewoon de file die Pi-Hole v5 altijd al gebruikte : custom.list
(Zeg ik zo effe uit het blote hoofd...)

- Verder is zo'n bestand IIRC in theorie onderhevig aan dezelfde syntax als een hosts bestand en zou die zo eruit moeten zien :

code:

192.168.1.234 host.domein.lan host

Zie : https://www.man7.org/linux/man-pages/man5/hosts.5.html

Is geen ramp of zo, maar wel officiëel de standaard

- Is het echt de bedoeling dat meerdere hosts in alle 3 VLANs actief zijn
Ik zie dit :

code:

# tech.lan - vlan 1
192.168.139.201 osiris.tech.lan
192.168.139.234 cypher.tech.lan
192.168.139.235 morpheus.tech.lan

######
# wired.lan - vlan 210
192.168.210.201 osiris.wired.lan
192.168.210.234 cypher.wired.lan
192.168.210.235 morpheus.wired.lan

######
# wifi.lan - vlan 220
192.168.220.201 osiris.wifi.lan
192.168.220.234 cypher.wifi.lan
192.168.220.235 morpheus.wifi.lan

Morpheus begrijp ik, want daar hebben we het over (Pi-Hole Server) maar waarom die andere twee dan ?!


/Vragen, vragen, zoveel vragen !!!

strandbal schreef op dinsdag 25 februari 2025 @ 20:31:
Nou, ik draaide dus 6.0.3 met de settings die niet werden overgenomen handmatig opnieuw geconfigureerd... Update naar 6.0.4, is 'ie alsnog allerlei oude settings gaan mergen, staat de NTP server ineens weer aan, en is de interface naar poort 8080 geswitcht terwijl ik lighttpd al had opgeruimd

Poort 80 is dus niet in gebruik, hoe krijg ik 'm weer terug? Reboot van de container helpt iig niet.
edit: Gevonden in pihole.toml config file.

Dit is een bug en degene die daar verantwoordelijk voor is heeft er heel veel spijt van : https://discourse.pi-hole...ate-broke-pihole/76891/10

Donstil schreef op dinsdag 25 februari 2025 @ 21:29:
Ik had altijd poort 81 voor mijn PiHole installaties, dat werkte prima en staat ook nog ingesteld in mijn lighttpd.conf.

Dan doe je nu niet dit :

Donstil schreef op dinsdag 25 februari 2025 @ 22:21:
ChatGPT

Maar dan zoek je gewoon op hoe je dat met 1 commando verandert of speel je effe in een SSH sessie met het pihole-FTL commando en dan zie je dit :

code:

pihole-FTL --config webserver.port '80o,443os,[::]:80o,[::]:443os'

Als je poort 81 wilt hebben dan doe je dit :

code:

pihole-FTL --config webserver.port '81'

En dat zou weer in /etc/pihole/pihole.toml weggeschreven moeten worden als het goed is

[Donstil]

nero355 schreef op woensdag 26 februari 2025 @ 16:16:



Maar dan zoek je gewoon op hoe je dat met 1 commando verandert of speel je effe in een SSH sessie met het pihole-FTL commando en dan zie je dit :

code:

pihole-FTL --config webserver.port '80o,443os,[::]:80o,[::]:443os'

Als je poort 81 wilt hebben dan doe je dit :

code:

pihole-FTL --config webserver.port '81'

En dat zou weer in /etc/pihole/pihole.toml weggeschreven moeten worden als het goed is

< Nah met deze emoji ben ik het niet eens , chatGPT heeft mij prima de oplossing gegeven en ik welke file ik het moest aanpassen.

Neemt niet weg dat PiHole zich gewoon niet met de andere poorten moet bemoeien natuurlijk, dat gaat ze helemaal niets aan

[nero355]

Donstil schreef op woensdag 26 februari 2025 @ 16:33:
Neemt niet weg dat PiHole zich gewoon niet met de andere poorten moet bemoeien natuurlijk, dat gaat ze helemaal niets aan

- https://pi-hole.net/blog/2025/02/18/introducing-pi-hole-v6/
- https://pi-hole.net/blog/...lease-fixes-and-findings/

Had je kunnen weten...

[Donstil]

nero355 schreef op woensdag 26 februari 2025 @ 16:34:
[...]

- https://pi-hole.net/blog/2025/02/18/introducing-pi-hole-v6/
- https://pi-hole.net/blog/...lease-fixes-and-findings/

Had je kunnen weten...

Ja ik heb wel wat beters te doen natuurlijk

[nero355]

Donstil schreef op woensdag 26 februari 2025 @ 16:35:
Ja ik heb wel wat beters te doen natuurlijk

Als je het had gelezen dan had je meer tijd voor die andere dingen gehad uiteindelijk

[Donstil]

nero355 schreef op woensdag 26 februari 2025 @ 16:36:
[...]

Als je het had gelezen dan had je meer tijd voor die andere dingen gehad uiteindelijk

Haha ja misschien wel.

Neemt het punt niet weg dat ze gewoon van de andere poorten moeten afblijven in een bestaande situatie, of het nou in de release notes staat of niet

[ed1703]

Donstil schreef op woensdag 26 februari 2025 @ 16:38:
[...]


Haha ja misschien wel.

Neemt het punt niet weg dat ze gewoon van de andere poorten moeten afblijven in een bestaande situatie, of het nou in de release notes staat of niet

Volgens mij is dat een kwestie van lighttpd ja of nee disabled. (bij nee gaat men naar 8080)
Pihole met versie 5 en lighttpd installeren, lighttpd ook voor andere toepassingen gebruiken en dan vervolgens gaan upgraden naar 6 met lighttpd disabled gaan je andere toepassingen stuk natuurlijk.
Er is daar al lezende geen rekening mee gehouden.

[Donstil]

ed1703 schreef op woensdag 26 februari 2025 @ 16:53:
[...]

Volgens mij is dat een kwestie van lighttpd ja of nee disabled. (bij nee gaat men naar 8080)
Pihole met versie 5 en lighttpd installeren, lighttpd ook voor andere toepassingen gebruiken en dan vervolgens gaan upgraden naar 6 met lighttpd disabled gaan je andere toepassingen stuk natuurlijk.

Er is daar al lezende geen rekening mee gehouden.

Dat laatste lijkt het op inderdaad, ik denk dat ik vanavond even een backup terugzet en dan handmatig de update doen met de huidige resultaten in het achterhoofd

[Airw0lf]

nero355 schreef op woensdag 26 februari 2025 @ 16:16:
[...]

Ik heb het idee dat jij de Pi-Hole webGUI vanuit elke VLAN wilt kunnen benaderen op de Host+Domein uit dat VLAN manier en dat is dus naar mijn mening nergens voor nodig en levert je alleen maar gedoe op dus laat die lekker in je Management VLAN

Nee - dat is niet zo - alleen de dhcp en dns zijn in elk vlan beschikbaar.
De webgui is alleen in het management vlan beschikbaar.

Alleen... als ik vanuit een willekeurig vlan de webui wil aanspreken via de url van het management vlan (d.w.z. morpheus.tech.lan), dan geeft pihole het verkeerde ip adres terug. Namelijk het ip adres van de dns server van het betreffende vlan.

[...]

Als @Freee!! zegt dat het de beste Docker optie is dan is dat gewoon zo !!!

[...]

Als je het echt 100% zeker weet dan moet je effe via Discourse of GitHub een Bug Report dan wel Feature Request aanmaken

Ja - ga ik doen.

[...]

Enkele vragen van mijn kant :

- Waarom heeft elke Interface ook een Gateway/DNS Server/Search Domain ingesteld staan in /etc/network/interfaces
Ik zou verwachten dat je eth0 dat alleen heeft en de rest "domme takjes" zijn so to speak

Dit kan namelijk ook invloed hebben op je eerdere DNS Resolving problemen waarbij je in feite een ongewenst resultaat kreeg !!
Ik zou eigenlijk voor willen stellen om die weg te halen en dan weer te gaan testen

Ga ik doen - bedankt voor de tip

Wel een kleine sidenote vanwege iets wat ik onlangs heb ontdekt :
Dankzij de switch van Ubiquiti UniFi USG Router naar OPNsense als mijn Router ben ik erachter gekomen dat ik last had van A-Symmetric Routing op mijn Pi-Hole met meerdere VLAN Interfaces en kreeg ik last van een SSH sessie die na 30 seconden of zo bevroor !!

Dit is te fixen en hoe precies kan je in mijn eerdere reacties lezen met het stukje over Policy Based Routing op basis van Source ingevoerd in een SystemD-NetworkD netwerk configuratie
Deze voert in feite enkele ip rule & ip route regeltjes uit als die wordt ingelezen...

Linkje met dat stukje policy based routing?
Ik heb dat probleem tot nu toe niet gehad.

- Waarom is je "Local DNS Records" file niet gewoon de file die Pi-Hole v5 altijd al gebruikte : custom.list
(Zeg ik zo effe uit het blote hoofd...)

- Verder is zo'n bestand IIRC in theorie onderhevig aan dezelfde syntax als een hosts bestand en zou die zo eruit moeten zien :

code:

192.168.1.234 host.domein.lan host

Zie : https://www.man7.org/linux/man-pages/man5/hosts.5.html

Is geen ramp of zo, maar wel officiëel de standaard

- Is het echt de bedoeling dat meerdere hosts in alle 3 VLANs actief zijn

Ja - dit is echt de bedoeling.
De meeste dingen hebben een historische achtergrond - ben ooit eens begonnen met alleen dnsmasq - die kent geen "custom.list". Op enig moment heb ik daar pihole aan toegevoegd.

Ik zie dit :

code:

# tech.lan - vlan 1
192.168.139.201 osiris.tech.lan
192.168.139.234 cypher.tech.lan
192.168.139.235 morpheus.tech.lan

######
# wired.lan - vlan 210
192.168.210.201 osiris.wired.lan
192.168.210.234 cypher.wired.lan
192.168.210.235 morpheus.wired.lan

######
# wifi.lan - vlan 220
192.168.220.201 osiris.wifi.lan
192.168.220.234 cypher.wifi.lan
192.168.220.235 morpheus.wifi.lan

Morpheus begrijp ik, want daar hebben we het over (Pi-Hole Server) maar waarom die andere twee dan ?!

Dit is gedaan zodat apparaten in het betreffende vlan niet langs de vlan-router/switch hoeven.
In die vlan-router/switch staat alleen een regel wat vlan-naar-vlan blokkert.
In dit voorbeeld is osiris een nas met samba, nextcloud en syncthing.
En cypher de tailscale vpn router.

/Vragen, vragen, zoveel vragen !!!

[quote]

[ Voor 7% gewijzigd door Airw0lf op 26-02-2025 17:46 ]

[Freee!!]

nero355 schreef op woensdag 26 februari 2025 @ 16:16:
[...]
Als @Freee!! zegt dat het de beste Docker optie is dan is dat gewoon zo !!!

Ik zeg niet dat het de beste optie is, het is gewoon de optie die ik gebruik omdat die voor mij goed (zonder problemen) werkt, maar het vereist wel correcte inrichting.

[nero355]

Airw0lf schreef op woensdag 26 februari 2025 @ 17:45:
Nee - dat is niet zo - alleen de dhcp en dns zijn in elk vlan beschikbaar.
De webgui is alleen in het management vlan beschikbaar.

Alleen... als ik vanuit een willekeurig vlan de webui wil aanspreken via de url van het management vlan (d.w.z. morpheus.tech.lan), dan geeft pihole het verkeerde ip adres terug. Namelijk het ip adres van de dns server van het betreffende vlan.

Ahh... OK... vandaar dus mijn voorstel om effe overnieuw naar het geheel te kijken

Linkje met dat stukje policy based routing?
Ik heb dat probleem tot nu toe niet gehad.

Dat was dit : nero355 in "[Pi-Hole] Ervaringen & discussie"
Wat dus dit is geworden : nero355 in "Zelfbouw project: Firewall / Router / AP"

En dus vooral draait om deze regels :

code:

[RoutingPolicyRule]
From=192.168.1.3
Table=100
Priority=1

[Route]
Gateway=192.168.1.1
Destination=10.0.0.0/24
Source=192.168.1.3
Scope=site
Table=100

Ik bind OpenSSH Server namelijk altijd aan eth0 alleen wat in mijn Management VLAN zit en dus altijd via de Firewall moet vanuit mijn reguliere thuisnetwerk.

Echter bleek het verkeer zo te lopen :
- SSH komt binnen via 192.168.1.x
- Wil vervolgens naar buiten via een 10.0.0.x VLAN Interface
_{(Is tenslotte logische Kernel Routing via de kortste route naar het Destination IP Address toe hé!)}
- Firewall vindt dat niet leuk op het moment dat die de inhoud van de pakketjes ziet (Is niet Stateful tenslotte) en houdt het tegen.

Gevolg/Resultaat = Time-outs en dus een niet meer reagerende SSH sessie

Ja - dit is echt de bedoeling.
De meeste dingen hebben een historische achtergrond - ben ooit eens begonnen met alleen dnsmasq - die kent geen "custom.list". Op enig moment heb ik daar pihole aan toegevoegd.

OK, maar zoals je dus kan lezen heb "ik zelfs" wat typische "Ja, maar het heeft altijd goed gewerkt!!!111oneoneone" momentjes gehad dus soms moet je dingen helaas toch anders gaan doen !!

Kwam ook op het Pi-Hole Forum deze een paar keer tegen : https://xkcd.com/1172/

Freee!! schreef op woensdag 26 februari 2025 @ 17:57:
Ik zeg niet dat het de beste optie is, het is gewoon de optie die ik gebruik omdat die voor mij goed (zonder problemen) werkt, maar het vereist wel correcte inrichting.

Ja, maar ik vind dat je gewoon keihard gelijk hebt en daarom moedig ik anderen graag aan om hetzelfde te doen

[Freee!!]

nero355 schreef op woensdag 26 februari 2025 @ 18:24:
[...]
Kwam ook op het Pi-Hole Forum deze een paar keer tegen : https://xkcd.com/1172/

[Airw0lf]

@nero355 -

Die routing policy lijkt me niet meer dan een manier van static routes aanmaken - toch?

Ik heb de test gedaan met de "domme" pootjes - heeft niet geholpen.
Nog steeds wordt het verkeerde IP adres teruggegeven.

Mijn oog "viel" net ook weer op een probleempje wat al langer bestaat:
Soms wordt een fqdn "aangevuld" met .tech.lan.
Zo komt een zoekactie naar synthing.net ook voorbij als syncthing.net.tech.lan.
Of een apparaat in het iot-vlan (bijvoorbeeld inv-1.iot.lan) komt ook langs als inv-1.iot.lan.tech.lan.
Enig idee waar dat vandaan zou kunnen komen?

Inzake alles anders doen:
Over een week of twee eens kijken wat de situatie is met pihole v6.
Als er dan nog steeds dezelfde probleempjes zijn eens van scratch opnieuw opbouwen.

We gaan het zien...

[ed1703]

Airw0lf schreef op woensdag 26 februari 2025 @ 19:21:
@nero355 -

Nog steeds wordt het verkeerde IP adres teruggegeven.

Klinkt een beetje alsof er iets met FQDN c.q. search-domain hier iets niet goed gaat.
Iets anders kan ik er niet van maken als ik jouw setup lees. Ben benieuwd of iemand anders nog een ingeving heeft.

[Airw0lf]

ed1703 schreef op woensdag 26 februari 2025 @ 19:36:
[...]

Klinkt een beetje alsof er iets met FQDN c.q. search-domain hier iets niet goed gaat.
Iets anders kan ik er niet van maken als ik jouw setup lees. Ben benieuwd of iemand anders nog een ingeving heeft.

Ja - het domein staat in /etc/resolv.conf achter keyword domain en search. Ik kan het weghalen - maar is na een reboot weer terug.

Iemand een idee waar dit vandaan komt?
En beter nog: hoe te voorkomen dat die search na een reboot in /etc/resolv.conf gezet wordt?

[ Voor 12% gewijzigd door Airw0lf op 26-02-2025 22:45 ]

[Eraser127]

Wilde PiHole net updaten (was al op V6), maar de core en web modules worden niet meegenomen?

Na de update:

code:

Core version is v6.0 (Latest: v6.0.4)
Web version is v6.0 (Latest: v6.0.1)
FTL version is v6.0.2 (Latest: v6.0.2)

[ Voor 3% gewijzigd door Eraser127 op 27-02-2025 11:06 ]

[ed1703]

Eraser127 schreef op donderdag 27 februari 2025 @ 10:52:
Wilde PiHole net updaten (was al op V6), maar de core en web modules worden niet meegenomen?

Na de update:

code:

Core version is v6.0 (Latest: v6.0.4)
Web version is v6.0 (Latest: v6.0.1)
FTL version is v6.0.2 (Latest: v6.0.2)

PiHole bestaat uit verschillende onderdelen, dus is het ook geheel logisch dat ze verschillende versie-nummers kunnen hebben.

[Eraser127]

@ed1703 Klopt, maar eerder werden bij het pihole -up commando alle modules toch geüpdatet?

[ed1703]

Eraser127 schreef op donderdag 27 februari 2025 @ 11:23:
@ed1703 Klopt, maar eerder werden bij het pihole -up commando alle modules toch geüpdatet?

Soms gaat dat gelijk op. Maar het heeft natuurlijk geen nut om een versienummer op te hogen als er geen update is. Volgens de repository's op github zijn dit de laatste versies die beschikbaar zijn.

[W1ck1e]

ed1703 schreef op donderdag 27 februari 2025 @ 11:53:
[...]

Soms gaat dat gelijk op. Maar het heeft natuurlijk geen nut om een versienummer op te hogen als er geen update is. Volgens de repository's op github zijn dit de laatste versies die beschikbaar zijn.

@Eraser127 bedoelt dat zijn core & web niet worden geupdate. Terwijl er wel nieuwere versies zijn. Hij heeft van beide versie 6.0, terwijl de nieuwste resp. 6.0.4 & 6.01 zijn.

code:

Core version is v6.0 (Latest: v6.0.4)
Web version is v6.0 (Latest: v6.0.1)
FTL version is v6.0.2 (Latest: v6.0.2)

Bij mij zijn deze 2 modules wel bij een update na eerdere installatie wel ge-update.

[ Voor 17% gewijzigd door W1ck1e op 27-02-2025 12:03 ]

[ed1703]

W1ck1e schreef op donderdag 27 februari 2025 @ 12:02:
[...]

@Eraser127 bedoelt dat zijn core & web niet worden geupdate. Terwijl er wel nieuwere versies zijn. Hij heeft van beide versie 6.0, terwijl de nieuwste resp. 6.0.4 & 6.01 zijn.

code:

Core version is v6.0 (Latest: v6.0.4)
Web version is v6.0 (Latest: v6.0.1)
FTL version is v6.0.2 (Latest: v6.0.2)

Bij mij zijn deze 2 modules wel bij een update na eerdere installatie wel ge-update.

[Afbeelding]

Ah, i missed that... heb denk ik koffie nodig

[Eraser127]

W1ck1e schreef op donderdag 27 februari 2025 @ 12:02:
[...]

[...]

Bij mij zijn deze 2 modules wel bij een update na eerdere installatie wel ge-update.

[Afbeelding]

Naja, kan altijd nog een verse install doen als het zo blijft.

[andregroeneveld]

andregroeneveld schreef op maandag 24 februari 2025 @ 15:30:
dhcpcd.config was de boosdoener want er ontbrak onderin dit file:
interface eth0
static ip_address=192.168.1.xxx/24
static routers=192.168.1.1
static domain_name_servers=208.67.222.xxx 208.67.220.xxx


En je moet dit doen:
sudo systemctl stop lighttpd.service
sudo systemctl disable lighttpd.service

Ik heb mijn SSD weer draaien en heb eigenlijk alles hetzelfde gedaan net als met de SD kaart maar ik krijg mijn Pi-Hole niet te zien in mijn webbrowser. Hij werkt overigens wel. Wat kan het zijn?

Met wat geklooi in de shorcut op mijn bureaublad is het gelukt. Ik moest nu voor https kiezen.

[ Voor 7% gewijzigd door andregroeneveld op 27-02-2025 17:40 ]

[nero355]

Airw0lf schreef op woensdag 26 februari 2025 @ 19:21:
Die routing policy lijkt me niet meer dan een manier van static routes aanmaken - toch?

Ja en Nee : Er moet ook een IP Rule bij om het ook daadwerkelijk door de Kernel te laten gebruiken en dus ook de Source aan te geven i.p.v. het gebruikelijke namelijk de Destination

Ik heb de test gedaan met de "domme" pootjes - heeft niet geholpen.
Nog steeds wordt het verkeerde IP adres teruggegeven.

Hmm... crap...

Mijn oog "viel" net ook weer op een probleempje wat al langer bestaat:
Soms wordt een fqdn "aangevuld" met .tech.lan.
Zo komt een zoekactie naar synthing.net ook voorbij als syncthing.net.tech.lan.
Of een apparaat in het iot-vlan (bijvoorbeeld inv-1.iot.lan) komt ook langs als inv-1.iot.lan.tech.lan.

Enig idee waar dat vandaan zou kunnen komen?

Had je die vraag zelf niet beantwoord een tijdje geleden

Ik vergeet namelijk elke keer de uitleg voor dat verschijnsel

Inzake alles anders doen:
Over een week of twee eens kijken wat de situatie is met pihole v6.
Als er dan nog steeds dezelfde probleempjes zijn eens van scratch opnieuw opbouwen.

We gaan het zien...

Opzich geen gek idee

ed1703 schreef op woensdag 26 februari 2025 @ 19:36:
Klinkt een beetje alsof er iets met FQDN c.q. search-domain hier iets niet goed gaat.

Iets anders kan ik er niet van maken als ik jouw setup lees.
Ben benieuwd of iemand anders nog een ingeving heeft.

Dat denk ik dus ook, maar ik kan zo gauw niet zien waar precies en of dat het wel is überhaupt...

Airw0lf schreef op woensdag 26 februari 2025 @ 21:43:
Ja - het domein staat in /etc/resolv.conf achter keyword domain en search. Ik kan het weghalen - maar is na een reboot weer terug.

Iemand een idee waar dit vandaan komt?

En beter nog: hoe te voorkomen dat die search na een reboot in /etc/resolv.conf gezet wordt?

Dat doet je netwerkconfig als het goed is

Zie ook : https://linux.die.net/man/5/resolv.conf

Eraser127 schreef op donderdag 27 februari 2025 @ 10:52:
Wilde PiHole net updaten (was al op V6), maar de core en web modules worden niet meegenomen?

Na de update:

code:

Core version is v6.0 (Latest: v6.0.4)
Web version is v6.0 (Latest: v6.0.1)
FTL version is v6.0.2 (Latest: v6.0.2)

Switch voor de grap eens naar checkout dev en daarna weer naar master en kijk eens wat er gebeurt

andregroeneveld schreef op donderdag 27 februari 2025 @ 17:37:
Ik heb mijn SSD weer draaien en heb eigenlijk alles hetzelfde gedaan net als met de SD kaart maar ik krijg mijn Pi-Hole niet te zien in mijn webbrowser. Hij werkt overigens wel. Wat kan het zijn?

Met wat geklooi in de shorcut op mijn bureaublad is het gelukt. Ik moest nu voor https kiezen.

Als HTTPS wel werkt en HTTP niet dan heb je een poort 80 conflict in principe en moet je uitzoeken waar dat vandaan komt

Ik vind het trouwens zo gaaf dat je nu makkelijk HTTPS werkend kan krijgen (Ook al is het met een Self Signed Certificate...) dat ik gewoon alleen poort 443 zou gebruiken op de regel :

code:

ports =

[andregroeneveld]

@nero@Als HTTPS wel werkt en HTTP niet dan heb je een poort 80 conflict in principe en moet je uitzoeken waar dat vandaan komt

Ik vind het trouwens zo gaaf dat je nu makkelijk HTTPS werkend kan krijgen (Ook al is het met een Self Signed Certificate...) dat ik gewoon alleen poort 443 zou gebruiken op de regel :
code:
1
ports =

Vergeef mijn kennis maar ik weet niet precies waar je het over hebt? Moet ik een poort ergens instellen?

[Raven]

nero355 schreef op donderdag 27 februari 2025 @ 18:41:
Ik vind het trouwens zo gaaf dat je nu makkelijk HTTPS werkend kan krijgen (Ook al is het met een Self Signed Certificate...) dat ik gewoon alleen poort 443 zou gebruiken op de regel :

code:

ports =

Nu maar hopen dat het importeren van een eigen (wildcard)certificaat net zo makkelijk gaat
* Raven heeft daar nog niet naar gekeken....

[MRE-Inc]

Raven schreef op vrijdag 28 februari 2025 @ 06:05:
[...]

Nu maar hopen dat het importeren van een eigen (wildcard)certificaat net zo makkelijk gaat
* Raven heeft daar nog niet naar gekeken....

Ik heb letterlijk alle stappen die hier staan beschreven uitgevoerd en was met 5 minuten klaar. Ik had gelukkig mijn domeinnaam een tijdje geleden al naar Cloudflare overgezet mbt DNS. Het enige wat niet staat beschreven, is hoe je zelf je api token kunt maken bij Cloudflare.

Het kan zijn dat je een andere DNS provider hebt, maar dan moet je bij stap 2 iets andere commando's geven. Bv als je DNS bij Godaddy draait (wat ik eerst had) dan moet je GD_token= gebruiken, die staan hier https://github.com/acmesh-official/acme.sh/wiki/dnsapi

https://gist.github.com/k...ddb59a7d336b20376695797c6

[sweetdude]

Eraser127 schreef op donderdag 27 februari 2025 @ 10:52:
Wilde PiHole net updaten (was al op V6), maar de core en web modules worden niet meegenomen?

Na de update:

code:

Core version is v6.0 (Latest: v6.0.4)
Web version is v6.0 (Latest: v6.0.1)
FTL version is v6.0.2 (Latest: v6.0.2)

Ze zijn ondertussen hard aan het sleutelen geweest als ik op de versie nummers afga

code:

Core
    Version is v6.0.4-18-gc5d66c2 (Latest: null)
Web
    Version is v6.0.1-25-g3ecc3e7d (Latest: null)
FTL
    Version is vDev-f0a4ac1 (Latest: null)

[Eraser127]

@sweetdude @nero355

Net de switch naar dev gedaan, nu terug naar master en nu zijn de web en core modules wel op de laatste versie

[nero355]

sweetdude schreef op vrijdag 28 februari 2025 @ 12:05:
Ze zijn ondertussen hard aan het sleutelen geweest als ik op de versie nummers afga

code:

Core
    Version is v6.0.4-18-gc5d66c2 (Latest: null)
Web
    Version is v6.0.1-25-g3ecc3e7d (Latest: null)
FTL
    Version is vDev-f0a4ac1 (Latest: null)

Bij de "checkout dev" versie komen dan ook constant kleine fixes erbij en zo dus dan gaat het al gauw heel hard

Eraser127 schreef op vrijdag 28 februari 2025 @ 12:15:
@sweetdude @nero355

Net de switch naar dev gedaan, nu terug naar master en nu zijn de web en core modules wel op de laatste versie

LEKKER!!!

andregroeneveld schreef op donderdag 27 februari 2025 @ 20:46:
Vergeef mijn kennis maar ik weet niet precies waar je het over hebt?

Moet ik een poort ergens instellen?

Je kan de gebruikte poort van de webGUI van Pi-Hole v6 heel makkelijk instellen :
- Optie #1 = Via de webGUI zelf die dan op dat moment via een ongewenste poort te bereiken is.
- Optie #2 = Via de /etc/pihole/pihole.toml file als je via SSH inlogt.
- Optie #3 = Via het pihole-FTL commando : pihole-FTL --config webserver.port '80o,443os,[::]:80o,[::]:443os'
Dat is geloof ik wat er standaard in de Pi-Hole v6 configuratie staat

Als je via SSH inlogt en naar /etc/pihole/pihole.toml kijkt dan zie je zoiets staan :

code:

port = '80o,443os,[::]:80o,[::]:443os'

Als je daar bijvoorbeeld dit van maakt :

code:

port = '443s'

Dan heb je alleen HTTPS toegang op poort 443

Wil je echter alleen HTTP toegang op poort 80 dan kan je dit doen :

code:

port = '80'

Maar bij die poort lijk jij een conflict te hebben dus die is blijkbaar onbruikbaar om wat voor reden dan ook...

Wat draai je nog meer naast Pi-Hole op dit moment ??

Raven schreef op vrijdag 28 februari 2025 @ 06:05:
Nu maar hopen dat het importeren van een eigen (wildcard)certificaat net zo makkelijk gaat
* Raven heeft daar nog niet naar gekeken....

Onderhuids is het gewoon Civetweb : https://civetweb.github.io/civetweb/

Dus je kan relatief makkelijk alles regelen en je zal geen gedoe hebben met inpakken/uitpakken/herpakken van bestanden zoals bij een Ubiquiti UniFi Controller bijvoorbeeld

Ik zag ook al meerdere voorbeelden van een werkende Let's Encrypt Certificate configuratie dus dat komt wel goed

MRE-Inc schreef op vrijdag 28 februari 2025 @ 09:46:
https://gist.github.com/k...ddb59a7d336b20376695797c6

Stap #4 is heel belangrijk vooral : Alles wat in de file staat moet in de juiste volgorde staan !!

Anders krijg je half werkende rare toestanden zag ik...

Verder eigenlijk dit gewoon : https://docs.pi-hole.net/api/tls/#using-your-own-certificate

[Airw0lf]

nero355 schreef op donderdag 27 februari 2025 @ 18:41:

[...]

Had je die vraag zelf niet beantwoord een tijdje geleden

Ik vergeet namelijk elke keer de uitleg voor dat verschijnsel

Ja - klopt - maar die aanpak lijkt niet altijd te werken voor lxc containers.

Dat lijkt nu opgelost te zijn met de volgende acties:
(1) - sudo touch /etc/.pve-ignore.resolv.conf
(2) - domain= uit-commenten in /etc/systemd/resolved.conf
(3) - sudo ln -sf ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
(4) - in de dnsmasq-pihole-addn-config dhcp-option=option:domain-search,.
(5) - in de dnsmasq-vlan-config dhcp-option=eth0<.vlan-id>,option:domain-search,.

Voor de lxc met pihole heb ik (1), (4) en (5) gedaan. Voor alle andere lxc's (1), (2) en (3).

(1) zorgt er voor dat Proxmox het bestandje resolv.conf in de lxc met rust laat.
(2) zorgt er voor dat de search-list leeg blijft.
(3) zorgt er voor dat systemd-resolved zijn local caching via pihole blijft doen.
(4) zorgt er voor dat pihole/dnsmasq voor het management vlan search alleen een punt meestuurt.
(5) is als (4) - maar dan voor alle vlans/subnetten.

[
[...]

Dat denk ik dus ook, maar ik kan zo gauw niet zien waar precies en of dat het wel is überhaupt...

[...]

Dat doet je netwerkconfig als het goed is

Zie ook : https://linux.die.net/man/5/resolv.conf

Klopt - maar in mijn geval was het een combinatie van dingen.
Zie de 5 acties hierboven: dit lijkt het fenomeen grotendeels op te lossen.
Alleen Windows en synthing lijken er zich niks van aan te trekken.

edit:
Ow... en de reverse proxy (via swag) doet het ook weer - in de proxy-conf moet de api-locatie meegenomen worden. Hier is het even afwachten hoe de officiele config eruit komt te zien.
Maar voor nu lijkt pihole via de reverse proxy volledig te werken.

[ Voor 19% gewijzigd door Airw0lf op 28-02-2025 20:09 ]

[nero355]

@Airw0lf Progress !!! Lekker man!

[Raven]

MRE-Inc schreef op vrijdag 28 februari 2025 @ 09:46:
[...]


Ik heb letterlijk alle stappen die hier staan beschreven uitgevoerd en was met 5 minuten klaar. Ik had gelukkig mijn domeinnaam een tijdje geleden al naar Cloudflare overgezet mbt DNS. Het enige wat niet staat beschreven, is hoe je zelf je api token kunt maken bij Cloudflare.

Het kan zijn dat je een andere DNS provider hebt, maar dan moet je bij stap 2 iets andere commando's geven. Bv als je DNS bij Godaddy draait (wat ik eerst had) dan moet je GD_token= gebruiken, die staan hier https://github.com/acmesh-official/acme.sh/wiki/dnsapi

https://gist.github.com/k...ddb59a7d336b20376695797c6

Volgens mij was ik niet helemaal duidelijk , ik heb al een wildcard-certificaat, m.b.v. certbot en wat bash-scripts om de DNS-verificatie (DirectAdmin) te doen, het gaat mij alleen om het importeren van een al bestaand certificaat

Na een eind naar beneden scrollen zag ik

Bash:

sudo rm -f /etc/pihole/tls* && \
  sudo cat fullchain.cer ns1.mydomain.com.key | sudo tee /etc/pihole/tls.pem && /
  sudo service pihole-FTL restart

Dat zocht ik , later eens testen op een van de test-Pi's. De primaire zit nog op v5.

nero355 schreef op vrijdag 28 februari 2025 @ 16:46:
[...]

Onderhuids is het gewoon Civetweb : https://civetweb.github.io/civetweb/

Dus je kan relatief makkelijk alles regelen en je zal geen gedoe hebben met inpakken/uitpakken/herpakken van bestanden zoals bij een Ubiquiti UniFi Controller bijvoorbeeld

Ik zag ook al meerdere voorbeelden van een werkende Let's Encrypt Certificate configuratie dus dat komt wel goed


[...]

Stap #4 is heel belangrijk vooral : Alles wat in de file staat moet in de juiste volgorde staan !!

Anders krijg je half werkende rare toestanden zag ik...

Verder eigenlijk dit gewoon : https://docs.pi-hole.net/api/tls/#using-your-own-certificate

Zie hierboven , bij Unifi is het een ander verhaal inderdaad, heb daar (en voor andere dingen zoals pfSense, Webmin en HASS) bash-scriptjes voor geschreven. Het gaat bij de een wel véél eenvoudiger dan de ander

[W1ck1e]

Er was vanmorgen weer een update.



Ik moest daarna wel even mijn wachtwoord weer wissen. Geen idee of het door de update kwam.
Bij de update op een andere installatie niets van gemerkt.

[ Voor 9% gewijzigd door W1ck1e op 01-03-2025 12:49 ]

[Webgnome]

Als ik van niet docker naar wel docker variant wil gaan. Zijn er daar al goede tutorial/rtfm's voor? Mijn huidige installatie is twee pi's die allebei DHCP doen ( andere ranges ) en 1 unbound die op een orangepi draait.

[DjoeC]

Webgnome schreef op zaterdag 1 maart 2025 @ 13:03:
Als ik van niet docker naar wel docker variant wil gaan. Zijn er daar al goede tutorial/rtfm's voor? Mijn huidige installatie is twee pi's die allebei DHCP doen ( andere ranges ) en 1 unbound die op een orangepi draait.

Ik heb een V6.0.7 Docker draaien als test met macvlan. Voor ik m operationeel ga maken (deze week niet echt tijd gehad) wil ik er unbound bijzetten. DHCP doet mijn Fritz, in de Fritz, pihole is puur dns. Upgrade van V5 naar V6 heb ik met Teleporter gedaan en even alle instellingen nagelopen. Heb default DNS moeten corrigeren.

Misschien begin ik nog opnieuw, ik kwam deze youtube tegen: YouTube: Pi-hole v6 and unbound setup for recursive DNS. Easy steps and expla... Komt goed van pas, ik gebruik ook OMV op Debian. Behalve de teleporter voor de lijsten en de lokale DNS records wil ik alles vanaf de basis opzetten. Voorlopig lijkt dat allemaal geen probleem te zijn.

[Pixelmagic]

Webgnome schreef op zaterdag 1 maart 2025 @ 13:03:
Als ik van niet docker naar wel docker variant wil gaan. Zijn er daar al goede tutorial/rtfm's voor? Mijn huidige installatie is twee pi's die allebei DHCP doen ( andere ranges ) en 1 unbound die op een orangepi draait.

Ik ben hier de boel opnieuw aan het inrichten en wilde ook van echte install (op een vmware machine) naar een docker installatie. Tegelijk wilde ik nog even niet naar de 6.x versie vanwege het "gedoe".

Na wat zoeken heb ik het met deze docker-compose.yaml volledig werken:

code:

version: "3"
services:
  pihole:
    container_name: PiHole
    image: pihole/pihole:2024.07.0
    network_mode: host
    environment:
      TZ: 'Europe/Amsterdam'
      WEBPASSWORD: ''
    volumes:
      - '/opt/pihole/etc-pihole/:/etc/pihole/'
      - '/opt/pihole/etc-dnsmasq.d/:/etc/dnsmasq.d/'
      - '/opt/pihole/etc-lighttpd/:/etc/lighttpd/'
    cap_add:
      - NET_ADMIN
    restart: always

Dit is dus wel de laatste 5.x dokter versie die er is maar deze voldoet voor mij op dit moment prima. Misschien dat je de versie ook naar latest kan omzetten maar dat heb ik niet geprobeerd.

[DjoeC]

Ik draai al lang op V5, een basis V6 heb ik ook draaiend - eigenlijk geen issues mee gehad, alleen unbound heb ik (nog) niet gekoppeld. Die heb ik t liefst ook in een losse container op vmaclan. IP adressen heb ik voldoende met een 10.x.x.x netwerk.

Komende week Heb net wel even de hier door mij gelinkte video bekeken. Geloof dat alles er wel inzit al is het wat "rommelig" gemaakt.

[Freee!!]

DjoeC schreef op zaterdag 1 maart 2025 @ 13:54:
Ik draai al lang op V5, een basis V6 heb ik ook draaiend - eigenlijk geen issues mee gehad, alleen unbound heb ik (nog) niet gekoppeld. Die heb ik t liefst ook in een losse container op vmaclan.

Als je toch een unbound als losse container gebruikt met macvlan, zou ik meteen twee verschillende nemen, Pi-Hole kan twee verschillende upstreams gebruiken en als er dan wat met de ene is, is de andere nog steeds beschikbaar.

[DjoeC]

Freee!! schreef op zaterdag 1 maart 2025 @ 14:57:
[...]

Als je toch een unbound als losse container gebruikt met macvlan, zou ik meteen twee verschillende nemen, Pi-Hole kan twee verschillende upstreams gebruiken en als er dan wat met de ene is, is de andere nog steeds beschikbaar.

Goed idee! Al komen ze dan wel op dezelfde pi.... Uiteindelijk wil ik een kloon van die pi "klaar hebben liggen" voor als er waar dan ook iets mis gaat.

Ik heb inmiddels wel ontdekt dat ik naast een vast IP ook een MAC adres moet meegeven om de macvlan hosts in de Fritzbox herkenbaar te houden. Dat lijkt een "nieuw" docker dingetje.....

code:

    networks:
      macvlan:
        ipv4_address: ${pihole02_ip}
    mac_address: xx:xx:xx:xx:xx:xx

Ik pak het MAC address van de 1e keer dat het ip in m'n netwerklijst verschijnt, anders wisselt het na elke docker compose.

[Freee!!]

DjoeC schreef op zaterdag 1 maart 2025 @ 15:20:
[...]
Goed idee! Al komen ze dan wel op dezelfde pi.... Uiteindelijk wil ik een kloon van die pi "klaar hebben liggen" voor als er waar dan ook iets mis gaat.

Ik heb vier Pi-Holes (twee ":latest", twee die ik handmatig update) verdeeld over twee RPi's met twee Unbounds per RPi.

Ik heb inmiddels wel ontdekt dat ik naast een vast IP ook een MAC adres moet meegeven om de macvlan hosts in de Fritzbox herkenbaar te houden. Dat lijkt een "nieuw" docker dingetje.....

code:

    networks:
      macvlan:
        ipv4_address: ${pihole02_ip}
    mac_address: xx:xx:xx:xx:xx:xx

Ik pak het MAC address van de 1e keer dat het ip in m'n netwerklijst verschijnt, anders wisselt het na elke docker compose.

Dat probleem heb ik niet, door problemen met een eerder modem heb ik DHCP ook op een RPi, mijn Fritzbox is uitsluitend modem/switch, zelfs de WiFi zit op aparte AC's (met een controller in Docker op een RPi).

[DjoeC]

Freee!! schreef op zaterdag 1 maart 2025 @ 15:41:
[...]

Ik heb vier Pi-Holes (twee ":latest", twee die ik handmatig update) verdeeld over twee RPi's met twee Unbounds per RPi.

[...]

Dat probleem heb ik niet, door problemen met een eerder modem heb ik DHCP ook op een RPi, mijn Fritzbox is uitsluitend modem/switch, zelfs de WiFi zit op aparte AC's (met een controller in Docker op een RPi).

Tja, DHCP naar de Pi ben ik huiverig voor.... Als ik nu serieuze problemen heb is het de DNS over naar de ISP en klaar. Maar, met standby Pi's moet het wel kunnen natuurlijk. Er draaien momenteel al 5 Pi's en nog een hele hoop meer meuk. Ergens houdt t een keertje op (al liggen er hier nog 4 op de stapel), ook met de tijd die ik erin wil steken. Heb nog meer projecten....

[Freee!!]

DjoeC schreef op zaterdag 1 maart 2025 @ 15:55:
[...]
Tja, DHCP naar de Pi ben ik huiverig voor.... Als ik nu serieuze problemen heb is het de DNS over naar de ISP en klaar. Maar, met standby Pi's moet het wel kunnen natuurlijk. Er draaien momenteel al 5 Pi's en nog een hele hoop meer meuk. Ergens houdt t een keertje op (al liggen er hier nog 4 op de stapel), ook met de tijd die ik erin wil steken. Heb nog meer projecten....

Als het echt nodig is, kan ik DHCP naar de Fritzbox zetten, maar ik heb een tweede RPi met DHCP klaar staan, hoef ik alleen de DHCP server maar aan te zetten.

[andregroeneveld]

@nero@
Wat draai je nog meer naast Pi-Hole op dit moment ??

Een Arduino
Twee BananaPi`s

Refereer je naar dit stukje in het pihole.toml file?
# Possible values are:
# comma-separated list of <[ip_address:]port>
port = "8080o,443os,[::]:8080o,[::]:443" ### CHANGED, default = "80o,443os,[::]:80o,[::]:443os"

[ Voor 55% gewijzigd door andregroeneveld op 03-03-2025 10:42 ]

[DjoeC]

Wat is trouwens de "aanbevolen" Unbound Docker container om met pihole te gebruiken? Ik heb nu

code:

mvance/unbound-rpi:latest

maar die lijkt me af en toe in de steek te laten..... Kan ook zijn dat ik nog wat aan de config moet sleutelen.

[Toet3r]

DjoeC schreef op maandag 3 maart 2025 @ 15:14:
Wat is trouwens de "aanbevolen" Unbound Docker container om met pihole te gebruiken? Ik heb nu

code:

mvance/unbound-rpi:latest

maar die lijkt me af en toe in de steek te laten..... Kan ook zijn dat ik nog wat aan de config moet sleutelen.

Ik gebruik zelf klutchell/unbound.
mvance is standaard ingesteld op gebruik maken van servers van cloudflare.
Waarmee naar mijn idee het idee van zelf een DNS server draaien enigzins verloren gaat.

[Cyberpope]

Iemand een hele goed guide voor het opzetten van pihole en unbound in docker setup. Degene die ik gebruik geven problemen met bestandstoegang.

[Slonzo]

Cyberpope schreef op maandag 3 maart 2025 @ 15:49:
Iemand een hele goed guide voor het opzetten van pihole en unbound in docker setup. Degene die ik gebruik geven problemen met bestandstoegang.

... letterlijk de post boven de jouwe?

[Cyberpope]

Slonzo schreef op maandag 3 maart 2025 @ 16:00:
[...]


... letterlijk de post boven de jouwe?

Nou... #hoedan? Ik zie alleen dit:

Toet3r schreef op maandag 3 maart 2025 @ 15:43:
[...]

Ik gebruik zelf klutchell/unbound.
mvance is standaard ingesteld op gebruik maken van servers van cloudflare.
Waarmee naar mijn idee het idee van zelf een DNS server draaien enigzins verloren gaat.

Kom ik niet heel ver mee hoor.

En ook alleen zoiets als dit:

Pixelmagic schreef op zaterdag 1 maart 2025 @ 13:31:
[...]


Ik ben hier de boel opnieuw aan het inrichten en wilde ook van echte install (op een vmware machine) naar een docker installatie. Tegelijk wilde ik nog even niet naar de 6.x versie vanwege het "gedoe".

Na wat zoeken heb ik het met deze docker-compose.yaml volledig werken:

code:

version: "3"
services:
  pihole:
    container_name: PiHole
    image: pihole/pihole:2024.07.0
    network_mode: host
    environment:
      TZ: 'Europe/Amsterdam'
      WEBPASSWORD: ''
    volumes:
      - '/opt/pihole/etc-pihole/:/etc/pihole/'
      - '/opt/pihole/etc-dnsmasq.d/:/etc/dnsmasq.d/'
      - '/opt/pihole/etc-lighttpd/:/etc/lighttpd/'
    cap_add:
      - NET_ADMIN
    restart: always

Kom ik niet erg ver mee... Staat zelfs geen verwijzing naar unbound in de yaml.

Volgens mij ben ik nu heel ver, maar zie ik in de pihole webinterface nog steeds een verwijzing naar google staan, dus volgens mij geen unbound. Maar kan me vergissen.

[Toet3r]

Cyberpope schreef op maandag 3 maart 2025 @ 15:49:
Iemand een hele goed guide voor het opzetten van pihole en unbound in docker setup. Degene die ik gebruik geven problemen met bestandstoegang.

Zelf heb ik pihole en unbound in een docker container draaien met macvlan.
Hierdoor hebben beide containers hun eigen ip-adres.

Voor de container settings gebruik ik docker compose.
Hiermee is de container heel makkelijk opnieuw maken na een update.
Je haalt de nieuwe image binnen met

docker pull <naam:tag>

Daarna container opnieuw maken met commando

docker compose up -d <container naam>

Ik gebruik deze docker-compse

code:

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    mac_address: d0:ca:ab:cd:ef:01
    hostname: pihole
    restart: unless-stopped
    environment:
      FTLCONF_dns_upstreams: 192.168.1.251
      TZ: 'europe/amsterdam'
    volumes:
      - '/docker/pihole/pihole:/etc/pihole'
    networks:
      piNet:
        ipv4_address: 192.168.1.250

  unbound:
    container_name: unbound
    image: klutchell/unbound:latest
    mac_address: d0:ca:ab:cd:ef:02
    restart: unless-stopped
    volumes:
      - '/docker/pihole/unbound:/etc/unbound/custom.conf.d'
    networks:
      piNet:
        ipv4_address: 192.168.1.251

networks:
  piNet:
    driver: macvlan
    driver_opts:
      parent: eth0
    ipam:
      config:
        - subnet: 192.168.1.0/24
          gateway: 192.168.1.1
          ip_range: 192.168.1.248/29

Mijn unbound.conf

code:

server:
  # The verbosity level.
  # Level 0: No verbosity, only errors.
  # Level 1: Gives operational information.
  # Level 2: Gives detailed operational information including short information per query.
  # Level 3: Gives query level information, output per query.
  # Level 4: Gives algorithm level information.
  # Level 5: Logs client identification for cache misses.
  # Default: 1
  verbosity: 0

  # Interface to use to connect to the network.
  # This interface is listened to for queries from clients, and answers to clients are given from it.
  interface: 127.0.0.1

  # The port number on which the server responds to queries.
  # Default: 53
  port: 53

  # Enable or disable whether IPv4 queries are answered or issued.
  # Default: yes
  do-ip4: yes

  # Enable or disable whether IPv6 queries are answered or issued.
  # Default: yes
  do-ip6: no

  # Enable or disable whether UDP queries are answered or issued.
  # Default: yes
  do-udp: yes

  # Enable or disable whether TCP queries are answered or issued.
  # Default: yes
  do-tcp: yes

  # Will trust glue only if it is within the servers authority.
  # Default: yes
  harden-glue: yes

  # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes bogus.
  # Default: yes
  harden-dnssec-stripped: yes

  # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
  # Default: no
  use-caps-for-id: no

  # Default: 1232
  edns-buffer-size: 1232

  # Perform prefetching of close to expired message cache entries
  # This only applies to domains that have been frequently queried
  # Default: no
  prefetch: yes

  # The number of threads to create to serve clients. Use 1 for no threading.
  # Default: 1
  num-threads: 1

  # Ensure kernel buffer is large enough to not lose messages in traffic spikes
  # Default: 0
  # so-rcvbuf: 1m

  # Ensure privacy of local IP ranges
  private-address: 192.168.0.0/16
  private-address: 169.254.0.0/16
  private-address: 172.16.0.0/12
  private-address: 10.0.0.0/8
  private-address: fd00::/8
  private-address: fe80::/10

Success

[ Voor 40% gewijzigd door Toet3r op 03-03-2025 16:54 ]

[Pixelmagic]

Cyberpope schreef op maandag 3 maart 2025 @ 16:34:
[...]

Nou... #hoedan? Ik zie alleen dit:


[...]


Kom ik niet heel ver mee hoor.

En ook alleen zoiets als dit:

[...]

Kom ik niet erg ver mee... Staat zelfs geen verwijzing naar unbound in de yaml.

Volgens mij ben ik nu heel ver, maar zie ik in de pihole webinterface nog steeds een verwijzing naar google staan, dus volgens mij geen unbound. Maar kan me vergissen.

Ik geef je een startpunt om mee te beginnen, ik gebruik unbound (nog) niet omdat ik de toegevoegde waarde (nog) niet zie.

Als je al niet lekker thuis bent in docker dan zou ik eerst eens met de basis starten, juist zaken als apart netwerk maken het naar mijn idee complex.

Succes

[Airw0lf]

@nero355 - misschien herinner je je deze nog?

Airw0lf schreef op maandag 24 februari 2025 @ 17:27:
@nero355 - waar ik last van heb:

[...]

Nu is er een client in het wired vlan met 192.168.210.35. Die heeft 192.168.210.235 als dns server. Die rapporteert bij alle dns aanvragen dat morpheus.tech.lan de dns server is die antwoord geeft.

Bovenstaande komt door de instelling piholePTR (van pihole.toml). In pihole v6 wordt die fqdn (d.w.z. morpheus.tech.lan) mee terug gegeven als dns server bij het beantwoorden van een dns aanvraag. In pihole v5 is dit niet zo - daar wordt de fqdn van dns server van het vlan mee terug gegeven.

Daar ben ik achtergekomen door HOSTNAMEFQDN te vervangen door HOSTNAME waardoor (in mijn geval) alleen morpheus wordt teruggegeven.

Dat is nog tot daar aan toe - maar bij de beheer applicaties wordt het vervelender: als ik een nslookup doe naar morpheus.tech.lan, dan krijg ik bij de eerder genoemde client het IP adres 192.168.210.235 als antwoord. Als ik de pihole webui wil aanspreken met morpheus.tech.lan:88/admin, dan werkt dat natuurlijk niet - die draait alleen via het tech.lan (d.w.z. 192.168.139.235/24) beheer-domein. Hetzelfde geldt voor alle andere beheer applicaties zoals Portainer, Omada en Synthing.

Nu terug op v5 werkt dit allemaal weer zoals verwacht...

Dit heb ik op kunnen lossen met een paar aanpassingen:
(1) - de instelling dns.domain (in pihole.toml) omzetten van tech.lan naar lan.
(2) - de volgende regels in het veld dnsmasq_lines (in pihole.toml) gestoken:
domain=tech.lan,192.168.139.0/24,local
dhcp-option=eth0,option:domain-name,tech.lan
dhcp-option=eth0,option:domain-search,.
(3) - de no-host in de custom dnsmasq config weggehaald

Inzake (2): het vlan tech.lan is het management vlan met 192.168.139.0/24.

Nu werkt de dns resolving voor morpheus.tech.lan weer zoals verwacht.

[Slonzo]

Cyberpope schreef op maandag 3 maart 2025 @ 16:34:
Nou... #hoedan? Ik zie alleen dit:
Kom ik niet heel ver mee hoor.

Ik had over het woordje 'guide' gelezen, mea culpa

[Slonzo]

Toet3r schreef op maandag 3 maart 2025 @ 16:49:
Zelf heb ik pihole en unbound in een docker container draaien met macvlan.
Hierdoor hebben beide containers hun eigen ip-adres.
...
Ik gebruik deze docker-compse

code:

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    mac_address: d0:ca:ab:cd:ef:01
    hostname: pihole
    restart: unless-stopped
    environment:
      FTLCONF_dns_upstreams: 192.168.1.251
      TZ: 'europe/amsterdam'
    volumes:
      - '/docker/pihole/pihole:/etc/pihole'
    networks:
      piNet:
        ipv4_address: 192.168.1.250

  unbound:
    container_name: unbound
    image: klutchell/unbound:latest
    mac_address: d0:ca:ab:cd:ef:02
    restart: unless-stopped
    volumes:
      - '/docker/pihole/unbound:/etc/unbound/custom.conf.d'
    networks:
      piNet:
        ipv4_address: 192.168.1.251

networks:
  piNet:
    driver: macvlan
    driver_opts:
      parent: eth0
    ipam:
      config:
        - subnet: 192.168.1.0/24
          gateway: 192.168.1.1
          ip_range: 192.168.1.248/29

Ik gebruik ongeveer dezelfde setup, maar dan met cloudflared (voor DoH) ipv unbound. Macvlan is ideaal om meerdere instances te kunnen draaien op dezelfde server. Ik gebruik wel een andere (private) IP range voor de containers zelf; deze manier kan IP conflicten geven als je DHCP server niet goed geconfigureerd staat + ik vind het onnodig/onwenselijk dat de cloudflared (of in jouw geval unbound) ook publiek (intern) bereikbaar is.

[ Voor 9% gewijzigd door Slonzo op 03-03-2025 19:14 ]

[Airw0lf]

@Slonzo en anderen:
Mij lijkt het handig om tenminste ook de pihole log te mounten met:

code:

- /opt/docker/pihole/v6/var-log-pihole:/var/log/pihole

Op die manier heb je iets om terug te zoeken - mocht het toch niet werken zoals bedoeld.

[ Voor 7% gewijzigd door Airw0lf op 03-03-2025 19:29 ]

[boomer21]

Freee!! schreef op zaterdag 1 maart 2025 @ 15:41:
[...]

Ik heb vier Pi-Holes (twee ":latest", twee die ik handmatig update) verdeeld over twee RPi's met twee Unbounds per RPi.

[...]

Dat probleem heb ik niet, door problemen met een eerder modem heb ik DHCP ook op een RPi, mijn Fritzbox is uitsluitend modem/switch, zelfs de WiFi zit op aparte AC's (met een controller in Docker op een RPi).

Mag als leek vragen wat voordeel is van 4 pi-hole i.p.v 1?

[Webgnome]

Redundancy? Als er eentje uitklapt heb je de ander nog ? Heb er zelf twee. Ze klappen er eigenlijk nooit uit, soms is het toch wel handig als ik weer eens aan het klooien ben met eentje

[Airw0lf]

Webgnome schreef op dinsdag 4 maart 2025 @ 08:54:
Redundancy? Als er eentje uitklapt heb je de ander nog ? Heb er zelf twee. Ze klappen er eigenlijk nooit uit, soms is het toch wel handig als ik weer eens aan het klooien ben met eentje

Maar voor "klooi-" en "pruts-werk" is docker uitgevonden...

[W1ck1e]

boomer21 schreef op dinsdag 4 maart 2025 @ 08:53:
[...]

Mag als leek vragen wat voordeel is van 4 pi-hole i.p.v 1?

4 ipv 1 weet ik even niet.
Ik heb er zelf 2. Vanwege redundancy. En ze staan aan de 2 kanten van een interne wifi verbinding tussen 2 deco's. Clients hebben de pihole aan hun kant van de wifi verbinding als 1ste en de andere als 2de.
Als een pihole dan offline is door onderhoud of een storing dan werkt mijn dns nog steeds.

[Freee!!]

boomer21 schreef op dinsdag 4 maart 2025 @ 08:53:
[...]
Mag als leek vragen wat voordeel is van 4 pi-hole i.p.v 1?

Zoals anderen al aangegeven hebben: redundantie.
Als er een RPi uit ligt om wat voor reden dan ook (behalve stroomuitval en dan heb ik toch geen internet), draait de ander gewoon door.
Als een automatische update mislukt, draait de andere Pi-Hole, die niet automatisch bijgewerkt wordt, gewoon door.
Er moet wel heel veel aan de hand zijn als ik niet minimaal 1 Pi-Hole heb draaien.

[Toet3r]

Webgnome schreef op dinsdag 4 maart 2025 @ 08:54:
Redundancy? Als er eentje uitklapt heb je de ander nog ? Heb er zelf twee. Ze klappen er eigenlijk nooit uit, soms is het toch wel handig als ik weer eens aan het klooien ben met eentje

Dit is ook mijn ervaring. Daarom ondanks dat ik er eerder aan zat te denken geen 2e pi opgetuigd.

Zoals anderen al aangegeven hebben: redundantie.
Als er een RPi uit ligt om wat voor reden dan ook (behalve stroomuitval en dan heb ik toch geen internet), draait de ander gewoon door.
Als een automatische update mislukt, draait de andere Pi-Hole, die niet automatisch bijgewerkt wordt, gewoon door.
Er moet wel heel veel aan de hand zijn als ik niet minimaal 1 Pi-Hole heb draaien.

Daarom draai ik het in Docker
Met docker kan ik heel makkelijk een versie terug als er iets kapot gaat na de update. Kwestie van de tag veranderen in docker compose file.

[ Voor 41% gewijzigd door Toet3r op 04-03-2025 10:25 ]

[W1ck1e]

Toet3r schreef op dinsdag 4 maart 2025 @ 10:23:
[...]

Dit is ook mijn ervaring. Daarom ondanks dat ik er eerder aan zat te denken geen 2e pi opgetuigd.

[...]

Daarom draai ik het in Docker
Met docker kan ik heel makkelijk een versie terug als er iets kapot gaat na de update. Kwestie van de tag veranderen in docker compose file.

Een kapotte pihole is geen probleem vanaf dat je het weet, tot dan echter mogelijk wel. En wat doe je als je niet thuis bent ?

Daarnaast door 2 piholes te hebben kan je in dat geval op naam naar die kapotte pihole, en hoef je het ipadres niet te gebruiken.

[Freee!!]

Toet3r schreef op dinsdag 4 maart 2025 @ 10:23:
[...]

Dit is ook mijn ervaring. Daarom ondanks dat ik er eerder aan zat te denken geen 2e pi opgetuigd.


[...]

Daarom draai ik het in Docker
Met docker kan ik heel makkelijk een versie terug als er iets kapot gaat na de update. Kwestie van de tag veranderen in docker compose file.

Ik draai ze ook in Docker (enige manier om meer dan 1 Pi-Hole op een RPi te draaien). En ja, fixen is gemakkelijk genoeg, maar ik ben niet alleen thuis en internettoegang moet wel door blijven gaan, ook als ik eens een uurtje aan het knutselen ben (of op mijn werk).

[Webgnome]

Airw0lf schreef op dinsdag 4 maart 2025 @ 09:02:
[...]


Maar voor "klooi-" en "pruts-werk" is docker uitgevonden...

ehm... nee. Redundancy is niet alleen maar eventjes twee instances op dezelfde 'server' draaien. Maak je je server stuk dan heb je alsnog niks. Ik speel wel eens met de installs en dan is het fijn als er ik een andere rpi heb die gewoon blijft doen wat ie moet doen..

[ Voor 39% gewijzigd door Webgnome op 04-03-2025 11:02 ]

[W1ck1e]

Freee!! schreef op dinsdag 4 maart 2025 @ 10:45:
[...]

Ik draai ze ook in Docker (enige manier om meer dan 1 Pi-Hole op een RPi te draaien). ....

Dan is er geen redundantie op hardware nivo.

[ed1703]

Webgnome schreef op dinsdag 4 maart 2025 @ 11:00:
[...]


ehm... nee. Redundancy is niet alleen maar eventjes twee instances op dezelfde 'server' draaien. Maak je je server stuk dan heb je alsnog niks. Ik speel wel eens met de installs en dan is het fijn als er ik een andere rpi heb die gewoon blijft doen wat ie moet doen..

Daarom zou je ook een 2e pi willen hebben en zoveel mogelijk in docker draaien en erop keepalived. Op een pi doe ik eigenlijk alleen nog maar systeemupdates en op mijn vps bij transip hetzelfde. Een docker container die je stuk maakt en herstellen is ook weinig moeite.

[ Voor 5% gewijzigd door ed1703 op 04-03-2025 11:14 ]

[Airw0lf]

Webgnome schreef op dinsdag 4 maart 2025 @ 11:00:
[...]

ehm... nee. Redundancy is niet alleen maar eventjes twee instances op dezelfde 'server' draaien. Maak je je server stuk dan heb je alsnog niks. Ik speel wel eens met de installs en dan is het fijn als er ik een andere rpi heb die gewoon blijft doen wat ie moet doen..

Een scriptje in een cronjob doet wonderen...
Bijvoorbeeld elke 5 minuten een ss -tulpn | grep 53.
Geen resultaat? Dan de tweede pihole container starten.

En inderdaad - als je op hardware nivo ook iets van redundantie wil is er wat meer werk.
Maar is verder niet heel veel anders - alleen het scriptje in de cronjob zal dan draaien over de as van een nslookup of een ping. Met een status-bestandje van de laatst bekende actieve pihole. Hierdoor weet je hoe de failover eruit zou moeten zien.

Wel lijkt het me handig om geen rsync (o.i.d) te doen tussen beide piholes...

[Freee!!]

W1ck1e schreef op dinsdag 4 maart 2025 @ 11:03:
[...]
Dan is er geen redundantie op hardware nivo.

Daarom heb ik dus twee RPi's met ieder twee Pi-Holes (en nog een paar andere RPi's voor andere dingen).

[W1ck1e]

W1ck1e schreef op dinsdag 4 maart 2025 @ 09:26:
[...]

Ik heb er zelf 2. Vanwege redundancy. En ze staan aan de 2 kanten van een interne wifi verbinding tussen 2 deco's. Clients hebben de pihole aan hun kant van de wifi verbinding als 1ste en de andere als 2de.
Als een pihole dan offline is door onderhoud of een storing dan werkt mijn dns nog steeds.

Met dnsbench krijg ik de volgende resultaten:

Aan deze kant van de wifi verbinding:



Aan de overkant van de wifi verbinding:



ik heb een 500/40 verbinding van ziggo

Beide piholes zijn
elk geinstalleerd op een rpi2b
op basis van dietpi, zonder docker
met de normale installatie van pihole (dat curl commando)

de tijden zijn volgens mij in secondes, dus effectief in het milliseconde bereik
waarbij de rode waarde de tijd weergeeft indien de informatie uit de cache van de pihole komt en er geen upstream server nodig is.

In de logging van de pihole zelf zijn dit soort getallen:



dus dnsbench meet ook de tijd van en naar de raspberry. Duh.

Ik vraag mij af of andere gebruikers hier heel andere getallen krijgen. Op andere hardware en met en zonder docker.

[ Voor 13% gewijzigd door W1ck1e op 05-03-2025 09:20 ]

[GieltjE]

W1ck1e schreef op woensdag 5 maart 2025 @ 09:08:
[...]
Ik vraag mij af of andere gebruikers hier heel andere getallen krijgen. Op andere hardware en met en zonder docker.

Met een Intel J5005, wel met docker maar met Redis erachter (draait ook nog Nextcloud met een paar TB, BitWarden en wat andere dingen):



- Edit -

Misschien relevanter 4.1 q/s, 3,99m domeinen in de lijst.

[ Voor 6% gewijzigd door GieltjE op 05-03-2025 14:22 ]

[W1ck1e]

GieltjE schreef op woensdag 5 maart 2025 @ 14:19:
[...]


Met een Intel J5005, wel met docker maar met Redis erachter (draait ook nog Nextcloud met een paar TB, BitWarden en wat andere dingen):

[Afbeelding]

Ha, ik weet je Network ID. Ik ga je hacken

Misschien relevanter 4.1 q/s, 3,99m domeinen in de lijst.

ik heb nog q/min. Jouw pihole zal wel niet in een huishouden staan.
en ik heb "maar" 224 duizend domeinen.

[ Voor 15% gewijzigd door W1ck1e op 05-03-2025 14:28 ]

[GieltjE]

W1ck1e schreef op woensdag 5 maart 2025 @ 14:22:
[...]

Ha, ik weet je Network ID. Ik ga je hacken

Prima, boschebollen als het je daadwerkelijk lukt

[andregroeneveld]

andregroeneveld schreef op maandag 3 maart 2025 @ 10:31:
@nero355
Wat draai je nog meer naast Pi-Hole op dit moment ??

Een Arduino
Twee BananaPi`s

Refereer je naar dit stukje in het pihole.toml file?
# Possible values are:
# comma-separated list of <[ip_address:]port>
port = "8080o,443os,[::]:8080o,[::]:443" ### CHANGED, default = "80o,443os,[::]:80o,[::]:443os"

Hi Nero, bedoel je bovenstaand file?

[alesandro_46]

andregroeneveld schreef op woensdag 5 maart 2025 @ 18:25:
[...]


Hi Nero, bedoel je bovenstaand file?

Correct @nero355 taggen helpt wellicht, anders krijgt ie geen trigger.

[Eraser127]

Eraser127 schreef op donderdag 27 februari 2025 @ 10:52:
Wilde PiHole net updaten (was al op V6), maar de core en web modules worden niet meegenomen?

Na de update:

code:

Core version is v6.0 (Latest: v6.0.4)
Web version is v6.0 (Latest: v6.0.1)
FTL version is v6.0.2 (Latest: v6.0.2)

Nah, ga eens even verder kijken. Core en Web interface worden weer niet meegenomen in de update:

code:

Core version is v6.0.4 (Latest: v6.0.5)
Web version is v6.0.1 (Latest: v6.0.2)
FTL version is v6.0.4 (Latest: v6.0.4)

Maar ik ben iig niet de enige: https://discourse.pi-hole...re-and-webinterface/77504

[andregroeneveld]

andregroeneveld schreef op woensdag 5 maart 2025 @ 18:25:
[...]


Hi Nero, bedoel je bovenstaand file?

@nero355

[(KBX) Harkanoid]

Bij mij gaat de experiabox van groen naar knipperend blauw wanneer Pi hole actief is , 192.168.2.254 is dan ook niet meer benaderbaar , wat kan je daar aan doen?

[sweetdude]

(KBX) Harkanoid schreef op zondag 9 maart 2025 @ 10:51:
Bij mij gaat de experiabox van groen naar knipperend blauw wanneer Pi hole actief is , 192.168.2.254 is dan ook niet meer benaderbaar , wat kan je daar aan doen?

je instellingen goed zetten en indien nodig corrigeren

Maar alle gekheid op een stokje, kun je iets meer info geven hoe heb je het allemaal aan elkaar geknoopt? Want met deze info kan het alles zijn.

[(KBX) Harkanoid]

Ik laat de dns van de hysteriabox verwijzen naar 192
168.2.32 (de Pi) die heeft als dns 1.1.1.1 , internet werkt ook gewoon alle devices krijgen automatisch dns van de PiHole echter de box zelf is niet meer benaderbaar

[sweetdude]

(KBX) Harkanoid schreef op zondag 9 maart 2025 @ 11:11:
Ik laat de dns van de hysteriabox verwijzen naar 192
168.2.32 (de Pi) die heeft als dns 1.1.1.1 , internet werkt ook gewoon alle devices krijgen automatisch dns van de PiHole echter de box zelf is niet meer benaderbaar

Daar gaat het dus mis, je experiabox gaat dus niet naar buiten maar naar binnen (je eigen pihole) kijken voor het DNS verzoek. Daar wordt hij hysterisch van.

Je dient in de DHCP instellingen van je experiabox aan te geven dat de clients die connecteren het IP adres van de Pihole krijgen uitgedeeld in jouw geval de 192.168.2.32.
De DNS servers die je experiabox gebruikt van je provider kun je laten staan, of wijzigen in die van google of openDNS 208.67.222.222 en als backup 208.67.220.220

[(KBX) Harkanoid]

Aha dus dhcp uitzetten op de hysteriabox en via de PiHole laten lopen , gek genoeg werkt het hier al een half jaar gewoon op deze manier , alleen dat lampje.doet wat gek (V10A)

[W1ck1e]

(KBX) Harkanoid schreef op zondag 9 maart 2025 @ 15:25:
Aha dus dhcp uitzetten op de hysteriabox en via de PiHole laten lopen , gek genoeg werkt het hier al een half jaar gewoon op deze manier , alleen dat lampje.doet wat gek (V10A)

Ik denk niet dat @sweetdude dat bedoelt.
Volgens mij wel het volgende.
dhcp aan op experiabox
uit op pihole (static ipadres)
experiabox geeft middels dhcp het adres van de pihole als dns server door aan de clients.

[ Voor 6% gewijzigd door W1ck1e op 09-03-2025 15:38 ]

[sweetdude]

W1ck1e schreef op zondag 9 maart 2025 @ 15:37:
[...]

Ik denk niet dat @sweetdude dat bedoelt.
Volgens mij wel het volgende.
dhcp aan op experiabox
uit op pihole (static ipadres)
experiabox geeft middels dhcp het adres van de pihole als dns server door aan de clients.

Inderdaad, ik bedoelde dat de experiabox als DHCP server fungeerde en de pihole als DNS server naar de clients adverteerde.
Maar er zijn meer wegen naar rome. PiHole heeft een ingebouwde DHCP server. dus dat kan ook.

[W1ck1e]

sweetdude schreef op zondag 9 maart 2025 @ 15:56:

Inderdaad, ik bedoelde dat de experiabox als DHCP server fungeerde en de pihole als DNS server naar de clients adverteerde.
Maar er zijn meer wegen naar rome. PiHole heeft een ingebouwde DHCP server. dus dat kan ook.

Ja dat kan, maar als dat nu nog niet zo is dan zijn het meer aanpassingen. En meer mogelijkheden om het fout te doen.