[Pi-Hole] Ervaringen & discussie

[jpgview]

ivootjuh schreef op zondag 17 mei 2020 @ 15:55:
Ik snap er echt helemaal niks van, ben toch best wel bekend met groep management op mijn server en nas, maar krijg dit gewoon niet werkend.

Omdat ik vermoed dat er wel meer mensen geintereseerd zijn in deze oplossing, heb ik een document (handleiding) gemaakt, specifief voor dit scenario. je vind het hier.

Er zit een script bij (GitHub link) dat het meeste werk voor jou doet. Je hoeft daarna alleen nog maar een client aan te maken en aan de groep toe te voegen (ook beschreven in het document)

Ik heb het getest, het werkt (hardware is raspberry pi 3B, OS Raspbian, laatste versie)

Opgelet, je bent beta tester (maar bij mij liep alles goed). issues op GitHub a.u.b.

- users.telenet.be in sommige block lists -> lezen = whitelisten.
- zorg ervoor dat je eerst alle oude troep verwijderd, ook whitelist entries die je in het verleden voor je wag hebt aangemaakt (zijn van toepassing op alle devices).
- lees de comments in het script, voor je het uitvoert!

downloaden:

code:

sudo wget https://raw.githubusercontent.com/jpgpi250/piholemanual/master/googleads.sh -O /home/pi/googleads.sh
chmod +x /home/pi/googleads.sh

execute:

code:

sudo /home/pi/googleads.sh

Graag hoor ik commentaar op de whitelist entries, daar ben ik niet 100% van overtuigd (teveel?)

Laat maar iets weten, bij mij werkt het in elk geval (scripted implementation).

[Jazco2nd]

Ik vind PiHole 5.0 toch best tegenvallen. Dat Group Management is leuk om mee te spelen achter je servertje, maar is toch geen antwoord op de simpele vraag: terwijl je op je telefoon zit even ad-blocking uitzetten. En dan weer aanzetten. Zonder dat dat effect heeft op je hele netwerk.

Nu moet ik dus eerst een groep per device aanmaken, elk device zijn eigen groep geven.
Vervolgens, als ik even ads wil toelaten moet ik naar pi.hole, group management, de groep zoeken en voor die even adblocking uitzetten.

Dat is hopeloos omslachtig!

[ed1703]

Jazco2nd schreef op zondag 17 mei 2020 @ 17:40:
Ik vind PiHole 5.0 toch best tegenvallen. Dat Group Management is leuk om mee te spelen achter je servertje, maar is toch geen antwoord op de simpele vraag: terwijl je op je telefoon zit even ad-blocking uitzetten. En dan weer aanzetten. Zonder dat dat effect heeft op je hele netwerk.

Nu moet ik dus eerst een groep per device aanmaken, elk device zijn eigen groep geven.
Vervolgens, als ik even ads wil toelaten moet ik naar pi.hole, group management, de groep zoeken en voor die even adblocking uitzetten.

Dat is hopeloos omslachtig!

Als ik dit zo lees is eventjes snel omswitchten naar dns.google of 1.1.1.1 toch wat sneller
Ik weet ook niet zo goed wat je verwacht zodat het minder omslachtig gaat worden zonder user-interactie?

[Jazco2nd]

ed1703 schreef op zondag 17 mei 2020 @ 17:46:
[...]

Als ik dit zo lees is eventjes snel omswitchten naar dns.google of 1.1.1.1 toch wat sneller
Ik weet ook niet zo goed wat je verwacht zodat het minder omslachtig gaat worden zonder user-interactie?

Een aan/uit knop in de interface (en de API) die werkt voor het IP vanaf waar het request komt (via API) of vanwaar de webUI wordt benadert.

Op Android krijg je dan de mogelijkheid voor app developers om de Android Tile specifiek voor het device te maken en kan je met 1 klik schakelen.. alsof je een lokale adblocker hebt draaien.

[pinojo123]

Jazco2nd schreef op zondag 17 mei 2020 @ 17:40:
Ik vind PiHole 5.0 toch best tegenvallen. Dat Group Management is leuk om mee te spelen achter je servertje, maar is toch geen antwoord op de simpele vraag: terwijl je op je telefoon zit even ad-blocking uitzetten. En dan weer aanzetten. Zonder dat dat effect heeft op je hele netwerk.

Nu moet ik dus eerst een groep per device aanmaken, elk device zijn eigen groep geven.
Vervolgens, als ik even ads wil toelaten moet ik naar pi.hole, group management, de groep zoeken en voor die even adblocking uitzetten.

Dat is hopeloos omslachtig!

Even de Wifi uit is ook een oplossing.

[The Eagle]

Dat was ook mijn eerste gedachte ja
Hier in NL doen we niet moeilijk over een paar 100 MB meer of minder via 4G. Bedenk je echter wel dat men in BE nog een stukje achter ligt wat dat aan gaat.

[Pinobigbird]

Als je met je Raspberry Pi via Wireguard vpn verbindt dan heb je een toggle in je Quick Panel (Samsung Galaxy S10 hier). Stel dan ook wel de rpi als dsn-adres in:

[Bongoarnhem]

Jazco2nd schreef op zondag 17 mei 2020 @ 17:40:
Ik vind PiHole 5.0 toch best tegenvallen. Dat Group Management is leuk om mee te spelen achter je servertje, maar is toch geen antwoord op de simpele vraag: terwijl je op je telefoon zit even ad-blocking uitzetten. En dan weer aanzetten. Zonder dat dat effect heeft op je hele netwerk.

Nu moet ik dus eerst een groep per device aanmaken, elk device zijn eigen groep geven.
Vervolgens, als ik even ads wil toelaten moet ik naar pi.hole, group management, de groep zoeken en voor die even adblocking uitzetten.

Dat is hopeloos omslachtig!

Ik heb de pihole admin console in mn favorieten staan. Ik surf erheen, log in en disable dns blocking voor 5 minuten.

Is denk ik in jou geval het minst omslachtige. Staat los van Pihole v5 imho.

[Jazco2nd]

@Bongoarnhem Dat doe ik nu, dan disable je adblocking voor je hele netwerk. Dat vind ik dus zonde. Hoop dat ze met V6 met een betere oplossing komen.

@pinojo123 @The Eagle
Ik wil nog instellen dat mijn DNS verkeer altijd via mijn Pi-Hole gaat. Via Wireguard VPN wanneer ik niet op mijn thuisnetwerk zit. Zoals @Pinobigbird maar ik heb nog geen PiVPN geïnstalleerd.

Nadeel van het togglen van WireGuard (of Wifi) is dat mijn DNS requests dan ook niet meer via Unbound (recursive DNS) gaan.

[alesandro_46]

How about this?

Grim in "[Pi-Hole] Ervaringen & discussie"

[pinojo123]

alesandro_46 schreef op zondag 17 mei 2020 @ 20:26:
How about this?

Grim in "[Pi-Hole] Ervaringen & discussie"

Klopt maar @Jazco2nd heeft gelijk, dan staat je hele netwerk voor 5 min zonder pihole, voor mij is dit ook niet zo'n groot probleem. Maar dat geldt niet voor iedereen.

sugarcube schreef op zondag 27 oktober 2019 @ 20:40:
[...]

Kijk, dat is nou es een goeie tip ! ik wist niet dat dat kon, weer wat bijgeleerd
Nog zulke tips ?

Er is ook nog het pihole minimenu voor Android
https://play.google.com/s...m.acuf5928.minimenu&hl=nl

[ Voor 32% gewijzigd door pinojo123 op 17-05-2020 20:48 ]

[Wachten...]

jpgview schreef op zondag 17 mei 2020 @ 17:21:
[...]


Omdat ik vermoed dat er wel meer mensen geintereseerd zijn in deze oplossing, heb ik een document (handleiding) gemaakt, specifief voor dit scenario. je vind het hier.

Er zit een script bij (GitHub link) dat het meeste werk voor jou doet. Je hoeft daarna alleen nog maar een client aan te maken en aan de groep toe te voegen (ook beschreven in het document)

Ik heb het getest, het werkt (hardware is raspberry pi 3B, OS Raspbian, laatste versie)

Opgelet, je bent beta tester (maar bij mij liep alles goed). issues op GitHub a.u.b.

- users.telenet.be in sommige block lists -> lezen = whitelisten.
- zorg ervoor dat je eerst alle oude troep verwijderd, ook whitelist entries die je in het verleden voor je wag hebt aangemaakt (zijn van toepassing op alle devices).
- lees de comments in het script, voor je het uitvoert!

downloaden:

code:

sudo wget https://raw.githubusercontent.com/jpgpi250/piholemanual/master/googleads.sh -O /home/pi/googleads.sh
chmod +x /home/pi/googleads.sh

execute:

code:

sudo /home/pi/googleads.sh

Graag hoor ik commentaar op de whitelist entries, daar ben ik niet 100% van overtuigd (teveel?)

Laat maar iets weten, bij mij werkt het in elk geval (scripted implementation).

Bedankt voor de tijd en moeite die je erin hebt gestoken.
Ik ben eerst even door de manual handleiding heen gegaan, en kwam geen enkele misstap tegen. Ik had alles gedaan zoals jij gedaan hebt, maar toch nog maar extra aandacht geschonken aan het flushen van de DNS en de browser volledig afgesloten. Vervolgens icognito venster geopend (voor de zekerheid) en alles werkt naar behoren.
Er ging voorheen dus blijkbaar iedere keer iets niet goed met het flushen van de DNS
Kan ik met een gerust hart verder.....

Mijn volgende stap is om de lijsten even bij te werken. Ik had namelijk ooit een lijst hier van Tweakers afgehaald maar veel stond op host-file.net, echter zijn deze allemaal offline gehaald.

Weet jij toevallig een goede blocklijst ook om trackers e.d. te blokkeren? Ik kom veelal de lijst tegen van Wally3k https://firebog.net/
Mocht ik deze willen gebruiken, moet ik dan al die links die daarin staan één voor één in de Adlist onder Group management toevoegen, of is daar nu ook al een makkelijkere manier voor (is alweer even geleden).

[jpgview]

ivootjuh schreef op zondag 17 mei 2020 @ 22:18:

Weet jij toevallig een goede blocklijst ook om trackers e.d. te blokkeren? Ik kom veelal de lijst tegen van Wally3k https://firebog.net/
Mocht ik deze willen gebruiken, moet ik dan al die links die daarin staan één voor één in de Adlist onder Group management toevoegen, of is daar nu ook al een makkelijkere manier voor (is alweer even geleden).

En opnieuw verwijs ik naar mijn manual, sectie 16

An interesting set of lists, can be found here. This page will let you choose from 3 sets of lists, I’ve been using the non-crossed lists. This page will display a set of URLs that can be added. Using sqlite3, it is possible to add these list with a script. You can add these lists by running /home/pi/firebog.sh:

voor de links en het script verwijs ik naar de manual... (remember users.telenet.be misschien geblocked. lezen = whitelisten)

[Wachten...]

jpgview schreef op zondag 17 mei 2020 @ 22:31:
[...]


En opnieuw verwijs ik naar mijn manual, sectie 16

[...]

voor de links en het script verwijs ik naar de manual... (remember users.telenet.be misschien geblocked. lezen = whitelisten)

Nogmaals dank Ik zag dat je daar inderdaad ook verwees naar die lijst. Ik heb de complete wally3k lijst toevegoed (meer dan 2,5 miljoen domeinen) met uitzondering op de X lijsten en ga eens kijken of ik tegen problemen aan ga lopen met gamen streamen en internetten!

Ik ga eens een keer helemaal door de manual heen lopen. Je hebt hem niet toevallig in het Nederlands of wel? Het is voor mij namelijk een beetje dubbelop Engels, plus niet dagelijks met dit soort dingen bezig zijn. Ik waardeer het wel enorm dat mensen zoals jij veel moeite en tijd in steken

[pinojo123]

ivootjuh schreef op zondag 17 mei 2020 @ 22:18:
[...]

Weet jij toevallig een goede blocklijst ook om trackers e.d. te blokkeren? Ik kom veelal de lijst tegen van Wally3k https://firebog.net/
Mocht ik deze willen gebruiken, moet ik dan al die links die daarin staan één voor één in de Adlist onder Group management toevoegen, of is daar nu ook al een makkelijkere manier voor (is alweer even geleden).

Deze moet je hebben, wordt door een tweaker hier onderhouden.
https://dbl.oisd.nl/ ~1 miljoen

Interessant hoe zijn lijst tot stand is gekomen ->
https://www.reddit.com/r/...rnets_1_domain_blocklist/

[ Voor 49% gewijzigd door pinojo123 op 18-05-2020 05:35 ]

[nero355]

Jazco2nd schreef op zondag 17 mei 2020 @ 17:54:
Een aan/uit knop in de interface (en de API) die werkt voor het IP vanaf waar het request komt (via API) of vanwaar de webUI wordt benadert.

Volgens mij zijn de Tools nu wel aanwezig voor zoiets :
- Er is een API optie.
- Je kan per Client instellingen wijzigen qua Blocklists/Whitelist/Blacklist.

Dus als je gezegend bent met programmeertalent dan zou je zelf wat in elkaar kunnen knutselen

Op Android krijg je dan de mogelijkheid voor app developers om de Android Tile specifiek voor het device te maken en kan je met 1 klik schakelen.. alsof je een lokale adblocker hebt draaien.

