The loop lived in a shell-form ENTRYPOINT one-liner: unlintable, uncommentable,
and expanded by docker into two nested shells. It is a file now, and the loop
is CMD with the base image's `certbot` entrypoint reset — CMD is appended to
ENTRYPOINT rather than replacing it, so without the reset the loop would have
arrived as arguments to certbot. In exchange a one-off run replaces the loop
outright and needs no --entrypoint:
docker run --rm -v letsencrypt:/etc/letsencrypt <image> certbot certificates
`wait $(jobs -p)` became a bare `wait`: 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. A failed pass is now reported
rather than passing silently, and the trap covers INT as well so Ctrl-C in an
interactive run works.
What this does not fix: a signal arriving while certbot is talking to Let's
Encrypt is held until that call returns, because a POSIX shell runs a trap only
after the foreground command finishes. That can outlast docker's ten-second
stop grace. Set stop_grace_period on the service if a clean stop matters.
Setting CERTBOT_EMAIL broke certificate issuance outright. CERTBOT_OPTS was
built as "--email $CERTBOT_EMAIL" and passed quoted, so certbot received the
flag and its value as one argument and rejected it as unrecognised; `set -e`
then ended the pass, and the loop repeated the same failure every 12 hours
while the site served the self-signed placeholder. The arguments are built
with `set --` now, which keeps them two words.
Installation into the running HAProxy reported success whatever happened. The
runtime API answers a refusal in the reply text and still closes cleanly, so
socat exits 0 either way; the script sent set, commit and show in a row and
inspected none of them. It now matches the replies and stops at the first that
is not an acknowledgement, saying plainly that the running HAProxy is still on
its previous certificate. It also reaches the API over a unix socket on a
volume shared with haproxy rather than TCP 9999, so the private key it carries
no longer crosses a network in the clear.
Also:
- The self-signed placeholder wrote site.key, site.csr and site.crt to the
working directory (/opt/certbot) and left the private key there for good.
It is built in a subshell under umask 077 on the volume the key belongs on,
the CSR step is gone, and `>>` is replaced by a temporary file and an atomic
rename — HAProxy reads site.pem at start-up and must never find it partial.
- 2-concatenate-cert.sh changed into the live directory without checking, and
on failure looked for fullchain.pem in whatever directory the caller was
sitting in — the scripts are sourced, so that is a real possibility. It uses
absolute paths and reports when there is nothing to concatenate.
- The wait for HAProxy watches for the runtime API socket instead of probing
TCP 9999, which no longer exists.
- compose: /var/lib/letsencrypt is declared a VOLUME by the base image, so
leaving it unnamed created a fresh anonymous volume on every container
creation. It and the volumes section, which was missing entirely, are added.
Build context is the repository root, as the Dockerfile's COPY expects.
Verified on testnet2 against a real unix socket: the happy path sends set,
commit and show; a refused set stops before commit; a refused commit and an
unreachable socket are both reported. The runtime API payload is byte-identical
to what the previous echo produced.
bitdeals
private-user