So... Is this still out of the scope of the project?
Currently, yes. There are no plans to include any high-availability features from our side. But as always, we're up for external contributions.
We're working hard on Pi-hole v6 which will offer a completely new API. One of the features is the ability to up/download a teleporter archive remotely. This could simplify a high availability setup dramatically.
As a proof-of-concept I wrote a bash script "syncing" a main Pi-hole to a secondary one. Nothing needs to be installed, just run the script from any computer which can reach both v6 APIs.
Don't run this script in production as it will restore the full teleporter backup to the secondary Pi-hole, overwriting all previous settings.
As always: external scripts should not be discussed here, use the linked github repo.
6 Likes
In the meantime, what about a "medium" availability? An entry in the admin interface where you can add the IP of another pihole on the network and then once saved, the first pihole confirms that the second pihole exists and is a pihole.
Then if you're using the first pihole for DHCP, it can add the second pihole to the list of DNS servers for you instead of having to go into the DNS masq config files yourself. (not sure if the vmstan's gravity-sync script already does this, I just learned about it today)
2 Likes
Ultimately, the solution I would like to see is this:
- A feature in the Web UI where you can enter an IP and a Key for another PiHole instance
- By adding the other PiHole's IP and Keys, the two devices would trust each other
- With this trust, the devices would automatically sync, and advertise each other via DHCP
This would allow for easy implementation of redundant instances, possibly across multiple platforms - i.e. one in Docker, one running on a Raspberry Pi. If the Docker Host is rebooted, the Pi can keep chugging, and if the Pi has issues, the Docker instance can pick up the slack.