But the current Pi-hole v5 installer errors out when it finds any override config, hence this will break pihole -up for now... I hope I can convince everyone to drop that behaviour, as we have an exact fine reason here to use them .EDIT: Ah nope sorry, this has not been merged: Full systemd support by Kiskae · Pull Request #2900 · pi-hole/pi-hole · GitHub So no issue at all with the above override config .
And the iptables forwarding rules are required for VPN clients to access anything else then the VPN server itself (local network or internet). If indeed the VPN is only to enable Pi-hole for mobile clients, then indeed those rules can and should be dropped, same for sysctl net.ipv4.ip_forward which is as well not required then.
You could also just create a new file like 02-wireguard.conf in /etc/dnsmasq.d/ with interface=wg0.
This worked for me to sustain a reboot and have pihole to listen on eth0 and wg0 with the setting Listen all interfaces (not Listen on all interfaces, permit all origins)
Dirty fix. The problem with such unconditional delays is that one can never be sure that it is enough in every case and/or if it is unnecessary long in most cases. I would always go with a conditional delay, so things start as fast as possible but as late as required. But great for inexperienced users who simply need to get things working quickly .
Posted above for this particular case: Have to "pihole restartdns" after reboot - #21 by MichaIng
However indeed reasons to delay pihole-FTL for and service handlers/init system can vary, so I cannot imagine any Pi-hole provided solution for this, without adding a tons of checks and options.
The service could contain Required-Start: $network, probably there is even an equivalent for the systemd network-online.target (not supported on older systemd version, e.g. Debian Jessie). But neither network.target nor network-online.target guarantee that all network interfaces have been fully configured.
So while the above could reduce the chance for such issue slightly, it is finally something that the admin needs to add manually if required for the particular network setup.
Nothing I can think of. You can try to implement all possible solutions, or a GUI for service ordering based on init system. But in special cases there will be always individual solutions required, not everything is, can be or even should be under control of Pi-hole, IMO.
"dirty fix" btw does not mean that I dislike the implementation. As said it is great to get things working quickly. It is just not something that I would keep as long-term solution for my server, for the mentioned reasons.
.
.