bitdeals
e8204bbb4d
A pass branched on whether /etc/letsencrypt/live/<first-name> existed:
present, it ran `certbot renew`; absent, it handed over to the creation
script. Only the second path was ever told the names to ask for, so
after the first issuance CERTBOT_DOMAIN stopped reaching certbot
altogether -- renew takes the names off the certificate it already holds.
Editing the variable did nothing, silently, and the README documented the
manual issuance needed to work around it.
The branch is gone. Every pass now runs certonly with the names spelled
out, and certbot decides what that means:
same names, not due -> "Certificate not yet due for renewal; no
action taken", no connection opened, nothing
spent against the rate limits
name added or removed -> reissued with exactly the requested set
due for renewal -> renewed
--keep-until-expiring is what makes the first line true, and --cert-name
(already passed) is what keeps a changed list updating the existing
lineage instead of starting a second one beside it. No --expand is
needed to add a name once the lineage is named.
All three decisions were checked against the live stands: the no-op one
with a real run on testnet2, the other two as dry runs on testnet1 and
testnet2.
With the branch removed, 1-renew-cert.sh is a pass-through and the
numbering finally matches the order things run in -- 0-create-cert.sh
used to execute after 1-renew-cert.sh. So: 1-renew-cert.sh deleted,
0-create-cert.sh renamed to 1-ensure-cert.sh, which is what it now does.
Claude-Session: https://claude.ai/code/session_01BvgYcYPWd1KGABLKViVPSk
33 lines
1.3 KiB
Bash
33 lines
1.3 KiB
Bash
#!/bin/sh
|
|
|
|
# The renewal loop: run a pass, sleep 12 hours, repeat. PID 1 of the container.
|
|
#
|
|
# Deliberately not `set -e`: a pass that fails — Let's Encrypt unreachable,
|
|
# HAProxy refusing the certificate — must not end the loop, it must be retried
|
|
# on the next one.
|
|
#
|
|
# The trap is not decoration. PID 1 has no default signal dispositions, so a
|
|
# signal with no handler installed is ignored outright and `docker stop` would
|
|
# always have to fall through to SIGKILL.
|
|
#
|
|
# `sleep &` followed by `wait`, rather than a plain `sleep`: a foreground
|
|
# command keeps the shell from running a trap until it finishes, so a plain
|
|
# sleep would leave the container deaf to SIGTERM for up to 12 hours. `wait` is
|
|
# interruptible. Bare `wait` rather than `wait $(jobs -p)` — the command
|
|
# substitution runs in a subshell that reports the parent's jobs in bash but
|
|
# not in dash, and bare `wait` waits for every background job in either.
|
|
#
|
|
# One thing this cannot fix: a signal arriving while 1-ensure-cert.sh is in the
|
|
# foreground is deferred until that script returns, and an issuance talking to
|
|
# Let's Encrypt can outlast docker's 10-second stop grace. Give the service a
|
|
# longer `stop_grace_period` if that matters.
|
|
|
|
trap 'exit 0' TERM INT
|
|
|
|
while :; do
|
|
/opt/scripts/1-ensure-cert.sh \
|
|
|| echo "entrypoint: renewal pass failed, retrying in 12h" >&2
|
|
sleep 12h &
|
|
wait
|
|
done
|