I would like to contribute a new feature to pi-hole, but I'm struggling to figure out the best practice for developing it. Specifically, I want to add something to the web interface that plumbs through to the dnsmasq configuration, so it involves both the AdminLTE package and the pi-hole one, and while I can read the code I want to change, I'm not sure what the best practice is for setting up a complete pi-hole development stack to test out my theory.
What's the best way to have an entire pi-hole running on my laptop in such a way as to allow me to test these changes?
A regular installation of Pi-hole gives you everything you need.
AdminLTE will be in /var/www/html/admin
Pi-hole core will be in /etc/.pihole
FTL is installed as a pre-compiled binary for the sake of convenience, you'd have to clone the repo separately if you want to develop FTL.
There is no developers guide. We can, however, discuss everything here and give some guidance for a specific implementation. Please note that we're slowly phasing out the current web interface in favor of a rewrite.
This will also move all dnsmasq related file manipulation from the core into a dedicated API.
Everything that would be added to AdminLTE currently needs to be submitted to the new web interface as well. Otherwise, this would put the burden of porting yet another feature to us which will inevitably result in a general slowdown of the process.
So, the best way seems to be to add the feature to the new web interface + API right away to avoid doubling the amount of work that needs to be done.
Cool. I'm happy to talk specifics. I'm looking specifically at plumbing through the ability to tag DHCP clients so that some of them are assigned DNS servers that are not the pi-hole, which will allow per-client bypassing of the pi-hole. I have a few clients in my network whose behaviour on the black hole turned out to be problematic, and I want to correct for that.
I believe I understand the gist of it -- I plan to base the eventual work off of this post on the subject -- but before committing to the patch, my plan had been to tweak my existing pi-hole to do it that way already.
If I'm wildly off track, that'd be good to know now
The obvious way of implementing this seems to be as simple as a checkbox just called "Bypass Pi-hole" inside the "static DHCP leases" table. If the box is ticked, we add the corresponding tag lines for this client. As destination DNS server, we should just copy the ones we use for upstream as well.
You may still want to see them behind a Pi-hole, however, behind a second one with a less strict blocking list?
Maybe. I think "bypass" would be a simpler concept to suggest, first, but having the option of per-client blocking lists -- including, optionally, a "not-blocking-at-all" list -- would also suffice.
This is an often requested feature, however, it is technically not possible without sacrificing the performance (both memory and response time) dramatically.
