From 25ee7dcda5ed6f3066a4e46bcc81313f5e06be61 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane=20Lesimple?= Date: Wed, 8 Nov 2023 15:38:16 +0000 Subject: [PATCH] doc: more details about upgrade to 3.14.15 --- doc/sphinx/installation/upgrading.rst | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/doc/sphinx/installation/upgrading.rst b/doc/sphinx/installation/upgrading.rst index f271a5889..f34abbe0b 100644 --- a/doc/sphinx/installation/upgrading.rst +++ b/doc/sphinx/installation/upgrading.rst @@ -56,9 +56,19 @@ by all the instances of the same cluster. Hence, you should start by deploying t node, which will generate the secret automatically during the standard upgrading procedure, so that this node can push the shared-secret to the other nodes. The other nodes don't have to be upgraded beforehand, they'll just not use the secret until they're upgraded to this version, and JIT MFA for ``scp`` and ``sftp`` -will not work through them until this is the case. Once the primary node is upgraded, you should restart -the synchronization daemon, so that it takes into consideration the new file (containing the shared secret) -to push to the other nodes. This is usually done this way: +will not work through them until this is the case. + +Once the primary node is upgraded, you should ensure the new file containing the HMAC shared secret is part +of the synchronization list. If you did not customize your synchronization list, you can apply the new one +over the old one directly: + +.. code-block:: shell + :emphasize-lines: 1 + + cat /opt/bastion/etc/bastion/osh-sync-watcher.rsyncfilter.dist > /etc/bastion/osh-sync-watcher.rsyncfilter + +Then, you need to restart the synchronization daemon, so that it takes into consideration the new file +(containing the shared secret) to push to the other nodes. This is usually done this way: .. code-block:: shell :emphasize-lines: 1