Ander idee : Maak een aparte SSID aan voor je WiFi devices om tijdelijk zonder ads te surfen

En als het ook bekabeld moet dan kan je een extra VLAN ervoor gebruiken!

Daarnaast was er in ieder geval voor Windows één programma in ieder geval waarmee je snel tussen de DNS Forwarding van Pi-Hole en die van je Router kan switchen dus kijk daar ook eens naar voor Android en zo

[Jazco2nd]

nero355 schreef op maandag 18 mei 2020 @ 14:46:
[...]

Volgens mij zijn de Tools nu wel aanwezig voor zoiets :
- Er is een API optie.
- Je kan per Client instellingen wijzigen qua Blocklists/Whitelist/Blacklist.

Dus als je gezegend bent met programmeertalent dan zou je zelf wat in elkaar kunnen knutselen


[...]

Ander idee : Maak een aparte SSID aan voor je WiFi devices om tijdelijk zonder ads te surfen

En als het ook bekabeld moet dan kan je een extra VLAN ervoor gebruiken!

Daarnaast was er in ieder geval voor Windows één programma in ieder geval waarmee je snel tussen de DNS Forwarding van Pi-Hole en die van je Router kan switchen dus kijk daar ook eens naar voor Android en zo

Programmeren kan ik niet, ben geen ontwikkelaar. Beetje scripten kan ik wel.
Ik zou dan eerder naar Unbound DNS schakelen, wil altijd recursive DNS gebruiken. Ik zoek nog wel uit wat de mogelijkheden zijn.

[max2k9]

Als het puur om gebruiksgemak gaat; je kan ook api calls uitvoeren via een URL. Ik heb deze URL in de favourites bar van Safari om mijn Pi met 1 klik 60 seconden netwerkbreed uit te schakelen:

code:

http://pi.hole/admin/api.php?disable=60&auth=[PASSWORD]

[jpgview]

Jazco2nd schreef op maandag 18 mei 2020 @ 15:54:
Ik zou dan eerder naar Unbound DNS schakelen, wil altijd recursive DNS gebruiken. Ik zoek nog wel uit wat de mogelijkheden zijn.

https://discourse.pi-hole...-for-pihole-disable/20246

[Jazco2nd]

jpgview schreef op maandag 18 mei 2020 @ 16:40:
[...]


https://discourse.pi-hole...-for-pihole-disable/20246

Vaag, als je Unbound reeds gebruikt icm Pihole heb je zijn hele verhaal niet nodig. Volgens mij zegt hij dat ook in het begin. Ik kan me niet voorstellen waarom je deze oplossing zou volgen..

Als je Pihole disabled, disable je alleen adblocking. DNS queries worden nog steeds resolved door PiHole via Unbound.
Voordeel daarvan is dat je nog steeds DNS caching van Pihole gebruikt. Unbound heeft die functie niet.

[jpgview]

Jazco2nd schreef op maandag 18 mei 2020 @ 16:46:
[...]


Vaag, als je Unbound reeds gebruikt icm Pihole heb je zijn hele verhaal niet nodig. Volgens mij zegt hij dat ook in het begin. Ik kan me niet voorstellen waarom je deze oplossing zou volgen..

Als je Pihole disabled, disable je alleen adblocking. DNS queries worden nog steeds resolved door PiHole via Unbound.

ligatus .com zit in een of andere block list
- eerste nslookup -> default DNS (pihole), result 0.0.0.0
- tweede nslookup -> secondary IP (redirected to unbound), result 104.115.80.64



de oplossing werkt, ik gebruik ze al sinds ik het topic heb gemaakt op discourse

Jazco2nd schreef op maandag 18 mei 2020 @ 16:46:
Voordeel daarvan is dat je nog steeds DNS caching van Pihole gebruikt. Unbound heeft die functie niet.

unbound heeft wel degelijk caching (veel info over de cache in how to optimize), meer nog, ik zet de cache van dnsmasq (=pihole-FTL) op nul (cache-size=0), draai dit al maanden op die manier, geen delays...

Je moet meer lezen dan de eerste zin, daarin zeg ik allen waar het idee vandaan komt, al de rest gaat over de methode, gebruikt om pihole te bypassen en de queries om te leiden naar unbound

[ Voor 3% gewijzigd door jpgview op 18-05-2020 17:23 ]

[Videopac]

Kan iemand me uitleggen wat unbound is en hoe dat werkt en waarom je dan geen DNS server meer hoeft in te vullen. Er wordt hier aangenomen dat dat algemene kennis is, maar dat is het voor mij (nog) niet.

[jpgview]

Videopac schreef op maandag 18 mei 2020 @ 21:28:
Kan iemand me uitleggen wat unbound is en hoe dat werkt en waarom je dan geen DNS server meer hoeft in te vullen. Er wordt hier aangenomen dat dat algemene kennis is, maar dat is het voor mij (nog) niet.

lees eerst deze handleiding van de pihole developers. het is de eenvoudigste manier om met unbound aan de slag te gaan.

[Freee!!]

jpgview schreef op maandag 18 mei 2020 @ 22:01:
[...]
lees eerst deze handleiding van de pihole developers. het is de eenvoudigste manier om met unbound aan de slag te gaan.

Persoonlijk vind ik Unbound in een Docker container nog iets eenvoudiger, maar ik heb Pi-Hole ook in een Docker container draaien (voordeel: geen poortconflicten als je ze met Macvlan draait).

[nero355]

Videopac schreef op maandag 18 mei 2020 @ 21:28:
Kan iemand me uitleggen wat unbound is en hoe dat werkt en waarom je dan geen DNS server meer hoeft in te vullen. Er wordt hier aangenomen dat dat algemene kennis is, maar dat is het voor mij (nog) niet.

Effe een uitleg zonder een veel te drukke handleiding te moeten lezen :

Unbound/PowerDNS/BIND zijn DNS Server pakketten die bijvoorbeeld je ISP gebruikt om jou van DNS Resolving te voorzien.
Deze communiceert dan weer met de zogenaamde Root DNS Servers waar alle ISP's wereldwijd gebruik van maken.

Als jij zelf Unbound gaat draaien via de HowTo van het Pi-Hole Team dan ben jij dus in feite jouw eigen DNS ISP die direct communiceert met de Root DNS Servers

That's it!

[Mundatin]

Heeft iemand een oplossing voor het blokkeren van Facebook ads? Misschien een goede blocklist of een vergelijkbaar script als voor YouTube?

[Bongoarnhem]

Jannick schreef op dinsdag 19 mei 2020 @ 21:03:
Heeft iemand een oplossing voor het blokkeren van Facebook ads? Misschien een goede blocklist of een vergelijkbaar script als voor YouTube?

Heb je zelf wel gezocht?

[ Voor 15% gewijzigd door Equator op 20-05-2020 09:34 . Reden: Lmgtfy link verwijderd ]

[rvk]

jpgview schreef op donderdag 14 mei 2020 @ 13:27:
[...]
Het originele script voegt uitsluitend entries met de structuur rx.sn- toe. Ik heb geexperimenteerd met het toevoegen van entries met de structuur rx---sn-. Het duurde minder dan een uur om een load video error te krijgen.
dus:
- toevoegen (example): r1.sn-25ge7n76.googlevideo.com
- NIET toevoegen (example): r1---sn-25ge7n76.googlevideo.com

Ik ben het hele script werkend maar zit toch met een probleem.
Als ik een rx.sn-xxx toevoeg aan de hosts.youtube en daarna de rx---sn-xxx opvraag krijg ik toch een dns request. Als ik direct daarna nog een keer dezelfde rx--sn-xxx opvraag krijg ik de juiste ip.

Dus de eerste keer haalt ie hem niet uit dnsmasq terwijl die wel allang in hosts.youtube staat. (Opgegeven ip 172.217.132.104)

code:

pi@sonarr:~ $ sudo pihole restartdns
  [✓] Restarting DNS server
pi@sonarr:~ $
pi@sonarr:~ $ cat /etc/hosts.youtube |grep r5---sn-5hne6nlr.googlevideo.com
pi@sonarr:~ $ cat /etc/hosts.youtube |grep r5.sn-5hne6nlr.googlevideo.com
172.217.132.104 r5.sn-5hne6nlr.googlevideo.com
pi@sonarr:~ $
pi@sonarr:~ $ ping -qc1 r5.sn-5hne6nlr.googlevideo.com |grep bytes
PING r5.sn-5hne6nlr.googlevideo.com (172.217.132.104) 56(84) bytes of data.
pi@sonarr:~ $ ping -qc1 r5---sn-5hne6nlr.googlevideo.com |grep bytes
PING r5.sn-5hne6nlr.googlevideo.com (74.125.8.187) 56(84) bytes of data.
pi@sonarr:~ $ ping -qc1 r5---sn-5hne6nlr.googlevideo.com |grep bytes
PING r5.sn-5hne6nlr.googlevideo.com (172.217.132.104) 56(84) bytes of data.
pi@sonarr:~ $
pi@sonarr:~ $ tail -n200 /var/log/pihole.log |grep 5hne6nlr
May 19 23:17:22 dnsmasq[14263]: query[A] r5.sn-5hne6nlr.googlevideo.com from 192.168.2.251
May 19 23:17:22 dnsmasq[14263]: /etc/hosts.youtube r5.sn-5hne6nlr.googlevideo.com is 172.217.132.104
May 19 23:17:22 dnsmasq[14263]: query[AAAA] r5.sn-5hne6nlr.googlevideo.com from 192.168.2.251
May 19 23:17:22 dnsmasq[14263]: forwarded r5.sn-5hne6nlr.googlevideo.com to 192.168.2.1
May 19 23:17:22 dnsmasq[14263]: forwarded r5.sn-5hne6nlr.googlevideo.com to 192.168.2.1
May 19 23:17:22 dnsmasq[14263]: reply r5.sn-5hne6nlr.googlevideo.com is 2a00:1450:400e:23::b
May 19 23:17:27 dnsmasq[14263]: query[A] r5---sn-5hne6nlr.googlevideo.com from 192.168.2.251
May 19 23:17:27 dnsmasq[14263]: forwarded r5---sn-5hne6nlr.googlevideo.com to 192.168.2.1
May 19 23:17:27 dnsmasq[14263]: query[AAAA] r5---sn-5hne6nlr.googlevideo.com from 192.168.2.251
May 19 23:17:27 dnsmasq[14263]: forwarded r5---sn-5hne6nlr.googlevideo.com to 192.168.2.1
May 19 23:17:27 dnsmasq[14263]: reply r5---sn-5hne6nlr.googlevideo.com is <CNAME>
May 19 23:17:27 dnsmasq[14263]: reply r5.sn-5hne6nlr.googlevideo.com is 74.125.8.187
May 19 23:17:27 dnsmasq[14263]: reply r5---sn-5hne6nlr.googlevideo.com is <CNAME>
May 19 23:17:27 dnsmasq[14263]: reply r5.sn-5hne6nlr.googlevideo.com is 2a00:1450:400e:23::b
May 19 23:17:33 dnsmasq[14263]: query[A] r5---sn-5hne6nlr.googlevideo.com from 192.168.2.251
May 19 23:17:33 dnsmasq[14263]: cached r5---sn-5hne6nlr.googlevideo.com is <CNAME>
May 19 23:17:33 dnsmasq[14263]: /etc/hosts.youtube r5.sn-5hne6nlr.googlevideo.com is 172.217.132.104
May 19 23:17:33 dnsmasq[14263]: query[AAAA] r5---sn-5hne6nlr.googlevideo.com from 192.168.2.251
May 19 23:17:33 dnsmasq[14263]: cached r5---sn-5hne6nlr.googlevideo.com is <CNAME>
May 19 23:17:33 dnsmasq[14263]: cached r5.sn-5hne6nlr.googlevideo.com is 2a00:1450:400e:23::b
pi@sonarr:~ $

Regel 10 en 12 zouden hetzelfde resultaat moeten geven.

[jpgview]

rvk schreef op dinsdag 19 mei 2020 @ 23:22:
Ik ben het hele script werkend maar zit toch met een probleem.

Zoals al eerder aangegeven, ik heb nog steeds geen idee hoe het komt dat het youtube script werkt.

Een verklaring voor jouw probleem zou kunnen zijn (zie hieronder waarom ik dit denk).
- je doet een restartdns, de dnsmasq (=pihole-FTL) cache is nu dus leeg.
- je doet een ping, omdat de cache leeg is, forward dnsmasq de query (r5---sn-5hne6nlr.googlevideo.com zit NIET in de cache).
- het antwoord op de CNAME request (r5---sn-5hne6nlr.googlevideo.com is een CNAME) is het A record (r5.sn-5hne6nlr.googlevideo.com) EN het correcte IP address, deze worden nu beide in de dnsmasq cache opgenomen., het antwoord op de query wordt ook naar de client verstuurd.
- je doet opnieuw een query naar de CNAME (r5---sn-5hne6nlr.googlevideo.com). deze keer zit het resultaat in de cache, ook het A record zit in de cache, deze keer komt het resultaat voor het A record uit /etc/hosts.youtube
Dus, eerste keer (geen cache) antwoord van de forwarded query integraal naar client.
Tweede keer, CNAME uit de cache en A record uit /etc/hosts.youtube naar de client.

