[Pi-Hole] Ervaringen & discussie

[W1ck1e]

Webgnome schreef op vrijdag 21 februari 2025 @ 08:09:

offtopic:
Vertraging door het gebruik van wifi? wait what?

Ik bedoel dat "bekabeld sneller is dan wifi".
(he, alweer van die aanhalingstekens)

[Yucko]

ik krijg v6 (proxmox, LXC) maar niet aan de praat.
iedere keer als ik update gravity doe dan krijg ik

code:

[✗] Status: Connection Refused

zowel voor de standaard lijst (https://raw.githubusercon...nBlack/hosts/master/hosts) als alle lijsten die ik zelf toevoeg (zoals bv. big.oisd.nl)
Dezelfde lijsten werken wel in mijn AGH container

• heb het geprobeerd met een debian 12 als met een alpine LXC.
• unprivileged en privileged
• er draait alle gevallen geen firewall die dingen tegenhoudt
• heb geprobeerd met aparte user die in docker groep zit, maar ook met root (UID: 0 en GID: 0)

iemand die tegen ditzelfde probleem is aangelopen en weet in welke hoek ik het moet zoeken?

edit:
raar, ondanks dat upstream servers in PiHole gedefineerd waren op 1.1.1.1 en 9.9.9.10 werkte het niet omdat via DHCP de dns van de LXC en blijkbaar daardoor ook voor de Pi-Hole container nog naar de oude PiHole v5 op het netwerk verwees.
De stack aangepast en als dns 1.1.1.1 en 9.9.9.10 meegegeven en nu haalt hij de lijsten wel op.

[ Voor 35% gewijzigd door Yucko op 21-02-2025 14:04 ]

[Stimulate14]

nero355 schreef op donderdag 20 februari 2025 @ 19:38:
[...]

Genoeg anderen die dat helemaal goed hebben gemaakt, want https://discourse.pi-hole.net/ heeft gisteren serieuze downtime gehad

En heel wat van de vragen en "problemen" hadden voorkomen kunnen worden als mensen nou eens gewoon de Change Log zouden lezen

Ja, dat inlezen is kut werk dat doen er maar weinig.
En daar ben ik 1 van hoor haha.

Ik wacht wel even een update of 2 voordat ik over ga.

[strandbal]

Change log of niet, ik krijg mijn Ubuntu LXC container met pihole erin ook niet op 6... De update krijg ik nu zonder errors voor elkaar, alle vinkjes groen, maar geen DNS resolving en de admin interface geeft een fraaie error 403...

Snapshot maar teruggezet, ik wacht nog wel even met updaten dan, geen idee wat er mis gaat en ik kan ook niet veel debuggen.

Edit: Ah, lighttpd gooide nog roet in het eten, zie hier. Het ging dingen doen. Maar... Upstream servers weg, DHCP instellingen en reserveringen weg, lang niet alle settings zijn gemigreerd... De update gaat verre van vlekkeloos, snapshot maar weer terug, later een herinstallatie doen...

[ Voor 34% gewijzigd door strandbal op 21-02-2025 11:52 ]

[nero355]

strandbal schreef op vrijdag 21 februari 2025 @ 11:39:
Maar... Upstream servers weg, DHCP instellingen en reserveringen weg, lang niet alle settings zijn gemigreerd...

De update gaat verre van vlekkeloos, snapshot maar weer terug, later een herinstallatie doen...

Doe eens een REPAIR of desnoods als uiterste oplossing effe

code:

pihole checkout dev
pihole -up
pihole checkout master
pihole -up

Om zodoende het een en ander aan scripts te triggeren die de boel hopelijk voor je fixen

Best wel balen dat het niet vlekkeloos gaat, want er zit echt een hoop werk in het v5 naar v6 migreren van dingen van wat ik zo gauw heb gezien !!

Gisteren zelfs een grapjas een topic gestart dat die "teleurgesteld" is dat alles in één keer goed ging

[beerns]

ik heb de update gedraaid, mijn unbound ip/poort was verwijderd en dat ff toegevoegd en feitelijk werkte het gewoon daarna, behalve de remote app op IOS. Die heb ik geüpdatet, heb een app password aangemaakt in Pihole 6.
In de remote app nieuwe instance aangemaakt, app pw ingevuld dat gaat allemaal netjes, maar de app blijft mij een fout geven op de /api.
Dr staat dat default de link /api is. Dus ik heb https opgegeven, ip adres v mn PI, poortje ingevuld en verder valt er niet zo heel in te vullen. Echter de app blijft zeggen : invalid URL.
Iemand een idee wat ik fout doe?

[Kjoe_Ljan]

strandbal schreef op vrijdag 21 februari 2025 @ 11:39:
Change log of niet, ik krijg mijn Ubuntu LXC container met pihole erin ook niet op 6... De update krijg ik nu zonder errors voor elkaar, alle vinkjes groen, maar geen DNS resolving en de admin interface geeft een fraaie error 403...

Snapshot maar teruggezet, ik wacht nog wel even met updaten dan, geen idee wat er mis gaat en ik kan ook niet veel debuggen.

Edit: Ah, lighttpd gooide nog roet in het eten, zie hier. Het ging dingen doen. Maar... Upstream servers weg, DHCP instellingen en reserveringen weg, lang niet alle settings zijn gemigreerd... De update gaat verre van vlekkeloos, snapshot maar weer terug, later een herinstallatie doen...

Dit gebeurde bij mij ook. Ik weet niet of bij mij lighttpd roet in het eten gooide, of Unbound ofzo, maar de upgrade bleef hangen op het resolven van DNS, en toen had het hele huis ineens geen verbinding meer.
Ik heb ook een backup terug moeten zetten.

[Freee!!]

De updates blijven binnenkomen:

code:

Docker Tag 2025.02.3   Core v6.0.3   FTL v6.0.1   Web interface v6.0.1

[Toet3r]

beerns schreef op vrijdag 21 februari 2025 @ 17:14:
ik heb de update gedraaid, mijn unbound ip/poort was verwijderd en dat ff toegevoegd en feitelijk werkte het gewoon daarna, behalve de remote app op IOS. Die heb ik geüpdatet, heb een app password aangemaakt in Pihole 6.
In de remote app nieuwe instance aangemaakt, app pw ingevuld dat gaat allemaal netjes, maar de app blijft mij een fout geven op de /api.
Dr staat dat default de link /api is. Dus ik heb https opgegeven, ip adres v mn PI, poortje ingevuld en verder valt er niet zo heel in te vullen. Echter de app blijft zeggen : invalid URL.
Iemand een idee wat ik fout doe?

Er is best wel een hoop veranderd aan de api. Grote kans dat dit de oorzaak is. Afwachten tot de IOS app wordt ge-updated.

[Raven]

nero355 schreef op vrijdag 21 februari 2025 @ 15:07:
Gisteren zelfs een grapjas een topic gestart dat die "teleurgesteld" is dat alles in één keer goed ging

Serieus?

[strandbal]

Kjoe_Ljan schreef op vrijdag 21 februari 2025 @ 17:20:
[...]


Dit gebeurde bij mij ook. Ik weet niet of bij mij lighttpd roet in het eten gooide, of Unbound ofzo, maar de upgrade bleef hangen op het resolven van DNS, en toen had het hele huis ineens geen verbinding meer.
Ik heb ook een backup terug moeten zetten.

Mijn lxc container had als dns server zichzelf, dat was niet handig, toen kreeg ik tijdens de update ook een resolve error. Misschien bij jou ook zoiets?

[Toet3r]

Raven schreef op vrijdag 21 februari 2025 @ 18:13:
[...]

Serieus?

Denk dat ie dit topic bedoeld. Had hem ook gezien. Vond het wel grappig.
https://discourse.pi-hole...-very-disappointing/76015

[Kjoe_Ljan]

strandbal schreef op vrijdag 21 februari 2025 @ 18:16:
[...]


Mijn lxc container had als dns server zichzelf, dat was niet handig, toen kreeg ik tijdens de update ook een resolve error. Misschien bij jou ook zoiets?

Waarschijnlijk wel. Ik heb de stappen ooit doorlopen om de DNS recursief te maken. Pi-hole moet dan ingesteld worden met 127.0.0.1 als DNS. Zie https://docs.pi-hole.net/...nbound/#configure-pi-hole.

Ik zal er binnenkort nog eens naar kijken. Bedankt voor je reactie in elk geval. Dit wijst me richting een oplos richting.

[Jazzy]

Ook hier een drama bij de upgrade naar v6. Verloor complete toegang tot de webinterface en ook DNS-queries kreeg ik een REFUSED op. Had direct al door dat er iets mis was toen ik bij bij het uitvoeren van de update zag dat ik een nieuw wachtwoord kreeg voor de webinterface, mijn configuratie was dus al stuk. Kreeg op geen enkele manier meer toegang, met of zonder /admin/login.php en op hostnaam of IP-adres.

Sowieso een hele beroerde beslissing om die redirect naar /admin alleen nog maar te doen als je hem op pi.hole benadert en in alle andere gevallen niets meer dan een 403 te presenteren. Qua gebruiksvriendelijkheid is dat echt niet meer van deze tijd.

Na een half uurtje troubleshooten en proberen te fixen maar voor gekozen om mijn Raspberry Pi en nieuw image te geven en opnieuw te beginnen. Om vervolgens te ontdekken dat conditional forwarding uit de webinterface gesloopt is. Enige voordeel wat ik hiervan zie is dat die verwarrende lap tekst over het forwarden van DNS-queries naar je DHCP-server nu weg is, maar verder echt onbegrijpelijk.

Dat verwijzen naar de changelog vind ik ook wel iets van. Als je een breaking change introduceert mag je best een waarschuwing geven voor de upgrade blind door te voeren en gebruikers in verwarring achter te laten. Alsof iedereen eerst even de changelogs gaat lezen voordat je de applicatie of het OS bijwerkt.

/einde rant

[dss58]

Na 1 dag probleemloos met V6 en verse install kreeg ik allemaal vreemde dingen op 't scherm, na een hoop gezoek heb ik het URL veranderd van http naar https en de problemen verdwenen allemaal ! Het is dus zaak om goed op het URL te letten met V6 !

[Toet3r]

@Jazzy
Ik kan bij mij nog steeds gewoon op ip-adres bij de webinterface <ip adress>/admin.

Conditional forwarding zit ook nog steeds gewoon in de webinterface. Onderaan bij tab DNS onder settings.

Ik snap dat niet bij iedereen de upgrade naar versie 6 goed is gegaan en dat een oplossing ook niet altijd direct gevonden is. Maar ik lees ook dat mensen dingen zeggen die gewoon niet kloppen en soms ook weinig tot geen moeite doen om een oplossing te zoeken maar gelijk gaan klagen. Dit zie ik niet alleen bij in dit geval een pi-hole upgrade maar tegenwoordig op heel veel plekken.

[Toet3r]

dss58 schreef op vrijdag 21 februari 2025 @ 19:12:
Na 1 dag probleemloos met V6 en verse install kreeg ik allemaal vreemde dingen op 't scherm, na een hoop gezoek heb ik het URL veranderd van http naar https en de problemen verdwenen allemaal ! Het is dus zaak om goed op het URL te letten met V6 !

Klopt. Je kan bij settings onder all settings en dan de tab webserver and api
bij de settings webserver.port

80o,443os,[::]:80o,[::]:443os

veranderen in

80or,443os,[::]:80or,[::]:443os

Hier door wordt http automatisch naar https ge-redirect.

[Jazzy]

Toet3r schreef op vrijdag 21 februari 2025 @ 19:16:
@Jazzy
Conditional forwarding zit ook nog steeds gewoon in de webinterface. Onderaan bij tab DNS onder settings.

Kan het zijn dat je in de war bent met Custom DNS Servers? Want conditional forwarding staat er bij mij niet meer bij.

[khorions]

Jazzy schreef op vrijdag 21 februari 2025 @ 19:22:
[...]
Kan het zijn dat je in de war bent met Custom DNS Servers? Want conditional forwarding staat er bij mij niet meer bij.

[Afbeelding]

Kan je eens proberen basic naar expert te zetten. Daarna via all settings zoeken naar "dns.revServers"?

[Jazzy]

khorions schreef op vrijdag 21 februari 2025 @ 19:26:
[...]


Kan je eens proberen basic naar expert te zetten. Daarna via all settings zoeken naar "dns.revServers"?

Alleen al het omschakeln naar Expert was al voldoende om Conditional Forwarding zichtbaar te maken onder Settings, DNS. Bedankt!

[Jazzy]

Dan nog even over die tekst.

If not configured as your DHCP server, Pi-hole typically won't be able to determine the names of devices on your local network. As a result, tables such as Top Clients will only show IP addresses.

One solution for this is to configure Pi-hole to forward these requests to your DHCP server (most likely your router), but only for devices on your home network. To configure this we will need to know the IP address of your DHCP server and which addresses belong to your local network. Exemplary input is given below as placeholder in the text boxes (if empty).

If your local network spans 192.168.0.1 - 192.168.0.255, then you will have to input 192.168.0.0/24. If your local network is 192.168.47.1 - 192.168.47.255, it will be 192.168.47.0/24 and similar. If your network is larger, the CIDR has to be different, for instance a range of 10.8.0.1 - 10.8.255.255 results in 10.8.0.0/16, whereas an even wider network of 10.0.0.1 - 10.255.255.255 results in 10.0.0.0/8. Setting up IPv6 ranges is exactly similar to setting up IPv4 here and fully supported. Feel free to reach out to us on our Discourse forum in case you need any assistance setting up local host name resolution for your particular system.

You can also specify a local domain name (like fritz.box) to ensure queries to devices ending in your local domain name will not leave your network, however, this is optional. The local domain name must match the domain name specified in your DHCP server for this to work. You can likely find it within the DHCP settings.

Conditional forwarding is voor mij dat laatste. Als een query in een bepaald domein is, forward het request dan naar de volgende DNS-server want de upstream DNS-servers kennen deze zone niet.

Wat bedoelen ze in die tweede paragraaf met 'these requests'? Uit het stukje daarvoor leid ik af dat het hier om reverse lookups gaat, om een hostnaam te kunnen tonen in plaats van een IP-adres bij bijvoorbeeld Top Clients.

Sowieso is het natuurlijk onzin om te schrijven dat je DNS-queries doorstuurt naar een DHCP-server, een DHCP-server kan geen DNS-queries beantwoorden. Wat ze bedoelen, is de query doorsturen naar een DNS-server waar de namen van DHCP-clients geregistreerd staan.

Goed, dat vind ik verwarrend. Maar inmiddels een entry toegevoegd waarmee het voor mij weer werkt: true,192.168.2.0/24,192.168.2.81,mijndomein.local. Die 192.168.2.0/24 vertelt Pi-Hole dus waar hij terecht kan om een IP-adres om te zetten in een hostnaam voor in de logs of statistieken, het laatste deel zorgt er voor dat PiHole een request in die zone niet naar de upstream server stuurt maar naar mijn interne DNS-server.

[Airw0lf]

Bij de upgrade naar PiHole v6 worden config bestandjes in ./dnsmasq.d niet meer ingelezen en moet achteraf weer aangezet worden.

Wat in mijn geval wil zeggen dat ik bij een upgrade alle vlans en de vpn overlay "kwijt" ben. In ieder geval tot het moment dat ik bij de webUI kan en daar de betreffende instelling aan kan passen.

Is er een manier om de PiHole v5 config zodanig aan te passen dat deze config bestandjes wel meegenomen worden bij de upgrade. Bijvoorbeeld door in ./pihole/setupVars.conf de variabele etc_dnsmasq_d = true op te nemen?

In pihole.toml heb ik gezien dat die setupVars.conf wel gelezen wordt. En in dit toml-bestand heb ik ook deze variabele gevonden.

[ Voor 8% gewijzigd door Airw0lf op 21-02-2025 22:23 ]

[XWB]

.je schreef op vrijdag 21 februari 2025 @ 03:29:
Ik kreeg tijdens de upgrade (binnen raspb, geen docker) geen popup met lighttp vraag. Bleek dat na de upgrade niets het deed, elke site gaf een 403.

Blijkt dat pihole botst als je de vraag niet krijgt en hij lijkt onderwater toch pihole-ftl poort 80 te proberen te claimen.

Was enigszins simpel op te lossen door lighttp te stoppen en uit te zetten.

code:

sudo systemctl stop lighttpd.service
sudo systemctl disable lighttpd.service

Daarna reboot en hij deed het weer. Als je gewend bent je admin portal zonder ww te banderen, draai dan even

code:

pihole setpassword

Ook ik had een 403, lighttpd verwijderen loste het probleem op en ik kon weer in de GUI. Heb ook maar direct PHP verwijderd, scheelt weer een package die met v6 niet meer nodig is.

Maar daarna had ik geen internet meer, bleek dat de pihole geen DNS instellingen meer had waardoor alle queries op REFUSED stonden (zag ik in de pihole log). Dat kon ik handmatig fixen, maar het is nu ook gefixt in versie 6.0.3 (specifiek deze change).

[ Voor 3% gewijzigd door XWB op 21-02-2025 23:47 ]

[XWB]

Toet3r schreef op vrijdag 21 februari 2025 @ 19:16:
@Jazzy
Ik kan bij mij nog steeds gewoon op ip-adres bij de webinterface <ip adress>/admin.

Conditional forwarding zit ook nog steeds gewoon in de webinterface. Onderaan bij tab DNS onder settings.

Die instelling is alsnog makkelijk te missen als je de Basic instellingen hebt aanstaan. Je moet eerst op de groene knop klikken alvorens je conditional forwarding te zien krijgt.

[jojost1]

beerns schreef op vrijdag 21 februari 2025 @ 17:14:
ik heb de update gedraaid, mijn unbound ip/poort was verwijderd en dat ff toegevoegd en feitelijk werkte het gewoon daarna, behalve de remote app op IOS. Die heb ik geüpdatet, heb een app password aangemaakt in Pihole 6.
In de remote app nieuwe instance aangemaakt, app pw ingevuld dat gaat allemaal netjes, maar de app blijft mij een fout geven op de /api.
Dr staat dat default de link /api is. Dus ik heb https opgegeven, ip adres v mn PI, poortje ingevuld en verder valt er niet zo heel in te vullen. Echter de app blijft zeggen : invalid URL.
Iemand een idee wat ik fout doe?

Iets met HTTP/HTTPS misschien? Gebruik je versie v6.0.2 van Pi-hole Remote, daar zitten weer wat fixes in.

[GG85]

Twee vraagjes wbt V6:

-hoe enable je HTTPS of moet je dit alsnog met een extern tooltje doen die een certificaat genegeerd?

-mijn Network Overview blijft leeg sinds de update, meer mensen last van?

[beerns]

jojost1 schreef op zaterdag 22 februari 2025 @ 08:07:
[...]

Iets met HTTP/HTTPS misschien? Gebruik je versie v6.0.2 van Pi-hole Remote, daar zitten weer wat fixes in.

Ja, ik heb nieuwste vanmorgen binnen gehaald, thanks. Waar het (denk ik) op vast loopt, want er valt feitelijk niet zo heel veel foutief in te vullen; is de api. Daar staat dat je een link in moet geven en dat default /api is.
Ik kan niet zo heel veel fout doen aan het ip adres (of pi.hole invullen) en dan de poort ingeven (80 of 443 bij http of https, want ik heb beide geprobeerd).
En dan krijg ik de melding dat er een invalid URL is.

Dus als iemand dit netjes met v6 aan de praat heeft gekregen, hou ik me aanbevolen wat daar in te vullen

[Airw0lf]

Voor de liefhebbers...

In de vroege ochtend heeft Watchtower hier de laatste docker-pihole-v6-versie opgehaald.
De daaropvolgende upgrade verliep zoals verwacht:
* geen dhcp en dns meer voor alle vlans
* webserver op poort 80 en 443 (ondanks v5-env-var WEB_PORT=88)
* pihole ntp server die niet werkt (door de inzet van chrony)
* geen tailscale VPN meer

De oorzaak lag in alle gevallen in de combi Watchtower/pihole-v6-defaults.
Watchtower haalt de update binnen en gebruikt dezelfde env-settings om een nieuwe container te starten - bij mijn weten is er geen mogelijkheid om hier wat aan te doen.

Wat bleef werken is het management vlan omdat deze instellingen netjes overgezet werden naar de nieuwe v6-settings in pihole.toml. Vanaf het beheersysteem heb ik toen een pihole-v6-Docker installatie/upgrade gedaan met onderstaand Docker-cli script.

Om de proef-op-de-som te nemen heb ik een backup teruggezet zodat pihole-v5 weer beschikbaar was. Vervolgens onderstaand Docker-v6-cli script uitgevoerd. Hiermee verliep de migratie vlekkeloos. Dit geldt zowel voor dns (waaronder tailscale) als dhcp.

Restpunt: de reverse proxy genaamd swag (d.w.z. linuxserver.io/swag) - die combi heb ik nog niet aan de praat gekregen. Ik krijg wel het login scherm. Maar na invoering van het ww stopt het. Iemand hier nog suggesties?

Docker-cli-v5 script:
docker run -d \
--name pihole \
--network host \
-v /opt/docker/pihole/etc-pihole:/etc/pihole \
-v /opt/docker/pihole/etc-dnsmasq.d:/etc/dnsmasq.d \
-v /opt/docker/pihole/var-log:/var/log \
-e TZ=Europe/Amsterdam \
-e QUERY_LOGGING=false \
-e FTLCONF_LOCAL_IPV4=192.168.139.235 \
-e WEB_PORT=88 \
-e IPv6=false \
-e WEBTHEME=default-light \
-e DNSMASQ_USER=pihole \
--cap-add=NET_ADMIN \
--restart unless-stopped \
pihole/pihole

Docker-cli-v6 script
docker run -d \
--name pihole \
--network host \
-v /opt/docker/pihole/etc-pihole:/etc/pihole \
-v /opt/docker/pihole/etc-dnsmasq.d:/etc/dnsmasq.d \
-v /opt/docker/pihole/var-log:/var/log \
-e TZ=Europe/Amsterdam \
-e FTLCONF_dns_queryLogging=false \
-e FTLCONF_webserver_port=88 \
-e FTLCONF_webserver_interface_theme=default-light \
-e FTLCONF_misc_etc_dnsmasq_d=true \
--cap-add=NET_ADMIN \
--restart unless-stopped \
pihole/pihole

Let op: in deze Docker-cli scripts wordt pihole gestart met het Docker-host netwerk. Of de upgrade ook vlekkeloos loopt bij een ander type Docker netwerk weet ik niet - niet getest.

@nero355 - aan de vlan-kant is er niks veranderd... tis te zeggen... ik heb hier nog niks over gevonden.

[ Voor 18% gewijzigd door Airw0lf op 22-02-2025 13:27 ]

[beerns]

heb 'm aan de praat (hehe).

met pi.hole (dus geen ip adres, dat gaf fouten) over https en niet met het (nieuwe) app password, maar gewoon met het password van Pihole. Dat was in mijn geval OOK gereset na de update.

[Jazzy]

XWB schreef op zaterdag 22 februari 2025 @ 00:57:
[...]


Die instelling is alsnog makkelijk te missen als je de Basic instellingen hebt aanstaan. Je moet eerst op de groene knop klikken alvorens je conditional forwarding te zien krijgt.

Dat was inderdaad precies waar ik ook tegenaan liep. Begrijp de gedachte, maar zou mooi zijn als je hier bij een eerste inlog op gewezen wordt.

[ed1703]

Airw0lf schreef op zaterdag 22 februari 2025 @ 11:13:

De oorzaak lag in alle gevallen in de combi Watchtower/pihole-v6-defaults.
Watchtower haalt de update binnen en gebruikt dezelfde env-settings om een nieuwe container te starten - bij mijn weten is er geen mogelijkheid om hier wat aan te doen.

Je haalt hier nu precies aan (en ik heb geen behoefte aan een watchtower welles/nietes autoupdate proces) waarom watchtower bij mij op monitor-only staat en eerst eventjes bekijk of er nog aanpassingen gedaan moeten worden. Sowieso vind ik dat elke ontwikkelaar een lijfstraf moet krijgen ( ) die op app:latest gewoon nieuwe of zelfs vervangende env's erin propt. Stop daar de eerst komende tijd dan eerst even een versienummer tussen zou je zeggen, maarja.. blijkbaar wil men een overload aan forumposts.

[Jazzy]

GG85 schreef op zaterdag 22 februari 2025 @ 09:05:
-hoe enable je HTTPS of moet je dit alsnog met een extern tooltje doen die een certificaat genegeerd?

Lijkt er op dat je dit inderdaad buiten Pi-hole moet regelen. Vervolgens onder Settings het schuifje van Basic naar Expert zetten, All settings selecteren en dan webserver.port en webserver.tls.cert configureren.

[MRE-Inc]

Stimulate14 schreef op donderdag 20 februari 2025 @ 17:29:
Dat V6 uit is gebracht is mij compleet ontgaan.

Bij mij ook. Eigenlijk zonder te kijken (ja dom) via putty een pihole -up uitgevoerd. Dat resulteerde dat ik op de webinterface niet meer kon inloggen met mijn normale wachtwoord. Via putty een password reset gedaan en het werkte weer, ik kon weer in de webinterface.

Jazzy schreef op vrijdag 21 februari 2025 @ 19:46:

Goed, dat vind ik verwarrend. Maar inmiddels een entry toegevoegd waarmee het voor mij weer werkt: true,192.168.2.0/24,192.168.2.81,mijndomein.local. Die 192.168.2.0/24 vertelt Pi-Hole dus waar hij terecht kan om een IP-adres om te zetten in een hostnaam voor in de logs of statistieken, het laatste deel zorgt er voor dat PiHole een request in die zone niet naar de upstream server stuurt maar naar mijn interne DNS-server.

Heb het ook ingevuld, maar dan uiteaard met mijn eigen netwerk gegevens. Zorgt dit er ook weer voor dat de Query Log gevuld wordt ? Ik weet dat er dingen geblocked worden door PiHole, maar zie in de Query Log niks terug. Geen enkele data. Heb dus die "true,192.168.1.0/24,192.168.1.1,intern.lan" ingevuld bij conditional forwarding, hopende dat de Query Log nu wel gevuld wordt.

2e probleem is dat ik op mijn iPhone een iOS Shortcut had waarmee je eigenlijk via de CLI een opdracht geeft om PiHole voor een bepaalde tijd te stoppen.

Zie ook: https://aaroneaton.blog/posts/disable-pihole-shortcuts/

Het commando dat in de shortcut dan wordt gegeven is: http://<YOUR_PIHOLE_DOMAIN>/admin/api.php?auth=<YOUR_PIHOLE_API_TOKEN>?disable=<DURATION_IN_SECONDS>

Dit werkt dus allemaal niet meer. Ik wilde de API key controleren of die hetzelfde is gebleven maar die kan ik ook niet meer terug vinden.

[Jazzy]

MRE-Inc schreef op zaterdag 22 februari 2025 @ 13:29:
Ik weet dat er dingen geblocked worden door PiHole, maar zie in de Query Log niks terug. Geen enkele data. Heb dus die "true,192.168.1.0/24,192.168.1.1,intern.lan" ingevuld bij conditional forwarding, hopende dat de Query Log nu wel gevuld wordt.

Nee, die entry onder Conditional Forwarding zorgt er alleen voor dat Pi-hole je lokale IP-adressen kan vertalen naar een hostnaam.

Als je daar helemaal geen data ziet moet je even checken of je query logging wel aan hebt gezet: dns.queryLogging (die vind je onder All Settings, schuifje eerst van Basic naar Expert zetten).

[ Voor 6% gewijzigd door Jazzy op 22-02-2025 13:35 ]

[rvk]

MRE-Inc schreef op zaterdag 22 februari 2025 @ 13:29:
Dit werkt dus allemaal niet meer. Ik wilde de API key controleren of die hetzelfde is gebleven maar die kan ik ook niet meer terug vinden.

Nee, heel die API is bij v6 gewijzigd. Dus ook de authenticatie.
https://discourse.pi-hole...icating-to-v6-api/66010/6

[MRE-Inc]

Jazzy schreef op zaterdag 22 februari 2025 @ 13:34:
[...]
Nee, die entry onder Conditional Forwarding zorgt er alleen voor dat Pi-hole je lokale IP-adressen kan vertalen naar een hostnaam.

Als je daar helemaal geen data ziet moet je even checken of je query logging wel aan hebt gezet: dns.queryLogging (die vind je onder All Settings, schuifje eerst van Basic naar Expert zetten).

Ja die stond/staat aan. Dat is namelijk Default dat die aan staat, echter krijg ik geen data te zien in de Query Log. Ook als ik op het dashboard de tegel aanklik: Queries Blocked > List Blocked queries, dan krijg ik niks te zien.

Op het dashboard worden verder wel alle goede statistieken weergegeven, dus hostnamen van clients, top blocked domain etc.

Zou een sudo pihole repair nog iets kunnen uithalen ? EDIT: Nee dus.

Wanneer ik op het dashboard op het blauwe tegeltje klik met de naam: Total queries 687, 20 active clients, dan verschijnt onderstaande foutmelding.

[ Voor 27% gewijzigd door MRE-Inc op 22-02-2025 14:09 ]

[Freee!!]

MRE-Inc schreef op zaterdag 22 februari 2025 @ 13:38:
[...]
Ja die stond/staat aan. Dat is namelijk Default dat die aan staat, echter krijg ik geen data te zien in de Query Log. Ook als ik op het dashboard de tegel aanklik: Queries Blocked > List Blocked queries, dan krijg ik niks te zien.

Op het dashboard worden verder wel alle goede statistieken weergegeven, dus hostnamen van clients, top blocked domain etc.

Zou een sudo pihole repair nog iets kunnen uithalen ? EDIT: Nee dus.

Wanneer ik op het dashboard op het blauwe tegeltje klik met de naam: Total queries 687, 20 active clients, dan verschijnt onderstaande foutmelding.


[Afbeelding]

En een search op de foutmelding levert niets op.

[MRE-Inc]

Freee!! schreef op zaterdag 22 februari 2025 @ 14:28:
[...]

En een search op de foutmelding levert niets op.

Is dat een vraag of je eigen bevinding ?

Maar idd zoeken op die foutmelding levert niks op.

[rvk]

MRE-Inc schreef op zaterdag 22 februari 2025 @ 13:38:
[...]
Ja die stond/staat aan. Dat is namelijk Default dat die aan staat, echter krijg ik geen data te zien in de Query Log. Ook als ik op het dashboard de tegel aanklik: Queries Blocked > List Blocked queries, dan krijg ik niks te zien.

Misschien stomme vraag... Maar kan het niet zijn dat je nu met twee pihole omgevingen zit? V5 en v6. De v6 zou zijn eigen nieuwe http omgeving hebben (en geen externe web en php meer gebruiken). Als je nu dus nog iets van v5 benaderd dan gaat dat natuurlijk mis.

(Ik denk dat ik voorlopig maar even wacht met het updaten van mijn docker image )

[MRE-Inc]

rvk schreef op zaterdag 22 februari 2025 @ 14:42:
[...]

Misschien stomme vraag... Maar kan het niet zijn dat je nu met twee pihole omgevingen zit? V5 en v6. De v6 zou zijn eigen nieuwe http omgeving hebben (en geen externe web en php meer gebruiken). Als je nu dus nog iets van v5 benaderd dan gaat dat natuurlijk mis.

(Ik denk dat ik voorlopig maar even wacht met het updaten van mijn docker image )

Je bedoelt dus naast elkaar op 1 RPi en dat er dus resten van de v5 installatie nog ergens zitten. Dat zou wellicht best kunnen. Ik heb echter maar 1 RPi draaien waarop PiHole staat.

Enige optie is nog om Pihole te verwijderen en vanaf scratch af aan te beginnen.

[Slonzo]

ed1703 schreef op zaterdag 22 februari 2025 @ 12:11:
Sowieso vind ik dat elke ontwikkelaar een lijfstraf moet krijgen ( ) die op app:latest gewoon nieuwe of zelfs vervangende env's erin propt. Stop daar de eerst komende tijd dan eerst even een versienummer tussen zou je zeggen, maarja.. blijkbaar wil men een overload aan forumposts.

Wat is dat nou voor onzin? Je kiest er zelf voor om `latest` te gebruiken i.p.v. version pinning te doen, en dan zou het de schuld van de maintainer zijn als jij domweg blindlings alles laat updaten naar versies waar ook breaking changes in kunnen zitten? Dan heb je gewoon geen idee waar je mee bezig bent.

[Freee!!]

MRE-Inc schreef op zaterdag 22 februari 2025 @ 14:32:
[...]
Is dat een vraag of je eigen bevinding ?

Eigen bevinding, ik ken het correcte gebruik van de leestekens waaronder het vraagteken ("?").

[MRE-Inc]

Freee!! schreef op zaterdag 22 februari 2025 @ 15:07:
[...]

Eigen bevinding, ik ken het correcte gebruik van de leestekens waaronder het vraagteken ("?").

Uiteindelijk lijkt het weer te werken:

Oplossing: https://discourse.pi-hole...ftl-db-corrupted/39196/10

Ik heb gewoon deze commando's via putty uitgevoerd

sudo service pihole-FTL stop

sudo mv /etc/pihole/pihole-FTL.db /etc/pihole/pihole-FTL-old.db

sudo service pihole-FTL start

Als ik de blauwe tegel aanklik, komt er ook geen foutmelding meer. De Query log werkt ook weer.

Nu alleen nog in die API duiken om de iOS shortcuts werkend te krijgen. Mocht iemand dat weten, laat maar weten wat de oplossing is.

[ Voor 9% gewijzigd door MRE-Inc op 22-02-2025 15:15 ]

[Freee!!]

MRE-Inc schreef op zaterdag 22 februari 2025 @ 15:10:
[...]


Uiteindelijk lijkt het weer te werken:

Oplossing: https://discourse.pi-hole...ftl-db-corrupted/39196/10

Ik heb gewoon deze commando's via putty uitgevoerd


[...]


Als ik de blauwe tegel aanklik, komt er ook geen foutmelding meer. De Query log werkt ook weer.

Nu alleen nog in die API duiken om de iOS shortcuts werkend te krijgen. Mocht iemand dat weten, laat maar weten wat de oplossing is.

De "service" commando's krijg ik niet werkend op mijn Docker containers, maar het "mv" commando in combinatie met een herstart van de container lost het probleem op.

[MRE-Inc]

Freee!! schreef op zaterdag 22 februari 2025 @ 15:24:
[...]

De "service" commando's krijg ik niet werkend op mijn Docker containers, maar het "mv" commando in combinatie met een herstart van de container lost het probleem op.

Oh had jij exact hetzelfde probleem dan ? Dat had ik uit je eerdere post niet opgemaakt. Mooi dat het dan bij jouw ook weer werkt.

[Freee!!]

MRE-Inc schreef op zaterdag 22 februari 2025 @ 15:27:
[...]
Oh had jij exact hetzelfde probleem dan ? Dat had ik uit je eerdere post niet opgemaakt. Mooi dat het dan bij jouw ook weer werkt.

Ik had hetzelfde probleem twee keer. Nu nog twee pi-holes handmatig overzetten naar V6, maar dat kan nog wel een paar dagen wachten totdat V6 stabiel is ipv twee tot drie updates per dag.

[ed1703]

Slonzo schreef op zaterdag 22 februari 2025 @ 15:01:
[...]

Wat is dat nou voor onzin? Je kiest er zelf voor om `latest` te gebruiken i.p.v. version pinning te doen, en dan zou het de schuld van de maintainer zijn als jij domweg blindlings alles laat updaten naar versies waar ook breaking changes in kunnen zitten? Dan heb je gewoon geen idee waar je mee bezig bent.

Deels mee eens. Dan zou je ook de tag v5:latest van V5 moeten aanbieden. Dan breek je normaal gesproken niets. Maar nogmaals, je quote namelijk nogal selectief: ik gaf eerder al aan dat je niet 'zomaar' als een kip zonder kop moet gaan updaten (een regel die niet alleen voor docker-gebruikers van toepassing is). Ik denk inderdaad namelijk dat een groot deel van de docker gebruikers vaak geen idee hebben wat ze doen, maar dat terzijde.

[ Voor 11% gewijzigd door ed1703 op 22-02-2025 16:26 ]

[XWB]

GG85 schreef op zaterdag 22 februari 2025 @ 09:05:
Twee vraagjes wbt V6:

-hoe enable je HTTPS of moet je dit alsnog met een extern tooltje doen die een certificaat genegeerd?

Versie 6 komt met een self-signed certificaat (zie /etc/pihole/tls.pem) dus je zou de pihole al moeten kunnen bereiken via https://<ip> of https://pi.hole

Je krijgt vervolgens een browser warning die je kan negeren, of je kan het certificaat toevoegen aan je browser zoals omschreven in https://docs.pi-hole.net/api/tls/

[.je]

Maar daarna had ik geen internet meer, bleek dat de pihole geen DNS instellingen meer had waardoor alle queries op REFUSED stonden (zag ik in de pihole log). Dat kon ik handmatig fixen, maar het is nu ook gefixt in versie 6.0.3 (specifiek deze change).

Dat klopt idd, al was dat onderdeel van de notifications met andere errors die ik zag, dus gewoon opgelost zonder erbij na te denken dat ik het ook in de forum post had moeten zetten...

Het was ook weer even zoeken hoe dnssec erbij moest. Bij de vorige versie was dat een extra vinkje en dan zag je dat in de query logs er meteen bij. Nu moet je de logs expliciet aanklikken / uitklappen om de stats erbij te zien. Iets wat niet lekker werkt als je de logs automagisch laat refreshen.

[strandbal]

Nou ik heb v6 draaiend... Voor de volledigheid, het is een LXC container in Proxmox.

- De prompt om lighttpd te disablen bij upgrade komt bij mij niet, dus geeft de admin interface een error 403 na updaten. Om wat voor reden dan ook werkt poort 8080 ook niet. Lighttpd handmatig disablen en pihole-ftl herstarten en voila, we hebben een admin interface.
- De upstream DNS servers zijn allen uitgeschakeld waardoor resolving niet werkt, die settings komen blijkbaar niet goed mee. De fix die hierboven staat werkt dus blijkbaar bij mij niet.
- De DHCP server settings worden in zijn geheel niet mee gemigreerd, alleen de active leases komen mee. Ik vond ergens iets op de discourse van Pihole waar stond dat dat gefixt zou moeten zijn, maar ook dat werkt bij mij blijkbaar dus niet.
- Custom DNS records en domein instellingen komen ook niet mee, handmatig terug moeten zetten.
- Het admin password wordt tijdens upgrade gereset.

Even zoet mee geweest, maar goed, het werkt nu. Verre van een seamless upgrade...

Ik klaag niet overigens hoor, het houdt mijn lan weer mooi zo goed als advrij Als ik er absoluut geen werk aan wil hebben laat ik DNS wel aan mijn ISP over

edit: dit lijkt erg op wat ik ervaar. De upgrade gaat niet lekker dus. Valt nu niet veel meer te debuggen bij mij, het werkt nu en 't gezin werd onrustig, dus ik laat het voor nu maar even

[ Voor 12% gewijzigd door strandbal op 22-02-2025 22:07 ]

[Get!em]

In dat topic wordt nu een fix genoemd; migratie fails

https://github.com/pi-hole/pi-hole/pull/5968

[asing]

ed1703 schreef op zaterdag 22 februari 2025 @ 12:11:
[...]

Je haalt hier nu precies aan (en ik heb geen behoefte aan een watchtower welles/nietes autoupdate proces) waarom watchtower bij mij op monitor-only staat en eerst eventjes bekijk of er nog aanpassingen gedaan moeten worden. Sowieso vind ik dat elke ontwikkelaar een lijfstraf moet krijgen ( ) die op app:latest gewoon nieuwe of zelfs vervangende env's erin propt. Stop daar de eerst komende tijd dan eerst even een versienummer tussen zou je zeggen, maarja.. blijkbaar wil men een overload aan forumposts.

Ik dacht al, wat is het druk hier!

Anyway, Diun meldde dat mijn beide Pi-hole docker instances een update nodig hadden. Watchtower werkte bij niet fijn, die ging van alles doen ook al had ik ingesteld dat dat niet moest. Dus vanmorgen in Portainer een redeploy van beide dockers gedaan. Dat ging zonder enig probleem meteen goed.

Daarna maar eens gekeken wat al de fuss hier was, en dat was V6. Even ingelogd op 1 van de Pi-holes maar dat ziet er heel goed uit.

Alleen Orbital Sync is nu kapot, maar daar is de ontwikkelaar al van op de hoogtee.

[nero355]

beerns schreef op vrijdag 21 februari 2025 @ 17:14:
de remote app op IOS.

Dr staat dat default de link /api is. Dus ik heb https opgegeven, ip adres v mn PI, poortje ingevuld en verder valt er niet zo heel in te vullen. Echter de app blijft zeggen : invalid URL.

Iemand een idee wat ik fout doe?

Die Remote App voor iOS zal de komende tijd geüpdate worden voor Pi-Hole v6 dus gewoon wachten is het antwoord daarop

Toet3r schreef op vrijdag 21 februari 2025 @ 17:23:
Er is best wel een hoop veranderd aan de api. Grote kans dat dit de oorzaak is. Afwachten tot de IOS app wordt ge-updated.

Precies!

Kjoe_Ljan schreef op vrijdag 21 februari 2025 @ 17:20:
Dit gebeurde bij mij ook.

Ik weet niet of bij mij lighttpd roet in het eten gooide, of Unbound ofzo, maar de upgrade bleef hangen op het resolven van DNS, en toen had het hele huis ineens geen verbinding meer.

Ik heb het al meerdere keren moeten schrijven de afgelopen dagen, maar bij deze nog een keer dan maar :

Dat kan ALTIJD gebeuren als je /etc/resolve.conf 127.0.0.1 bevat en dus Pi-Hole zelf is

Wat je dan doet is een tweede SSH sessie open zetten, je systeem effe een andere DNS Server geven, daarna de hele networking toestand of alleen DNS Resolving herstarten en de update/upgrade zal vanzelf verder gaan ook al staan er al een heleboel ............ te wachten in je venster

strandbal schreef op vrijdag 21 februari 2025 @ 18:16:
Mijn lxc container had als dns server zichzelf, dat was niet handig, toen kreeg ik tijdens de update ook een resolve error. Misschien bij jou ook zoiets?

Voor jou geldt hetzelfde

Raven schreef op vrijdag 21 februari 2025 @ 18:13:
Serieus?

Ja, was best wel effe lachen tussen alle PEBCAK toestanden in

Toet3r schreef op vrijdag 21 februari 2025 @ 18:24:
Denk dat ie dit topic bedoeld. Had hem ook gezien. Vond het wel grappig.
https://discourse.pi-hole...-very-disappointing/76015

Yup!

Jazzy schreef op vrijdag 21 februari 2025 @ 19:06:
Kreeg op geen enkele manier meer toegang, met of zonder /admin/login.php en op hostnaam of IP-adres.

PHP is niet meer nodig dus dat kan sowieso niet werken !!

Net als LigHTTPd want dat is nu een ingebouwde Civetweb HTTP(S) Webserver geworden

Sowieso een hele beroerde beslissing om die redirect naar /admin alleen nog maar te doen als je hem op pi.hole benadert en in alle andere gevallen niets meer dan een 403 te presenteren. Qua gebruiksvriendelijkheid is dat echt niet meer van deze tijd.

- Je kan de www root veranderen als je dat wilt met wat handmatige ingrepen
- Er wordt sowieso een link naar /admin weergegeven als alles goed is geïnstalleerd !!

conditional forwarding

IMHO is die hele functie gewoon sowieso R-U-K en moet je dat eigenlijk niet nodig willen hebben !!

Zorg ervoor dat al je Clients :
- Een Static IP Address in het OS hebben staan.
- Of dat er een Static DHCP IP Mapping op basis van het MAC Address in je DHCP Server bestaat.

En maak vervolgens Local DNS Records aan voor al die IP adressen in Pi-Hole en KLAAR!!!

Ik heb die meuk nooit gebruikt of nodig gehad de afgelopen 8+ jaar dat ik Pi-Hole gebruik

Als je een breaking change introduceert

Er zijn gewoon opeens onvoorziene en vooral onverklaarbare bugs naar boven gekomen en ze werken er hard aan om die te fixen !!

Alsof iedereen eerst even de changelogs gaat lezen voordat je de applicatie of het OS bijwerkt.

https://pi-hole.net/blog/2025/02/18/introducing-pi-hole-v6/ is niet zomaar geschreven...

Zie zelfs dat er alweer een extra artikel is verschenen waarin een hoop dingen worden uitgelegd omtrent de meest voorkomende problemen : https://pi-hole.net/blog/...lease-fixes-and-findings/

Airw0lf schreef op vrijdag 21 februari 2025 @ 22:05:
Bij de upgrade naar PiHole v6 worden config bestandjes in ./dnsmasq.d niet meer ingelezen en moet achteraf weer aangezet worden.

/etc/dnsmasq.d/

En in theorie heb je die niet meer nodig, want alles kan je in /etc/pihole/pihole.toml overzetten !!
Helaas inderdaad handmatig indien dat niet automatisch is gebeurd...

Wat in mijn geval wil zeggen dat ik bij een upgrade alle vlans en de vpn overlay "kwijt" ben.
In ieder geval tot het moment dat ik bij de webUI kan en daar de betreffende instelling aan kan passen.

Bij de Docker Container versie is dat inderdaad niet het geval, maar dat is helaas niet anders op te lossen...

Een reguliere installatie van Pi-Hole v6 pakt echter WEL standaard alle VLAN Interfaces op en qua VPN toestanden zal je het eventueel wel zelf effe moeten toevoegen, want geen echte Lokale Interface

Is er een manier om de PiHole v5 config zodanig aan te passen dat deze config bestandjes wel meegenomen worden bij de upgrade. Bijvoorbeeld door in ./pihole/setupVars.conf de variabele etc_dnsmasq_d = true op te nemen?

setupVars = History!

Voortaan is /etc/pihole/pihole.toml gewoon DE PLEK voor al je aanpassingen en daarbij is ALLES beschikbaar via de webGUI via de Expert Mode die bij het Settings gedeelte een "All Settings" sub-menu laat verschijnen

In pihole.toml heb ik gezien dat die setupVars.conf wel gelezen wordt.
En in dit toml-bestand heb ik ook deze variabele gevonden.

setupVars.conf aanpassen is zelfs nooit een goed idee geweest, want die werd altijd na een update/upgrade overschreven geloof ik

GG85 schreef op zaterdag 22 februari 2025 @ 09:05:
-hoe enable je HTTPS of moet je dit alsnog met een extern tooltje doen die een certificaat genegeerd?

Check effe https://discourse.pi-hole.net/ waar meerdere topics zijn over het toepassen van een Let's Encrypt Certificaat voor Pi-Hole v6

Er is zelfs iemand die ik heb geholpen en het werkend heeft gekregen, maar sinds ik de afgelopen dagen ruim 18 uur op het Pi-Hole Forum heb doorgebracht kan ik dat zo gauw effe niet meer terugvinden

mijn Network Overview blijft leeg sinds de update, meer mensen last van?

Volgens mij zag ik die bug ook in ieder geval 2 keer langskomen...

Airw0lf schreef op zaterdag 22 februari 2025 @ 11:13:
Restpunt: de reverse proxy genaamd swag (d.w.z. linuxserver.io/swag) - die combi heb ik nog niet aan de praat gekregen. Ik krijg wel het login scherm. Maar na invoering van het ww stopt het.

Iemand hier nog suggesties?

Alle Reverse Proxy achtige setups dienen volledig aangepast te worden, want LigHTTPd die door Civetweb is vervangen

Het werkt nu gewoon anders en dat moet je effe uitvogelen...

Op https://discourse.pi-hole.net/ kan je eventueel wat richtlijnen terugvinden, want genoeg andere Reverse Proxy combinaties die ondertussen zijn aangepast en gepost

Jazzy schreef op zaterdag 22 februari 2025 @ 12:06:
Dat was inderdaad precies waar ik ook tegenaan liep.

Begrijp de gedachte, maar zou mooi zijn als je hier bij een eerste inlog op gewezen wordt.

Leer jezelf aan om eerste flink rond te kijken en daarna pas aan de slag te gaan met de boel instellen/aanpassen naar je wensen

Het eerste wat ik deed toen ik de Pi-Hole v6 Beta had geïnstalleerd is alle opties doorbladeren via zowel de webGUI als SSH en daarna pas alles instellen om daadwerkelijk wat ermee te kunnen doen

En dat is ook iets wat ik doe als ik bijvoorbeeld een nieuwe TV/Telefoon/Mediaplayer/enz. koop !!!

MRE-Inc schreef op zaterdag 22 februari 2025 @ 13:29:
Heb het ook ingevuld, maar dan uiteaard met mijn eigen netwerk gegevens. Zorgt dit er ook weer voor dat de Query Log gevuld wordt ? Ik weet dat er dingen geblocked worden door PiHole, maar zie in de Query Log niks terug. Geen enkele data. Heb dus die "true,192.168.1.0/24,192.168.1.1,intern.lan" ingevuld bij conditional forwarding, hopende dat de Query Log nu wel gevuld wordt.

Men is bezig met een soortgelijke bug te fixen dus ik gok dat jij die ook te pakken hebt

2e probleem is dat ik op mijn iPhone een iOS Shortcut had waarmee je eigenlijk via de CLI een opdracht geeft om PiHole voor een bepaalde tijd te stoppen.

Zie ook: https://aaroneaton.blog/posts/disable-pihole-shortcuts/

Het commando dat in de shortcut dan wordt gegeven is: http://<YOUR_PIHOLE_DOMAIN>/admin/api.php?auth=<YOUR_PIHOLE_API_TOKEN>?disable=<DURATION_IN_SECONDS>

Dit werkt dus allemaal niet meer. Ik wilde de API key controleren of die hetzelfde is gebleven maar die kan ik ook niet meer terug vinden.

PHP is niet meer dus die link zal sowieso niet werken hé!

Ik geloof dat de URL voor de API nu http://<YOUR_PIHOLE_DOMAIN>/api/ is zelfs...

MRE-Inc schreef op zaterdag 22 februari 2025 @ 14:47:
Je bedoelt dus naast elkaar op 1 RPi en dat er dus resten van de v5 installatie nog ergens zitten.
Dat zou wellicht best kunnen.

Je zal na een upgrade sowieso zelf LigHTTPd en PHP en de .php files van v5 moeten verwijderen

Freee!! schreef op zaterdag 22 februari 2025 @ 15:24:
De "service" commando's krijg ik niet werkend op mijn Docker containers, maar het "mv" commando in combinatie met een herstart van de container lost het probleem op.

Jij moet het service commando vervangen door de Container herstarten geloof ik en het mv commando doe je sowieso op de lokale storage buiten de Container waar de database van Pi-Hole staat

Er schijnen heel veel mensen met super oude extreem grote databases te zijn die eventueel zelfs (deels) corrupt zijn geraakt door de tijd heen en dan gaan er gewoon een heleboel dingen over de zeik

Daarnaast is tegenwoordig het advies bij gebruik van extreem grote Gravity Lists om minimaal 1 GB RAM te hebben om het verwerken ervan na een Gravity Lists Update goed te laten verlopen

.je schreef op zaterdag 22 februari 2025 @ 19:38:
Het was ook weer even zoeken hoe dnssec erbij moest. Bij de vorige versie was dat een extra vinkje en dan zag je dat in de query logs er meteen bij. Nu moet je de logs expliciet aanklikken / uitklappen om de stats erbij te zien. Iets wat niet lekker werkt als je de logs automagisch laat refreshen.

Ik geloof dat ze ondertussen al bezig zijn met toekomstige aanpassingen inplannen voor die functionaliteit

strandbal schreef op zaterdag 22 februari 2025 @ 22:01:
Nou ik heb v6 draaiend... Voor de volledigheid, het is een LXC container in Proxmox.

Voor mijn nieuwsgierigheid : Priveleged of Unprivileged ?

- De prompt om lighttpd te disablen bij upgrade komt bij mij niet, dus geeft de admin interface een error 403 na updaten.
Om wat voor reden dan ook werkt poort 8080 ook niet.

Lighttpd handmatig disablen en pihole-ftl herstarten en voila, we hebben een admin interface.

Bekende bug die bij sommigen soms consistent en soms inconsistent optreeft om de een of ander reden en aan wordt gewerkt

- De upstream DNS servers zijn allen uitgeschakeld waardoor resolving niet werkt, die settings komen blijkbaar niet goed mee.
De fix die hierboven staat werkt dus blijkbaar bij mij niet.

Kan je via SSH fixen via het pihole commando of door /etc/pihole.toml aan te passen

En ook een bekende bug waar aan wordt gewerkt trouwens!

- De DHCP server settings worden in zijn geheel niet mee gemigreerd, alleen de active leases komen mee. Ik vond ergens iets op de discourse van Pihole waar stond dat dat gefixt zou moeten zijn, maar ook dat werkt bij mij blijkbaar dus niet.
- Custom DNS records en domein instellingen komen ook niet mee, handmatig terug moeten zetten.
- Het admin password wordt tijdens upgrade gereset.

Volgens mij ook bekend ondertussen, maar wel relatief nieuw vergeleken met de rest dus misschien duurt die fix langer dan de rest !!

Verre van een seamless upgrade...

Helaas voor een heleboel mensen inderdaad het geval, maar een heleboel mensen hebben er ook echt 0,0 voorbereiding in gestoken en dat vind ik best wel lullig voor de developers

Ik klaag niet overigens hoor, het houdt mijn lan weer mooi zo goed als advrij Als ik er absoluut geen werk aan wil hebben laat ik DNS wel aan mijn ISP over

Precies!

edit: dit lijkt erg op wat ik ervaar. De upgrade gaat niet lekker dus.
Valt nu niet veel meer te debuggen bij mij, het werkt nu en 't gezin werd onrustig, dus ik laat het voor nu maar even

Ik geloof dat er al 1 of meerdere gebruikers zijn die bereid waren meerdere keren hun LXC dan wel VM terug te zetten naar de Pi-Hole v5 backup en de Pi-Hole v6 upgrade meerdere keren te herhalen om de fouten eruit te halen voor toekomstige upgrades dus het komt wel goed


Zo...


Tot zover uw "Pi-Hole v6 staat van zaken Update¨ van vandaag

[strandbal]

Voor mijn nieuwsgierigheid : Priveleged of Unprivileged ?

Unprivileged, privileged containers lijken me security wise niet handig. Overigens ook de reden dat de ntp server/client opties die ineens aan stonden uit moesten, dat genereerde allerlei insufficient rights meldingen. Raar ook dat ze die settings hebben verstopt onder "all settings". Ik verwacht niet direct een ntp server in een dns server

[Raymond P]

strandbal schreef op zondag 23 februari 2025 @ 08:00:
[...]


[...] Ik verwacht niet direct een ntp server in een dns server

DNSSEC.

[Raven]

nero355 schreef op zondag 23 februari 2025 @ 00:04:
[...]

Die Remote App voor iOS zal de komende tijd geüpdate worden voor Pi-Hole v6 dus gewoon wachten is het antwoord daarop


[...]

Precies!


[...]

Ik heb het al meerdere keren moeten schrijven de afgelopen dagen, maar bij deze nog een keer dan maar :

Dat kan ALTIJD gebeuren als je /etc/resolve.conf 127.0.0.1 bevat en dus Pi-Hole zelf is

Wat je dan doet is een tweede SSH sessie open zetten, je systeem effe een andere DNS Server geven, daarna de hele networking toestand of alleen DNS Resolving herstarten en de update/upgrade zal vanzelf verder gaan ook al staan er al een heleboel ............ te wachten in je venster


[...]

Voor jou geldt hetzelfde


[...]

Ja, was best wel effe lachen tussen alle PEBCAK toestanden in


[...]

Yup!


[...]

PHP is niet meer nodig dus dat kan sowieso niet werken !!

Net als LigHTTPd want dat is nu een ingebouwde Civetweb HTTP(S) Webserver geworden


[...]

- Je kan de www root veranderen als je dat wilt met wat handmatige ingrepen
- Er wordt sowieso een link naar /admin weergegeven als alles goed is geïnstalleerd !!


[...]

IMHO is die hele functie gewoon sowieso R-U-K en moet je dat eigenlijk niet nodig willen hebben !!

Zorg ervoor dat al je Clients :
- Een Static IP Address in het OS hebben staan.
- Of dat er een Static DHCP IP Mapping op basis van het MAC Address in je DHCP Server bestaat.

En maak vervolgens Local DNS Records aan voor al die IP adressen in Pi-Hole en KLAAR!!!

Ik heb die meuk nooit gebruikt of nodig gehad de afgelopen 8+ jaar dat ik Pi-Hole gebruik


[...]

Er zijn gewoon opeens onvoorziene en vooral onverklaarbare bugs naar boven gekomen en ze werken er hard aan om die te fixen !!


[...]

https://pi-hole.net/blog/2025/02/18/introducing-pi-hole-v6/ is niet zomaar geschreven...

Zie zelfs dat er alweer een extra artikel is verschenen waarin een hoop dingen worden uitgelegd omtrent de meest voorkomende problemen : https://pi-hole.net/blog/...lease-fixes-and-findings/


[...]

/etc/dnsmasq.d/

En in theorie heb je die niet meer nodig, want alles kan je in /etc/pihole/pihole.toml overzetten !!
Helaas inderdaad handmatig indien dat niet automatisch is gebeurd...


[...]

Bij de Docker Container versie is dat inderdaad niet het geval, maar dat is helaas niet anders op te lossen...

Een reguliere installatie van Pi-Hole v6 pakt echter WEL standaard alle VLAN Interfaces op en qua VPN toestanden zal je het eventueel wel zelf effe moeten toevoegen, want geen echte Lokale Interface


[...]

setupVars = History!

Voortaan is /etc/pihole/pihole.toml gewoon DE PLEK voor al je aanpassingen en daarbij is ALLES beschikbaar via de webGUI via de Expert Mode die bij het Settings gedeelte een "All Settings" sub-menu laat verschijnen


[...]

setupVars.conf aanpassen is zelfs nooit een goed idee geweest, want die werd altijd na een update/upgrade overschreven geloof ik


[...]

Check effe https://discourse.pi-hole.net/ waar meerdere topics zijn over het toepassen van een Let's Encrypt Certificaat voor Pi-Hole v6

Er is zelfs iemand die ik heb geholpen en het werkend heeft gekregen, maar sinds ik de afgelopen dagen ruim 18 uur op het Pi-Hole Forum heb doorgebracht kan ik dat zo gauw effe niet meer terugvinden


[...]

Volgens mij zag ik die bug ook in ieder geval 2 keer langskomen...


[...]

Alle Reverse Proxy achtige setups dienen volledig aangepast te worden, want LigHTTPd die door Civetweb is vervangen

Het werkt nu gewoon anders en dat moet je effe uitvogelen...

Op https://discourse.pi-hole.net/ kan je eventueel wat richtlijnen terugvinden, want genoeg andere Reverse Proxy combinaties die ondertussen zijn aangepast en gepost


[...]

Leer jezelf aan om eerste flink rond te kijken en daarna pas aan de slag te gaan met de boel instellen/aanpassen naar je wensen

Het eerste wat ik deed toen ik de Pi-Hole v6 Beta had geïnstalleerd is alle opties doorbladeren via zowel de webGUI als SSH en daarna pas alles instellen om daadwerkelijk wat ermee te kunnen doen

En dat is ook iets wat ik doe als ik bijvoorbeeld een nieuwe TV/Telefoon/Mediaplayer/enz. koop !!!


[...]

Men is bezig met een soortgelijke bug te fixen dus ik gok dat jij die ook te pakken hebt


[...]

PHP is niet meer dus die link zal sowieso niet werken hé!

Ik geloof dat de URL voor de API nu http://<YOUR_PIHOLE_DOMAIN>/api/ is zelfs...


[...]

Je zal na een upgrade sowieso zelf LigHTTPd en PHP en de .php files van v5 moeten verwijderen


[...]

Jij moet het service commando vervangen door de Container herstarten geloof ik en het mv commando doe je sowieso op de lokale storage buiten de Container waar de database van Pi-Hole staat

Er schijnen heel veel mensen met super oude extreem grote databases te zijn die eventueel zelfs (deels) corrupt zijn geraakt door de tijd heen en dan gaan er gewoon een heleboel dingen over de zeik

Daarnaast is tegenwoordig het advies bij gebruik van extreem grote Gravity Lists om minimaal 1 GB RAM te hebben om het verwerken ervan na een Gravity Lists Update goed te laten verlopen


[...]

Ik geloof dat ze ondertussen al bezig zijn met toekomstige aanpassingen inplannen voor die functionaliteit


[...]

Voor mijn nieuwsgierigheid : Priveleged of Unprivileged ?


[...]

Bekende bug die bij sommigen soms consistent en soms inconsistent optreeft om de een of ander reden en aan wordt gewerkt


[...]

Kan je via SSH fixen via het pihole commando of door /etc/pihole.toml aan te passen

En ook een bekende bug waar aan wordt gewerkt trouwens!


[...]

Volgens mij ook bekend ondertussen, maar wel relatief nieuw vergeleken met de rest dus misschien duurt die fix langer dan de rest !!


[...]

Helaas voor een heleboel mensen inderdaad het geval, maar een heleboel mensen hebben er ook echt 0,0 voorbereiding in gestoken en dat vind ik best wel lullig voor de developers


[...]

Precies!


[...]

Ik geloof dat er al 1 of meerdere gebruikers zijn die bereid waren meerdere keren hun LXC dan wel VM terug te zetten naar de Pi-Hole v5 backup en de Pi-Hole v6 upgrade meerdere keren te herhalen om de fouten eruit te halen voor toekomstige upgrades dus het komt wel goed


Zo...


Tot zover uw "Pi-Hole v6 staat van zaken Update¨ van vandaag

Zo te lezen is het denk ik verstandig om tot 6.1 te wachten

[Airw0lf]

Waarschijnlijk kijk ik er naast - maar in v5 bestonden de instellingen AAAA_QUERY_ANALYSIS=false en RESOLVE_IPV6=false waarmee IPv6 queries niet meer te zien waren in de dashboards. Die lijken er nu niet meer te zijn? Of heb ik iets gemist?

Of nog beter: is er een manier om alle soorten IPv6 aanvragen te negeren (helemaal niks mee doen)?

edit:
Kwam er net achter dat RESOLVE_IPV6 ook niet meer lijkt te bestaan...

[ Voor 63% gewijzigd door Airw0lf op 23-02-2025 11:57 ]

[ed1703]

strandbal schreef op zondag 23 februari 2025 @ 08:00:
[...]


Unprivileged, privileged containers lijken me security wise niet handig. Overigens ook de reden dat de ntp server/client opties die ineens aan stonden uit moesten, dat genereerde allerlei insufficient rights meldingen. Raar ook dat ze die settings hebben verstopt onder "all settings". Ik verwacht niet direct een ntp server in een dns server

Vraag mij ook af waarom ze dat geimplementeerd hebben, want werkt dit tegenwoordig op elk OS?
Windows kijkt al niet naar de NTP settings die meegegeven worden via DHCP vziw en ik dacht macOS ook niet.

[Airw0lf]

@nero355 - ik kan me voorstellen dat je na 18 uur op het forum het ff gehad hebt...

Maar het feit dat de vlan interfaces te zien zijn wil niet zeggen dat de achterliggende dnsmasq settings terug te vinden zijn in het "All Settings" sub-menu... tis te zeggen... ik heb ze daar nog niet terug kunnen vinden... make-my-day...

Overigens staan die vlan interfaces in /etc/network/interfaces en heeft pihole-ftl zich "verbonden" met alle interfaces. En die zijn ook in pihole te zien zonder de dnsmasq instellingen in te lezen.

[andregroeneveld]

.je schreef op vrijdag 21 februari 2025 @ 03:29:
Ik kreeg tijdens de upgrade (binnen raspb, geen docker) geen popup met lighttp vraag. Bleek dat na de upgrade niets het deed, elke site gaf een 403.

Blijkt dat pihole botst als je de vraag niet krijgt en hij lijkt onderwater toch pihole-ftl poort 80 te proberen te claimen.

Was enigszins simpel op te lossen door lighttp te stoppen en uit te zetten.

code:

sudo systemctl stop lighttpd.service
sudo systemctl disable lighttpd.service

Daarna reboot en hij deed het weer. Als je gewend bent je admin portal zonder ww te banderen, draai dan even

code:

pihole setpassword

Dit trucje is bij mij nu wel gelukt maar dan werkt de Pi-Hole nog niet. Ik kan niet via de Pi-Hole mijn internet laten lopen want dan krijg ik niets door.

[ Voor 7% gewijzigd door andregroeneveld op 24-02-2025 11:54 ]

[jojost1]

beerns schreef op zaterdag 22 februari 2025 @ 09:26:
[...]


Ja, ik heb nieuwste vanmorgen binnen gehaald, thanks. Waar het (denk ik) op vast loopt, want er valt feitelijk niet zo heel veel foutief in te vullen; is de api. Daar staat dat je een link in moet geven en dat default /api is.
Ik kan niet zo heel veel fout doen aan het ip adres (of pi.hole invullen) en dan de poort ingeven (80 of 443 bij http of https, want ik heb beide geprobeerd).
En dan krijg ik de melding dat er een invalid URL is.

Dus als iemand dit netjes met v6 aan de praat heeft gekregen, hou ik me aanbevolen wat daar in te vullen

Hier werkt het met gewoon dezelfde info als in Safari op m’n iPhone.. Misschien de ontwikkelaar even contacten via de app!

[.je]

andregroeneveld schreef op zondag 23 februari 2025 @ 13:28:
[...]


Dit trucje is bij mij niet gelukt.

Vergeet niet opnieuw en dns server te selecteren in je instelling. Op de eoa manier verliest hij dat. Zie oa het notificatie gedeelte voor nog meer foutmeldingen.

[nero355]

strandbal schreef op zondag 23 februari 2025 @ 08:00:
Unprivileged, privileged containers lijken me security wise niet handig.

Uiteraard, maar ik vroeg het dus vanwege dit :

Overigens ook de reden dat de ntp server/client opties die ineens aan stonden uit moesten, dat genereerde allerlei insufficient rights meldingen.

Thnx!

Raar ook dat ze die settings hebben verstopt onder "all settings". Ik verwacht niet direct een ntp server in een dns server

Het is meer dat het onder de Expert Settings Mode staat en niet de Basic Settings om te voorkomen dat minder kundigen in de war raken denk ik ?!

Raven schreef op zondag 23 februari 2025 @ 09:17:
Zo te lezen is het denk ik verstandig om tot 6.1 te wachten

Mja, aan de eene kant wel, maar aan de andere kant misschien ook niet :

Het is gewoon stom genoeg ondanks de uitgebreide Beta periode bij een aantal gevallen/in een aantal situaties alsnog buggy gebleken om een v5 naar v6 upgrade uit te voeren en dat zijn ze nu aan het uitzoeken...

Ik heb het idee dat als je een verse installatie doet of een "netjes onderhouden" Pi-Hole upgrade dat er dan weinig aan de hand zal zijn
En de mensen die al heel lang de Beta gewoon in produktie draaiden hebben ook weinig problemen lijkt het wel...

Airw0lf schreef op zondag 23 februari 2025 @ 09:19:
Waarschijnlijk kijk ik er naast - maar in v5 bestonden de instellingen AAAA_QUERY_ANALYSIS=false en RESOLVE_IPV6=false waarmee IPv6 queries niet meer te zien waren in de dashboards.

Die lijken er nu niet meer te zijn? Of heb ik iets gemist?

Of nog beter: is er een manier om alle soorten IPv6 aanvragen te negeren (helemaal niks mee doen)?

edit:
Kwam er net achter dat RESOLVE_IPV6 ook niet meer lijkt te bestaan...

Deze lijst is handig wat betreft variabelen/files die nu anders of simpelweg foetsie zijn : https://docs.pi-hole.net/docker/upgrading/v5-v6/

ed1703 schreef op zondag 23 februari 2025 @ 10:28:
Vraag mij ook af waarom ze dat geimplementeerd hebben, want werkt dit tegenwoordig op elk OS?

Windows kijkt al niet naar de NTP settings die meegegeven worden via DHCP vziw en ik dacht macOS ook niet.

Volgens mij is het niet vanwege de DHCP Option maar vanwege de volledigheid vanuit DNSmasq/FTLDNS gedaan en/of mogelijk grote vraag ernaar vanuit de Community

Airw0lf schreef op zondag 23 februari 2025 @ 11:11:
@nero355 - ik kan me voorstellen dat je na 18 uur op het forum het ff gehad hebt...

Verspreid over meerdere dagen, maar daarom wel een hoop te weten gekomen

Maar het feit dat de vlan interfaces te zien zijn wil niet zeggen dat de achterliggende dnsmasq settings terug te vinden zijn in het "All Settings" sub-menu... tis te zeggen... ik heb ze daar nog niet terug kunnen vinden... make-my-day...

Jij schrijft precies wat ik al tegen je zei :

Overigens staan die vlan interfaces in /etc/network/interfaces en heeft pihole-ftl zich "verbonden" met alle interfaces.
En die zijn ook in pihole te zien zonder de dnsmasq instellingen in te lezen.

In mijn geval was het tijdens het testen van de Beta nog een kwestie van alleen de WebGUI effe aan eth0 binden en dan bleef DNS vanzelf als enige over die op ALLE Interfaces actief was

[Airw0lf]

@nero355 - nu volg ik je niet meer...

In een eerdere post schreef je:

/etc/dnsmasq.d/

En in theorie heb je die niet meer nodig, want alles kan je in /etc/pihole/pihole.toml overzetten !!
Helaas inderdaad handmatig indien dat niet automatisch is gebeurd...

Dit heb ik begrepen als de *inhoud* van de configs in [mone]/etc/dnsmasq.d[/mono] zijn niet meer nodig. En vormen een onderdeel van pihole.toml. Danwel kunnen er handmatig aan toegevoegd worden - mochten ze niet meekomen met de upgrade.

In praktijk lijkt dat niet zo te zijn - in de nieuwe pihole-config is alleen een parameter opgenomen waarmee aangegeven wordt of deze ingelezen moeten worden bij het starten - meer dan dat gebeurd er niet => de inhoud van die config bestandjes wordt niet opgenomen in de nieuwe pihole-config.

Zo ook de verwijzing naar de lijst met vars: die had ik gezien. Maar daar staat niet alles tussen - niet als een andere naam. Maar ook niet als ze zijn komen te vervallen (waaronder de twee die ik noemde).

[nero355]

Airw0lf schreef op zondag 23 februari 2025 @ 17:48:
nu volg ik je niet meer...

Ik jou ook niet meer

In een eerdere post schreef je:

[...]

Dit heb ik begrepen als de *inhoud* van de configs in /etc/dnsmasq.d/ zijn niet meer nodig.
En vormen een onderdeel van pihole.toml.

Danwel kunnen er handmatig aan toegevoegd worden - mochten ze niet meekomen met de upgrade.

Dat klopt!

Je hebt namelijk als nieuwe optie naast het includen van /etc/dnsmasq.d/ dingetjes ook de optie die heet iets van "Misc DNSmasq lines" waar je alles in kan voeren

In praktijk lijkt dat niet zo te zijn - in de nieuwe pihole-config is alleen een parameter opgenomen waarmee aangegeven wordt of deze ingelezen moeten worden bij het starten - meer dan dat gebeurd er niet => de inhoud van die config bestandjes wordt niet opgenomen in de nieuwe pihole-config.

Dan heb jij dus ook één van die vreemde bugs te pakken of is er iets mis met je Docker Container configuratie, want dat hoort gewoon te werken over het algemeen

Zo ook de verwijzing naar de lijst met vars: die had ik gezien.
Maar daar staat niet alles tussen - niet als een andere naam. Maar ook niet als ze zijn komen te vervallen (waaronder de twee die ik noemde).

Dat was meer een "Ik vertel je wat ik weet en als dat niet genoeg is dan zal je misschien effe een Bug Report via Discourse of GitHub moeten inschieten" opmerking

[Mau_Maus]

Ik heb trouwens sinds v6 na elke -up dat ik mijn RPI fysiek een keer moeten herstarten.
Via VNC of /admin word er niet gereageerd. Heel vreemd. Of de tree building moet extreem lang duren... Kan niet zo snel andere vinden die dit hebben na de update.

[ Voor 10% gewijzigd door Mau_Maus op 23-02-2025 18:06 ]

[nero355]

Mau_Maus schreef op zondag 23 februari 2025 @ 17:54:
Ik heb trouwens sinds v6 na elke -up dat ik mijn RPI fysiek een keer moeten herstarten.

Welk model precies ?!

Via VNC of /admin word er niet gereageerd. Heel vreemd.

Klinkt als een hoog CPU gebruik...

Of de tree building moet extreem lang duren...

Kan niet zo snel andere vinden die dit hebben na de update.

Heb je grote lijsten of veel lijsten in gebruik toevallig ?!

Dan wil je minimaal 1 GB RAM hebben namelijk en kan je dat soort problemen verwachten als je minder RAM hebt

[Mau_Maus]

nero355 schreef op zondag 23 februari 2025 @ 18:10:
[...]
Welk model precies ?
[...]
Klinkt als een hoog CPU gebruik...
[...]
Heb je grote lijsten of veel lijsten in gebruik toevallig ?!

Dan wil je minimaal 1 GB RAM hebben namelijk en kan je dat soort problemen verwachten als je minder RAM hebt

Ja deze info had ik wel alvast mogen noemen haha. Heb de 3B+ en ja best veel lijsten. Denk tussen de 10 en 15 miljoen geblokkeerde domeinen. Ik weet is extreem, maar whitelisten liever achteraf.
Met v5 nooit een probleem.
Deze is 1gb ram, maar wordt dus krap? Jammer.

[Airw0lf]

@nero355 - bedankt voor de laatste toelichting - alles is duidelijk nu.

Als die Misc DNSmasq lines het inderdaad is dan blijf ik voorlopig nog wel even draaien met de configs in /etc/dnsmasq.d - werkt voor mij net wat praktischer dan steeds die webgui in te moeten duiken.

Blijft over de settings die verdwenen zijn en de reverse proxy. Van de settings heb ik inmiddels een vraag uitgezet iin het forum. En de reverse proxy is even wachten op linuxserver.io...

[nero355]

Mau_Maus schreef op zondag 23 februari 2025 @ 18:16:
Ja deze info had ik wel alvast mogen noemen haha.

Hoe oud is je kaartje trouwens ?!

Dat kan ook een hoop schelen

Heb de 3B+ en ja best veel lijsten. Denk tussen de 10 en 15 miljoen geblokkeerde domeinen.
Ik weet is extreem, maar whitelisten liever achteraf.

Met v5 nooit een probleem.

Je zou eens je gravity.db kunnen hernoemen naar gravity.db.bak of gravity_old.db en dan een Gravity Lists Update draaien

Deze is 1gb ram, maar wordt dus krap? Jammer.

Bij jou zou het misschien wel beter 2 GB RAM of zelfs meer kunnen zijn, maar het hoeft natuurlijk niet alleen maar daaraan te liggen dus kijk effe wat je allemaal kan testen en hoe dat uitpakt

Airw0lf schreef op zondag 23 februari 2025 @ 18:18:
bedankt voor de laatste toelichting - alles is duidelijk nu.

Als die Misc DNSmasq lines het inderdaad is dan blijf ik voorlopig nog wel even draaien met de configs in /etc/dnsmasq.d - werkt voor mij net wat praktischer dan steeds die webgui in te moeten duiken.

In alle eerlijkheid :

Voor bepaalde dingen heeft dat ook mijn voorkeur op de een of andere manier...

Voelt gewoon fijner of zo

Blijft over de settings die verdwenen zijn en de reverse proxy. Van de settings heb ik inmiddels een vraag uitgezet iin het forum. En de reverse proxy is even wachten op linuxserver.io...

Ben benieuwd!

Wie weet heb je wat gevonden dat ze over het hoofd hebben gezien of zo...

[ Voor 35% gewijzigd door nero355 op 23-02-2025 18:24 ]

[Freee!!]

nero355 schreef op zondag 23 februari 2025 @ 18:21:
[...]
Bij jou zou het misschien wel beter 2 GB RAM of zelfs meer kunnen zijn,

Lastig met een 3B+, die hebben 1 GB aan boord.

[nero355]

Freee!! schreef op zondag 23 februari 2025 @ 18:27:
Lastig met een 3B+, die hebben 1 GB aan boord.

Bedoel het uiteraard in het algemeen :

Er zijn ook mensen die de hoeveelheid RAM voor hun VM of LXC hebben moeten vergroten bijvoorbeeld

In het geval van een Raspberry Pi zal je dan een ander model moeten pakken helaas... of een Odroid... of een Banana Pi... of een Orange Pi... enz... enz.. enz.

[Mau_Maus]

nero355 schreef op zondag 23 februari 2025 @ 18:21:
[...]
Hoe oud is je kaartje trouwens ?!
Dat kan ook een hoop schelen

Kaartje is al zeker paar jaar, maar juist verrassend stabiel en responsive met v5 en handelingen die op op Raspbian deed, maar inderdaad die zijn met zoveel schijfacties snel aan vervanging toe.

[...]
Je zou eens je gravity.db kunnen hernoemen naar gravity.db.bak of gravity_old.db en dan een Gravity Lists Update draaien

Hou ik in mijn achterhoofd, maar laat hem denk ik even nachtje draaien zonder de herstarten.
Misschien is het alleen de eerste keer lastig?

[...]
Bij jou zou het misschien wel beter 2 GB RAM of zelfs meer kunnen zijn, maar het hoeft natuurlijk niet alleen maar daaraan te liggen dus kijk effe wat je allemaal kan testen en hoe dat uitpakt

Ja ik heb nog een Pi4 en 5 beide 8GB ram, maar vond dat wat overkill haha.

Zal ook nog wel eens een herinstallatie proberen. Had gehoopt op een 'bekend' aanwijsbaar iets in de config na v6, maar helaas haha. Dank voor de tips ieder geval!
Ik zit ook midden in een verhuizing dus mocht ik er later even rustig voor kunnen zitten laat ik nog wel weten als 1 van de opties geholpen heeft.

[nero355]

Mau_Maus schreef op zondag 23 februari 2025 @ 18:33:
Kaartje is al zeker paar jaar, maar juist verrassend stabiel en responsive met v5 en handelingen die op op Raspbian deed, maar inderdaad die zijn met zoveel schijfacties snel aan vervanging toe.

Mijn microSDXC kaartje is een 100 MB/s Read & 100 MB/s Write model en 6 jaar oud en ik merk nu toch wel dat die trager is geworden...

Hou ik in mijn achterhoofd, maar laat hem denk ik even nachtje draaien zonder de herstarten.
Misschien is het alleen de eerste keer lastig?

Misschien, maar dat merk je vanzelf wel bij de volgende Gravity List Update als je op dat moment online bent zeg maar

Er is trouwens ook nog een instelling die het aantal Threads bepaalt, maar dat is alleen voor de webGUI van toepassing als ik me niet vergis en staat standaard op "Auto" maar kan je zelf gewoon aanpassen als je dat wilt en dus ook mee testen!

Ja ik heb nog een Pi4 en 5 beide 8GB ram, maar vond dat wat overkill haha.

Dat is ook zo, maar als je ze effe kan gebruiken om te testen dan is dat niet verkeerd

Ik moet sowieso upgraden naar minimaal een Raspberry Pi 5 of iets soortgelijks waarschijnlijk vanwege de ARM instructie set die alleen de Pi 5 heeft en voorkomt dat ik elke keer met een outdated MongoDB zit te klooien in de toekomst...

Zal ook nog wel eens een herinstallatie proberen.

Opzich wel interessant om te weten hoe dat uitpakt!

Had gehoopt op een 'bekend' aanwijsbaar iets in de config na v6, maar helaas haha. Dank voor de tips ieder geval!

Ik zit ook midden in een verhuizing dus mocht ik er later even rustig voor kunnen zitten laat ik nog wel weten als 1 van de opties geholpen heeft.

Succes alvast met beide toestanden!

[Mau_Maus]

nero355 schreef op zondag 23 februari 2025 @ 18:51:
[...]
Er is trouwens ook nog een instelling die het aantal Threads bepaalt, maar dat is alleen voor de webGUI van toepassing als ik me niet vergis en staat standaard op "Auto" maar kan je zelf gewoon aanpassen als je dat wilt en dus ook mee testen!

Enige tips hierin voor het aantal Threads?

En bedankt op al het andere

[Get!em]

Voor proxmox helperscripts lopen nu een aantal tickets hier mbt pihole, unbound sinds v6

https://github.com/community-scripts/ProxmoxVE/issues/2549

[Jazzy]

nero355 schreef op zondag 23 februari 2025 @ 00:04:
IMHO is die hele functie gewoon sowieso R-U-K en moet je dat eigenlijk niet nodig willen hebben !!

Zorg ervoor dat al je Clients :
- Een Static IP Address in het OS hebben staan.
- Of dat er een Static DHCP IP Mapping op basis van het MAC Address in je DHCP Server bestaat.

En maak vervolgens Local DNS Records aan voor al die IP adressen in Pi-Hole en KLAAR!!!

Ik heb die meuk nooit gebruikt of nodig gehad de afgelopen 8+ jaar dat ik Pi-Hole gebruik

Kan het zijn dat je de functie gewoon niet goed begrijpt? Leg anders even uit wat je precies R-U-K vindt aan conditional forwarding? Want statische IP-adressen gaan gebruiken ipv. DHCP lijkt me nooit de oplossing.

[Wildfire]

Fijn dat PiHole v6 opeens een NTP server lijkt te bevatten. Gauw maar uitgezet, mijn Raspberry Pi *is* zelf al een NTP server -- zit een DS3231 RTC module op de Pi en is dus ingeregeld als NTP server.

Moet wel zeggen dat de upgrade naar v6 hier verder goed verlopen lijkt te zijn. Ook Unbound ging gewoon netjes mee over.

Was een onverwachte upgrade, niet bij stil gestaan dat 'pihole -up' gewoon klakkeloos naar een nieuwe major versie zou gaan upgraden.

Gelukkig doe ik altijd eerst een upgrade van mijn secundaire PiHole, ik wacht nu even met mijn primaire PiHole om v6 de tijd te geven door de kinderziektes heen te komen (ook al lijk ik daar op die tweede PiHole -vooralsnog- geen last van te hebben).

[ Voor 56% gewijzigd door Wildfire op 24-02-2025 00:55 ]

[MRE-Inc]

Met betrekking tot de iOS Shortcut die je kan starten op een iPhone of iPad om snel blocking in of uit te schakelen:

https://discourse.pi-hole...ole-v6-ios-shortcut/76425

Iemand heeft dus de iOS shortcut aangepast om te werken met PiHole v6.

Echter komt deze shortcut nu met een melding over een certificaat:

Het certificaat van deze server in ongeldig. Mogelijk maak je verbinding met een server die zich voordoet als "pi.hole", waardoor je vertrouwlijke informatie gevaar kan lopen.

Ik heb dat self signed certificaat op mijn iPhone geinstalleerd en in bv Safari werkt dat als in: geen certificaat melding bij https, maar voor shortcuts moet je toch wat anders doen of een niet-self signed certificaat gebruiken ?

[Jazzy]

MRE-Inc schreef op maandag 24 februari 2025 @ 08:32:
Echter komt deze shortcut nu met een melding over een certificaat:


[...]


Ik heb dat self signed certificaat op mijn iPhone geinstalleerd en in bv Safari werkt dat als in: geen certificaat melding bij https, maar voor shortcuts moet je toch wat anders doen of een niet-self signed certificaat gebruiken ?

Dit is een iOS beperking, helaas. Denk dat je toch echt aan een Let's Encrypt certificaat zult moeten, als je een Shortcut gebruikt.

[Airw0lf]

Ter informatie: ik ben terug naar v5 - te veel problemen.
Het grootste probleem is dat dns-resolving met vlans via een dnsmasq-config-bestandje niet goed meer werkt. Hebben anderen hier ook last van?

[nero355]

Mau_Maus schreef op zondag 23 februari 2025 @ 19:35:
Enige tips hierin voor het aantal Threads?

Gewoon zelf testen/uitproberen en kijken wat echt nut heeft

En bedankt op al het andere

Get!em schreef op zondag 23 februari 2025 @ 20:14:
Voor proxmox helperscripts lopen nu een aantal tickets hier mbt pihole, unbound sinds v6

https://github.com/community-scripts/ProxmoxVE/issues/2549

Zoveel werk is het toch niet om :
- Een LXC/VM op te zetten.
- Debian te Installeren.
- Pi-Hole te installeren.
- Unbound te installeren.

KLAAR!!!

Jazzy schreef op zondag 23 februari 2025 @ 20:47:
Kan het zijn dat je de functie gewoon niet goed begrijpt?

Ik weet prima hoe het werkt, maar als je gewoon je netwerk fatsoenlijk opzet dan zou je er 0,0 behoefte aan moeten hebben

Leg anders even uit wat je precies R-U-K vindt aan conditional forwarding?

Omdat er heel veel mensen zijn die :
- Daarmee DNS loops voor elkaar krijgen...
- Er meerdere gevallen zijn geweest van rare bugs doordat er het een en ander mis is gegaan aan de kant van de gebruikte Router en het dus niet of slecht werkt...

Want statische IP-adressen gaan gebruiken ipv. DHCP lijkt me nooit de oplossing.

Wat vind je zo erg aan Static DHCP IP Mappings op basis van MAC Address dan

MRE-Inc schreef op maandag 24 februari 2025 @ 08:32:
Met betrekking tot de iOS Shortcut die je kan starten op een iPhone of iPad om snel blocking in of uit te schakelen:

https://discourse.pi-hole...ole-v6-ios-shortcut/76425

Iemand heeft dus de iOS shortcut aangepast om te werken met PiHole v6.

Echter komt deze shortcut nu met een melding over een certificaat:

[...]

Ik heb dat self signed certificaat op mijn iPhone geinstalleerd en in bv Safari werkt dat als in: geen certificaat melding bij https, maar voor shortcuts moet je toch wat anders doen of een niet-self signed certificaat gebruiken ?

Heb je niet heel toevallig een mismatch tussen de Hostname+Domain combinatie die ingesteld staat en degene die in het HTTPS/SSL Certificaat staat

Dat kan je namelijk heel simpel fixen :
- Eerst de gewenste Hostname+Domain instellen in /etc/pihole/pihole.toml
- Vervolgens de 3 TLS files verwijderen in /etc/pihole/
- Daarna effe Pi-Hole restarten :

code:

systemctl restart pihole-FTL

En dan ben je van die irritante mismatch melding af

Airw0lf schreef op maandag 24 februari 2025 @ 15:11:
Ter informatie: ik ben terug naar v5 - te veel problemen.
Het grootste probleem is dat dns-resolving met vlans via een dnsmasq-config-bestandje niet goed meer werkt.

Hebben anderen hier ook last van?

Waar heb je dan allemaal last van precies ??

[ Voor 6% gewijzigd door nero355 op 24-02-2025 15:19 ]

[andregroeneveld]

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

[ Voor 18% gewijzigd door andregroeneveld op 24-02-2025 15:32 ]

[Jazzy]

nero355 schreef op maandag 24 februari 2025 @ 15:18:
Wat vind je zo erg aan Static DHCP IP Mappings op basis van MAC Address dan

Dat het niet schaalbaar is natuurlijk. Zoiets werkt alleen in een statisch en gecontroleerd netwerkje. Alleen al in mijn thuisomgeving heb je het over tientallen devices die op enig moment aan het netwerk zouden kunnen hangen en dan heb je nog niet eens over mijn kinderen en hun vrienden die hier binnenkomen met een telefoons, laptops, spelcomputers, Raspberry Pi of Arduino's en wat niet meer.

En waar hebben we het over? Dit is allemaal niet nodig als je Pi-hole simpelweg naar een DNS-server kunt wijzen waar deze informatie 24/7 dynamisch wordt geregistreerd.

[nero355]

andregroeneveld schreef op maandag 24 februari 2025 @ 15:30:
dhcpcd.config was de boosdoener want er ontbrak onderin dit file:

code:

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

Als je systeem zonder DNS Resolving zat tijdens een upgrade dan is dat inderdaad de oplossing

!! Doe dit echter wel via een tweede SSH sessie en ram niet op CTRL+C zoals sommigen, want dan maak je grote kans op onnodige problemen met je Pi-Hole v5 naar Pi-Hole v6 upgrade !!

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

En daarmee voorkom je dat LigHTTPd poort 80 en eventueel 443 bezet houdt

Jazzy schreef op maandag 24 februari 2025 @ 15:59:
Dat het niet schaalbaar is natuurlijk. Zoiets werkt alleen in een statisch en gecontroleerd netwerkje.

Voor je thuisnetwerk een prima oplossing

Alleen al in mijn thuisomgeving heb je het over tientallen devices die op enig moment aan het netwerk zouden kunnen hangen

Maar...

Wel of niet van jou ??

en dan heb je nog niet eens over mijn kinderen en hun vrienden die hier binnenkomen met een telefoons, laptops, spelcomputers, Raspberry Pi of Arduino's en wat niet meer.

Die prop je in een Guest VLAN en laat ze daar lekker verder prutsen...

En waar hebben we het over? Dit is allemaal niet nodig als je Pi-hole simpelweg naar een DNS-server kunt wijzen waar deze informatie 24/7 dynamisch wordt geregistreerd.

Tja, het is een keuze...

[Jazzy]

nero355 schreef op maandag 24 februari 2025 @ 16:07:
Die prop je in een Guest VLAN en laat ze daar lekker verder prutsen...

Je verandert nu steeds van onderwerp, dat is geen manier om een discussie te voeren. Ik hou het hier bij. Wil je mijn onderbouwde kritiek op de Pi-hole implementatie van conditional forwarding lezen dan kan dat hierboven.

[ Voor 3% gewijzigd door Jazzy op 24-02-2025 16:16 ]

[nero355]

Jazzy schreef op maandag 24 februari 2025 @ 16:16:
Je verandert nu steeds van onderwerp.

Nee...

Ik vertel je dat je jezelf te druk maakt om apparaten die niet constant actief zijn op je netwerk

dat is geen manier om een discussie te voeren. Ik hou het hier bij. Wil je mijn onderbouwde kritiek op de Pi-hole implementatie van conditional forwarding lezen dan kan dat hierboven.

Discussie ontwijken omdat je het niet eens bent met iemand is blijkbaar ook een ding...

[Airw0lf]

@nero355 - waar ik last van heb:

Het management domein is tech.lan. Dit is ook het domein wat via de gui in pihole is ingesteld. Het subnet is 192.168.139.0/24.

Daarnaast zijn er verschillende vlans/domeinen voor clients en applicatieservers. Bijvoorbeeld de client vlans wired.lan en wifi.lan - allemaal ingesteld via een dnsmasq-config bestandje.

Pihole draait als docker container op een lxc container met de dns naam morpheus.
Het ip adres van deze lxc container eindigt voor alle vlans op .235.
Dus voor het management vlan wordt het dan morpheus.tech.lan met 192.168.139.235
Voor het wired vlan wordt het morpheus.wired.lan met 192.168.210.235.

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.

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...

[ Voor 6% gewijzigd door Airw0lf op 24-02-2025 19:04 ]

[Toet3r]

@Airw0lf
staat bij versie 6 bij settings - all settings - Miscellaneous - misc.etc_dnsmasq_d aangevinkt?

[Airw0lf]

Toet3r schreef op maandag 24 februari 2025 @ 17:34:
@Airw0lf
staat bij versie 6 bij settings - all settings - Miscellaneous - misc.etc_dnsmasq_d aangevinkt?

Zekers - anders had ik geeneens dhcp en dns op die vlans.

Zo staat die in pihole.toml:
etc_dnsmasq_d = true ### CHANGED (env), default = false

[ Voor 19% gewijzigd door Airw0lf op 24-02-2025 18:43 ]

[MRE-Inc]

@nero355 Bedankt voor de tip. Ga het vanavond proberen.

Heb ook maar die PI Hole Remote app gekocht voor 11 euro. Werkt ook prima en daarmee kan ik zelfs een mooie widget gebruiken.

Werkt ook prima op de iPhone van m'n vrouw als die weer op van die boutique/kleding sites zit waarvan de betaling weer niet werkt omdat er weer iets geblokkeerd wordt. Kan ze hetooi via de widget even uitschakelen en verberg ik de Pi hole Remote app op haar iPhone.

[Toet3r]

Airw0lf schreef op maandag 24 februari 2025 @ 17:48:
[...]


Zekers - anders had ik geeneens dhcp en dns op die vlans.

Zo staat die in pihole.toml:
etc_dnsmasq_d = true ### CHANGED (env), default = false

Dan zou het moeten werken

[Toet3r]

Gaat wel lekker met de updates, zit ondertussen op docker tag 2025.02.6

[MRE-Inc]

nero355 schreef op maandag 24 februari 2025 @ 15:18:
[...]

Heb je niet heel toevallig een mismatch tussen de Hostname+Domain combinatie die ingesteld staat en degene die in het HTTPS/SSL Certificaat staat

Dat kan je namelijk heel simpel fixen :
- Eerst de gewenste Hostname+Domain instellen in /etc/pihole/pihole.toml
- Vervolgens de 3 TLS files verwijderen in /etc/pihole/
- Daarna effe Pi-Hole restarten :

code:

systemctl restart pihole-FTL

En dan ben je van die irritante mismatch melding af

Welke regels zijn dat in die pihole.toml ?

Hostnaam zie ik niet specifiek staan. Vanaf regel 50 staat er dit bij mij:

# Controls whether and how FTL will reply with for address for which a local interface
# exists. Changing this setting causes FTL to restart.
#
# Possible values are:
# - "NONE"
# Pi-hole will not respond automatically on PTR requests to local interface
# addresses. Ensure pi.hole and/or hostname records exist elsewhere.
# - "HOSTNAME"
# Serve the machine's hostname. The hostname is queried from the kernel through
# uname(2)->nodename. If the machine has multiple network interfaces, it can
# also have multiple nodenames. In this case, it is unspecified and up to the
# kernel which one will be returned. On Linux, the returned string is what has
# been set using sethostname(2) which is typically what has been set in
# /etc/hostname.
# - "HOSTNAMEFQDN"
# Serve the machine's hostname (see limitations above) as fully qualified domain
# by adding the local domain. If no local domain has been defined (config option
# dns.domain), FTL tries to query the domain name from the kernel using
# getdomainname(2). If this fails, FTL appends ".no_fqdn_available" to the
# hostname.
# - "PI.HOLE"
# Respond with "pi.hole".
piholePTR = "PI.HOLE"

Moet ik hier iets aanpassen ?

Domein instellen staat bij mij in regel 135

# The DNS domain used by your Pi-hole to expand hosts and for DHCP.
#
# Only if DHCP is enabled below: For DHCP, this has two effects; firstly it causes the
# DHCP server to return the domain to any hosts which request it, and secondly it sets
# the domain which it is legal for DHCP-configured hosts to claim. The intention is to
# constrain hostnames so that an untrusted host on the LAN cannot advertise its name
# via DHCP as e.g. "google.com" and capture traffic not meant for it. If no domain
# suffix is specified, then any DHCP hostname with a domain part (ie with a period)
# will be disallowed and logged. If a domain is specified, then hostnames with a
# domain part are allowed, provided the domain part matches the suffix. In addition,
# when a suffix is set then hostnames without a domain part have the suffix added as
# an optional domain part. For instance, we can set domain=mylab.com and have a
# machine whose DHCP hostname is "laptop". The IP address for that machine is
# available both as "laptop" and "laptop.mylab.com".
#
# You can disable setting a domain by setting this option to an empty string.
#
# Possible values are:
# <any valid domain>
domain = "intern.lan" ### CHANGED, default = "lan"

Edit: het aanpassen van regel 53 naar HOSTNAME of HOSTNAMEFQDN maakt niet uit. Op een of andere manier is de CN in het certificaat nog steeds pi.hole ipv de hostnaam van mijn rasperry pi, namleijk mre-rpi4. En ja, ook de FTL herstart en de bestaande certificaten verwijderd.

EDIT: via https://gist.github.com/k...ddb59a7d336b20376695797c6 in combinatie van een al hebbend Cloudflare account + DNS.

Nu gewoon een geldig normaal SSL certificaat.

[ Voor 4% gewijzigd door MRE-Inc op 24-02-2025 21:40 ]

[Mau_Maus]

nero355 schreef op maandag 24 februari 2025 @ 15:18:
[...]
Gewoon zelf testen/uitproberen en kijken wat echt nut heeft

Uiteindelijk maar de Pi4 maar gepakt met nieuw kaartje (als ik toch opnieuw moet installeren).
Wat uiteraard prima werkt

[nero355]

Airw0lf schreef op maandag 24 februari 2025 @ 17:27:
Het management domein is tech.lan.
Dit is ook het domein wat via de gui in pihole is ingesteld.
Het subnet is 192.168.139.0/24.

wired.lan
wifi.lan
allemaal ingesteld via een dnsmasq-config bestandje.

Pi-Hole Docker Container in LXC
dns naam morpheus.
Het ip adres van deze lxc container eindigt voor alle vlans op .235.

management vlan
morpheus.tech.lan
192.168.139.235

wired vlan
morpheus.wired.lan
192.168.210.235.

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.

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...

_{Ik heb effe je reply een beetje ingekort/aangepast/overzichtelijk voor mezelf gemaakt... Please ignore... Is puur ter referentie voor mezelf...}

Ik begrijp je probleem helemaal en is iets wat ik mezelf ook een beetje zat af te vragen hoe ik dat straks ga fixen, maar opzich is het geen echt probleem naar mijn mening op het "Wat zal een nslookup of dig antwoorden als gebruikte DNS Server" gedeelte na dan

Waarom ?
Nou...

- De webGUI van Pi-Hole kan je makkelijk alleen aan je Management VLAN koppelen.
Dus morpheus.tech.lan en dan op de gewenste poort.

Wil je deze eventueel vanuit een andere VLAN bereiken (Wired of WiFi) dan moet je Firewall dat natuurlijk wel toelaten en dan bedoel ik die van je Router die Inter-VLAN Routing doet

Ga die dus niet direkt op het DNS IP adres benaderen vanuit andere VLANs want dat is iets wat je sowieso niet moet willen...
Je Router beheer je ook niet vanuit een Guest VLAN om het maar effe zo te zeggen

- Dat je als antwoord morpheus.tech.lan krijgt als je morpheus.wired.lan verwacht op IP adres 192.168.210.235 heeft denk ik met je DNS setup te maken, maar waar precies de fout zit durf ik effe niet te zeggen...

Ik zou namelijk verwachten dat je standaard alleen 192.168.210.235 hebt op het VLAN Interface genaamd wired.lan en zelf handmatig een Local DNS Record aan zou moeten maken om überhaupt een DNS Record te hebben voor 192.168.210.235 dus in dit geval morpheus.wired.lan


Kan je hier wat mee


_{(Hier totaal offtopic, maar kijk uit voor A-Symmetric Routing in je setup !!
Als je SSH session ineens freezed op het moment dat je vanuit Wired/WiFi naar je Tech VLAN verbinding maakt met je Pi-Hole via SSH dan heb je dat probleem te pakken...)}

MRE-Inc schreef op maandag 24 februari 2025 @ 18:04:
Bedankt voor de tip. Ga het vanavond proberen.

Heb ook maar die PI Hole Remote app gekocht voor 11 euro.
Werkt ook prima en daarmee kan ik zelfs een mooie widget gebruiken.

Dat is een hoop geld voor zoiets simpels

Werkt ook prima op de iPhone van m'n vrouw als die weer op van die boutique/kleding sites zit waarvan de betaling weer niet werkt omdat er weer iets geblokkeerd wordt. Kan ze hetooi via de widget even uitschakelen en verberg ik de Pi hole Remote app op haar iPhone.

Dat moet je gewoon oplossen met een Whitelist die aan haar telefoon/tablet/laptop/enz. is gekoppeld

MRE-Inc schreef op maandag 24 februari 2025 @ 20:31:
Welke regels zijn dat in die pihole.toml ?


Edit: het aanpassen van regel 53 naar HOSTNAME of HOSTNAMEFQDN maakt niet uit. Op een of andere manier is de CN in het certificaat nog steeds pi.hole ipv de hostnaam van mijn rasperry pi, namleijk mre-rpi4. En ja, ook de FTL herstart en de bestaande certificaten verwijderd.

Kijk anders effe naar deze HowTo/Guide @ https://docs.pi-hole.net/api/tls/

[Jazzy]

MRE-Inc schreef op maandag 24 februari 2025 @ 20:31:
[...]


Welke regels zijn dat in die pihole.toml ?

Je moet webserver.domain aanpassen in de pihole.toml. Kan trouwens ook gewoon vanuit All Settings.

[ Voor 10% gewijzigd door Jazzy op 24-02-2025 23:50 ]

[MRE-Inc]

nero355 schreef op maandag 24 februari 2025 @ 22:12:
[...]

Dat is een hoop geld voor zoiets simpels

Kijk anders effe naar deze HowTo/Guide @ https://docs.pi-hole.net/api/tls/

Ach, anders was het 1 euro per maand. Doe dat 2 jaar...En van een Nederlandse dev en het ziet er ook nog eens goed uit met interactieve widgets. Niet een of andere webapp achtige schil om je eigen url. Hier zit echt wel wat werk in. Kan ook in een gezin gedeeld worden.
Ja ik kan wel wachten tot iemand die shortcut zo maakt zoals die weer was zoals de oude di ik had, maar dan ben je misschien wel weer weken verder.

Tevens nu een echt ssl certificaat via https://gist.github.com/k...ddb59a7d336b20376695797c6

Vernieuwd ook nog eens. Zodra ik alle commando'sn had uitgevoerd werkte het meteen in mijn browsers zonder gekke .cer bestanden ergens te moeten importeren etc.

[Jumpman]

Hmmm, ik blijf sinds Pi-Hole V6.X op mijn Synology met Container Manager toch tegen wat problemen aanlopen. Ik heb er net te weinig kennis van, denk ik.

Allereerst sinds V6.X moet ik [code] -e DNSMASQ_USER=pihole [/code] naar [code] -e DNSMASQ_USER=root [/code] veranderen, anders krijg ik het niet meer werkend.

Ten tweede zie ik nog maar één gebruiker in Pi-Hole namelijk: 172.17.0.1 (dit is in Container Manager het bridge adress), voorheen zag ik hier alle lokale adressen van de devices die door de Pi-Hole gingen. Ik heb ook al [code]--network=host [/code] geprobeerd, maar dat werkt ook niet.

Welke code gebruik ik in de Taakplanner:

code:

docker run -d --name Pi-Hole \
  -p 53:53/tcp \
  -p 53:53/udp \
  -p 8080:80/tcp \
  -p 3443:443/tcp \
  --security-opt no-new-privileges=false \
  -v /volume1/docker/pihole/dnsmasq.d:/etc/dnsmasq.d:rw \
  -v /volume1/docker/pihole/pihole:/etc/pihole:rw \
  -e FTLCONF_webserver_api_password=12345678 \
  -e TZ=Europe/Amsterdam \
  -e DNSMASQ_USER=root \
  -e PIHOLE_UID=1000 \
  -e PIHOLE_GID=100 \
  --cap-add SYS_TIME \
  --cap-add SYS_NICE \
  --restart on-failure:5 \
  pihole/pihole

Password, UID en GID zijn uiteraard niet die van mij.

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

Welke versies gebruik ik: Docker Tag 2025.02.6, Core v6.0.4, FTL v6.0.2, Web interface v6.0.1.

[ Voor 8% gewijzigd door Jumpman op 25-02-2025 12:18 ]

[Airw0lf]

@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.