Markus,

Just explaining a little bit more:

When the Maxscale is set up, the best to do is to avoid having clear text passwords for any of the users that access the backends, so, we run the `maxkeys` on each of the servers which has a different entropy. So, we have users (maxmon, maxuser, mariadb) with the same passwords as they are on the databases/backends, but, when we encrypt, they get a different hash for each of the instance. When we run a dynamic command, the whole monitor definition, for example, is added to the persistdir. At this point we have something to be synced with the other instances and then, if the `maxctrl cluster sync` executes the `alter monitor cluster-monitor user=maxmon password=<hash_defined for instance 01>` on the instance 02, when the maxscale restarts on that instance :boom: it’s not going to connect to the backends and Maxscale will fail and will die. The Engineering Team is yet studying a way to deal with that.

Markus,

I did more tests while we were having a chat internally and detected that we need to add one additional step for the Maxscale setup when you decide to use the encrypted passwords for users (service, monitor, and replication user). Here I'm considering also considering that the set up has more than one MaxScale instance forming a pool of instances for High Availability when you need to make sure all Maxscale instances must have the same configs before failing over.

The test is below, a simple one, done before, but, repeated today for the sake of sanity: in one of the instances running MaxScale, considering you have two or three instances, I created the current encryption key with the command maxkeys and then, rsynced it to the other host. In the end, with the user's password in hands, I got an encrypted password based on the same key.

#: instance A

[root@max01 ~]# ls -lh /var/lib/maxscale/.secrets

-r--------. 1 root root 48 Jul  5 16:17 /var/lib/maxscale/.secrets

[root@max01 ~]# cat /var/lib/maxscale/.secrets | md5sum

5f84b7cb7915bbec493e1d055dac2722  -

[root@max01 ~]# maxpasswd 123

472C1AFEBEE1B9466F531482F8196056

#: moving the file

[root@max01 ~]# rsync -av -e ssh /var/lib/maxscale/.secrets 35.171.16.59:/var/lib/maxscale/.secrets

sending incremental file list

.secrets

sent 141 bytes  received 35 bytes  352.00 bytes/sec

total size is 48  speedup is 0.27

#: instance B

[root@max02 ~]# ls -lh /var/lib/maxscale/.secrets

-r--------. 1 root root 48 Jul  5 16:17 /var/lib/maxscale/.secrets

[root@max02 ~]# cat /var/lib/maxscale/.secrets | md5sum

5f84b7cb7915bbec493e1d055dac2722  -

[root@max02 ~]# maxpasswd 123

472C1AFEBEE1B9466F531482F8196056

The above will make the user's passwords the same across the MaxScale instances/setups, and then, we can use MaxCtrl to sync everything between/among Maxscale instances.

Let's close this JIRA; it's OK.