Waarom ik denk dat dit de verklaring is:
Als je een dig r5---sn-5hne6nlr.googlevideo.com uitvoerd, komt alle info (het is een CNAME, het A record is r5.sn-5hne6nlr.googlevideo.com en het IP) terug als één antwoord (één request, één reply met alle noodzakelijke info). Ik ga er vanuit dat dnsmasq het antwoord niet gaat evalueren (kijken of het A record toch eventueel in een config voorkomt), omdat een en ander simpelweg voor te veel vertraging zou zorgen (je zou dit voor elke query moeten doen). Met andere woorden, het lijkt erop dat dnsmasq de query resultaten kan beinvloeden (geeft een antwoord uit de config) vóór het een query forward, dnsmasq lijkt nooit een reply te wijzigen (antwoord op een query die geforward is). Omdat er dus queries voor de CNAMEs worden uitgevoerd (telkens wanneer een video laad), en die in de config (/etc/hosts.youtube) niet voorkomen, krijg je de eerste keer altijd het echte IP als antwoord.

Let wel, deze analyse doe ik op basis van jouw log entries, om een of andere, mij voorlopig nog onduidelijke reden, zie ik NOOIT entries zoals /etc/hosts.youtube r5.sn-5hne6nlr.googlevideo.com is 172.217.132.104. Er worden bij mij nooit entries uit /etc/hosts.youtube als antwoord aan de client gegeven (dat is ook een van de redenen dat ik geen verklaring vind, waarom het script werkt).

Nogmaals, vermoedens… Het is, bij mijn weten, niet mogelijk de cache van dnsmasq te bekijken, je weet dus nooit wat daar juist in zit. De code van dnsmasq uitpluizen om een sluitend antwoord te vinden, is een optie.

Als je met dit antwoord niet tevreden bent, stel ik voor dat je de vraag stelt aan Simon ([e-mail]), de developer van dnsmasq.

[rvk]

jpgview schreef op woensdag 20 mei 2020 @ 10:44:
[...]
Als je een dig r5---sn-5hne6nlr.googlevideo.com uitvoerd, komt alle info (het is een CNAME, het A record is r5.sn-5hne6nlr.googlevideo.com en het IP) terug als één antwoord (één request, één reply met alle noodzakelijke info)

Ik denk inderdaad ook dat het zoiets is. Ik had op discourse ook al een vergelijkbaar issue gevonden (en deze log toegevoegd).

Het probleem wat ik nu dus heb is dat het script ook elke keer een "restartdns reload" doet. Dat betekent dus dat ELKE keer als er een nieuwe domein is, de cache geflusched wordt. En ik dus ook weer videos van alle andere domeinen kan krijgen (want een enkele hit is voldoende om de video te laten zien).

code:

pi@sonarr:~ $ sudo pihole restartdns reload
  [✓] Flushing DNS cache
pi@sonarr:~ $ ping -qc1 r5---sn-5hne6nlr.googlevideo.com |grep bytes
PING r5.sn-5hne6nlr.googlevideo.com (74.125.8.187) 56(84) bytes of data.
pi@sonarr:~ $ ping -qc1 r5---sn-5hne6nlr.googlevideo.com |grep bytes
PING r5.sn-5hne6nlr.googlevideo.com (172.217.132.104) 56(84) bytes of data.

Enige wat ik nog kan bedenken is na de "restartdns reload" eventjes de hele hosts.youtube parsen en van alle domeinen een ping opvragen. Want hoe meer domeinen in die host komen, hoe meer domeinen bij elke flush weer toegankelijk worden (ondanks dat ze in die host staan).

----
Edit: Nog even gekeken naar de andere oplossing bij issues. Het hele gebeuren van redirecten van rx.sn-xxx is sowieso flawed. Ja, het werkt misschien even voor een paar reclames. Maar hoe meer je af gaat blokken, hoe eerder je problemen krijgt. De gedachte dat op de focedIP je video wel (maar reclame niet) gehost wordt is namelijk niet juist. Ik heb nu met address=/.*.googlevideo.com/172.217.132.104 e.d. ALLE rx.sn-xxx geredirect. En dan krijg je een 400 error op de desbetreffende request. Bij een enkele komt de video wel door (met een 200).

[ Voor 16% gewijzigd door rvk op 20-05-2020 11:19 ]

[Verwijderd]

jpgview schreef op dinsdag 5 mei 2020 @ 22:05:
Er is een interessante wending aangaande youtube ads. Je kan er alles over lezen in dit discourse topic.
Je kan het script hier downloaden.

Het zou uitermate nuttig zijn om dit te testen met zoveel mogelijk gebruikers, gelieve eventuele problemen te melden op discourse, niet hier (de auteur is, bij mijn weten, niet actief op dit forum).

Er word nog hard gewerkt aan verbeteringen, het is dus aan te raden de GitLab pagina in de gaten te houden voor eventuele updates.

Hoe werkt het? (je kan dit ook lezen in de comment - begin van het script).
- download het script

code:

sudo wget https://gitlab.com/grublets/youtube-updater-for-pi-hole/-/raw/master/youtube.update.sh -O /home/pi/youtube.update.sh

- maak het script executable (sudo chmod +x /home/pi/youtube.update.sh)
- je moet het script aanpassen, vervang 123.456.789.999 (dummy) door een IP address uit je pihole log, dat address is een googlevideo address in jouw regio (something like r6---sn-ni5f-tfbl.googlevideo.com - lees ook de comment in het script)
- run het script één maal met sudo (sudo /home/pi/youtube.update.sh)
- controleer of het bestand /etc/dnsmasq.d/99-youtube.grublets.conf bestaat.
- controleer of het bestand /etc/hosts.youtube bestaat.
- herstart pihole-FTL (sudo service pihole-FTL restart)
- maak een cron job aan, maak een bestand /etc/cron.d/youtubeupdate, inhoud:

code:

* * * * * root  PATH="$PATH:/home/pi/" /home/pi/youtube.update.sh 2>&1

vanaf nu zal de cron job elke minuut draaien, en eventuele nieuwe domain names toevoegen aan /etc/hosts.youtube, er word, door pihole-FTL dan altijd verwezen naar het IP address dat jezelf hebt gekozen uit je pihole log, wat het aantal ads drastisch zal (zou - het blijft een test, maar de eerste resultaten zijn gunstig) doen dalen.

Er zijn voorlopig nog geen entries voor IPv6 (word aan gewerkt)
Het script maakt intensief gebruik van je SD kaart (voor pi gebruikers). Er is een voorstel gedaan om dit te wijzigen naar TMPFS (memory).

Heeft iemand dit al werkend i.c.m. Pihole die in Docker draait?
Zo ja, hoe?

[jpgview]

rvk schreef op woensdag 20 mei 2020 @ 11:04:
Enige wat ik nog kan bedenken is na de "restartdns reload" eventjes de hele hosts.youtube parsen en van alle domeinen een ping opvragen. Want hoe meer domeinen in die host komen, hoe meer domeinen bij elke flush weer toegankelijk worden (ondanks dat ze in die host staan).

