Since upgrading to Pihole v6 I have run into quite a few issues. I would ask for a feature request but I am not allowed to. I am asking for a way to disconnect my Pihole v6 from the new (in lack of a better description) auto-repair features.
I run with custom dynamic lists that I update daily (i.e. Threatfox IoC's). Wanting these lists in the /etc/pihole folder for tidyness needs me to run a RBAC script after each pihole -up, as pihole -up resets all file permissions inside the /etc/pihole folder. Allowing a folder to retain access rights inside the /etc/pihole folder would be nice, such as /etc/pihole/custom_lists/custom_list.
While on that topic of resetting to default, it is quite inconvenient to have Local DNS entries, DNS upstream, Binding Interface, DNSSEC and Conditional Forwarding forced to reside in the pihole.toml, especially since that file has proven to be quite volatile to changes during updates. More than once the pihole -up command has reset my whole pihole.toml configuration file leading to DNS breakdown in my environment. Adding in customization here is crucial, think /etc/pihole/pihole.toml.d/custom.toml.
The dynamics between Pihole v6 and Unbound also seem to have changed a bit where I have been forced to create a custom systemd override configuration to be able to control max concurrent sessions. I understand Pihole and Unbound are two completely different products with no promises in between, but in reality a lot of setups rely on both to collaborate well.
I also understand my predicaments might be unusual compared to the every day install. You have added a lot of nice features into Pihole v6, all I am asking for is a true expert mode that can be enabled for us who believe us to be experts. It is great that the default mode is heavily standardized.
What prevents you from creating those files with matching permissions straight away?
pihole-FTL would honor your manual changes to pihole.toml, leaving them untouched during upgrades.
It only would fall back to create it with default contents if it fails to find or access pihole.toml.
What has prompted you to do so?
Did you perhaps upgrade from a pre-Bullseye to a new OS release only recently?
Pi-hole's upstream handling hasn't changed with v6, but you may see new warning message types that haven't been logged by v5, and pihole-FTL/dnsmasq introduced mIxEd case/0x20 encoding to be active by default, which may need to be disabled with certain upstreams (I'll add that my own unbound instance runs fine with that default).
Thank you Bucking_Horn for taking your time going through my whole post.
I have disabled all scheduled tasks in /etc/cron.d/pihole and will do very controlled manual updates in the future. I also run scheduled custom scripts to ensure access rights and other important settings stay intact. So from a practical standpoint I'm all good.
My threatfox script do set permissions of the /etc/pihole/custom-threatfox.list right -> pihole:pihole -rw-r--r-- but "pihole -up" or one of the other cron tasks resets it back to -rw-r----- that renders a read/access error when running "pihole -g".
Regarding Unbound I am likely wrong and it is me who cannot grasp how the FTL fits together with dnsmasq and any upstream DNS service. I try to set a higher rate limit to avoid alerts, rate limiting, etc. But even though I have set dns.rateLimit.count to 10000, and my systemd service override (PIHOLE_MAXCONCURRENT=1000) I still get the alerts in Pihole (Maximum number of concurrent DNS queries reached (max: 150)). I will deep dive into this when there's more time.
Thanks again, and my asking of the optional custom settings files remain. The vanilla Pihole can remain fully automated for those who do not require 100% uptime and reliability.
Those are all dnsmasq options. You could tell Pi-hole to load custom configs from /etc/dnsmasq.d/ and place a custom config with the desired options in there.
Yes I have dug down the path of resolvconf.conf although I run one instance on a clean installed Debian 12.9 and one on a clean installed Armbian 24.8.2.
I can live with the errors as it seems to have little practical impact.
Oh okay, I need to dig deeper into the Pihole 6 documentation then. I was under the impression all configuration was originating from pihole.toml now and force overwritten to every other needed supporting folders and files.
