mirror of
https://github.com/dehydrated-io/dehydrated.git
synced 2026-01-11 22:30:44 +01:00
Feature: Option to dry-run #346
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mrhackcz on GitHub (May 14, 2018).
Can you please to the next version add a option to run "dry-run" ?
@danimo commented on GitHub (Sep 30, 2020):
Here is a Gist with a conceptual patch. However, it does not implement some vital aspects, especially
@kousu commented on GitHub (Jun 12, 2021):
Hello friends :)
I am motivated to figure out some kind of
--dry-runso I can wrapdehydratedin anansiblescript. It will cover anywhere from 1 to 1000 servers, and I can't, and definitely can't ask my lab to, manually verify the configuration of each server before attempting to get a cert. But letsencrypt's rate limits are set to 5 per weekso are buypass's:
and I already ran into this once and had to wait a week before I could continue developing.
--dry-runcould also be a solution for #792: instead of implementing retry logic, include a dry run step in the regular cronjob: the cronjob will take care of retrying and there's less risk of negative consequences from turning up the cronjob's rate.prior art
I discovered that
certbothasSo with
certbot, I think they expect that if you're at all unsure about your configuration (in DNS, webserver, domains, connectivity) you should always do:which:
letsencrypt-testto try to make new certsletsencryptto make new ones, burning one of your attempts for the weekcertbot, configuration is the same as getting an initial cert (certbot certonly -d "$(hostname) [and probably some other options]")To do a proper dry run, you must contact a server. I just wish I could do that dry run without And now with multiple ACME servers in the wild it's complicated:
--ca letsencryptvs--ca letsencrypt-test--ca buypassvs--ca buypass-test--ca zerossl(which doesn't have a staging server; but it also doesn't have rate limits, so maybe we can consider it its own staging server)Then I tried
@danimo's patch doesn't seem to address this? Maybe it was written before multiple ACME CAs existed?
dehydrated-based workarounds/extensionswhich will
check if certs need renewing/creatingnot true; see https://github.com/dehydrated-io/dehydrated/issues/561#issuecomment-860274941letsencrypt-testto get new certs, replacing the working certs with test certsSo this is closer, but leaves me with invalid test certs on my server.
This form:
letsencrypt-testto get new certs, replacing the working certs with test certsDestryoing all certs is okay for my situation, as I am only planning one domain per server at the moment,
but it's a dangerous precedent to set.
This form:
letsencrypt-testto try to make new certs, and then forgets themletsencryptto get new certs, burning one of your attempts for the weekHowever, this wastes about 10s per deploy, by not being smart enough.
So the previous two forms both have the right result, at the expense of a. danger or b. time.
Maybe a hook could do it?
This seems to check all my boxes:
and it is idempotent, only doing work when work is needed.
@lukas2511 commented on GitHub (Jun 13, 2021):
@kousu Mh, from what I understand you are suggesting that a "dry-run" would connect to a staging environment of the corresponding CA? My understanding of a dry-run would be something that involves no real connections and only internal / partially mocked data. The staging environments have API limits too, so using them as some form of dry-run would only postpone eventual rate limit issues.
My big goal (for which I unfortunately didn't find much time yet...) is to restructure dehydrated into smaller internal parts, making it easier to change overall execution flow and replace parts in the future. That would make it a lot easier to implement real dry-runs, would allow for more flexibility with e.g. different CAs for different certificates, CA specific weirdness, etc.
@kousu commented on GitHub (Jun 13, 2021):
That's right. I want to be able to vet my setup: DNS, file permissions, webserver, ACME configuration files. Some of these can be tricky the first time, and others can get changed over time outside of my control. The only way to be sure is to run the complete ACME protocol.
The rate limits on the staging servers are much higher and designed to support this sort of testing and development.
Maybe
--dry-runis the wrong name for the feature I'm looking for. Maybe I want--testand I should start a separate issue for it.--ca letsencrypt-testgoes most of the way to what I want, I just wish it wouldn't overwrite my existing certs on success, because then I could automate `` and be pretty confident that I can detect and fix a bad configuration long before getting banned.Right now I either run
which got me banned last time
which doesn't get me banned but leaves me with invalid certs or
which gets me valid certs, but spends an extra 10s per attempt that it really doesn't need to.
The ideal for me would be a
--testthat didn't save certs to disk so thatwould only run when certs are expiring, would still produce valid certs, and would avoid getting banned all at the same time.
Oh this is the story of my life too! No worries. We're all volunteers here.
@jasoncodes commented on GitHub (Jun 13, 2021):
Have you tried copying your current real certs over to a temporary directory before running against
letsencrypt-test?Something like this should avoid requesting certs from the test CA unnecessarily:
@kousu commented on GitHub (Jun 13, 2021):
@jasoncodes it's genius. I think I will use it! Thank you.
@kousu commented on GitHub (Jun 13, 2021):
For what it's worth,
certbotdecided that their--dry-runimplies contacting the staging server; their--dry-run~=--ca letsencrypt-test -o $(mktemp -d).-v --dryrunreports:certbot -v renew --dry-run
I take back what I said above: their
--dry-runruns regardless of the state of your actual certs. Sois functionally identical to
Which is probably good enough for my purposes, honestly. But Jason's solution is better :)
@kousu commented on GitHub (Jun 14, 2021):
@jasoncodes I've refined your suggestion into:
It's working well so far :)