feat(linux.net): DHCP server selection method

[pierantoniomerlino]

This PR updates the method used to check if dnsmasq is available on the system.

Related Issue: This PR fixes/closes N/A

Description of the solution adopted: Since the DHCP server manager uses the Systemd unit for dnsmasq, the method used to check the presence of the tool on the system has to check the existence of the unit and the command. This PR adds this check.

The check runs this command: systemctl status dnsmasq. Then the exit code is checked, based on the official documentation. Since the DhcpServerManager class uses a static method to check the tools, the method in LinuxNetworkUtil has to be static too.
This implies that the CommandExecutorService cannot be used since we haven't a reference to it. So, the method uses the standard ProcessBuilder class to run the command.

I don't like it.

In addition to the test for this specific feature, this PR adds few test on the getTool method.

[mattdibi]

Tested on RPi and found the following issue.

Starting point: in this setup isc-dhcp-server, dnsmasq and dnsmasq-base are all installed on the system.

When dnsmasq is removed with apt remove

Kura still thinks the unit is "functional" and "available".

In Kura logs:

2024-11-22T10:48:51,302 [Start Level: Equinox Container: 831d6796-ff4e-4b32-b8e2-7ea0f15b04f7] INFO  o.e.k.l.n.d.DhcpServerManager - Using dnsmasq as DHCP server.

which results in client not being able to correctly get an IP address from Kura's access point.

When dnsmasq is removed with apt purge

In Kura logs:

2024-11-22T11:08:25,565 [Start Level: Equinox Container: 76f5aed4-bdae-40e0-8249-9cac2fb13f8a] INFO  o.e.k.l.n.d.DhcpServerManager - Using dhcpd as DHCP server.

Conclusion

systemctl status return value is not entirely reliable to evaluate whether the systemd unit is installed and functional.

[marcellorinaldo]

Tested working on 3 different scenarios:

1. dnsmasq-base installed, dnsmasq not installed, /usr/sbin/dnsmasq binary present, isc-dhcp-server installed
2. dnsmasq-base installed, dnsmasq installed, /usr/sbin/dnsmasq binary present, isc-dhcp-server installed
3. dnsmasq-base installed, dnsmasq installed, /usr/sbin/dnsmasq binary present, isc-dhcp-server not installed

In scenario 1, Kura picked up dhcpd as DHCP server tool. In scenarios 2 and 3 dnsmasq was selected correctly. In all 3 scenarios the following basic test passes:

• Configure an interface as WAN, configure another one as DHCP server with NAT with passDNS=true
• Connect a client to the DHCP server interface and ping google

[marcellorinaldo]

Conclusion

systemctl status return value is not entirely reliable to evaluate whether the systemd unit is installed and functional.

Exit code is 3 when apt remove. When purging, exit code is 4. Currently we check that systemctl status returns an exit code < 4, we might solve this by changing just that

[mattdibi]

1. dnsmasq-base installed, dnsmasq not installed, /usr/sbin/dnsmasq binary present, isc-dhcp-server installed

3 is returned when dnsmasq is installed but stopped. That's why this is not reliable.

[mattdibi]

Tested with the latest changes: when the condition described in #5578 (comment) verifies, we get the following error in the log:

2024-11-22T14:18:08,345 [pool-22-thread-1] ERROR o.e.k.l.n.d.s.DnsmasqTool - dnsmasq Systemd unit startup failed. Is dnsmasq package installed on the system?

which gives enough information for the user to fix this issue.

Therefore, given that the situation in which

1. The user has isc-dhcp-server, dnsmasq and dnsmasq-base installed.
2. They remove dnsmasq without purging
3. Install kura

is quite unlikely and programmatically handling this situation brings diminishing returns, we accept current solution albeit not completely reliable.

We're planning to remove the support for isc-dhcp-server in the near future and thus this issue should be even less relevant.