Follow-up to 9249c892 (#7249). The mkdir -p ran unconditionally before
the guarded cp calls, so a first deploy left an empty backup directory
behind. Move the mkdir into each guarded block.
1. The four backup cp calls (KEYFILE/CERTFILE/CAFILE/FULLCHAIN) ran
unguarded. With USE_SCP=yes MULTI_CALL is implicit, so each cp is its
own ssh call and a missing source aborted the deploy. In batched mode
it was masked because the exit code is that of the last command.
Each cp is now wrapped in a remote [ -f ] test.
2. deploy/ssh.sh tested DEPLOY_SSH_FULLCHAIN = "yes" instead of
DEPLOY_SSH_MULTI_CALL (since 2017). Effect was only that the
fullchain backup got deferred to the next batch. Fixed as well.
Please upgrade with acme.sh --upgrade -b dev and retest.
ssh_deploy() ignored the result of _ssh_deploy and always returned
success, so a failed transfer to one (or all) of the servers in
DEPLOY_SSH_SERVER was silently swallowed. Track the return code across
the loop and return non-zero if any server failed, letting the caller
handle notification.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Before this update all remote commands were bunched together and
sent to the remote host in a single SSH command. This could result
in a very long sequence of commands that might be rejected by a
remote host (example is VMware ESXi that uses busybox sh).
With this update you can set DEPLOY_SSH_BATCH_MODE="no" and
each remote command is sent as a separate SSH call so now we
do not have big long sequence of commands. Defaults to same
behaviour as before this update.