multi-domains: behavior on failure to continue for each other entries #462

Closed
opened 2025-12-29 01:25:40 +01:00 by adam · 5 comments
Owner

Originally created by @tst2005 on GitHub (Mar 2, 2020).

Hello,

I'm using dehydrated 0.6.5, with http challenge.
My domains.txt file seems like :

example.com www.example.com server1.example.com
test.example.com
foo.example.com
service2.example.com
anotherdomain1.com www.anotherdomain1.com
anotherdomain2.com www.anotherdomain2.com

Everything is managed on one server named server1.example.com.
I'm working to migrate everything on server2.example.com.
I started by migrate one part. It took time.

I got an issue.
All the certificates needs to be renewed everything should be fine except one of the vhost (foo.example.com) that is move on the new server. The challenge produced by the server1 is not found on server2 by letsencrypt servers.

I used a simple workaround : comment the foo.example.com to renew all the other certificates.

The current behavior is "stop everything" on error.
I got:

- [x] OK: example.com www.example.com server1.example.com
- [x] OK: test.example.com
- [ ] FAILURE: foo.example.com
- [ ] nothing tried: service2.example.com
- [ ] nothing tried: anotherdomain1.com www.anotherdomain1.com
- [ ] nothing tried: anotherdomain2.com www.anotherdomain2.com

Feature/bug request:

  • It is possible to have a behavior to continue after a failure to try to renew all certificates ? do not let expire certificates because of a neighbour has an issue.
Originally created by @tst2005 on GitHub (Mar 2, 2020). Hello, I'm using dehydrated 0.6.5, with http challenge. My `domains.txt` file seems like : ``` example.com www.example.com server1.example.com test.example.com foo.example.com service2.example.com anotherdomain1.com www.anotherdomain1.com anotherdomain2.com www.anotherdomain2.com ``` Everything is managed on one server named `server1.example.com`. I'm working to migrate everything on `server2.example.com`. I started by migrate one part. It took time. I got an issue. All the certificates needs to be renewed everything should be fine except one of the vhost (`foo.example.com`) that is move on the new server. The challenge produced by the `server1` is not found on `server2` by letsencrypt servers. I used a simple workaround : comment the `foo.example.com` to renew all the other certificates. The current behavior is "stop everything" on error. I got: ``` - [x] OK: example.com www.example.com server1.example.com - [x] OK: test.example.com - [ ] FAILURE: foo.example.com - [ ] nothing tried: service2.example.com - [ ] nothing tried: anotherdomain1.com www.anotherdomain1.com - [ ] nothing tried: anotherdomain2.com www.anotherdomain2.com ``` Feature/bug request: - It is possible to have a behavior to continue after a failure to try to renew all certificates ? do not let expire certificates because of a neighbour has an issue.
adam closed this issue 2025-12-29 01:25:40 +01:00
Author
Owner

@txr13 commented on GitHub (Mar 2, 2020):

Are you using the --keep-going flag?

See the parameter list under "Usage" on the main page:

--keep-going (-g)                Keep going after encountering an error while creating/renewing multiple certificates in cron mode
@txr13 commented on GitHub (Mar 2, 2020): Are you using the `--keep-going` flag? See the parameter list under "Usage" on the main page: ```text --keep-going (-g) Keep going after encountering an error while creating/renewing multiple certificates in cron mode ```
Author
Owner

@tst2005 commented on GitHub (Mar 2, 2020):

oh... I really missed this option ?!
It seems exactly what I needs !
but ... why it is not the default behavior ?

@tst2005 commented on GitHub (Mar 2, 2020): oh... I really missed this option ?! It seems exactly what I needs ! but ... why it is not the default behavior ?
Author
Owner

@txr13 commented on GitHub (Mar 2, 2020):

but ... why it is not the default behavior ?

When you're using --keep-going, the script will continue normally. You'll need to review the cron logs or have some other way of verifying that your certificates were all renewed successfully. You won't have a non-zero exit code to indicate that the program terminated abnormally.

@txr13 commented on GitHub (Mar 2, 2020): > but ... why it is not the default behavior ? When you're using `--keep-going`, the script will continue normally. You'll need to review the cron logs or have some other way of verifying that your certificates were all renewed successfully. You won't have a non-zero exit code to indicate that the program terminated abnormally.
Author
Owner

@lukas2511 commented on GitHub (Mar 3, 2020):

Thanks @txr13. Closing this as it's solved :)

@lukas2511 commented on GitHub (Mar 3, 2020): Thanks @txr13. Closing this as it's solved :)
Author
Owner

@tst2005 commented on GitHub (Mar 4, 2020):

Really ? dehydrated are unable to manage a simple global error status ?!
This option is a trap...

I implemented the behavior by myself.

#!/bin/sh
set -e
cd -- "$(dirname "$0")"

ERROR=0
[ -f all.domains.txt ] || cp -a domains.txt all.domains.txt
while read -r line; do
        case "$line" in ('#'*) continue;; esac
        echo "$line" > domains.txt
        ./dehydrated-v0.6.5 --config config "${@:--c}" || ERROR=1
done < all.domains.txt
cp -a all.domains.txt domains.txt
exit $ERROR

Regards,

@tst2005 commented on GitHub (Mar 4, 2020): Really ? dehydrated are unable to manage a simple global error status ?! This option is a trap... I implemented the behavior by myself. ```bash #!/bin/sh set -e cd -- "$(dirname "$0")" ERROR=0 [ -f all.domains.txt ] || cp -a domains.txt all.domains.txt while read -r line; do case "$line" in ('#'*) continue;; esac echo "$line" > domains.txt ./dehydrated-v0.6.5 --config config "${@:--c}" || ERROR=1 done < all.domains.txt cp -a all.domains.txt domains.txt exit $ERROR ``` Regards,
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#462