support for configuration as environment variables

[MaximilianMeister]

the config file is already a great feature! thanks a lot for that.
would it be possible to also add support for setting flags/options via environment variables?

this would facilitate the usage of geth within a container orchestration engine like kubernetes and containers in general as it will get rid of the requirement to mount a volume with the config file.

[lmars]

@MaximilianMeister one option for using environment variables is to wrap the running of geth with a script which first writes the config using environment variables and then exec's geth (I actually prefer this approach as it gives me the opportunity to verify the env vars before starting geth).

[MaximilianMeister]

@lmars makes sense, only problem is that i'd still need to add this wrapper to the container. ideally one could use the official container from dockerhub and just pass it the environment variables.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[MaximilianMeister]

@fjl @karalabe do you think this is in any way possible or desirable? i still would love such a feature, but i am not sure if something like that is maintainable

[karalabe]

Hmm, it's an interesting question. One one had I can definitely see the utility.

On the other hand though, it introduces problematic cases where the presence of an anv var could cause geth to execute differently without the user realizing. Currently if you use the CLI without a config, every behavior is fully specified via the flags. If you switch to a config file, there's already hidden behavior, but it's self contained within a file, that's still explicitly specified via a CLI flag.

Now with env vars, all of a sudden you have a hidden behavioral modifier in the picture. Since we wouldn't maintain individual env vars, rather would enable support for all, things could get weird if a user has a leftover env var somewhere which influences all future geth invocations. Also it changes the security model a bit, since all of a sudden you need to ensure that noone can tamper with your env vars before trusting your geth instance.

[MaximilianMeister]

On the other hand though, it introduces problematic cases where the presence of an anv var could cause geth to execute differently without the user realizing. Currently if you use the CLI without a config, every behavior is fully specified via the flags. If you switch to a config file, there's already hidden behavior, but it's self contained within a file, that's still explicitly specified via a CLI flag.

@karalabe the config file is already good, but it doesn't cover all flags, so it's also not as complete as providing a long list of flags, and you can not easily know which option is supported in the config file. i usually pass the flag to the dumpconfig subcommand to see if it changes the config file

Now with env vars, all of a sudden you have a hidden behavioral modifier in the picture. Since we wouldn't maintain individual env vars, rather would enable support for all, things could get weird if a user has a leftover env var somewhere which influences all future geth invocations. Also it changes the security model a bit, since all of a sudden you need to ensure that noone can tamper with your env vars before trusting your geth instance.

the leftovers would definitely be the user's responsibility, it perhaps also would not be encouraged to do that on bare metal, when you have flags/configfile as a better and more explicit alternative.

the change in the security model is probably the deal breaker here, thanks for the explanation!