Created an Ansible playbook to automate the installation of Pi-hole and configure the add block repos, configure fine-tune nftables, performance optimization using unbound DNS, and a few kernel parameters.
Please review this and give your feedback
GitHub repo link:
I don't see the advantage, sorry.
While automating things is generally a good idea, configuring a system for Pi-hole and unbound heavily would depend on actual system parameters as well as user preferences.
This would apply in particular (but not limited to) to your personal choice of adlists.
Your ansible playbooks may match your personal preferences, but it's highly likely it won't be applicable for others.
Also, installing Pi-hole is a one-time job.
You'd probably run a Pi-hole system for years after, and by the time you may opt for a clean installation, your ansible playbooks may suffer from a fair bit of rot, so you may not be able to run them anymore.
On top of that, your playbooks are making some questionable choices which are bound to cause issues.
As far as I can tell after a quick browse, they won't run on all systems supported by Pi-hole, as they are making use of apt only as package manager, disregarding rpm/dnf/yum.
They are blindly setting kernel options that are not required for Pi-hole's operation, and may actually lower some values on systems, or are best left untouched altogether.
By setting values explicitly, you are also preventing the system from picking sane values based on its actual environment itself.
Similar happens for unbound, where increasing cache sizes to 150 MB (up to 25 times from the default) may cause swapping on memory constrained systems if actually used (I run Pi-hole on a 256M system).
Interfering with minimum TTLs may have a detrimental effect on Pi-hole's cache optimisers, potentially resulting in resolution issues and/or clients to use outdated information for longer than necessary.
Both Pi-hole and unbound have better methods of reducing client latency for expired records, and both of those may be negatively affected by fiddling with minimum TTLs.
It also unnecessarily shifts responsibility for updating root hints from the package manager to the user, by manually downloading and installing them into a custom location.
Also, the current playbook is introducing a logrotate for some of Pi-hole's log files which would conflict with Pi-hole's own logrotate configurations.
It would also wipe Pi-hole's cache once a day, which I wouldn't consider an optimisation.
The nftables rules set may interfere with different firewall packages on a system as installed by a user.
It's also using a fixed range of ports, which may ruin user configurations that run additional services next to their Pi-hole, and if you'd e.g. opt to move your webserver to port 8081, you'd have to remember to update nftables rules yourself.
In their current form, I'd advise other users against using the playbooks, as they may negatively affect your Pi-hole experience, and neither would they lend themselves for use as a template, for a lack of comments on why a specific parameter is used and how it is intended to affect/improve default behaviour.
I am new to Pi-hole, and please suggest what the issues in with this playbook and what things are not required.
Why did I create this?
I had an issue with the SD card in my Raspberry Pi, and recreating pihole environment took good amount of time. Hence I felt it might be good to have this sort of automation
In case you want me to add or drop something, please do let me know. I will change the playbook accordingly.
But I strongly feel that having some sort of automation is very useful, and storing configuration in a central repo makes a lot of difference when debugging and recovering from a crash. Again, it is my humble opinion.
Related to adlist:
Completely changed and refactored. Dropped all suggested improvements
Please feel free to suggest further improvements!
Just keep using your playbook as it is (with the exception of conflicting logrotates and wiping Pi-hole's cache once a day, perhaps).
Like I said, automating things is generally a good idea.
And as long as the playbook is working for you, there would be no need to remove things like unbound or nftables for it.
But your playbook is tightly coupled to your specific Pi-hole setup - the result of a range of personal choices. And one size doesn't fit all: Considering to offer this as some kind of service to try for others would require quite some additional effort.
Chances are that your configuration would not produce the same wanted outcome for users on different systems with different preferences.
Trying to cater for those would be a complex endeavour that would entail to either include interactive choices or to mark options to be adopted by users according to their preferences, and to comment them sufficiently enough to facilitate such choices.
Picking sane defaults that would work across different systems could also prove challenging, as would safeguarding installation scripts, e.g. by denying installation on unsupported OSs or configurations.