Software-update: Pi-hole Core 5.4 / Web 5.6 / FTL 5.9

Pi-hole logo (75 pix) Versie 5.4 van Pi-hole Core is verschenen. Ook zijn Pi-hole Web 5.6 en FTL 5.9 uitgekomen. Pi-hole is een advertising-aware dns- en webserver bedoeld om te draaien op een Raspberry Pi in het netwerk. Als op de router naar Pi-hole wordt verwezen voor dns-afhandelingen, zullen alle apparaten binnen het netwerk er automatisch gebruik van maken zonder dat er instellingen moeten worden aangepast. Vervolgens worden advertenties niet meer opgehaald, waardoor pagina's sneller laden. In potentie kan er ook malware mee buiten de deur worden gehouden. Voor meer informatie verwijzen we jullie door naar de uitleg en video's op deze pagina, of deze handleiding van tweaker jpgview. De belangrijkste veranderingen die in deze uitgave zijn aangebracht zijn hieronder voor je op een ritje gezet.

Highlights
  • Update embedded dnsmasq DNS server to version 2.86
    • Handle DHCPREBIND requests in the DHCPv6 server code
    • Fix bug which caused dnsmasq to lose track of processes forked to handle TCP DNS connections under heavy load
      The code checked that at least one free process table slot was available before listening on TCP sockets, but didn’t take into account that more than one TCP connection could arrive, so that check was not sufficient to ensure that there would be slots for all new processes. It compounded this error by silently failing to store the process when it did run out of slots. Even when this bug is triggered, all the right things happen, and answers are still returned. Only under very exceptional circumstances, does the bug manifest itself: see https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q2/014976.html
    • Major rewrite of the DNS server and domain handling code
      This should be largely transparent, but it drastically improves performance and reduces memory foot-print when configuring large numbers domains of the form local=/adserver.com/ or local=/adserver.com/# Lookup times now grow as log-to-base-2 of the number of domains, rather than greater than linearly, as before. The change makes multiple addresses associated with a domain work address=/example.com/1.2.3.4 address=/example.com/5.6.7.8
      It also handles multiple upstream servers for a domain better; using the same try/retry algorithms as non domain-specific servers. This also applies to DNSSEC-generated queries. Finally, some of the oldest and gnarliest code in dnsmasq has had a significant clean-up. It’s far from perfect, but it is better.
    • Revise resource handling for number of concurrent DNS queries
      This used to have a global limit, but that has a problem when using different servers for different upstream domains. Queries which are routed by domain to an upstream server which is not responding will build up and trigger the limit, which breaks DNS service for all other domains which could be handled by other servers. The change is to make the limit per server-group, where a server group is the set of servers configured for a particular domain. In the common case, where only default servers are declared, there is no effective change.
    • Improve efficiency of DNSSEC
      The sharing point for DNSSEC RR data used to be when it entered the cache, having been validated. After that queries requiring the KEY or DS records would share the cached values. There is a common case in dual-stack hosts that queries for A and AAAA records for the same domain are made simultaneously. If required keys were not in the cache, this would result in two requests being sent upstream for the same key data (and all the subsequent chain-of-trust queries.) Now we combine these requests and elide the duplicates, resulting in fewer queries upstream and better performance. To keep a better handle on what’s going on, the extra logging mode has been modified to associate queries and answers for DNSSEC queries in the same way as ordinary queries. The requesting address and port have been removed from DNSSEC logging lines, since this is no longer strictly defined.
    • Allow wildcards in dnsmasq config domain patterns
      Domain patterns in --address, --server and --local have, for many years, matched complete labels only, so --server=/google.com/1.2.3.4 will apply to google.com and www.google.com but NOT supergoogle.com. dnsmasq now introduces an optional * at the LHS of the domain string which changes this behaviour so as to include substring matches within labels. So, --server=/*google.com/1.2.3.4 applies to google.com and www.google.com AND supergoogle.com
    • FTL also imported the requested feature to Support Cisco Umbrella/OpenDNS Device ID Remote IP FTL#1096
    • Connection track mark based DNS query filtering
    • Allow smaller than 64 prefix lengths in synth-domain, with caveats. --synth-domain=1234:4567::/56,example.com is now valid.
    • Make domains generated by --synth-domain appear in replies when in authoritative mode.
    • Ensure CAP_NET_ADMIN capability is available when conntrack is configured.
    • When --dhcp-hostsfile --dhcp-optsfile and --addn-hosts are
      given a directory as argument, define the order in which files within that directory are read (alphabetical order of filename).
  • Interface-dependent handling of pi.hole and the machine’s hostname
    This makes FTL automatically reply with the appropriate IP address to both pi.hole and the machines hostname. Before this change, FTL always used a hard-coded address set during the weekly gravity updates (pihole -g). The new method is interface-aware and may reply with different addresses on different interfaces (e.g. Ethernet, WiFi or Wireguard network). The address FTL replies with can be overwritten using the REPLY_ADDR4/6 settings in /etc/pihole/pihole-FTL.conf.
  • Show automatically generated DNSSEC queries
    After each restart of pihole-FTL, there will be a high number of DNSSEC-related queries (DNSKEY and DS) as the DNSSEC chain of trust needs to build for all domains queried in your network. The number of queries will quickly drop afterwards when the chain has been primed with all the top-level domains you are typically visiting. You should then only rarely see a DS query when visiting an altogether new webpage. To ensure this new information is valuable for you, we will sketch how DNSSEC validation works in another upcoming blog post. If you dont want to see these queries, you can easily set SHOW_DNSSEC=false in /etc/pihole/pihole-FTL.conf to suppress analyzing them altogether (they will still be happening in the background).
  • Update embedded SQLite engine to version 3.36
    1. Improvement to the EXPLAIN QUERY PLAN output to make it easier to understand.
    2. Byte-order marks at the start of a token are skipped as if they were whitespace.
    3. An error is raised on any attempt to access the rowid of a VIEW or subquery. Formerly, the rowid of a VIEW would be indeterminate and often would be NULL.
    4. The memdb VFS now allows the same in-memory database to be shared among multiple database connections in the same process as long as the database name begins with /.
    5. Back out the EXISTS-to-IN optimization (item 8b in the SQLite 3.35.0 change log 1) as it was found to slow down queries more often than speed them up.
    6. Improve the constant-propagation optimization 1 so that it works on non-join queries.
    7. The REGEXP extension 2 is now included in CLI builds (use pihole-FTL sqlite in your terminal to access the embedded SQLite engine).
  • Enable .recover option for embedded SQLite engine
    Exemplary use to repair a corrupted long-term database:
    pihole-FTL /etc/pihole/pihole-FTL.db ".recover" | pihole-FTL ~/pihole-FTL_recovered.db
    On success, the old database can be replaced by the repaired one.
  • Fix dnsmasq --server option interpretation (fix sent and accepted upstream)
  • Allow users to configure how FTL reacts to queries when the gravity database is not available (REPLY_WHEN_BUSY option )
  • Rate-limiting events are shown in the Pi-hole diagnosis system so you get notified on the web dashboard if any of your clients is rate-limited
  • Also display DNSSEC status of cache replies and internally generated DNSSEC-related queries
  • Add new regex extension ;reply=... to force specific replies on regex match
  • Other changes and bugfixes
    • Improve reliability under heavy TCP query load
    • Log when listening on the wildcard address. This will help debugging edge-case setups.
    • Fix crash when bind-address is used.
    • Fix for incorrect (but harmless) FATAL: Trying to access query ID -1 errors messages in pihole-FTL.log
    • Show hostnames also for clients specified by MAC address
    • Improve warning messages for defect hwclocks
    • Delay startup of FTL earlier to avoid database importing issues with incorrectly configured fake-clocks (if applicable)
    • Add a new theme that can automatically switch to dark mode if used on the device
    • Enable PHP8 support for Debian/Ubuntu
    • Be explicit in IPv6 RA values
    • Don’t overwrite existing logrotate script
    • Less coloring in the Query Log to enhance clarity

Versienummer 5.4 / 5.6 / 5.9
Releasestatus Final
Website Pi-hole
Download https://github.com/pi-hole/pi-hole/releases/tag/v5.4
Licentietype GPL

Reacties (75)

75
75
59
2
0
4
Wijzig sortering
Wil FTL bij mij niet updaten met commando pihole -up. :|
krijg ook de mededeling voor FTL:


Error: Unable to update package cache. Please try "sudo apt-get update"
Unable to complete update, please contact Pi-hole Support
Bij updaten check pihole of er updates zijn voor je base System. Met sudo apt update && sudo apt upgrade -y zal je systeem ook ge-update worden.

Probeer daarna pihole -up

Mogelijk zal hij dan wel updaten.
Heb dit gedaan en nog een reboot, maar geeft aan:
[i] Checking for updates...
[i] Pi-hole Core: up to date
[i] Web Interface: up to date
[i] FTL: update available

[i] FTL out of date, it will be updated by the installer.
Backup maken van je pihole en pihole -r draaien? Anders pihole install script op nieuw draaien??
Duurde even, maar updaten is op deze manier gelukt, thnx.
Om je systeem automagisch up to date te houden (zeker voor security updates), doe je:
apt update
apt -y install unattended-upgrades
dpkg-reconfigure unattended-upgrades
Yes: dit werkt. Dank.
Bij mij alle drie net voorzien van laatste update
waarom gebruik je er 3? zou toch denken dat eentje gnoeg is...
Vorige week heb ik zelf kunnen ervaren dat het geen overbodige luxe is om ten minste twee piholes te gebruiken.

Tijdens het updaten van de pi zelf ging een en ander mis, waardoor die niet met up kwam. Op dat moment werden dus geen DNS queries verwerkt. En omdat ik via mijn openwrt alle (externe) destinations maar poort 53 deed doorsturen naar de pihole, kon ik niet lokaal even een eigen DNS instellen, maar moest dat op de openwrt gebeuren (die zelf even problemen gaf omdat Chrome me niet wilde laten verbinden vanwege het Self Signed Certificate wat niet werd vertrouwd) 8)7

Redundantie is geen overbodige luxe. De load kon die ene pihole (op een pi2) overigens makkelijk aan.

(edit : typo)

[Reactie gewijzigd door Patrickske op 23 juli 2024 05:46]

Tip: pas je firewall regel aan dat hij alleen alles doorstuurt die niet naar één van je twee installaties gaan. Dan kan je, mocht het nog is misgaan, gewoon op je apparaat zelf de andere instellen.
Ik wil ook dat wanneer iets of iemand bijvoorbeeld 8.8.8.8 als dns gebruikt, deze toch via de pihole gaat. Via ip masquerade doet mijn fw een forward naar een ander vlan adres, waardoor de response op de clients helemaal valid is, en afkomstig lijkt van de 8.8.8.8 server.... echter stiekem komt ie wel degelijk vandaan mijn piholes.

Hiermee vang ik nog een groot aantal requested af die anders direct naar buiten gingen.
Maar met een masquerade verlies je je bron-info. Dat is ook bedoeld voor naar het het grote boze web. Je kan beter een ip forward doen:

Dus als dst-port = 53 en (dst-ip niet gelijk is aan 192.168.1.20 of 192.168.1.30) en (src-ip niet gelijk is aan 192.168.1.20 of 192.168.1.30) forward naar 192.168.1.20

Edit:
Met een masquerade verlies je dus je bron-info, waardoor de logging op je pi-holes alle verkeer vanaf de router/gateway zien.
Door een ip-forward te gebruiken, behoud je je source-adres en kan je dus nog zien wie wat heeft gevraagd. Een ip-forward is ook 'sneller' dan een masquerade (voor zover je dat effectief zal merken). Het enige nadeel is dat (afhankelijk van hoe je je netwerk hebt opgezet) je mogelijk voor ieder VLAN een regel moet opzetten, maar dat is een eenmalig iets natuurlijk.

Stel dat je ipv Pi-Hole, AdGuard Home gebruikt, dan kan je zonder extra software ook gebruik maken van DoH-servers van bijvoorbeeld Cloudflare. Dit maakt je firewall regel dan weer wat makkelijker, omdat je dan je source-adres niet meer van belang is voor port 53 (aangezien je AGH-server over poort 443 naar bijvoorbeeld CloudFlare gaat).

(je kan natuurlijk ook nog een stuk software installeren als DoH-proxy, maar dan heb je dus extra bloat/overhead naast je dnsmasq, webserver, php-installatie, die je al van pi-hole hebt. AGH, is één binary, met één config-bestand en ondersteund out of the box DoH, DoT, enz. zowel binnen als buiten je netwerk, en kan verder qua filtering in grote lijnen hetzelfde als pi-hole. Ik heb dit zelf draaien en heb dus in m'n eigen LAN ook een DoH server voor de software die het ondersteund)

Edit2: Bijvoorbeeld.

ipset 'dns-serverset' bevat de ip-adressen van je DNS-servers (pi-holes in jouw geval)
iptables -A PREROUTING -i eth1.100 -p tcp -m set ! --match-set dns-serverset src -m udp --dport 53 -m set ! --match-set dns-serverset dst -m comment --comment "DNS vlan 100 onderscheppen" -j DNAT --to-destination 192.168.20.15:53

[Reactie gewijzigd door lenwar op 23 juli 2024 05:46]

Klinkt interessant, heb je hier een handleiding voor? Ik ben geen netwerk engineer en heb geen praktijkervaring met vlans, ik ken alleen de theorie.
Ik heb een dd image van het PiHole SD kaartje op mijn NAS staan.

dd if=/dev/mmcblk of=/nas/BACKUPS/pihole-$DATE.img status=progress
Een tweede Pihole docker container die pas aan gaat wanneer de andere niet meer bereikbaar is. Mét een docker container 'docker-pihole-sync' die alles up-to-date houdt.

Dit middels een ping check en html check
state=$(curl -s https://${target}:${target_prt}/admin/ | grep offline)
Ja dat ervaarde ik ook vaak, erg vervelend. Draaide hem al snel in een docker (op een pi4) om het upgraden makkelijker en minder fout gevoelig te laten verlopen. Nu in een docker op Unraid en wat een verademing!
ik zou eens kijken naar unraid en dockers. kan je zoveel pis draaien als je wilt...
-Syncing
-Redundantie
-HA
-Omdat het kan :)
Redundantie en HA is dan natuurlijk een beetje dubbelop.
Kijk ik heb er ook 3. Redundantie. Overigens heeft de 3e speciale functie, die zit in de dmz, waar ook mijn demo netwerk op uit komt.
Net ook de upgrade gedaan en gaat hier goed.

[i] The install log is located at: /etc/pihole/install.log
Update Complete!

Current Pi-hole version is v5.4
Current AdminLTE version is v5.6
Current FTL version is v5.9


Even in de log kijken waarom het fout gaat.
hier ook, 2 hier thuis en eentje bij een vriend van me, geen enkel probleem gehad met de update
Kan je dit gebruiken met een telenet router? Quick google zegt dat je geen dns server kan instellen.
Dan stel je de dns op je apparaten in toch? En als je wel dhcp in kan stellen laat je je pi ook dhcpserver spelen.
Dan stel je de dns op je apparaten in toch?
Een thuisnetwerkje van tegenwoordig heeft te veel toestellen om dit te doen. De tijd van 1 á 2 desktops/laptops per woning is allang voorbij. In het merendeel van de thuisnetwerken vind je een combinatie van meerdere desktops/laptops, smartphones, tablets, mediatoestellen, gameconsoles, 'slimme' apparaten,...

Het is een heel karwei om in elk toestel met verschillende OS'en, interfaces en skins alles te gaan instellen, laat staan van gast toestellen van vrienden en familie die op bezoek komen. Hier tel ik al snel 24+ toestellen in mijn netwerk. Wanneer er iets veranderd in je configuratie of er gaat iets fout kan je elk toestel ook opnieuw afgaan om het te fixen.

Ik zou sterk afraden om het per apparaat te doen en toch zoeken naar op oplossing om het netwerk-breed af te handelen.
Ja, uiteraard, maar dan moet je er dus een router bij zetten waar je wel DNS/DHCP in kunt stellen.
Ja, ik gebruik dit zelf ook op een Telenet router. Enige "nadeel" is dat je zelf dus op je apparaten je DNS moet aanpassen, dat lijkt me opzich niet zo een probleem. Meeste apparaten zijn standaard aanwezig in je netwerk en die dat niet standaard aanwezig zijn hebben geen baat aan je pi hole denk ik.
Je eigen router gebruiken en die in bridged modus plaatsen. Dan krijgt je eigen router een publiek IP en kan je hier alles in gaan configureren en heb je mijntelenet niet meer nodig. En dan kan je het allemaal regelen via je eigen router.
DHCP uitzetten op de router en DHCP aanzetten in PI hole. Google anders even op DNS Ziggo. Die router heeft hetzelfde probleem en daar wordt de workaround uitgelegd.
Dan moet je aangeven dat de Pi de DHCP-server is.
Als je dat kunt, kun je denk ik ook wel de router laten DHCP-en en aangeven dat de PI je DNS-server is.

Op mijn Ziggo-ding geef ik aan dat het Pi-adres moet worden doorgegeven via DHCP. Werkt prima.
De eigen netgear router heeft dat ook. Na heel veel heen en weer gerotzooi ben ik uiteindelijk maar over gegaan om op de netgear de DHCP uit te schakelen en over te stappen op DHCP van de pihole. Werkt prima.
Je eigen router gebruiken en die in bridged modus plaatsen. Dan krijgt je eigen router een publiek IP en kan je hier alles in gaan configureren en heb je mijntelenet niet meer nodig :)
Je kan je Telenet modem/router gratis omruilen voor een modem only en er je eigen router achter hangen. Althans vroeger kon dat, zit nu al enkele jaren bij edpnet.
Het is geen modem only model meer, het is een model met MAC bridging (onlangs nog voor gehoord).
Dan denk ik dat je fout bent. Ik heb vorige week mijn telenet router binnengebracht en overgegaan op modem only, en dat is ook werkelijk modem only. Telenet maakt er vaak een gewoonte van om dingen te zeggen die niet kloppen :-)
Eigenaardig! Toen ik hiernaar vroeg was het niet meer mogelijk om een modem-only modem te krijgen omdat dit niet meer ondersteund wordt op de laatste DOCSIS 3 modellen, enkel MAC bridging!
Heb hier hetzelfde antwoord gekregen. Maar op mijn werk waar we een business abbo hebben was het geen probleem en kregen we direct een modem-only.
Hmm, had dit nogtans als business klant aan de busineds helpdesk gevraagd. Zal het eens moeten proberen om een modem only model te krijgen :+ liever dat dan mac passtrough
ik gebruik nu thuis de passthrough mac optie en het werkt echt zeer goed. Ik heb nu zelfs 2 public IPs als ik wil ;D
Een tip voor mensen:

Ik heb op mijn PI een andere DNS server ingesteld (Cloudflare 1.1.1.1). Dit heb ik gedaan zodat wanneer Pi-Hole update er geen DNS issues zijn op de PI zelf.
Tevens wordt dit ook aangeraden door de dev's.
Beter 1.1.1.2 en 1.0.0.2 gebruiken :)
Waarom?

Ah, blijkbaar zijn 1.1.1.2 en 1.0.0.2 (beide ook van Cloudflare) bedoeld voor het blocken van Malware. Dan krijg je dus waarschijnlijk een soort extra PiHole, die geconfigureerd wordt door Cloudflare: https://developers.cloudf....1.1/1.1.1.1-for-families

Of dat echt "beter" is, weet ik niet, maar het is handig om te weten, I guess.

[Reactie gewijzigd door Kjoe_Ljan op 23 juli 2024 05:46]

1.1.1.2 & 1.0.0.2:
-> Malware Blocking Only
Change your router DNS to:
1.1.1.2
1.0.0.2

-> Malware and Adult Content Blocking Together
Change your router DNS to:
1.1.1.3
1.0.0.3
Ik heb er nooit eerder bij nagedacht om het zo te doen, maar er is natuurlijk wel wat voor te zeggen.

Je legt je vertrouwen in een stuk software dat met het internet praat en heel je netwerk van DNS-antwoorden voorziet. Als om welke reden dan ook je vertrouwde raspberrypi-besturingssysteem is geraakt door malware (en aangezien heel weinig mensen een virusscanner op Linux gebruiken is de kans zeker niet uit te sluiten dat als dat gebeurd je er pas heel laat achter komt), en daarmee dus je DNS-verzoeken voor de rest van je netwerk niet meer betrouwbaar zijn, dan hang je wel natuurlijk. Dan kan je dus beter de kans verkleinen dat je besturingssysteem geraakt wordt en dus die beschermende DNS-servers gebruiken van bijvoorbeeld Cloudflare (of één van al die andere natuurlijk))

Dit is een beetje inherent aan het open karakter van DNS. Je computer kan niet controleren of het antwoord dat hij ontvangt daadwerkelijk afkomt van je pi-hole, aangezien dit 'slechts' DNS is en geen controle heeft in je netwerk. Als je bijvoorbeeld intern een DoH-server gebruikt (zoals Adguard Home of een andere tool), weet je in elk geval zeker dat het antwoord daadwerkelijk van AdGuard Home af komt. (aangezien het dan is ondertekend met een TLS-certificaat).


(( Disclaimer: Bovenstaade is natuurlijk puur theoretisch. Als de malware al zo ver is dat het je pi-hole-verkeer kan onderscheppen, dan zou het in principe kunnen proberen de TLS-sleutel van de DoH-server te gebruiken, al is dat wel wat complexer ))
Dit wilde ik ook doen. Maar werd afgeraden omdat je nooit kan weten welke na een cliënt kiest. Dat hoeft namelijk niet standaard eerst de eerste te zijn waardoor je pi hole minder effectief werkt.
De DNS instellen in de OS van de Pi. Het zal helemaal los staan van Pi-Hole aangezien je in Pi-Hole apart een DNS insteld.

Voer command: sudo nano /etc/dhcpcd.conf
Voeg lijn toe (indien niet beschikbaar) static domain_name_servers=DNS1 DNS2
Voer command: sudo service dhcpcd restart

Als je namelijk geen static domain_name_servers ingesteld hebt dan vraag de Pi, de router om DNS en die zal dan de Pi-Hole DNS geven (mits correct ingesteld en niet per client handmatig).
Hierdoor kom je in een loop. Als je Pi-Hole uitvalt, heb geen DNS op je Pi ;-)

[Reactie gewijzigd door Joao op 23 juli 2024 05:46]

excuses, ik had het verkeerd begrepen.

maar dit is volgens mij de default want ik kan me niet herinneren dit ooit te hebben aangepast. Alhoewel mijn installatie al weer een paar jaar oud is natuurlijk.
interface wlan0
static ip_address=192.168.178.10/24
static routers=192.168.178.1
static domain_name_servers=1.1.1.1
Dit staat inderdaad correct :-)
Zoals @Joao zegt, als je dat doet ben je niet zeker welke DNS server Pi-Hole gebruikt, als je bedoelt dat je in de PI-Hole Admin webpage een andere server instelt.
Als je bedoelt in de instellingen van het OS, dan kan het wel nuttig zijn eventueel...
weet iemand hoe je de pihole-ftl.db tot een maximale bestand grote kan instellen.
Ik moet af en toe mijn pihole-ftl.db file removen omdat anders het hele zwikkie is 'vastgelopen'. Resulteert in geen internet verbinding willen maken en domoticz laadt dan niet meer.
Vroeger was dat eens per half jaar maar nou moet ik het wat te vaak doen.
bestandsgrootte is bij mijn weten niet mogelijk, wel kan je het aantal dagen dat de DB data vezamelt wijzigen. Default is 365 (een jaar dus), ik gebruik al sinds de setting beschikbaar is 8 dagen. zie hier voor deze en andere settings.
Dus MAXDBDAYS=8 toevoegen aan /etc/pihole/pihole-FTL.conf, daarna sudo service pihole-FTL restart.
Tnx,
Heb het nu op 20 dagen gezet. Zal eens zien of dat het probleem verhelpt.
Kijk hier eens: https://docs.pi-hole.net/ftldns/dns-cache/

Je kan een maximale size opgeven voor je caching. Dat zou je probleem moeten verhelpen. Alternatief is een cronjob die elke X uur/dagen die .db file weg gooit.
Updates zijn hier ook succesvol:
Pi-hole draaiend op:
- Synology nas via docker (portainer)
- Unifi UDM via podman
Kan de UDM containers draaien? Dat is handig.
Toch maar eens kijken naar een upgrade.
Niet standaard maar je kunt het wel op deze manier doen:

https://github.com/boostchicken/udm-utilities

Unifi firmware upgrade proof
Mijn tweaker hart gaat sneller kloppen <3 Thanks!
Wat ik hier niet meteen zie staan in de changelog is support voor Debian 11 aka Bullseye. Misschien handig om te weten voor sommigen.
Het werkt wel op deb11 het probleem was altijd geen support voor php8 en nu dat wel is werkt het als het goed is gewoon
Weet iemand een goede handleiding voor Pi-hole op Synology NAS? Kreeg het prima aan de gang
maar na het updaten stopte de service. Moet er iets meer induiken maar kon weinig goede ''how to''
vinden. Gezien het veelvuldige gebruik zal er vast wel iets zijn.
Ik heb dit gebruikt : https://www.synology-foru...er-via-dns-(handleiding)/
Draait op een DS214 die ook DHCP server is
Ik heb net 2 Pi-Hole instances geüpdatet.
- 1x op Ubuntu middels “pihole -up”
- 1x op een Synology Docker image

Beide gingen goed en ik merk dat de interface van beiden wat vlotter draait.

Pi-Hole is erg nuttige en goede software.

Ik gebruik trouwens de host list van oisd.nl
Waar kan men info vinden hoe men er 2 of 3 in sync/fail over moet zetten aub?
mijn pi 1 heeft het zwaar nu :(
Hoezo?
Ik draai op een Pi Zero en die draait Pi-Hole zonder te zweten (nu 7% CPU belasting in totaal, 14% geheugen totaal).
Klinkt alsof er iets anders draait of er iets aan de hand is misschien?
HMM oke tijd voor herinstallatie
Ik weet niet welk OS je draait, maar als je toch herbegint kan je misschien DietPI overwegen. Dat is eigenlijk Raspberry Pi OS Lite met wat extra scripts overheen. Draait hier als een zonnetje en de developers zijn ook actief in de Pi-Hole community (MichaIg bvb).

Als je je settings niet kwijt wil geraken, kan je een export doen met Teleporter.
ik gebruik ook DietPi, werkt inderdaad goed.
Hoe werkt die laatste zin van je comment (Teleporter) dan aub?
Met Teleporter maak je een backup van je Pi-hole configuration (settings & lists) naar een tar.gz bestand. Deze kun je op een andere machine weer inlezen.

Je vind deze onder Settings / tab Telporter
De systeem-update op mijn RPi-1 ging wat vreemd vanwege vermeend ruimtegebrek, dus heb ik wat gezipte logbestanden weggehaald. De pihole update zelf ging echter vlotjes.

Op dit item kan niet meer gereageerd worden.