Feature suggestion: couple per-domain configuration with domains.txt #196

New Issue

2025-12-29T01:18:43+01:00

adam commented

2025-12-29 01:18:43 +01:00

Originally created by @jbergstroem on GitHub (Feb 14, 2017).

Need to dig into the oneliner for parsing domains.txt; but I'd like to add a way to set per-domain specific configuration bundled as part of the same source (instead of having it stored with the certificates). This way, things like #354 would be very powerful -- one can read it from a database or whatever source.

The idea is to do something in style with bash env variables;

CHALLENGETYPE=dns-01 foo.com bar.foo.com
bar.com foo.bar.com
...

Thoughts?

Originally created by @jbergstroem on GitHub (Feb 14, 2017). Need to dig into the oneliner for parsing `domains.txt`; but I'd like to add a way to set per-domain specific configuration bundled as part of the same source (instead of having it stored with the certificates). This way, things like #354 would be very powerful -- one can read it from a database or whatever source. The idea is to do something in style with bash env variables; ```txt CHALLENGETYPE=dns-01 foo.com bar.foo.com bar.com foo.bar.com ... ``` Thoughts?

adam closed this issue

2025-12-29 01:18:43 +01:00

adam commented

2025-12-29 01:18:44 +01:00

@lukas2511 commented on GitHub (Feb 14, 2017):

I'd like this too but I didn't really find a nice way to do this. It would be possible to split the line at a predefined marker (like bar.com foo.bar.com | CHALLENGETYPE=dns-01) and just execute that, but I really don't want to add even more ugly config parsing code... the current "parser" is ugly enough for one bash script...

For now you can partly solve this with a small wrapper script which sets the parameters, like this one:

#!/bin/sh
dehydrated -c -d 'foo.com bar.foo.com' -t dns-01
dehydrated -c -d 'bar.com foo.bar.com'

You could easily make a few helper functions to make it a bit more readable, maybe something like this (untested):

#!/bin/sh
HTTP() { dehydrated -c -d "${@}" }
DNS() { dehydrated -c -d "${@}" -t dns-01 }

DNS foo.com bar.foo.com
HTTP bar.com foo.bar.com

I want to put a bit more work into command line options since they make the script really powerful, especially in combination with automation tools like Ansible and Puppet, but even with small wrapper scripts like the examples above.

@lukas2511 commented on GitHub (Feb 14, 2017): I'd like this too but I didn't really find a nice way to do this. It would be possible to split the line at a predefined marker (like `bar.com foo.bar.com | CHALLENGETYPE=dns-01`) and just execute that, but I really don't want to add even more ugly config parsing code... the current "parser" is ugly enough for one bash script... For now you can partly solve this with a small wrapper script which sets the parameters, like this one: ``` #!/bin/sh dehydrated -c -d 'foo.com bar.foo.com' -t dns-01 dehydrated -c -d 'bar.com foo.bar.com' ``` You could easily make a few helper functions to make it a bit more readable, maybe something like this (untested): ``` #!/bin/sh HTTP() { dehydrated -c -d "${@}" } DNS() { dehydrated -c -d "${@}" -t dns-01 } DNS foo.com bar.foo.com HTTP bar.com foo.bar.com ``` I want to put a bit more work into command line options since they make the script really powerful, especially in combination with automation tools like Ansible and Puppet, but even with small wrapper scripts like the examples above.

adam commented

2025-12-29 01:18:44 +01:00

@jbergstroem commented on GitHub (Feb 14, 2017):

Thanks for your quick reply. I agree with all you said and are personally fighting with arguments against why two different configs isn't a better solution.

I guess a major version bump could introduce a new config format making things like this easier.

@jbergstroem commented on GitHub (Feb 14, 2017): Thanks for your quick reply. I agree with all you said and are personally fighting with arguments against why two different configs isn't a better solution. I guess a major version bump could introduce a new config format making things like this easier.

adam commented

2025-12-29 01:18:45 +01:00

@jbergstroem commented on GitHub (Feb 22, 2017):

Going to close this. Splitting domains up in your cronjob is clearly a better approach.

@jbergstroem commented on GitHub (Feb 22, 2017): Going to close this. Splitting domains up in your cronjob is clearly a better approach.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#196