Ubuntu 20.04, both in a GCP VM and in a Docker container.

You put the password generated by maxpasswd into maxscale.cnf and use that for the password parameter. The contents of the /var/lib/maxscale/passwd file are the users used to manage Maxscale. Those passwords are managed with the create user, destroy user and alter user MaxCtrl commands.

I am looking to do an automated, hands off deployment of maxscale (including setting up an alternate maxctrl user with a non-default password). I would like to do this without having to include the plaintext password in the automation. Is there a method for creating these password entries before an individual system is deployed? Or is it required that maxctrl users be created or modified manually?

if you can have a post-installation step where you just call maxctrl create user <name of new user> $ENV_VAR_HOLDING_PASSWORD and maxctrl destroy user admin it would work. This seems like something you'll have to solve in your deployment system.

It is absolutely something that was done using our deployment system. And in 2.4.10, I used the output of maxpasswd to fill in the parameter in /var/lib/maxscale/passwd with the encrypted version of the password (and put a pre-made .secrets file into /var/lib/maxscale used to create that encrypted version of the password) and it worked well. This appears to have changed with 2.5.X.

I have multiple environments I want to use maxscale in (dev, ref, prod, etc) and I'd like to have different passwords for each. Creating these passwords at container build time means fewer moving parts (from an operational standpoint) and is easier to validate prior to deployment. If I am unable to use maxpasswd to create the password hash, is there an alternate method to do this? If there is not, would it be appropriate to add a feature request for this functionality?

Also, if there is a way to put a username and password in the maxscale.cnf specifically for use with maxctrl/the REST API, I was unable to find that in the documentation. That would be a suitable alternative method for injecting this in (presuming it would override the default admin/mariadb username and password that is set up by default).

Maxpasswd and the admin users use a completely different encryption scheme which means it should not work. Were the credentials actually tested to work? I'll have to double-check the 2.4 code to see that it doesn't have a bug in the password verification code if the passwd file is "corrupted".

The only way to create, remove or modify administrative users is via maxctrl however the generated file is self-contained and can be deployed alongside MaxScale. This should at least give you a user with a known password which can be changed at a later time with maxctrl alter user.

I am pretty confident I was able to log in using a file I created ahead of time with a password generated via maxpasswd inside the /var/lib/maxscale/passwd file, but looking at one of my deployed systems, the password is different from the output of maxpasswd. It is likely I conflated that in my head, and the actual process was what you suggested afterward: using maxctrl to create a password entry, then copying that into our deployment templates.

Thank you for the clarification as well as the alternative path to move down. This unblocks me and lets me move forward. Cheers!

No worries, it's good that this was brought up. The confusion about the passwords might mean that we could make it possible to generate admin users "offline" as it seems to be a valuable feature.