[WIP] - removal of hard dependency on dhcpcd 5.

[PromoFaux]

Also remove static address setting of any kind, display message to user at the end of the script advising that they should set it as static.

Very much open to change on all of this, especially the wording of the final message. If this goes ahead, I'll tidy up the commits. @bcambl can you take a look over the dependency section for the non-debian part?

[bcambl]

There is no dependency on dhcpcd for the non-debian side.
Removal of the static ip configuration function (setIFCFG) should be enough.

[MichaIng]

Great step, many thanks for this, most non-Raspbian users will like it. Keep in mind to remove that part in the docs as well: https://github.com/pi-hole/docs/blob/master/docs/main/prerequisites.md#ip-addressing

[DL6ER]

Firstly: Yes. This is a good move.

Secondly: This change may easily cause the new number one support request when users set up Pi-hole. They install the enter-mashing way and - at the next restart - they may end up with a different IP and "Pi-hole broke the Internet". Or they set up Pi-hole as DHCP server and booting doesn't work because the device itself wants to get an IP address even before it's own DHCP server could hand out one (dnsmasq only does this when an interface is already up so it knows which IP range this interface is responsible for).

[DL6ER]

We should print this at least in bold-face. Maybe even in red.

[MichaIng]

Remember that it doubles already with the whiptail prompt at install start: https://github.com/pi-hole/pi-hole/blob/master/automated%20install/basic-install.sh#L654
But that is not necessarily a bad thing.
EDIT: Ah, saying "whiptail", not possible to apply text colour or style in whiptail, capital letter or such is the best we can do.

[dschaper]

Require positive acknowledgement of the conditions. ("Type P to confirm ")

[MichaIng]

Interactive action, more than just hitting "return" is probably the best if you worry about user locking out themselves from SSH access after reboot.

Instead of having two places where this info is prompted + interactive input, what about changing the msgbox from welcome dialogues into a yesno with "no" as default, so that an interactive switch to "yes" is required. The information/text that is added here could be moved into the whiptail as replacement, and then as question:

Do you acknowledge this information and configured your system accordingly?

If "no" is chosen (respectively return pressed), the installer could exit and print again the information to apply a static IP or IP reservation (if router stays DHCP server) before installing Pi-hole.

For unattended installs the new printf below could stay and there red colour and bold can be done as well.

[PromoFaux]

