Versie 6.0.5 van Pi-hole Core is uitgekomen. Ook zijn Pi-hole Web 6.0.2 en Pi-hole FTL 6.0.4 verschenen. 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 releasenotes voor deze uitgave kunnen hieronder worden gevonden.
Pi-hole FTL v6.0.4, Web v6.0.2 and Core v6.0.5 Released!As always, please read through the changelogs before updating with
pihole -up
. (A new tag for docker image will follow shortly!) Don’t forget, you can use Teleporter to export your configuration. It can be found under the settings menu of the web interface or on the command line withpihole-FTL --teleporter
Another busy week of ironing out some post-release bug fixes, details of which can be found below! We’ve actually pushed a couple of smaller releases out since the last post, so we’ve included those notes in this post, too.
Notable Changes/Fixes
High RAM / CPU Usage during Gravity runsDuring the development of Pi-hole v6.0, we followed a blog post describing that increasing the number of allowed workers as well as changing the default location for temporary objects from always-on-disk to always-in-memory is key to increased performance without doing any real measurements on this – at least it did not make things slower.
Nothing unexpected showed up during the extended v6.0 beta period but now we have #2194 and friends describing a massively increased memory and CPU usage on devices that were always on the edge of being still feasible for Pi-hole: Using millions of lists on devices that merely have 256 MB RAM for the entire system. See #2321 for details on how we have sought to fix these issues.
Webserver / Interface SlownessA number of users reported a sluggish interface, which we suggested a potential workaround for in the last post. When we first released V6, we set the number of threads the webserver used to a conservative
n -1
, wheren
is the number of CPU cores on the device running Pi-hole. What this resulted in, was devices with 2 core CPUs only being allocated 1 thread. The reason for this default was due to a few reports during the beta test of the webserver not only becoming unresponsive, but the entire system becoming locked up to the point of not even being able to SSH into it!With the help of a wider user base, and people making changes to the
Crashing on Synology Deviceswebserver.threads
setting on their devices, we have revaluated that default. PR #2305 sets the default number of threads to 50, and #2326 aims to prevent the webserver from taking over the system under heavy load.A number of users running on Synology devices have been unable to set a web interface password without the web server crashing. Thanks to everyone reporting this issue, we were able narrow it down to being due to issues with older kernels being built without support for
getRandom()
.
Fortunately, DL6ER is a wizard. #2300 fixes this by adding two fallback layers in cases where secure (hardware) randomness is not available.