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>
When setting the password, explicitly disable bash logging. Leave the
re-enable code so that other functions work as expected. Additionally,
do not remove the print in generate_password so randomly generated
passwords are still logged for user consistency.
Signed-off-by: Kyle Kurz <kyle@doublekaudio.com>
From the docs:
> If a repository has any files in its own .github/ISSUE_TEMPLATE folder, including issue templates or a config.yml file, none of the contents of the default .github/ISSUE_TEMPLATE folder will be used.
So we need to copy the config.yml since it will be ignored.
The distro_check function includes updating the APT cache, checking for dependencies, which is both not required on Docker start where all required packages are installed already. The only required steps from this function is the webserver user and config file names, which can be applied directly instead since we know that the Pi-hole Docker container is based on Debian.
Furthermore this solves the issue that updating the APT cache fails, when Pi-hole itself is used for DNS resolution, since pihole-FTL has not yet been started at this stage. That failure was not visible since "apt-get update" does not exist with error code (currently) when facing DNS resolving issues, even if not a single list could have been updated, and no other step is done that would require DNS resolving, until pihole-FTL is started. For a regular (non-Docker) install or update it is however reasonable to error out directly when the APT cache could not have been updated, to not defer the exit unnecessarily to a harder-to-debug stage.
Signed-off-by: MichaIng <micha@dietpi.com>