-
-
Notifications
You must be signed in to change notification settings - Fork 708
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Option to dry-run #561
Comments
Here is a Gist with a conceptual patch. However, it does not implement some vital aspects, especially
|
Hello friends :) I am motivated to figure out some kind of
so are buypass's:
and I already ran into this once and had to wait a week before I could continue developing.
prior artI discovered that
So with
which:
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:
@danimo's patch doesn't seem to address this? Maybe it was written before multiple ACME CAs existed?
|
@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. |
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 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
would 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. |
Have you tried copying your current real certs over to a temporary directory before running against Something like this should avoid requesting certs from the test CA unnecessarily:
|
@jasoncodes it's genius. I think I will use it! Thank you. |
For what it's worth,
certbot -v renew --dry-run
I take back what I said above: their
is functionally identical to
Which is probably good enough for my purposes, honestly. But Jason's solution is better :) |
@jasoncodes I've refined your suggestion into:
It's working well so far :) |
Can you please to the next version add a option to run "dry-run" ?
The text was updated successfully, but these errors were encountered: