Since piholeFTL test properly spins down it's no longer
necessary to kill it. He's dead Jim
Merge #300, added `piholeFTL test` to the startup sequence to
replace dnsmasq as a dependency for validate_env and gravity.sh.
kill -9 was kept as a work around to a standing issue that
`piholeFTL test` didn't spin down on it's own. This was fixed
in pi-hole/FTL#1067, landed on Apr 14 2021 and confirmed
working, as evinced by #834 which was filed the same day it
that fix landed.
Signed-off-by: D.Rect <48034372+DistractionRectangle@users.noreply.github.com>
piholeFTL exposes configuration to relocate/rename gravityDB so
we cannot just check a hard coded location. This commit greps
pihole-FTL.conf for a custom location. Since pihole-FTL.conf
will eventually be replaced by TOML, some verbosity is added to
denote what config file is being checked and what location it
ultimately ended up checking.
Signed-off-by: D.Rect <48034372+DistractionRectangle@users.noreply.github.com>
Proposed solution to #834
I believe the correct way to solve this issue is to change when "Gravity on Boot" is run.
The s6 init system has different stages. Currently, "gravity on boot" is run during Stage 2.ii: cont-init.d. One instance of pihole-FTL is started during cont-init, but it is only there to check the validity of the config files; it exits soon after starting. The final "service mode" instance of pihole-FTL is not started until Stage 2.iii, when the supervisor starts doing work.
If gravity.sh is counting on FTL to do its DNS lookups, then we should not run gravity until the supervised instance of FTL is running. We can accomplish this by moving "Gravity on Boot" to a @reboot line in /etc/cron.d/gravity-on-boot, and making that file's existence dependent on the value of SKIPGRAVITYONBOOT.
This will work because cron isn't started until we've reached Stage 2.iii.
Signed-off-by: Matt Winter <MattWinter@gmail.com>
- Add a new container environment variable allowing to specify the user to run the pihole-FTL process as. Defaults to root.
- Set inherited capabilities attributes on the pihole-FTL file to automatically grant runtime permitted capabilities when available in the bounding set. This allows dropping root before starting pihole-FTL without failing with a permission error if the capabilities are not available to the container (the process may still error out if performing an operation requiring the capability).
- Add some information on capabilities to the Readme file.
Signed-off-by: Mathieu Hofman <86499+mhofman@users.noreply.github.com>
* Tests are passing, hopefully consistently
* FTL pulling from official releases
* thanks @DL6ER for the musl-libc build
* Thanks middleagedman for the IPv6 fixes
* Thanks everyone for patience while I get this release working!
Adam Warner
D.Rect
Matt Winter
Athrogate
Adam Hill
Mathieu Hofman
StefanSchoof
Thomas LEVEIL