Lego: Feature request: Configuration file support

[moritzheiber]

With the multitude of options lego supports it would be greatly appreciated if it supported reading its configuration from a file instead of having to specify every parameter on the command line.

I'm a huge fan of hcl, configuring Hashicorp products using it is a blast, but I'd be open for anything at this point :smile:

Here's a reference implementation: https://github.com/hashicorp/vault/blob/c44f1c9817955d4c7cd5822a19fb492e1c2d0c54/command/config.go

[snapercloud]

+1

[splitbrain]

Previous discussion in #121

[mhoran]

I'm in the process of creating a FreeBSD port for lego, and a config file would be particularly helpful. My initial pass was based off of acme-client, unfortunately now unmaintained for anything other than OpenBSD.

The acme-client port is run via the FreeBSD periodic system. I intended to take the same route for lego. However, jamming a bunch of command line flags into /etc/periodic.conf is not a great user experience, and it also makes it difficult to debug issues.

Also, given the run command must be run before the renew command (and users _should_ manually accept the TOS from the run command) it can also be cumbersome to construct the command line multiple times.

Ideally, the periodic (8) script I'm writing for FreeBSD would simply call out to lego, which would then load its configuration and do its thing. I would imagine the config could provide everything required to lego such as environment variables and all global and command flags. That way the port would be very simple, instead of what I've conjured together today.

The conversation in #121 didn't get very far, but I'm wondering if this is still seen as a undesirable feature. Unfortunately if the functionality doens't make it into lego itself, I'll be stuck with the rather cumbersome experience I've cobbled together today, which isn't great.

[ldez]

We need to do some changes before introduce the support of configuration file.

But it's in my plan :wink:

[mhoran]

Awesome, thanks @ldez!

Do you have any concerns around including environment variables in the config file? That would make it easier for the port I've written, but I could understand an argument the other way. It's just sightly inconvenient to have configuration in two places, especially with a config file. I'm thinking specifically about DNS challenge configuration, as well as the experimental CNAME feature flag.

Are there any bite size pieces I could help with? Happy to take a pass at making this happen.

[ldez]

For now, I don't think that the DNS configurations, managed by env vars, will not be a part of the CLI configuration.
These variables are very hard to be properly managed because of the wide variety of configuration options and DNS client behaviors, and it's impossible for some DNS providers (ex: Route53).

I also think that the experimental flags will not be part of the CLI configuration.

Remember that lego is a CLI but also a lib :wink:

I have to reconcile several points of view, evaluate several approaches, in short I need time to imagine a maintainable architecture.

I have already redesigned the "core", it's the v2. Now I have to rethink the CLI.

My first step to a new CLI (I'm currently working on that) is to create a new unified command run/renew.

Help is always welcome and when my ideas :bulb: will be a little more clear :sun_behind_small_cloud: , I will not hesitate to ask for help and for reviewers.

[mhoran]

For now, I don't think that the DNS configurations, managed by env vars, will not be a part of the CLI configuration.

Totally agree. My thought here was that the configuration file would be able to support the more complicated bits of text (like Route 53 keys), and therefore could accommodate a block of environment variables. For example, say I run lego -c /usr/local/etc/lego/example.com.conf run, where example.com.conf is:

global_flags:
  email: [email protected]
  path: /usr/local/etc/ssl/lego
  domains: example.com www.example.com
  dns: route53
renew_flags:
  days: 30
env:
  LEGO_EXPERIMENTAL_CNAME_SUPPORT: true
  AWS_REGION: us-east-1
  AWS_ACCESS_KEY_ID: key
  AWS_SECRET_ACCESS_KEY: secret

This would mean I wouldn't have to wrap calls to lego in another shell script, as I've done in the port today.

My first step to a new CLI (I'm currently working on that) is to create a new unified command run/renew.

That sounds awesome! Looking forward to these improvements.