"$network" on a systemd-driven OS leads to "After=network-online.target" in the generated systemd unit.
This target is no guarantee that all network interfaces have been fully configured, as it depends on the related network services types, but at least it reduces the risk that those have not fully finished their job when pihole-FTL starts. If this is the case, certain issues can occur:
- https://github.com/pi-hole/pi-hole/issues/2924
- https://discourse.pi-hole.net/t/have-to-pihole-restartdns-after-reboot/28772
Runtime files are now consistently created in "/run" instead of "/var/run". The second is a symlink to the first for backwards compatibility but on none-ancient distro versions one should use "/run", systemd even prints a warnings if service files use "/var/run". The service file used "/run" and "/var/run" both, in cases for the same files/directories before, which does not directly cause issues currently, due to the symlink, but is inconsistent at best.
Signed-off-by: MichaIng <micha@dietpi.com>
- Currently, if the SELinux config file exists, installed SELinux is assumed.
- But removing e.g. an APT package via "apt-get remove" leaves config files in place, or they could be present for other reasons.
- If the getenforce command is not present but the config file is, currently the installer exists without error message when calling getenforce due to "set -e".
- With this change, the presence of getenforce command is checked first. If it is not present, selinux-utils is not installed, which is a core part of SELinux, pulled in by selinux-basics as well. So it can be assumed that no SELinux is active if this command is missing.
Signed-off-by: MichaIng <micha@dietpi.com>
This is and was never required and the pihole user does in fact not get any additional permissions through that group.
Signed-off-by: MichaIng <micha@dietpi.com>
Using the meta package causes several issues:
- Install on Debian prior to Jessie and Ubuntu prior to Xenial is broken, since those do not serve the meta packages but php5-* packages instead.
- If $phpVer != "php", then multiple conflicting PHP versions can be installed.
- If "${phpVer}-intl" does not pull the correct package, then inherently "${phpVer}-xml" etc are wrong, too. This is theoretically possible, e.g. if PHP7.4 was installed while the webserver uses a concurrently installed PHP7.3 instance. Then the "php" shell command output can differ from what the webserver uses. This theoretical issue would need a different approach to derive $phpVer, not based on the shell command output but by asking the webserver somehow in the first place. But using $phpVer for some modules and hardcoded meta for the others can only lead to inconsistencies and issues.
Signed-off-by: MichaIng <micha@dietpi.com>