Om mijn theorie van hierboven te staven heb ik even het volgende gedaan (let op dit is géén oplossing om youtube ads te onderdrukken, video's zullen niet meer laden)

aan /etc/dnsmasq.d/99-youtube.grublets.conf volgende toegevoegd (tweede lijn):

addn-hosts=/etc/hosts.youtube
cname=r5---sn-5hne6nlr.googlevideo.com,r5.sn-5hne6nlr.googlevideo.com

na restart (dnsmasq) een dnslookup r5---sn-5hne6nlr.googlevideo.com
je krijgt nu onmiddelijk het correcte (geconfigureerde IP address), omdat dnsmasq geen forward hoeft te doen (alle info bekend in config files).

May 20 11:14:10 dnsmasq[31918]: query[A] r5---sn-5hne6nlr.googlevideo.com from 192.168.2.228
May 20 11:14:10 dnsmasq[31918]: config r5---sn-5hne6nlr.googlevideo.com is <CNAME>
May 20 11:14:10 dnsmasq[31918]: /etc/hosts.youtube r5.sn-5hne6nlr.googlevideo.com is 208.117.238.16
May 20 11:14:10 dnsmasq[31918]: query[AAAA] r5---sn-5hne6nlr.googlevideo.com from 192.168.2.228
May 20 11:14:10 dnsmasq[31918]: config r5---sn-5hne6nlr.googlevideo.com is <CNAME>
May 20 11:14:10 dnsmasq[31918]: /etc/hosts.youtube r5.sn-5hne6nlr.googlevideo.com is 2620:11a:a036::10

[rvk]

jpgview schreef op woensdag 20 mei 2020 @ 11:41:
[...]
na restart (dnsmasq) een dnslookup r5---sn-5hne6nlr.googlevideo.com
je krijgt nu onmiddelijk het correcte (geconfigureerde IP address), omdat dnsmasq geen forward hoeft te doen (alle info bekend in config files).

Inderdaad. Nu die CNAMEs dus vanuit een list. Ik kan de CNAME ook opnemen in de host file maar dan moet ik schijnbaar CNAME_DEEP_INSPECT op false zetten (en dan zit er een behoorlijke delay in).

Maar mijn test met address=/.*.googlevideo.com/172.217.132.104 (redirect van alle rx---sn-xxx) resulteert echter in heel veel (meeste) gevallen in een error 400 in youtube. Ik zie dat alle rx---sn-xxx wel netjes naar mijn forcedip gaan, dus dat werkt dan hetzelfde als het script, alleen dat het al honderden jaren draait (met alle domeinen). Dus dat laat al zien dat dit script uiteindelijk zal zorgen voor steeds meer video's die niet geladen worden.

[Mundatin]

Bongoarnhem schreef op dinsdag 19 mei 2020 @ 22:47:
[...]


Heb je zelf wel gezocht?

Ja... Alleen heb ik geen betrouwbare up-to-date block lists kunnen vinden of een vergelijkbare tool.

[Bongoarnhem]

Jannick schreef op woensdag 20 mei 2020 @ 22:29:
[...]


Ja... Alleen heb ik geen betrouwbare up-to-date block lists kunnen vinden of een vergelijkbare tool.

Facebook trackers:
https://raw.githubusercon...ter/facebook-trackers.txt

Facebook compleet blocken:
https://github.com/jmduga...corporations/facebook/all

[GieltjE]

Verwijderd schreef op woensdag 20 mei 2020 @ 11:13:
[...]


Heeft iemand dit al werkend i.c.m. Pihole die in Docker draait?
Zo ja, hoe?

Lijkt me een questie van de file locations aanpassen en het herstart commando aanpassen?

[Gunner]

Bongoarnhem schreef op vrijdag 22 mei 2020 @ 08:01:
[...]


Facebook trackers:
https://raw.githubusercon...ter/facebook-trackers.txt

Facebook compleet blocken:
https://github.com/jmduga...corporations/facebook/all

Bij de bovenste lijst blokkeert hij Facebook ook volledig

[dss58]

Gunner schreef op vrijdag 22 mei 2020 @ 09:26:
[...]

Bij de bovenste lijst blokkeert hij Facebook ook volledig

Net ook de lijst in de pihole gezet, bij mij niet, alleen deze:
scontent.fams1-2.fna.fbcdn.net
ge-whitelist omdatik een hoop plaatjes niet kon zien.

[Webgnome]

Weet iemand welke domains je moet whitelisten om windows defender smart screen weer te enablen? en ook andere windows defender cloud dingetjes? Ik zou die graag toch wel blijven gebruiken echter al het andere windows 10 spul kan mij gestolen worden.

[GieltjE]

Webgnome schreef op vrijdag 22 mei 2020 @ 09:56:
Weet iemand welke domains je moet whitelisten om windows defender smart screen weer te enablen? en ook andere windows defender cloud dingetjes? Ik zou die graag toch wel blijven gebruiken echter al het andere windows 10 spul kan mij gestolen worden.

Ben laatst met de office installer bezig geweest, een keer de installer opnieuw starten, zorgen dat al het ander uitstaat en de query log in de gaten houden. Als je Microsoft domeinnamen ziet kun je ze even googlen, Microsoft heeft van de meeste domeinnamen wel gedocumenteerd wat ze doen (sommigen niet).

[hp-got]

Webgnome schreef op vrijdag 22 mei 2020 @ 09:56:
Weet iemand welke domains je moet whitelisten om windows defender smart screen weer te enablen? en ook andere windows defender cloud dingetjes? Ik zou die graag toch wel blijven gebruiken echter al het andere windows 10 spul kan mij gestolen worden.

De beste referentie die ik ken is deze lijst met Windows endpoints: klik

[MrCrashdummy]

Ik heb een probleem. Ik had PiHole runnen vop 192.168.1.8, maar na een reinstall van m'n Pi is het IP-adres nu 192.168.1.3 - op de een of andere manier blijft mijn Windows 10 desktop maar verbinding maken met de DNS-server op 192.168.8, en krijg ik dus timeouts. Dat terwijl ik in mijn router settings de DNS op het nieuwe IP van 192.168.1.3 heb gezet.

Wat te doen?

[dss58]

MrCrashdummy schreef op vrijdag 22 mei 2020 @ 21:18:
Ik heb een probleem. Ik had PiHole runnen vop 192.168.1.8, maar na een reinstall van m'n Pi is het IP-adres nu 192.168.1.3 - op de een of andere manier blijft mijn Windows 10 desktop maar verbinding maken met de DNS-server op 192.168.8, en krijg ik dus timeouts. Dat terwijl ik in mijn router settings de DNS op het nieuwe IP van 192.168.1.3 heb gezet.

Wat te doen?

wat is het DNS IPadres van windows10 ?

[nero355]

MrCrashdummy schreef op vrijdag 22 mei 2020 @ 21:18:
Ik heb een probleem. Ik had PiHole runnen vop 192.168.1.8, maar na een reinstall van m'n Pi is het IP-adres nu 192.168.1.3 - op de een of andere manier blijft mijn Windows 10 desktop maar verbinding maken met de DNS-server op 192.168.8, en krijg ik dus timeouts. Dat terwijl ik in mijn router settings de DNS op het nieuwe IP van 192.168.1.3 heb gezet.

Wat te doen?

ipconfig /release
ipconfig /renew

En anders een reboot

[MrCrashdummy]

nero355 schreef op zaterdag 23 mei 2020 @ 00:54:
[...]

ipconfig /release
ipconfig /renew

En anders een reboot

Yes, dat heeft het gefixt! Top!

[blavlaa]

MrCrashdummy schreef op vrijdag 22 mei 2020 @ 21:18:
Ik heb een probleem. Ik had PiHole runnen vop 192.168.1.8, maar na een reinstall van m'n Pi is het IP-adres nu 192.168.1.3 - op de een of andere manier blijft mijn Windows 10 desktop maar verbinding maken met de DNS-server op 192.168.8, en krijg ik dus timeouts. Dat terwijl ik in mijn router settings de DNS op het nieuwe IP van 192.168.1.3 heb gezet.

Wat te doen?

Best practice is om de PiHole een static address te geven in je router dan heb je hier geen last meer van.

[pinojo123]

Met versie pihole v4 had ik op de plaats waar een advertentie geblocked werd een lege ruimte of helemaal niets. Nu zie ik aldoor op de plaats van een advertentie een grote tekst met:
"Hmm. We kunnen die website niet vinden. We kunnen geen verbinding maken met de server op googleads.g.doubleclick.net."

Weet er iemand een elegante oplossing dat dit automatisch onzichtbaar wordt gemaakt?

[Church of Noise]

pinojo123 schreef op zaterdag 23 mei 2020 @ 10:57:
Met versie pihole v4 had ik op de plaats waar een advertentie geblocked werd een lege ruimte of helemaal niets. Nu zie ik aldoor op de plaats van een advertentie een grote tekst met:
"Hmm. We kunnen die website niet vinden. We kunnen geen verbinding maken met de server op googleads.g.doubleclick.net."

Weet er iemand een elegante oplossing dat dit automatisch onzichtbaar wordt gemaakt?

Ik gebruik hiervoor uBlock Origin (in m'n browsers zoals o.a. Firefox, Edge en Chrome).
Op het niveau van je Raspberry Pi kan dit niet...

[ Voor 8% gewijzigd door Church of Noise op 23-05-2020 11:52 ]

[pinojo123]

Church of Noise schreef op zaterdag 23 mei 2020 @ 11:50:
[...]

Ik gebruik hiervoor uBlock Origin (in m'n browsers zoals o.a. Firefox, Edge en Chrome).
Op het niveau van je Raspberry Pi kan dit niet...

Is er binnen Pihole niet een oplossing?

Heb zelf dit gevonden maar weet niet of het werkt met v5.

[ Voor 17% gewijzigd door pinojo123 op 23-05-2020 12:53 ]

[Tralapo]

Gunner schreef op vrijdag 22 mei 2020 @ 09:26:
[...]

Bij de bovenste lijst blokkeert hij Facebook ook volledig

Bij mij is het resultaat inderdaad hetzelfde, maakt heel Facebook onbereikbaar.

[nero355]

blavlaa schreef op zaterdag 23 mei 2020 @ 10:00:
Best practice is om de PiHole een static address te geven in je router dan heb je hier geen last meer van.

Lees goed wat er staat : Het liefst gewoon een Static IP via /etc/dhcpcd.conf of anders een Static DHCP Mapping op basis van MAC adres.

Wat je echter het beste kan doen is beiden instellen, zodat alles blijft werken mocht er wat omvallen

pinojo123 schreef op zaterdag 23 mei 2020 @ 10:57:
Met versie pihole v4 had ik op de plaats waar een advertentie geblocked werd een lege ruimte of helemaal niets. Nu zie ik aldoor op de plaats van een advertentie een grote tekst met:
"Hmm. We kunnen die website niet vinden. We kunnen geen verbinding maken met de server op googleads.g.doubleclick.net."

Weet er iemand een elegante oplossing dat dit automatisch onzichtbaar wordt gemaakt?

Zal je toch echt je browser moeten laten doen via de ingebouwde "remove page elements" optie of via een add-on/plug-in

pinojo123 schreef op zaterdag 23 mei 2020 @ 11:53:
Is er binnen Pihole niet een oplossing?

Heb zelf dit gevonden maar weet niet of het werkt met v5.

Werkt prima i.c.m. versie 5.0 maar dat wil je niet, omdat alles dan trager werkt : https://docs.pi-hole.net/ftldns/blockingmode/

[ Voor 20% gewijzigd door nero355 op 23-05-2020 14:48 ]

[ocaj]

Ik heb sinds een paar weken pihole draaien en ben heel tevreden.

Nu las ik hier nieuws: Chrome blokkeert third-party-cookies in incognito en rolt dns-over-ht... dat Google Chrome Dns-Over-HTTPS gaat uitrollen tenzij ze kunnen detecteren dat er lokaal DoH ondersteund wordt.

Mij is niet helemaal duidelijk hoe Chrome dat doet. Is het een kwestie van de pihole configureren zodat hij ook doh-request accepteert?

Ik laat nu al mijn DNS via XS4all lopen, aangezien ik die vertrouw.

Maar hoe krijg je nu de standaard lighttpd dan zo geconfigureerd dat hij als doh-proxy gaat functioneren en alle doh-verzoeken aan de pihole doorsluist naar de xs4all-doh-resolver?

Of zie ik iets helemaal over het hoofd en gaat dat zo niet werken?

(zelf gebruik ik geen chrome, maar ik wel uiteraard ook mijn chrome-gebruikende huisgenoten beschermen tegen advertentie-ellende)

[nero355]

@ocaj

Schakel gewoon het volgende uit via chrome://flags :
- QUIC Protocol
- A-Sync DNS Resolving
- En dus ook DNS over HTTPS

Dan ben je er ook!

[ocaj]

@nero355 Dat is ook een methode, maar dan moet ik op elk apparaat waar Chrome draait instellingen gaan veranderen. Ik vroeg me eigenlijk af of het mogelijk is om de pihole als DOH-server (proxy) in te stellen om Chrome de pihole-filters te laten gebruiken. Lijkt me makkelijker om het in 1 keer te regelen voor het hele netwerk en alle apparaten.

Hmmm, ik bedenk me net dat dit voor het gastennetwerk dan toch weer niet gaat werken, want mijn fritzbox geeft zijn eigen ip-adres als DNS-server voor het gastennetwerk, waarna de fritzbox alle dns doorstuurt naar de pihole.

Lastige materie....

[Videopac]

ocaj schreef op zaterdag 23 mei 2020 @ 16:34:
Ik heb sinds een paar weken pihole draaien en ben heel tevreden.

Nu las ik hier nieuws: Chrome blokkeert third-party-cookies in incognito en rolt dns-over-ht... dat Google Chrome Dns-Over-HTTPS gaat uitrollen tenzij ze kunnen detecteren dat er lokaal DoH ondersteund wordt.

Mij is niet helemaal duidelijk hoe Chrome dat doet. Is het een kwestie van de pihole configureren zodat hij ook doh-request accepteert?

Ik laat nu al mijn DNS via XS4all lopen, aangezien ik die vertrouw.

Maar hoe krijg je nu de standaard lighttpd dan zo geconfigureerd dat hij als doh-proxy gaat functioneren en alle doh-verzoeken aan de pihole doorsluist naar de xs4all-doh-resolver?

Of zie ik iets helemaal over het hoofd en gaat dat zo niet werken?

(zelf gebruik ik geen chrome, maar ik wel uiteraard ook mijn chrome-gebruikende huisgenoten beschermen tegen advertentie-ellende)

Vraag je huisgenoten waarom ze de browser van dataverzamelaar #1 gebruiken.

[nero355]

ocaj schreef op zaterdag 23 mei 2020 @ 16:59:
@nero355 Dat is ook een methode, maar dan moet ik op elk apparaat waar Chrome draait instellingen gaan veranderen.

Dat moet je sowieso doen, want die instellingen zijn best wel ranzig en omzeilen je eigen DNS Server

Ik vroeg me eigenlijk af of het mogelijk is om de pihole als DOH-server (proxy) in te stellen om Chrome de pihole-filters te laten gebruiken. Lijkt me makkelijker om het in 1 keer te regelen voor het hele netwerk en alle apparaten.

Hmmm, ik bedenk me net dat dit voor het gastennetwerk dan toch weer niet gaat werken, want mijn fritzbox geeft zijn eigen ip-adres als DNS-server voor het gastennetwerk, waarna de fritzbox alle dns doorstuurt naar de pihole.

Lastige materie....

Router kopen met VLAN Support aan de LAN kant en daarmee de boel fatsoenlijk opzetten

[pinojo123]

nero355 schreef op zaterdag 23 mei 2020 @ 16:39:
@ocaj

Schakel gewoon het volgende uit via chrome://flags :
- QUIC Protocol
- A-Sync DNS Resolving
- En dus ook DNS over HTTPS

Dan ben je er ook!

Dank nero355, Die a-sync setting kan ik niet vinden, is dat Enable sending Sharing message via Sync?

[alesandro_46]

pinojo123 schreef op zondag 24 mei 2020 @ 08:39:
[...]


Dank nero355, Die a-sync setting kan ik niet vinden, is dat Enable sending Sharing message via Sync?

Zoeken op async of dns dan vind je deze:
Async DNS resolver
Enables the built-in DNS resolver. – Android

[Webgnome]

nero355 schreef op zaterdag 23 mei 2020 @ 16:39:
@ocaj

Schakel gewoon het volgende uit via chrome://flags :
- QUIC Protocol
- A-Sync DNS Resolving
- En dus ook DNS over HTTPS

Dan ben je er ook!

dit is hartstikke leuk natuurlijk maar op het moment dat Windows 10 DNS Over HTTPS gaat implementeren kom je hier niet heel ver mee. Volgens mij kun je dan beter iets als dit volgen

[pinojo123]

alesandro_46 schreef op zondag 24 mei 2020 @ 08:56:
[...]

Zoeken op async of dns dan vind je deze:
Async DNS resolver
Enables the built-in DNS resolver. – Android

Ah, in Windows10 zit die waarschijnlijk niet dan.
Op m'n android phone heb ik wel even deze settings toegepast in Chrome, alhoewel ik duckduckgo gebruik voor browsen.

Dank

[Church of Noise]

alesandro_46 schreef op zondag 24 mei 2020 @ 08:56:
[...]

Zoeken op async of dns dan vind je deze:
Async DNS resolver
Enables the built-in DNS resolver. – Android

Ik vind die setting ook niet (Chrome 83)

Nvm, is ook op Win10...

[ Voor 4% gewijzigd door Church of Noise op 24-05-2020 11:09 ]

[blavlaa]

Church of Noise schreef op zondag 24 mei 2020 @ 11:01:
[...]

Ik vind die setting ook niet (Chrome 83)

Nvm, is ook op Win10...

Denk dat hij gewijzigd is en dat je deze moet hebben.

chrome://flags/#dns-over-https

Zoek op dns, zo heb ik hem gevonden.

Ik heb Chrome Version 83.0.4103.61 (Official Build) (64-bit)

[ Voor 8% gewijzigd door blavlaa op 24-05-2020 11:19 ]

[ocaj]

Webgnome schreef op zondag 24 mei 2020 @ 08:58:
[...]


dit is hartstikke leuk natuurlijk maar op het moment dat Windows 10 DNS Over HTTPS gaat implementeren kom je hier niet heel ver mee. Volgens mij kun je dan beter iets als dit volgen

Dank je, dat ziet er wel uit alsof dat een oplossing is om DoH op de pihole te installeren
Maar hoe borg je dan dat die DoH-server gebruikt wordt? Ook zie ik daar dat ze cloudfared op poort 5053 draaien, hoe gaat dat dan? DoH draait normaal toch op 443?

Ik heb verder niet zoveel met Cloudfare, maar als ik het goed begrijp dan kan je -ondanks de naam - die cloudfared ook configureren zodat hij andere diensten gebruikt. Of sluist hij dan toch nog van alles door naar Cloudfare?

[asing]

ocaj schreef op zondag 24 mei 2020 @ 12:03:
[...]


Dank je, dat ziet er wel uit alsof dat een oplossing is om DoH op de pihole te installeren
Maar hoe borg je dan dat die DoH-server gebruikt wordt? Ook zie ik daar dat ze cloudfared op poort 5053 draaien, hoe gaat dat dan? DoH draait normaal toch op 443?

Ik heb verder niet zoveel met Cloudfare, maar als ik het goed begrijp dan kan je -ondanks de naam - die cloudfared ook configureren zodat hij andere diensten gebruikt. Of sluist hij dan toch nog van alles door naar Cloudfare?

Ze maken er een zooitje van, as usual .

DNS over HTTPS - DOH (443)
DNS over TLS - DoT (853)
CloudFlare - DoH (5053)

De eerste twee zijn standaard volgens de RFC, CloudFlare doet weer hun eigen ding.

Het grote gemak van poort 443 is dat het overal wel werkt. Binnen bedrijven, hotels etc. De andere poorten hoeven niet per se open te staan.

Ik heb deze gevolgd : https://docs.pi-hole.net/guides/dns-over-https/ . Ieder device in het netwerk wijst voor DNS naar Pihole. Pihole zelf wijst naar zichzelf op 5053 en daarop luistert een CloudFlare service om de DNS verzoeken naar CloudFlare zelf te sturen.

[ed1703]

ocaj schreef op zondag 24 mei 2020 @ 12:03:
[...]


Dank je, dat ziet er wel uit alsof dat een oplossing is om DoH op de pihole te installeren
Maar hoe borg je dan dat die DoH-server gebruikt wordt? Ook zie ik daar dat ze cloudfared op poort 5053 draaien, hoe gaat dat dan? DoH draait normaal toch op 443?

De cloudflared service draait als een proxy tussen je pihole en DoH. Pihole—->5053 —> DoH.
Pihole kan niet rechtstreeks DoH aanspreken dus moet er een service tussen. Het is ook pas DoH vanaf je pihole, dus niet op je clients.

asing schreef op zondag 24 mei 2020 @ 12:19:
[...]


Ze maken er een zooitje van, as usual .

DNS over HTTPS - DOH (443)
DNS over TLS - DoT (853)
CloudFlare - DoH (5053)

De eerste twee zijn standaard volgens de RFC, CloudFlare doet weer hun eigen ding.

Haal je nu geen zaken door elkaar? Die 5053 zit er tussen om juist DoH via pihole voor elkaar te krijgen. Cloudflare doet alleen DoH, 5053 gebruik je alleen intern op je PiHole.

[ Voor 34% gewijzigd door ed1703 op 24-05-2020 12:29 ]

[Webgnome]

Maar de vraag is nu. Als google doh doet bypassed die dan niet je pihole? Of 'wint' de dns dat je op je systeem hebt geconfigureerd?

[asing]

Webgnome schreef op zondag 24 mei 2020 @ 12:32:
Maar de vraag is nu. Als google doh doet bypassed die dan niet je pihole? Of 'wint' de dns dat je op je systeem hebt geconfigureerd?

Dat is makkelijk te controleren. Open Chrome, ga naar een website en check de logs van je pi hole om te zien of het verzoek daar is langs gekomen.

[asing]

ed1703 schreef op zondag 24 mei 2020 @ 12:22:
[...]
Haal je nu geen zaken door elkaar? Die 5053 zit er tussen om juist DoH via pihole voor elkaar te krijgen. Cloudflare doet alleen DoH, 5053 gebruik je alleen intern op je PiHole.

Je hebt gelijk . De CloudFlared daemon maakt gebruik van 5053. Ik had die poort ook naar buiten open staan. Die in de firewall verwijderd, daarna een dig commando op de pihole gedaan naar google.com en een aantal domeinen die ik de laatste weken niet bezocht heb. Ik kreeg steeds netjes antwoord.

CloudFlare zelf maakt dus wel gebruik van 443 (DoH).

[ocaj]

Hmmm, typisch gevalletje van hoe meer je snapt, hoe meer je snapt dat je het niet snapt

Wat ik eigenlijk wilde is:

OS/APP -> DoH -> DoH-service -> pihole -> upstream DNS

De meeste guides die ik nu zie doen:

OS/APP -> DNS -> pihole -> DoH-service -> upstream DoH

Er is dus nog niet echt een standaard manier waarop een OS of een App (chrome bijvoorbeeld) de DoH-server kunnen vaststellen? Ik had het idee dat ze default zoiets zouden proberen als https://<dns-server>/dns-query , maar dat vind ik niet terug.

Als een App of OS zelf besluit om een ingebakken DoH-dienst te gebruiken kun je dus niks beginnen? Alleen eventueel via de app of os instellen, mits die app dat ondersteunt.

Qua privacy is DoH misschien wel een goed ding (mits je je DoH-provider vertrouwt), maar qua systeem-architectuur is het totaal niet logisch. Enige dat logisch zou zijn, is als je op OS-niveau een DOH-lookup-service aanbiedt vergelijkbaar met de huidige DNS-lookup. En dat je op OS-niveau dan de DOH-server kunt instellen, maar dat is dus niet gangbaar?

[Zjemm]

valt me op dat als ik google safesearch forceer via DNS, mijn oneplus telefoon zegt geen internet meer te hebben bij we wifi instellingen.

ga ik dan het internet op dan werkt dat gewoon.

ook kan ik dan sommige games niet meer downloaden.

iemand hier ervaring mee?

op zich wil ik safesearch wel aan zetten, maar het gros moet wel gewoon blijven werken

[Kecin]

Ik heb pech hier na de update van PiHole 5.

Het dashboard werkt niet meer, en blokkade's zo af en toe. Ik kan het niet reproduceren op een manier waarop het logisch is. Als ik de Pi wil reconfigureren krijg ik het volgende:

code:

  [✓] Root user check

   

  [i] Existing PHP installation detected : PHP version 7.3.14-1~deb10u1
  [i] Repair option selected
  [✓] Disk space check
  [✗] Update local cache of available packages
  Error: Unable to update package cache. Please try "apt-get update"

Nadat ik apt-get update uitvoer lijkt mijn distro niet meer benaderbaar, iemand enig idee wat te doen? Foutmelding (je ziet eerst andere paketten die het wel doen zoals tvheadend).

code:

root@raspberrypi:/# apt-get update
Hit:1 http://deb.playonlinux.com trusty InRelease
Hit:2 http://mirrordirector.raspbian.org/raspbian jessie InRelease
Get:3 http://archive.raspberrypi.org/debian buster InRelease [25.1 kB]
Ign:4 https://dl.bintray.com/tvheadend/deb xenial InRelease
Ign:5 http://download.opensuse.org/repositories/home:/strycore/xUbuntu_16.04  InRelease
Get:6 https://dl.bintray.com/tvheadend/deb xenial Release [12.6 kB]
Err:7 http://download.opensuse.org/repositories/home:/strycore/xUbuntu_16.04  Release
  404  Not Found [IP: 195.135.221.134 80]
Reading package lists... Done
E: The repository 'http://download.opensuse.org/repositories/home:/strycore/xUbuntu_16.04  Release' no longer has a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
N: Skipping acquire of configured file 'main/binary-armhf/Packages' as repository 'http://deb.playonlinux.com trusty InRelease' doesn't support architecture 'armhf'
W: Skipping acquire of configured file 'staging/binary-armhf/Packages' as repository 'http://archive.raspberrypi.org/debian buster InRelease' doesn't have the component 'staging' (component misspelt in sources.list?)
W: Skipping acquire of configured file 'staging/i18n/Translation-en' as repository 'http://archive.raspberrypi.org/debian buster InRelease' doesn't have the component 'staging' (component misspelt in sources.list?)
W: Skipping acquire of configured file 'staging/i18n/Translation-en_GB' as repository 'http://archive.raspberrypi.org/debian buster InRelease' doesn't have the component 'staging' (component misspelt in sources.list?)
root@raspberrypi:/#

En inderdaad ik krijg ook xUbuntu_16.04 nergens te zien als ik hier kijk:
https://download.opensuse...:/strycore/xUbuntu_16.04/

Nu wil ik natuurlijk overspringen naar een versie die het wel doet. Iemand advies?
Ik draai verder Domoticz, en FlightRadar24, deze twee wil ik wel graag houden, maar kan ik opzich opnieuw installeren. Wellicht te offtopic voor de PiHole, maar geen idee.


Versie: Pi-hole Version v5.0 Web Interface Version v5.0 FTL Version v5.0

[asing]

Kecin schreef op maandag 25 mei 2020 @ 17:25:

verhaal

Als je nu eens kijkt in de logging zie je staan :

code:

http://download.opensuse.org/repositories/home:/strycore/xUbuntu_16.04

Als je daarheen gaat.....

Dit object is niet langer beschikbaar!

Je /var/apt/sources.list klopt dus niet meer. Dat kan ook wel kloppen, deze versie is al meer dan een jaar EOL.

probeer dit eens :

code:

## SOURCES LIST FOR UBUNTU 16.04 LTS XENIAL XERUS
## ALSO FOR XUBUNTU 16.04, LUBUNTU 16.04
## AND KUBUNTU 16.04
## From: http://sites.google.com/site/easylinuxtipsproject
## This list is for the Main server; you might want to select a
## faster mirror server closer to you, with Software & Updates.
## Only fit for 16.04 LTS Xenial Xerus!
#
## SOURCES FOR ORDINARY UPDATES AND SOFTWARE:
deb http://archive.ubuntu.com/ubuntu xenial main
deb http://archive.ubuntu.com/ubuntu xenial-updates main
deb http://archive.ubuntu.com/ubuntu xenial restricted
deb http://archive.ubuntu.com/ubuntu xenial-updates restricted
deb http://archive.ubuntu.com/ubuntu xenial universe
deb http://archive.ubuntu.com/ubuntu xenial-updates universe
deb http://archive.ubuntu.com/ubuntu xenial multiverse
deb http://archive.ubuntu.com/ubuntu xenial-updates multiverse
#
## SOURCES FOR SECURITY UPDATES:
deb http://archive.ubuntu.com/ubuntu xenial-security main
deb http://archive.ubuntu.com/ubuntu xenial-security restricted
deb http://archive.ubuntu.com/ubuntu xenial-security universe
deb http://archive.ubuntu.com/ubuntu xenial-security multiverse
#
## BACKPORTS SOURCES (WITH LOWERED PRIORITY):
deb http://archive.ubuntu.com/ubuntu xenial-backports main
deb http://archive.ubuntu.com/ubuntu xenial-backports restricted
deb http://archive.ubuntu.com/ubuntu xenial-backports universe
deb http://archive.ubuntu.com/ubuntu xenial-backports multiverse
#
## PARTNER SOURCE (FOR SOFTWARE FROM
## PARTNERS OF CANONICAL):
deb http://archive.canonical.com/ubuntu xenial partner

[nero355]

Kecin schreef op maandag 25 mei 2020 @ 17:25:
Nadat ik apt-get update uitvoer lijkt mijn distro niet meer benaderbaar, iemand enig idee wat te doen? Foutmelding (je ziet eerst andere paketten die het wel doen zoals tvheadend).

code:

root@raspberrypi:/# apt-get update
Hit:1 http://deb.playonlinux.com trusty InRelease
Hit:2 http://mirrordirector.raspbian.org/raspbian jessie InRelease
Get:3 http://archive.raspberrypi.org/debian buster InRelease [25.1 kB]
Ign:4 https://dl.bintray.com/tvheadend/deb xenial InRelease
Ign:5 http://download.opensuse.org/repositories/home:/strycore/xUbuntu_16.04  InRelease
Get:6 https://dl.bintray.com/tvheadend/deb xenial Release [12.6 kB]
Err:7 http://download.opensuse.org/repositories/home:/strycore/xUbuntu_16.04  Release
  404  Not Found [IP: 195.135.221.134 80]
Reading package lists... Done
E: The repository 'http://download.opensuse.org/repositories/home:/strycore/xUbuntu_16.04  Release' no longer has a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
N: Skipping acquire of configured file 'main/binary-armhf/Packages' as repository 'http://deb.playonlinux.com trusty InRelease' doesn't support architecture 'armhf'
W: Skipping acquire of configured file 'staging/binary-armhf/Packages' as repository 'http://archive.raspberrypi.org/debian buster InRelease' doesn't have the component 'staging' (component misspelt in sources.list?)
W: Skipping acquire of configured file 'staging/i18n/Translation-en' as repository 'http://archive.raspberrypi.org/debian buster InRelease' doesn't have the component 'staging' (component misspelt in sources.list?)
W: Skipping acquire of configured file 'staging/i18n/Translation-en_GB' as repository 'http://archive.raspberrypi.org/debian buster InRelease' doesn't have the component 'staging' (component misspelt in sources.list?)
root@raspberrypi:/#

En inderdaad ik krijg ook xUbuntu_16.04 nergens te zien als ik hier kijk:
https://download.opensuse...:/strycore/xUbuntu_16.04/

Nu wil ik natuurlijk overspringen naar een versie die het wel doet. Iemand advies?
Ik draai verder Domoticz, en FlightRadar24, deze twee wil ik wel graag houden, maar kan ik opzich opnieuw installeren. Wellicht te offtopic voor de PiHole, maar geen idee.

Geen ervaring met de rest, maar IMHO wordt het inderdaad wel tijd om te upgraden of eens te kijken waarom die repo überhaupt nog wordt aangesproken.

Is het een optie om die uit te zetten bijvoorbeeld

Kijk gewoon wat je kan doen en hoe ver je komt, maar voordat je verder gaat uiteraard wel effe backups maken mocht er een herinstallatie nodig zijn

pinojo123 schreef op zondag 24 mei 2020 @ 08:39:
Dank nero355, Die a-sync setting kan ik niet vinden, is dat Enable sending Sharing message via Sync?

Ik gebruik Chrome alleen onder Android en dan ook nog eens voor maar één website dus vandaar dat ik ze alle drie noemde

Mocht je echt niks te doen hebben dan kan je alle andere opties ook effe doorkijken voor zover er nog een aantal over zijn, want er zit echt een hoop troep in die ik altijd uitschakel!

Webgnome schreef op zondag 24 mei 2020 @ 08:58:
dit is hartstikke leuk natuurlijk maar op het moment dat Windows 10 DNS Over HTTPS gaat implementeren kom je hier niet heel ver mee. Volgens mij kun je dan beter iets als dit volgen

Die gebruik ik voorlopig niet dus dat kan me weinig schelen eerlijk gezegd

Daarnaast moet al dat verkeer nog steeds naar een IP toe en die kan je op je Router afvangen en doorsluizen naar je Pi-Hole net als we nu doen vanwege al die halvegare apparaten zoals de Google Chromecasts en dergelijken!

ocaj schreef op zondag 24 mei 2020 @ 13:44:
Hmmm, typisch gevalletje van hoe meer je snapt, hoe meer je snapt dat je het niet snapt

Bij mij is het meer hoe meer je dingen irritant gaat vinden en een workaround moet bedenken

Wat ik eigenlijk wilde is:

OS/APP -> DoH -> DoH-service -> pihole -> upstream DNS

De meeste guides die ik nu zie doen:

OS/APP -> DNS -> pihole -> DoH-service -> upstream DoH

Dat vind ik ook zo stom elke keer : Ik wil mijn DNS verkeer helemaal niet naar Cloudflare sturen!

Er is dus nog niet echt een standaard manier waarop een OS of een App (chrome bijvoorbeeld) de DoH-server kunnen vaststellen? Ik had het idee dat ze default zoiets zouden proberen als https://<dns-server>/dns-query , maar dat vind ik niet terug.

Als een App of OS zelf besluit om een ingebakken DoH-dienst te gebruiken kun je dus niks beginnen? Alleen eventueel via de app of os instellen, mits die app dat ondersteunt.

Volgens mij was daar wel iets voor :
- https://support.mozilla.o...ks-disable-dns-over-https
- https://support.mozilla.o...in-use-application-dnsnet

Maar... dat is dus alleen voor Firefox

Echter claimen zij dat men wel een standaard ervoor aan het afspreken is en ik heb geen idee hoe het daarmee verder zit...

Qua privacy is DoH misschien wel een goed ding (mits je je DoH-provider vertrouwt), maar qua systeem-architectuur is het totaal niet logisch. Enige dat logisch zou zijn, is als je op OS-niveau een DOH-lookup-service aanbiedt vergelijkbaar met de huidige DNS-lookup. En dat je op OS-niveau dan de DOH-server kunt instellen, maar dat is dus niet gangbaar?

Je hebt zojuist een beetje systemd onder Linux omschreven

Als ik heel eerlijk ben vind ik dat hele DNS over HTTPS gedoe maar een irritante hype en zou ik het liever kwijt dan rijk zijn als Pi-Hole + Unbound voorstander!

[Freee!!]

nero355 schreef op maandag 25 mei 2020 @ 18:12:
[...]
Als ik heel eerlijk ben vind ik dat hele DNS over HTTPS gedoe maar een irritante hype en zou ik het liever kwijt dan rijk zijn als Pi-Hole + Unbound voorstander!

AMEN!

[Gunner]

nero355 schreef op maandag 25 mei 2020 @ 18:12:
Volgens mij was daar wel iets voor :
- https://support.mozilla.o...ks-disable-dns-over-https
- https://support.mozilla.o...in-use-application-dnsnet

Dat kan toch veel eenvoudiger? https://support.mozilla.o...nnection-settings-firefox
Of is dat te simpel?

Maar is er in de Pi-Hole geen actieve community geen actuele discussie hierover? het is toch wel een dingetje lijkt me.

[ Voor 3% gewijzigd door Gunner op 25-05-2020 19:13 ]

[Cyberpope]

nero355 schreef op maandag 25 mei 2020 @ 18:12:
Als ik heel eerlijk ben vind ik dat hele DNS over HTTPS gedoe maar een irritante hype en zou ik het liever kwijt dan rijk zijn als Pi-Hole + Unbound voorstander!

Tja, moet je maar niet het verdienmodel van de grote jongens in gevaar brengen met je hobby projectje..

[ed1703]

nero355 schreef op maandag 25 mei 2020 @ 18:12:
[...]
Als ik heel eerlijk ben vind ik dat hele DNS over HTTPS gedoe maar een irritante hype en zou ik het liever kwijt dan rijk zijn als Pi-Hole + Unbound voorstander!

Juist. Vooral dat apps (volgens mij gaat het vooral om browsers) hun eigen koers varen, met hun eigen afspraken voor een upstream dnsprovider. Lekker efficiënt ook. Al is unbound ook niet the way-to-go. Andere discussie.

[ Voor 5% gewijzigd door ed1703 op 25-05-2020 19:40 ]

[nero355]

Gunner schreef op maandag 25 mei 2020 @ 19:04:
Dat kan toch veel eenvoudiger? https://support.mozilla.o...nnection-settings-firefox
Of is dat te simpel?

We hebben het over uitschakelen d.m.v. automatische detectie hé!

Maar is er in de Pi-Hole geen actieve community geen actuele discussie hierover? het is toch wel een dingetje lijkt me.

Geen idee, nog niet naar gekeken, maar komt vast wel goed in een toekomstige release.

Cyberpope schreef op maandag 25 mei 2020 @ 19:08:
Tja, moet je maar niet het verdienmodel van de grote jongens in gevaar brengen met je hobby projectje..

Mwahahaha! Dat is wel een goeie inderdaad!

ed1703 schreef op maandag 25 mei 2020 @ 19:37:
Juist. Vooral dat apps (volgens mij gaat het vooral om browsers) hun eigen koers varen, met hun eigen afspraken voor een upstream dnsprovider. Lekker efficiënt ook.

Word je ook als systeem/netwerkbeheerder heel vrolijk van net als dat random MAC address gedoe!

Al is unbound ook niet the way-to-go. Andere discussie.

Nood breekt wetten, maar in het begin vond ik het ook raar, want ik heb als eindgebruiker niks te zoeken bij de root servers!

[jpgview]

nero355 schreef op maandag 25 mei 2020 @ 18:12:
Als ik heel eerlijk ben vind ik dat hele DNS over HTTPS gedoe maar een irritante hype en zou ik het liever kwijt dan rijk zijn als Pi-Hole + Unbound voorstander!

Freee!! schreef op maandag 25 mei 2020 @ 18:51:
[...]

AMEN!

DoH op de firewall blocken? Lees dit discourse topic. Niet voor alle gebruikers, maar voor diegenen die een firewall hebben die het aankan (pfsense, opnsense, …).

IPv4 en IPv6 lijsten worden dagelijks geupdate (indien er wijzigingen zijn).

Indien iemand een DoH lijst kent, die niet vermeld is, graag een seintje via GitHub issue.

[Kecin]

asing schreef op maandag 25 mei 2020 @ 18:12:
[...]


Als je nu eens kijkt in de logging zie je staan :

code:

http://download.opensuse.org/repositories/home:/strycore/xUbuntu_16.04

Als je daarheen gaat.....

Dit object is niet langer beschikbaar!

Je /var/apt/sources.list klopt dus niet meer. Dat kan ook wel kloppen, deze versie is al meer dan een jaar EOL.

probeer dit eens :

code:

## SOURCES LIST FOR UBUNTU 16.04 LTS XENIAL XERUS
## ALSO FOR XUBUNTU 16.04, LUBUNTU 16.04
## AND KUBUNTU 16.04
## From: http://sites.google.com/site/easylinuxtipsproject
## This list is for the Main server; you might want to select a
## faster mirror server closer to you, with Software & Updates.
## Only fit for 16.04 LTS Xenial Xerus!
#
## SOURCES FOR ORDINARY UPDATES AND SOFTWARE:
deb http://archive.ubuntu.com/ubuntu xenial main
deb http://archive.ubuntu.com/ubuntu xenial-updates main
deb http://archive.ubuntu.com/ubuntu xenial restricted
deb http://archive.ubuntu.com/ubuntu xenial-updates restricted
deb http://archive.ubuntu.com/ubuntu xenial universe
deb http://archive.ubuntu.com/ubuntu xenial-updates universe
deb http://archive.ubuntu.com/ubuntu xenial multiverse
deb http://archive.ubuntu.com/ubuntu xenial-updates multiverse
#
## SOURCES FOR SECURITY UPDATES:
deb http://archive.ubuntu.com/ubuntu xenial-security main
deb http://archive.ubuntu.com/ubuntu xenial-security restricted
deb http://archive.ubuntu.com/ubuntu xenial-security universe
deb http://archive.ubuntu.com/ubuntu xenial-security multiverse
#
## BACKPORTS SOURCES (WITH LOWERED PRIORITY):
deb http://archive.ubuntu.com/ubuntu xenial-backports main
deb http://archive.ubuntu.com/ubuntu xenial-backports restricted
deb http://archive.ubuntu.com/ubuntu xenial-backports universe
deb http://archive.ubuntu.com/ubuntu xenial-backports multiverse
#
## PARTNER SOURCE (FOR SOFTWARE FROM
## PARTNERS OF CANONICAL):
deb http://archive.canonical.com/ubuntu xenial partner

Ik had het inderdaad gezien in de logging (zie mijn reactie boven), heb ondertussen mijn /etc/apt/sources.list aangepast. Wel overal even trusted voorgezet, i.v.m. keys. Maar commando's als

code:

root@raspberrypi:/etc/apt#  sudo apt-get update --fix-missing
Get:1 http://archive.raspberrypi.org/debian buster InRelease [25.1 kB]
Hit:2 http://deb.playonlinux.com trusty InRelease
Hit:3 http://archive.canonical.com/ubuntu xenial InRelease
Get:4 http://archive.ubuntu.com/ubuntu xenial InRelease [247 kB]
Ign:5 https://dl.bintray.com/tvheadend/deb xenial InRelease
Get:6 https://dl.bintray.com/tvheadend/deb xenial Release [12.6 kB]
Get:7 http://archive.ubuntu.com/ubuntu xenial-updates InRelease [109 kB]
Get:8 http://archive.ubuntu.com/ubuntu xenial-security InRelease [109 kB]
Get:9 http://archive.ubuntu.com/ubuntu xenial-backports InRelease [107 kB]
Ign:11 http://archive.ubuntu.com/ubuntu xenial/main armhf Packages
Get:12 http://archive.ubuntu.com/ubuntu xenial/main Translation-en [568 kB]
Get:13 http://archive.ubuntu.com/ubuntu xenial/main Translation-en_GB [426 kB]
Get:14 http://archive.ubuntu.com/ubuntu xenial/restricted armhf Packages [5,072 B]
Get:14 http://archive.ubuntu.com/ubuntu xenial/restricted armhf Packages [5,072 B]
Get:14 http://archive.ubuntu.com/ubuntu xenial/restricted armhf Packages [5,072 B]
Get:14 http://archive.ubuntu.com/ubuntu xenial/restricted armhf Packages [5,072 B]
Get:14 http://archive.ubuntu.com/ubuntu xenial/restricted armhf Packages [5,072 B]
Get:14 http://archive.ubuntu.com/ubuntu xenial/restricted armhf Packages [5,072 B]
Ign:14 http://archive.ubuntu.com/ubuntu xenial/restricted armhf Packages
Ign:21 http://archive.ubuntu.com/ubuntu xenial/universe armhf Packages
Ign:22 http://archive.ubuntu.com/ubuntu xenial/multiverse armhf Packages
Ign:11 http://archive.ubuntu.com/ubuntu xenial/main armhf Packages
Ign:14 http://archive.ubuntu.com/ubuntu xenial/restricted armhf Packages
Ign:21 http://archive.ubuntu.com/ubuntu xenial/universe armhf Packages
Ign:22 http://archive.ubuntu.com/ubuntu xenial/multiverse armhf Packages
Ign:11 http://archive.ubuntu.com/ubuntu xenial/main armhf Packages
Ign:14 http://archive.ubuntu.com/ubuntu xenial/restricted armhf Packages
Ign:21 http://archive.ubuntu.com/ubuntu xenial/universe armhf Packages
Get:22 http://archive.ubuntu.com/ubuntu xenial/multiverse armhf Packages [149 kB]
Get:22 http://archive.ubuntu.com/ubuntu xenial/multiverse armhf Packages [149 kB]
Get:22 http://archive.ubuntu.com/ubuntu xenial/multiverse armhf Packages [149 kB]
Get:22 http://archive.ubuntu.com/ubuntu xenial/multiverse armhf Packages [149 kB]
Ign:22 http://archive.ubuntu.com/ubuntu xenial/multiverse armhf Packages
Ign:27 http://archive.ubuntu.com/ubuntu xenial-updates/main armhf Packages
Ign:28 http://archive.ubuntu.com/ubuntu xenial-updates/restricted armhf Packages
Ign:29 http://archive.ubuntu.com/ubuntu xenial-updates/universe armhf Packages
Ign:30 http://archive.ubuntu.com/ubuntu xenial-updates/multiverse armhf Packages
Ign:11 http://archive.ubuntu.com/ubuntu xenial/main armhf Packages
Ign:14 http://archive.ubuntu.com/ubuntu xenial/restricted armhf Packages
Ign:21 http://archive.ubuntu.com/ubuntu xenial/universe armhf Packages
Ign:22 http://archive.ubuntu.com/ubuntu xenial/multiverse armhf Packages
Ign:27 http://archive.ubuntu.com/ubuntu xenial-updates/main armhf Packages
Ign:28 http://archive.ubuntu.com/ubuntu xenial-updates/restricted armhf Packages
Ign:29 http://archive.ubuntu.com/ubuntu xenial-updates/universe armhf Packages
Ign:30 http://archive.ubuntu.com/ubuntu xenial-updates/multiverse armhf Packages
Ign:11 http://archive.ubuntu.com/ubuntu xenial/main armhf Packages
Ign:14 http://archive.ubuntu.com/ubuntu xenial/restricted armhf Packages
Ign:21 http://archive.ubuntu.com/ubuntu xenial/universe armhf Packages
Ign:22 http://archive.ubuntu.com/ubuntu xenial/multiverse armhf Packages
Ign:27 http://archive.ubuntu.com/ubuntu xenial-updates/main armhf Packages
Ign:28 http://archive.ubuntu.com/ubuntu xenial-updates/restricted armhf Packages
Ign:29 http://archive.ubuntu.com/ubuntu xenial-updates/universe armhf Packages
Ign:30 http://archive.ubuntu.com/ubuntu xenial-updates/multiverse armhf Packages
Err:11 http://archive.ubuntu.com/ubuntu xenial/main armhf Packages
  404  Not Found [IP: 91.189.88.152 80]
Ign:14 http://archive.ubuntu.com/ubuntu xenial/restricted armhf Packages
Ign:21 http://archive.ubuntu.com/ubuntu xenial/universe armhf Packages
Ign:22 http://archive.ubuntu.com/ubuntu xenial/multiverse armhf Packages
Ign:27 http://archive.ubuntu.com/ubuntu xenial-updates/main armhf Packages
Ign:28 http://archive.ubuntu.com/ubuntu xenial-updates/restricted armhf Packages
Ign:29 http://archive.ubuntu.com/ubuntu xenial-updates/universe armhf Packages
Ign:30 http://archive.ubuntu.com/ubuntu xenial-updates/multiverse armhf Packages
Ign:27 http://archive.ubuntu.com/ubuntu xenial-updates/main armhf Packages
Ign:28 http://archive.ubuntu.com/ubuntu xenial-updates/restricted armhf Packages
Ign:29 http://archive.ubuntu.com/ubuntu xenial-updates/universe armhf Packages
Ign:30 http://archive.ubuntu.com/ubuntu xenial-updates/multiverse armhf Packages
Err:27 http://archive.ubuntu.com/ubuntu xenial-updates/main armhf Packages
  404  Not Found [IP: 91.189.88.152 80]
Ign:28 http://archive.ubuntu.com/ubuntu xenial-updates/restricted armhf Packages
Ign:29 http://archive.ubuntu.com/ubuntu xenial-updates/universe armhf Packages
Ign:30 http://archive.ubuntu.com/ubuntu xenial-updates/multiverse armhf Packages
Ign:31 http://download.opensuse.org/repositories/home:/strycore/xUbuntu_16.04  InRelease
Err:32 http://download.opensuse.org/repositories/home:/strycore/xUbuntu_16.04  Release
  404  Not Found [IP: 195.135.221.134 80]
Ign:33 http://archive.ubuntu.com/ubuntu xenial-security/main armhf Packages
Get:34 http://archive.ubuntu.com/ubuntu xenial-security/main Translation-en [328 kB]
Get:35 http://archive.ubuntu.com/ubuntu xenial-security/restricted armhf Packages [4,964 B]
Get:35 http://archive.ubuntu.com/ubuntu xenial-security/restricted armhf Packages [4,964 B]
Get:35 http://archive.ubuntu.com/ubuntu xenial-security/restricted armhf Packages [4,964 B]
Ign:35 http://archive.ubuntu.com/ubuntu xenial-security/restricted armhf Packages
Ign:39 http://archive.ubuntu.com/ubuntu xenial-security/universe armhf Packages
Ign:40 http://archive.ubuntu.com/ubuntu xenial-security/multiverse armhf Packages
Ign:33 http://archive.ubuntu.com/ubuntu xenial-security/main armhf Packages
Ign:35 http://archive.ubuntu.com/ubuntu xenial-security/restricted armhf Packages
Ign:39 http://archive.ubuntu.com/ubuntu xenial-security/universe armhf Packages
Ign:40 http://archive.ubuntu.com/ubuntu xenial-security/multiverse armhf Packages
Ign:33 http://archive.ubuntu.com/ubuntu xenial-security/main armhf Packages
Ign:35 http://archive.ubuntu.com/ubuntu xenial-security/restricted armhf Packages
Ign:39 http://archive.ubuntu.com/ubuntu xenial-security/universe armhf Packages
Ign:40 http://archive.ubuntu.com/ubuntu xenial-security/multiverse armhf Packages
Ign:33 http://archive.ubuntu.com/ubuntu xenial-security/main armhf Packages
Ign:35 http://archive.ubuntu.com/ubuntu xenial-security/restricted armhf Packages
Ign:39 http://archive.ubuntu.com/ubuntu xenial-security/universe armhf Packages
Ign:40 http://archive.ubuntu.com/ubuntu xenial-security/multiverse armhf Packages
Ign:33 http://archive.ubuntu.com/ubuntu xenial-security/main armhf Packages
Ign:35 http://archive.ubuntu.com/ubuntu xenial-security/restricted armhf Packages
Ign:39 http://archive.ubuntu.com/ubuntu xenial-security/universe armhf Packages
Ign:40 http://archive.ubuntu.com/ubuntu xenial-security/multiverse armhf Packages
Err:33 http://archive.ubuntu.com/ubuntu xenial-security/main armhf Packages
  404  Not Found [IP: 91.189.88.152 80]
Ign:35 http://archive.ubuntu.com/ubuntu xenial-security/restricted armhf Packages
Ign:39 http://archive.ubuntu.com/ubuntu xenial-security/universe armhf Packages
Ign:40 http://archive.ubuntu.com/ubuntu xenial-security/multiverse armhf Packages
Ign:41 http://archive.ubuntu.com/ubuntu xenial-backports/main armhf Packages
Get:42 http://archive.ubuntu.com/ubuntu xenial-backports/main Translation-en [4,456 B]
Get:43 http://archive.ubuntu.com/ubuntu xenial-backports/universe armhf Packages [7,740 B]
Ign:43 http://archive.ubuntu.com/ubuntu xenial-backports/universe armhf Packages
Ign:41 http://archive.ubuntu.com/ubuntu xenial-backports/main armhf Packages
Ign:43 http://archive.ubuntu.com/ubuntu xenial-backports/universe armhf Packages
Ign:41 http://archive.ubuntu.com/ubuntu xenial-backports/main armhf Packages
Ign:43 http://archive.ubuntu.com/ubuntu xenial-backports/universe armhf Packages
Ign:41 http://archive.ubuntu.com/ubuntu xenial-backports/main armhf Packages
Ign:43 http://archive.ubuntu.com/ubuntu xenial-backports/universe armhf Packages
Ign:41 http://archive.ubuntu.com/ubuntu xenial-backports/main armhf Packages
Ign:43 http://archive.ubuntu.com/ubuntu xenial-backports/universe armhf Packages
Err:41 http://archive.ubuntu.com/ubuntu xenial-backports/main armhf Packages
  404  Not Found [IP: 91.189.88.152 80]
Ign:43 http://archive.ubuntu.com/ubuntu xenial-backports/universe armhf Packages
Reading package lists... Done
N: Skipping acquire of configured file 'main/binary-armhf/Packages' as repository 'http://deb.playonlinux.com trusty InRelease' doesn't support architecture 'armhf'
W: Skipping acquire of configured file 'staging/binary-armhf/Packages' as repository 'http://archive.raspberrypi.org/debian buster InRelease' doesn't have the component 'staging' (component misspelt in sources.list?)
W: Skipping acquire of configured file 'staging/i18n/Translation-en' as repository 'http://archive.raspberrypi.org/debian buster InRelease' doesn't have the component 'staging' (component misspelt in sources.list?)
W: Skipping acquire of configured file 'staging/i18n/Translation-en_GB' as repository 'http://archive.raspberrypi.org/debian buster InRelease' doesn't have the component 'staging' (component misspelt in sources.list?)
E: The repository 'http://download.opensuse.org/repositories/home:/strycore/xUbuntu_16.04  Release' no longer has a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
root@raspberrypi:/etc/apt#

Hij blijft dus vragen naar 16.04, maar ik heb hem niet meer in mijn sources staan?!

code:

root@raspberrypi:/etc/apt# sudo apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 xserver-xorg-video-fbturbo : Depends: xorg-video-abi-24
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
root@raspberrypi:/etc/apt# sudo apt-get dist-upgrade --fix-broken install
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... Done
E: Unable to locate package install

Sources.list is nu:

code:

  GNU nano 3.2                                                                                                      sources.list

# Uncomment line below then 'apt-get update' to enable 'apt-get source'
## SOURCES LIST FOR UBUNTU 16.04 LTS XENIAL XERUS
## ALSO FOR XUBUNTU 16.04, LUBUNTU 16.04
## AND KUBUNTU 16.04
## From: http://sites.google.com/site/easylinuxtipsproject
## This list is for the Main server; you might want to select a
## faster mirror server closer to you, with Software & Updates.
## Only fit for 16.04 LTS Xenial Xerus!
#
## SOURCES FOR ORDINARY UPDATES AND SOFTWARE:
deb [trusted=yes] http://archive.ubuntu.com/ubuntu xenial main
deb [trusted=yes] http://archive.ubuntu.com/ubuntu xenial-updates main
deb [trusted=yes] http://archive.ubuntu.com/ubuntu xenial restricted
deb [trusted=yes] http://archive.ubuntu.com/ubuntu xenial-updates restricted
deb [trusted=yes] http://archive.ubuntu.com/ubuntu xenial universe
deb [trusted=yes] http://archive.ubuntu.com/ubuntu xenial-updates universe
deb [trusted=yes] http://archive.ubuntu.com/ubuntu xenial multiverse
deb [trusted=yes] http://archive.ubuntu.com/ubuntu xenial-updates multiverse
#
## SOURCES FOR SECURITY UPDATES:
deb [trusted=yes] http://archive.ubuntu.com/ubuntu xenial-security main
deb [trusted=yes] http://archive.ubuntu.com/ubuntu xenial-security restricted
deb [trusted=yes] http://archive.ubuntu.com/ubuntu xenial-security universe
deb [trusted=yes] http://archive.ubuntu.com/ubuntu xenial-security multiverse
#
## BACKPORTS SOURCES (WITH LOWERED PRIORITY):
deb [trusted=yes] http://archive.ubuntu.com/ubuntu xenial-backports main
deb [trusted=yes] http://archive.ubuntu.com/ubuntu xenial-backports restricted
deb [trusted=yes] http://archive.ubuntu.com/ubuntu xenial-backports universe
deb [trusted=yes] http://archive.ubuntu.com/ubuntu xenial-backports multiverse
#
## PARTNER SOURCE (FOR SOFTWARE FROM
## PARTNERS OF CANONICAL):
deb [trusted=yes] http://archive.canonical.com/ubuntu xenial partner

halen weinig uit.
Verder krijg ik op de PiHole Group pagina na een paar seconden nogsteeds deze error:

code:

DataTables warning: table id=groupsTable - Invalid JSON response. For more information about this error, please see http://datatables.net/tn/1

[Ztjuh]

Ik ben opzoek naar Nederlandse (up-to-date) ads lijsten, iemand die er een paar weet? (Pi-Hole 5)

Edit: Ik heb een gevonden, schijnen geen false positives in te zitten -> https://hosts.oisd.nl/

[ Voor 34% gewijzigd door Ztjuh op 26-05-2020 00:26 ]

[nero355]

Kecin schreef op maandag 25 mei 2020 @ 23:03:
Ik had het inderdaad gezien in de logging (zie mijn reactie boven), heb ondertussen mijn /etc/apt/sources.list aangepast. Wel overal even trusted voorgezet, i.v.m. keys.

Hij blijft dus vragen naar 16.04, maar ik heb hem niet meer in mijn sources staan?!

In je /etc/apt/sources.list.d/ kunnen ook nog losse config files staan met daarin de lijsten

Zie : https://wiki.debian.org/SourcesList#Using__a_text_editor

[Kecin]

nero355 schreef op dinsdag 26 mei 2020 @ 00:18:
[...]

In je /etc/apt/sources.list.d/ kunnen ook nog losse config files staan met daarin de lijsten

Zie : https://wiki.debian.org/SourcesList#Using__a_text_editor

Bingo!
Text-editor lukt en gaat goed! Ik had in de map sources.list.d/ nog een file lutris.list die dus de regel naar 16.04 had. Die heb ik uitgecomment, lets give it a shot .

[geenwindows]

Ztjuh schreef op maandag 25 mei 2020 @ 23:46:
Ik ben opzoek naar Nederlandse (up-to-date) ads lijsten, iemand die er een paar weet? (Pi-Hole 5)

Edit: Ik heb een gevonden, schijnen geen false positives in te zitten -> https://hosts.oisd.nl/

hier eentje:
https://dbl.oisd.nl/

(volgens mij is de beheerder of één van de beheerders, zelfs hier actief op Tweakers, Dacht ik...)

[twit]

geenwindows schreef op dinsdag 26 mei 2020 @ 11:28:
[...]


hier eentje:
https://dbl.oisd.nl/

(volgens mij is de beheerder of één van de beheerders, zelfs hier actief op Tweakers, Dacht ik...)

Is dit dan de enige lijst die jullie gebruiken of zijn dit NL specifieke links die jullie naast een set andere lists gebruiken? Ik vraag dit omdat ik zelf sinds Pi-hole nu een maandje draait toch wel het idee heb dat ik bij het openen van Instagram stories of twitch streams tegen problemen aanloop op mijn mobiel/appletv die waarschijnlijk komen door geblockte dns requests Pi-hole. Mogelijk blok ik op dit moment (veel) te veel. Wat is jullie totale set geconfigde blacklists?

[geenwindows]

nee, ik heb er momenteel 118 blocklists in gebruik, wel heel veel dubbele adressen welke pi-hole automatisch negeert. totaal geblokkeerde domeinen in blocklist staat hier nu op 1.839,498

Ik moet dan wel regelmatig wat toevoegen aan de whitelist
(het internet is hier regelmatig "kapot" )

overigens, die lijst die ik hier boven aangeef is Groot, enkel met die heb je al ruim voldoende te pakken...

code:

  [i] Number of domains being pulled in by gravity: 3330459
  [✓] Removing duplicate domains
  [i] Number of unique domains trapped in the Event Horizon: 1733577
  [i] Number of whitelisted domains: 280
  [i] Number of blacklisted domains: 61

zo zie je maar, 118 blocklists en dan behoorlijk veel dubbele domeinen.

[ Voor 44% gewijzigd door geenwindows op 26-05-2020 12:16 ]

[dss58]

geenwindows schreef op dinsdag 26 mei 2020 @ 11:28:
[...]


hier eentje:
https://dbl.oisd.nl/

(volgens mij is de beheerder of één van de beheerders, zelfs hier actief op Tweakers, Dacht ik...)

ja, dat is @sjhgvr

[CR2032]

Gebruik al jaren naar volle tevredenheid Pi-hole + Unbound op een Raspberry Pi. Werkt allemaal top.

Alleen na de komst van Pi-hole 5 continue problemen. Ik krijg steevast ads te zien wanneer je de configuratie aanpast van Pi-hole via de web interface. Bijvoorbeeld bij het uitzetten van de statistics, privacy op het laagste niveau, aanpassen van Adlists, soms na een herstart van de Pi. Nu werkt het weer wanneer je de statistics maar aan laat staan, herstart en DNS flushed.

Zelf zover gegaan om de Pi eens volledig opnieuw te installeren met de laatste versie van Raspbian lite, de internet router een factory reset gegeven. Ik heb in Client Group Management handmatig de clients toegevoegd naar de Default Group, toen werkte het weer even. De Pi heeft een static IP en wordt headless gebruikt. Clients krijgen vast ip van de router. Met Unbound of zonder maakt ook geen verschil.

Herkent iemand dit en enig idee waar ik dit moet zoeken?

[ Voor 3% gewijzigd door CR2032 op 26-05-2020 19:12 ]

[pinojo123]

twit schreef op dinsdag 26 mei 2020 @ 11:49:
[...]


Is dit dan de enige lijst die jullie gebruiken of zijn dit NL specifieke links die jullie naast een set andere lists gebruiken? Ik vraag dit omdat ik zelf sinds Pi-hole nu een maandje draait toch wel het idee heb dat ik bij het openen van Instagram stories of twitch streams tegen problemen aanloop op mijn mobiel/appletv die waarschijnlijk komen door geblockte dns requests Pi-hole. Mogelijk blok ik op dit moment (veel) te veel. Wat is jullie totale set geconfigde blacklists?

https://dbl.oisd.nl is een samenvoeging van 3000+ blocklisten waar alle false positives er uit zijn gehaald.

Lees even het stukje "how i made this work" https://www.reddit.com/r/...rnets_1_domain_blocklist/

[The Eagle]

geenwindows schreef op dinsdag 26 mei 2020 @ 11:28:
[...]


hier eentje:
https://dbl.oisd.nl/

(volgens mij is de beheerder of één van de beheerders, zelfs hier actief op Tweakers, Dacht ik...)

Thanks, meende al dat ik er vroeger eentje meer dan standaard had

[dss58]

CR2032 schreef op dinsdag 26 mei 2020 @ 19:09:
Gebruik al jaren naar volle tevredenheid Pi-hole + Unbound op een Raspberry Pi. Werkt allemaal top.

Alleen na de komst van Pi-hole 5 continue problemen. Ik krijg steevast ads te zien wanneer je de configuratie aanpast van Pi-hole via de web interface. Bijvoorbeeld bij het uitzetten van de statistics, privacy op het laagste niveau, aanpassen van Adlists, soms na een herstart van de Pi. Nu werkt het weer wanneer je de statistics maar aan laat staan, herstart en DNS flushed.

Zelf zover gegaan om de Pi eens volledig opnieuw te installeren met de laatste versie van Raspbian lite, de internet router een factory reset gegeven. Ik heb in Client Group Management handmatig de clients toegevoegd naar de Default Group, toen werkte het weer even. De Pi heeft een static IP en wordt headless gebruikt. Clients krijgen vast ip van de router. Met Unbound of zonder maakt ook geen verschil.

Herkent iemand dit en enig idee waar ik dit moet zoeken?

toevallig vandaag hetzelfde opnieuw geinstalleerd op een pi3, werkt fantastisch goed hier, dus geen idee wat er bij je fout gaat

[PhilipsFan]

Ik heb juist heel veel problemen met Raspberry Pi's. Soms gaat het goed. Mijn Domoticz loopt op een Pi2 en is al jaren stabiel (wel met wat quirks). Mijn Pihole draait op een Pi3 en dat is een puinhoop.

Laatst zag ik in de blacklist (via de Pihole webinterface) allemaal rare tekens. Gevalletje corruptie op de SD-kaart? Ik bewaar natuurlijk een image van mijn Pihole, dus die teruggezet, deed na een paar dagen weer gek. Dus opnieuw (hetzelfde) image op kaartje gezet en deze keer geverifieerd. Bingo, error in sector xxxx. Aha, dus toch het SD-kaartje.

Ander kaartje gepakt, image erop gezet, geverifieerd en.... weer error in dezelfde sector. Ik weet dat SD-kaartjes niet het eeuwige leven hebben, maar dat er twee op exact dezelfde plek kapot gaan, dat is toch sterk? De kaartjes zijn niet van hetzelfde merk en type(Kingston en Transcend). Iemand een idee wat hier aan de hand kan zijn?

[sjhgvr]

pinojo123 schreef op dinsdag 26 mei 2020 @ 21:22:
[...]

https://dbl.oisd.nl is een samenvoeging van 3000+ blocklisten waar alle false positives er uit zijn gehaald.

Dat klopt niet helemaal;

Die 3000+, daar zitten ook mirrors en inmiddels niet meer werkende lijsten tussen.
Maar das vóór de check of ik de lijsten daadwerkelijk ga includen. Bij die check vallen der een shitload af. Daarna ga ik pas whitelisten.

Voor een overzicht van de geïnclude lijsten (welke gecrossmatched konden worden met filterlists.com) zie https://includes.oisd.nl

[Freee!!]

PhilipsFan schreef op woensdag 27 mei 2020 @ 02:52:
Ik heb juist heel veel problemen met Raspberry Pi's. Soms gaat het goed. Mijn Domoticz loopt op een Pi2 en is al jaren stabiel (wel met wat quirks). Mijn Pihole draait op een Pi3 en dat is een puinhoop.

Laatst zag ik in de blacklist (via de Pihole webinterface) allemaal rare tekens. Gevalletje corruptie op de SD-kaart? Ik bewaar natuurlijk een image van mijn Pihole, dus die teruggezet, deed na een paar dagen weer gek. Dus opnieuw (hetzelfde) image op kaartje gezet en deze keer geverifieerd. Bingo, error in sector xxxx. Aha, dus toch het SD-kaartje.

Ander kaartje gepakt, image erop gezet, geverifieerd en.... weer error in dezelfde sector. Ik weet dat SD-kaartjes niet het eeuwige leven hebben, maar dat er twee op exact dezelfde plek kapot gaan, dat is toch sterk? De kaartjes zijn niet van hetzelfde merk en type(Kingston en Transcend). Iemand een idee wat hier aan de hand kan zijn?

Rotzooi in je bewaarde image
En verder heb ik nooit problemen met kaartjes van SanDisk.

[ed1703]

Freee!! schreef op woensdag 27 mei 2020 @ 09:27:
[...]

Rotzooi in je bewaarde image
En verder heb ik nooit problemen met kaartjes van SanDisk.

En met transcend eigenlijk ook niet. Ik bestel de meeste kaartjes sandisk uhs via dataio. Als je alles maar loopt te loggen gaat het hard. Ik heb mijn gehele logging disabled omdat ik het niet nodig heb. Pas als het nodig is vanwege iets wat je wilt whitelisten oid, zet ik het tijdelijk aan.

[PhilipsFan]

Freee!! schreef op woensdag 27 mei 2020 @ 09:27:
[...]

Rotzooi in je bewaarde image
En verder heb ik nooit problemen met kaartjes van SanDisk.

Ja, dat zou je denken he? Maar dat begrijp ik dan toch niet. Ik bewaar dat image op een Windows PC. Ik beschrijf dat kaartje op een Windows PC. En doe daar ook (meteen) de controle. Ik neem toch aan dat een bestand op een Windows PC niet zomaar van inhoud verandert. Dat de Raspberry het image niet snapt omdat er een fout in zit kan toch niet betekenen dat de PC het ook niet snapt?

[Freee!!]

PhilipsFan schreef op woensdag 27 mei 2020 @ 10:48:
[...]
Ja, dat zou je denken he? Maar dat begrijp ik dan toch niet. Ik bewaar dat image op een Windows PC. Ik beschrijf dat kaartje op een Windows PC. En doe daar ook (meteen) de controle. Ik neem toch aan dat een bestand op een Windows PC niet zomaar van inhoud verandert. Dat de Raspberry het image niet snapt omdat er een fout in zit kan toch niet betekenen dat de PC het ook niet snapt?

Soms valt er ook onder Windows wel eens een bitje om. En je PC hoeft dat bestand helemaal niet te snappen, het hoeft het alleen maar te bewaren en op verzoek de inhoud op te lepelen.

[hp-got]

PhilipsFan schreef op woensdag 27 mei 2020 @ 10:48:
[...]
Ik bewaar dat image op een Windows PC. Ik beschrijf dat kaartje op een Windows PC. En doe daar ook (meteen) de controle.
[...]

Als de controle op de Windows machine zegt dat het bestandje foutloos gekopieerd is mag je dat best geloven.
Mijn conclusie zou dan zijn dat er in het originele image iets mis is, en dat je die fout netjes doorgeeft aan alle kopieën.
Ik zou in zo'n geval alles vanaf scratch installeren op een nieuw SD kaartje.
Enneh..... is je voeding in orde? Bij vage problemen waar dit er misschien één van is: altijd de originele Raspberry voeding gebruiken!

[ed1703]

PhilipsFan schreef op woensdag 27 mei 2020 @ 10:48:
[...]

Ja, dat zou je denken he? Maar dat begrijp ik dan toch niet. Ik bewaar dat image op een Windows PC. Ik beschrijf dat kaartje op een Windows PC. En doe daar ook (meteen) de controle. Ik neem toch aan dat een bestand op een Windows PC niet zomaar van inhoud verandert. Dat de Raspberry het image niet snapt omdat er een fout in zit kan toch niet betekenen dat de PC het ook niet snapt?

Ik zou na zo'n rare tekens momentje ook eens checken wat de uptime is van je systeem.
Wat @hp-got al zegt.. en ook om eens van scratch te gaan beginnen.
Desnoods op een apart kaartje, dan is teruggaan ook mogelijk, al lijkt dat in dit geval geen goede optie.

[PhilipsFan]

hp-got schreef op woensdag 27 mei 2020 @ 11:28:
[...]

Als de controle op de Windows machine zegt dat het bestandje foutloos gekopieerd is mag je dat best geloven.
Mijn conclusie zou dan zijn dat er in het originele image iets mis is, en dat je die fout netjes doorgeeft aan alle kopieën.
Ik zou in zo'n geval alles vanaf scratch installeren op een nieuw SD kaartje.
Enneh..... is je voeding in orde? Bij vage problemen waar dit er misschien één van is: altijd de originele Raspberry voeding gebruiken!

Thanks (iedereen) voor de tips, maar deze paste ik al toe. Deze image is juist net nieuw van scratch gemaakt, daarom is het ook zo frustrerend. En als ik een bestand van de pc wegschrijf naar een sd-kaartje en vervolgens controleer, dan verwacht ik niet dat dit op 2 verschillende kaartjes op dezelfde sector fout gaat.

De schijf op de Windows pc heb ik ook al gecontroleerd en ik heb zelfs het bestand opnieuw uitgepakt uit een rar-file, dus bitrot op de Windows PC heb ik ook uitgesloten. Dus ik begrijp niet waar dit fout gaat.