It would need to be in a whiptail, as we cannot wait for user input when piping the curled script to bash. (Unless we changed the install command to bash -c "$(curl -sSL http://install.pi-hole.net)" - but that's a bit more of a mouthful)

[PromoFaux]

I misread your comment.

I kind of like the idea of the first whiptail requiring a switch to yes from a defaulted no

[PromoFaux]

Sorry, been a while since I looked at this. What do we want to do RE:Removing/keeping the code that sets static via dhcpcd if it is detected?

[tmuehlhoff]

I have been installing PI-Hole on a Ubuntu Focal machine, and stumbled over that problem.

the install script installed dhcpcd5, my physical Ethernet interface received an additional IP via DHCP and the 5 VLANs got an additional LLC address (as there was no DHCP server on those VLANs).

My understanding is that Raspberry OS would in any case use dhcpcd5 to assign even static IPs ? That seems a bit strange to me. Given that we talk about a DNS server which should be (really!) static and it's IP should be existing before the DNS daemon ist started. I can imagine the installer checking which of the common network manager tools are installed and act accordingly (which could mean, act not at all as the network configuration could be in place already, just as in my case and just query which of the interfaces/bridges to use as DNS listener), OR apply the Raspberry OS default case.

In fact I had a VPN end point configured on that machine and Pi-Hole installer wanted to re-assign that VPN IP(!) to the machine, not taking multiple interfaces into consideration at all apparently.

I removed and hid dhcpcd5 from apt so that the installation would eventually succeed, but this is more a workaround. I think even though Pi-Hole comes from the Pi itself, it shouldn't limit itself.

I'm happy to discuss, even if I'm rather new to Pi-Hole and not "digging deep" in the code.
/Tomas

[MichaIng]

My understanding is that Raspberry OS would in any case use dhcpcd5 to assign even static IPs ? That seems a bit strange to me.

Indeed, the official RPi docs intend it that way: https://www.raspberrypi.org/documentation/configuration/tcpip/README.md
However, I agree that is is strange to use a DHCP client to disable DHCP. The basic ifupdown package with networking.service and udev rules is installed as well, reasonably, so that /etc/network/interfaces can be used to configure static interfaces and hotplug devices a way that is much more common on Debian and known on all Linux distros. However, there is even a GUI tool available around dhcpcd config from the RPi repository, so to not make that obsolete or require a rewrite, I guess things will stay like that.

But that is all not an issue of Pi-hole (following just the RPi-ways) and since Pi-hole officially supports a number of other distributions for a while, it totally makes sense to not force an RPi-way network setup that at least creates an overhead of even breaks other distros network setup 😉.

[bcambl]

Install on Fedora 33 succeeds with either a dhcp or static ip.
With that said, here are a few thoughts:

• I would dare to assume that most users will not configure a static ip and attempt to install using dhcp. Without a dhcp reservation configured, it is very likely that the ip of the server will change causing dns breakage. Perhaps there should be a check if the system is configured as dhcp and breaks out with a message much like how the script does for unsupported os along with an override variable to allow users to continue with dhcp. When a user chooses to install via dhcp, there should be a touch or a config update stating that the user opted to install with a dhcp ip and this should be reflected within the debug logs to assist with future support/troubleshooting.

• The second half of this text is no longer valid as the next section is now the upstream dns configuration. This dialogue could likely be removed and a new dhcp check added to break out of the install earlier much like the unsupported os logic to support my previous suggestion.
  

[MichaIng]

I would dare to assume that most users will not configure a static ip and attempt to install using dhcp.

I mean for using Pi-hole, one must configure either the router or the clients manually to use Pi-hole, hence its IP address for DNS resolution. I cannot really believe that more than literally a hand full users will enter a dynamically assigned IP address and then start wondering that DNS resolution fails after DHCP lease times out 🤔. And if such happens, then my only suggestion would be for that user(s) to stop administrating network services with such few basic knowledge, as the risk for major security breakage is simply too high... I'm joking 😄.

The issue still is that there are many ways (many tools, high-level as well as low-level) to setup the network, so any attempt to check for either DHCP or static IP being used will end up with the same issue as before: It will work for most systems but fail and mess with others, hence limit the flexibility/freedom for admins, like dhcpcd currently does in a way.

The second half of this text is no longer valid

See above the suggestion to remove this prompt, respectively merging it with the one that is newly added with this PR and an interactive yes/no selection which must be manually switched from "no" to "yes" to proceed with the install, as a hopefully sufficient reminder about the static/reserved IP topic: #3715 (comment)

[dschaper]

so any attempt to check for either DHCP

Latest version of Pi-hole debug process:

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   Timeout: 10 seconds
   
   * Received 300 bytes from eth0:192.168.88.2
     Offered IP address: 192.168.88.5
     Server IP address: N/A
     Relay-agent IP address: N/A
     DHCP options:
      Message type: DHCPOFFER (2)
      server-identifier: 192.168.88.2
      lease-time: 300 ( 5m )
      netmask: 255.255.255.0
      router: 192.168.88.2
      dns-server: 192.168.88.5
      hostname: "ubuntu"
         domain-name: "lan"
      --- end of options ---
    
   DHCP packets received on interface docker0: 0
   DHCP packets received on interface lo: 0
   DHCP packets received on interface wlan0: 0
   DHCP packets received on interface veth6272519: 0
   DHCP packets received on interface eth0: 1

[MichaIng]

Received 300 bytes from eth0:192.168.88.2

Are you sending out a DHCP request and catch answers? Indeed a smart way, if so (EDIT: I see: pihole-FTL dhcp-discover), although it does not tell you whether the system uses this existing DHCP server or not. I thought about checking for active or installed DHCP clients, but such a check across all supported distros would be a maintenance nightmare.

[dschaper]

Are you sending out a DHCP request and catch answers?

I'm not exactly sure what method Dom picked for the check but it should be fairly easy to see if the address returned in the lease offer matches an IP address on the interface.

*** [ DIAGNOSING ]: Networking
[✓] IPv4 address(es) bound to the eth0 interface:
   192.168.88.5/24 matches the IP found in /etc/pihole/setupVars.conf

[✓] IPv6 address(es) bound to the eth0 interface:
   fe80::c272:4e8d:5efa:ec68 does not match the IP found in /etc/pihole/setupVars.conf (https://discourse.pi-hole.net/t/use-ipv6-ula-addresses-for-pi-hole/2127)

   ^ Please note that you may have more than one IP address listed.
   As long as one of them is green, and it matches what is in /etc/pihole/setupVars.conf, there is no need for concern.

   The link to the FAQ is for an issue that sometimes occurs when the IPv6 address changes, which is why we check for it.

Offered IP address: 192.168.88.5

[deatharse]

Thank you for coming up with this. This change of removing static addressing will also allow local install on devices that often switch networks and subnets to continue work when IPs change (e.g. installing on a PinePhone).