Email - bash-postfix-encrypt-filter-sync-smime.sh (S/MIME certificate synchronization)

Email Solution · Config document · referenced from High availability and key synchronization

The loop that keeps the directory of S/MIME certificates the same on both internal servers. It waits for any change in the directory with inotifywait, fixes owner and mode of the files, and pushes the whole directory to the other node with rsync over ssh, deleting there what is not here. The other node runs the mirror image.

The script

#!/bin/bash
#
# Supposed to run on DC2-A-VCMSX001
#
SMIME_KEYS_DIR=/var/spool/postfix/bash-postfix-encrypt-filter/smime/
USER=bash-postfix-encrypt-filter
HOST=dc2-b-vcmsx001.adm.example.net

# Synchronization of SMIME public certificates
while true; do
    inotifywait -r -e modify,attrib,close_write,move,create,delete $SMIME_KEYS_DIR
    chown bash-postfix-encrypt-filter:bash-postfix-encrypt-filter $SMIME_KEYS_DIR/*
    chmod 400 $SMIME_KEYS_DIR/*
    rsync -avz -e "ssh -o StrictHostKeyChecking=no -i /home/bash-postfix-encrypt-filter/.ssh/id_rsa" $SMIME_KEYS_DIR/ $USER@$HOST:$SMIME_KEYS_DIR/ --delete
done

Differences between the hosts

That is the whole difference. The trailing slash on node A only produces a double slash in the paths, which changes nothing. The install notes show it on both nodes; the archived file of node B does not have it.

Reading it today

• Push with --delete, from both sides. Whichever node sees an event first makes the other node equal to itself. What that means when both sides changed is worked through in High availability and key synchronization.
• Events are only seen while inotifywait runs. A change that lands while chown, chmod or rsync are running is not noticed until the next event.
• StrictHostKeyChecking=no accepts whatever host key the peer presents.
• *chmod 400 $SMIME_KEYS_DIR/** fails with a message when the directory is empty; the loop carries on.

Checked against inotify-tools 4 and rsync 3.4

The event names of inotifywait 4.x, the rsync options and the policy of current OpenSSH towards an RSA key made with ssh-keygen -t rsa in 2019 were not re-checked.