Originally created by @someone-somenet-org on GitHub (Jul 20, 2020).
What happened
We host a few wikis for random student's projects and allow them to use their own domain names.
Over the weekend some of our hosted wikis became unreachable (cert expired), because our cronjob was this: @weekly letsencrypt /usr/bin/dehydrated -c; /usr/bin/dehydrated -gc
Turns out: dehydrated aborts by default on the first error and one domain expired and failed to be renewed, aborting the renew operation for all subsequent domains. (And we failed to check on the "error" mails from dehydrated/cron, because you get them even if no error occurs so it turns out: all of us admins ignore them)
Proposal
Change the default of --keep-going to be enabled by default (and add a --abort-on-error or something like that to cover the usecase of actually wanting to fail on the first error.)
Originally created by @someone-somenet-org on GitHub (Jul 20, 2020).
### What happened
We host a few wikis for random student's projects and allow them to use their own domain names.
Over the weekend some of our hosted wikis became unreachable (cert expired), because our cronjob was this:
`@weekly letsencrypt /usr/bin/dehydrated -c; /usr/bin/dehydrated -gc`
Turns out: dehydrated aborts by default on the first error and one domain expired and failed to be renewed, aborting the renew operation for all subsequent domains. (And we failed to check on the "error" mails from dehydrated/cron, because you get them even if no error occurs so it turns out: all of us admins ignore them)
### Proposal
Change the default of `--keep-going` to be enabled by default (and add a `--abort-on-error` or something like that to cover the usecase of actually wanting to fail on the first error.)
Thanks for reporting. Unfortunately I think it's a bad idea to change this behavior as many people might already have built their tooling around this exact behavior and it could potentially silently break their setups. I think the current way is documented enough not to be a problem.
@lukas2511 commented on GitHub (Sep 17, 2020):
Thanks for reporting. Unfortunately I think it's a bad idea to change this behavior as many people might already have built their tooling around this exact behavior and it could potentially silently break their setups. I think the current way is documented enough not to be a problem.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @someone-somenet-org on GitHub (Jul 20, 2020).
What happened
We host a few wikis for random student's projects and allow them to use their own domain names.
Over the weekend some of our hosted wikis became unreachable (cert expired), because our cronjob was this:
@weekly letsencrypt /usr/bin/dehydrated -c; /usr/bin/dehydrated -gcTurns out: dehydrated aborts by default on the first error and one domain expired and failed to be renewed, aborting the renew operation for all subsequent domains. (And we failed to check on the "error" mails from dehydrated/cron, because you get them even if no error occurs so it turns out: all of us admins ignore them)
Proposal
Change the default of
--keep-goingto be enabled by default (and add a--abort-on-erroror something like that to cover the usecase of actually wanting to fail on the first error.)@lukas2511 commented on GitHub (Sep 17, 2020):
Thanks for reporting. Unfortunately I think it's a bad idea to change this behavior as many people might already have built their tooling around this exact behavior and it could potentially silently break their setups. I think the current way is documented enough not to be a problem.