Background:
I already got one Pi-hole node deployed on my RPi that's serving double-duty as a GPS-based NTP server (Raspbian). That went generally without a hitch, and I decided to deploy Pi-hole on a VM on my network for redundancy's sake. The VM in question is CentOS 7.5.1804 (core) on ESXi, and also serves as the network DHCP and authoritative DNS.
First off, I know I'm an outlier in this situation. The majority of your users are likely not installing on infrastructure that's already tightly integrated into a network. I'm also not sure if this counts as a bug or a feature [request]. (haha programmer jokes ok I'm done)
When I tried to install Pi-hole on this server, I got:
[i] Using interface: ens160.2
[i] Using [i] Your static IPv4 address: 10.0.1.1/27
[i] Your static IPv4 gateway: 10.0.1.30
[i] Warning: Unable to locate configuration file to set static IPv4 address
From perusing the install script, this appears to happen because it attempts to find a file named ifcfg-${PIHOLE_INTERFACE} where ${PIHOLE_INTERFACE} is the OS name of the NIC/VLAN. Unfortunately this file does not exist in this form on my system.
For the use of the DHCP server, the CentOS server has 5 VLANs configured. The VLANs were configured with NetworkManager, and I named them so that I wouldn't have to keep referencing the Excel Spreadsheet of IPs to decode VLAN IDs. Note here, eth_base is simply the parent NIC and has no IP information.
So, for the interface I want to use Pi-hole on (SaS), the file is actually named ifcfg-SaS not ifcfg-ens160.2.
Feature request: (sort of, because I plan on working on this):
I have a few options to solve this problem:
- Comment out the IPv4 address configuration and ignore my problems
- Add a detection algorithm to handle configurations of NetworkManager where the interfaces are named
- Add a screen before IPv4 configuration to query the user if they wish to configure IPv4 at this time.
I'm partial to option 3. I have source routing active on the interface in question, and I'd rather not have Pi-hole messing with a config file it was not designed to deal with (I already backed the config file up so I could diff/revert it as soon as Pi-hole was installed). As a sysadmin, I'm OK with this since it allows me to configure the server NICs as I please, and it would allow manual overrides in the case of a new system Pi-hole encounters issues with.
My question is this: from a Pi-hole development perspective, where would my energy better be placed between 2 and 3? Both seem doable and have their own caveats. I took a look through github to track down related bugs for this, and I've found enough bugs on both sides of the wire I'd like a more official statement.
Part of my reading included a few bugs and discussions about making Pi-hole less reliant on dhcpcd for use on non-Raspbian systems. I think both of these fall under that effort?