Reset FTL config values to default if they are not set in environment variables?

[PromoFaux]

If you start the container with, for example, FTLCONF_debug_all: 'true', and then stop the container and remove that environment variable - debug.all will still be enabled in FTL.

As it stands, if you want to turn it off again you have to explicitly set FTLCONF_debug_all: 'false', which is far from ideal.

Perhaps we should add in some code that sets the FTL config to default on every container start, and applies any FTLCONF environment variables onto that.

This would mean though that any customisations made to this file in a volume mounted directory would be overwritten on every restart. Perhaps this is OK.

[moya2162]

Agree with this issue and solution, however I can see people disliking the settings they select from the Pihole interface being lost at reboot of container when they have persistent data enabled. Especially if auto updating of container is enabled in their setups.

This is my suggesting on how to integrate this with persistent data. At restart / startup of Pihole docker container:

Data Management:

1. Mark settings modified from pihole website with a condition indicating such. Lets call this web.
2. Mark settings modified from environment variables with condition indicating such. Lets call this dockerenv.
3. Settings list not modified with condition indicating default. Lets call this default.

Workflow at Reboot:

1. Pihole loads default list of settings.
2. Pihole checks environment variables and applies changes indicated with condition dockerenv
3. Pihole checks existing persistent data and applies settings marked as web.
4. Final compiled list of setting will then be parsed to create pihole.toml and what not.

This is just a concept workflow.

[PromoFaux]

I entirely forgot about this issue.. We ended up doing something clever in FTL with the environment variables...

pi-hole/FTL#1693

Short version: If the value is set by environment variable, then the user is not allowed to set this in the web interface (or erven directly in the toml file

e.g on my own development-v6 deploy I have the DNS servers set by environment variable. In the web interface it is displayed like so:

[moya2162]

Im not sure if this issue is solved because I have been debugging Pihole last few days and I noticed that if i change a default via environment variable it sets the setting, but if i comment out the variable and reboot Pihole, it does not revert that setting to default.

Ive been having to redefine the environment variable to turn it off or completely deleting my persistent data and letting it rebuild upon reboot.

[PromoFaux]

Which image are you using? latest development-v6? If you set via the environment variable then it should never be written to the persistent storage (and so if you remove the variable it should revert to whatever the default is)

[PromoFaux]

Hmm, OK - just tested this myself with FTLCONF_webserver_port - and it does not revert to the default value if I unset the environment variable.

Digging in now... @DL6ER has something changed somewhere?

[moya2162]

Yup development-v6 branch. My FTL is on a difference branch because been working on a bug fix for a different issue, but it contains the commit you referenced.

Core vDev (development-v6, 8a924867)
FTL vDev (fix/resolver, 090c1ada)
Web interface vDev (development-v6, 59b1dcfc)

[PromoFaux]

Looking at it, this more or less behaves as designed. It's a tough one to balance.

Having the value set in the environment prevents any other process from manipulating that value. This is a good compromise to prevent settings from being changed by someone in the web interface when they have forgotten that they have also set it in the environment. High-level: If environment set, environment wins.

The difficult part of the balance is actually what to do once that value is no longer set in the environment.

When the value has been set previously, we can observe the following line above it in the toml file:

# >>> This config is overwritten by an environmental variable <<<

However, once we unset that variable, that line in the toml file is removed (or rather, isn't printed) but the value remains as it was previously. An idea here is that we could intercept this state when it is read for the first time. If the setting has # >>> This config is overwritten by an environmental variable <<<, but the environment variable no longer exists, then maybe this is the point where it should be set back to the default value.

In theory we know that the setting was once controlled by environment variable, but it is no longer. So it shouldn't be beyond the realms of possibility to say "Well, we no longer know what this value should be, so lets go back to default" - but it is very easy for me to say that from the point of view of someone who isn't very good at writing c code beyond basic debugging

[dschaper]

In theory we know that the setting was once controlled by environment variable, but it is no longer. So it shouldn't be beyond the realms of possibility to say "Well, we no longer know what this value should be, so lets go back to default"

That sounds logical to me. I think I copied in the output from a Vaultwarden instance that faces this same dilemma and shows how the startup output looks and how the administrative web interface differs when values are set via environment variables. Let me know if I should add that to this discussion thread.

[PromoFaux]

@DL6ER has worked his magic in pi-hole/FTL#1979

Now, when unsetting a config value that was previously forced by environment variable, it is restored to default.

[moya2162]

Confirmed working on my end with FTLCONF_resolver_refreshNames='ALL'. Comment out variable, rebooted, default value set. Probably ok to close issue.