Make storage from config set storage path for commands

[mdhowle]

Hello,

I'd like to suggest that when a configuration file is passed with storage value that it be applied all lego commands (e.g., accounts, certificates , etc.).

We store the lego configuration and data (certificates, env files, accounts, hooks) in /etc/lego instead of $PWD/.lego.

Currently, we run the following to obtain and renew certificates: lego --config /etc/lego/lego.yml with the lego.yml below.

storage: /etc/lego

# ..truncated..

This works fine. However, if we wish to run any commands, for example lego certificates list, the invocation we have to use is lego --config /etc/lego/lego.yml certificates list --path /etc/lego

The path is specified twice: once in the YAML configuration file and again as an argument to certificates list.
Having the storage value in the configuration file apply as the LEGO_PATH for the commands would improve usability.

[ldez]

Hello,

Related to #3118 (comment)

Note: I will not add a global flag to handle configuration path because some commands doesn't need it or should not support it.

[ldez]

I added the support of the configuration file for the list related commands: #3128

[mdhowle]

Hey, thank you for taking a look!

I believe I understand what you mean by not wanting to set a global flag. The --config argument is already a global flag and can indirectly set the storage path globally. Is that correct?

If so, would this be akin to running LEGO_PATH=/foo/bar lego <command-that-doesnt-need-path> and lego not using LEGO_PATH as it's not required for that task.

From a quick look, dnshelp and help are the only two commands I found that don't take a --path argument.

[ldez]

The --config argument is already a global flag and can indirectly set the storage path globally.

No, --config is not a global flag, this is a "local" flag.

This means for a command lego foo, the flag --config cannot be used for lego --config xx foo or lego foo --config xx.

The root command lego is not related to the sub-commands.

Think to the command lego migrate as a concrete example of command that should not have --config flag.

I think you already understand that, but to avoid any ambiguities: LEGO_PATH/--path and LEGO_CONFIG/--config are two different things.

• LEGO_PATH/--path is related to the storage of accounts and certificates
• LEGO_CONFIG/--config is related to the path to the configuration file.

Outside flags related to logger, the flags and the configuration file cannot be mixed.
The file configuration structure is too complex to be managed with simple flags, at least trying to support that will create an important complexity only for niche cases.
And the file configuration automatically manages the certificates and the accounts, this is incompatible with the "non-file-configuration" behavior.

https://go-acme.github.io/lego/advanced/file-configuration/index.html#archive-behavior

[ldez]

The complexity behind this behavior is mainly related to the sub-command lego run.
This command is standalone, works only with flags: this command is historically the "main" command.
This is a kind of "stateless" command (even if there is a state, yes I know this is confusing 😉).

The root command lego can also see as "standalone" but "stateful" because of the management of the file configuration.

The two behavior are incompatible.

[mdhowle]

OK, I see, thanks. My confusion stemmed from the lego --help where --config falls under "GLOBAL OPTIONS" and the configuration file documentation stating "global options" for settings such as storage that would apply to most all subcommands and the "lego" command.

GLOBAL OPTIONS:
   --help, -h     show help
   --version, -v  print the version

[ ... ]

   Flags related to the configuration file:

   --config string  Path to the configuration file. [$LEGO_CONFIG]

and thinking, perhaps naïvely :) "Why can't lego read the storage: value from the config file, and if it doesn't need the rest of the configuration, ignore it."

Anyway, thank you for your time.

(I didn't see the previous comment before I submitted; makes more sense now. Thank you :) )