RABBITMQ_DEFAULT_USER / RABBITMQ_DEFAULT_PASS behavior continues to confuse users

[lukebakken]

Related issue:

• RABBITMQ_DEFAULT_USER/PASS environment variables not taken into account docker-library/rabbitmq#150
• RABBITMQ_DEFAULT_USER/PASS environment variables not taken into account docker-library/rabbitmq#150 (comment)

Reproduction steps:

• Use the configuration and defs file from here. Edit rabbitmq.conf so that the path to the definitions file matches your environment. Notice that the definitions file does not define any users.
• Start a broker. I used main:

  make RABBITMQ_CONFIG_FILE="/home/lbakken/development/lukebakken/docker-library_rabbitmq-150/rabbitmq.conf" PLUGINS='rabbitmq_management rabbitmq_top' RABBITMQ_DEFAULT_USER=foobar RABBITMQ_DEFAULT_PASS=bazbat run-broker
  

• Note that neither the foobar nor the guest user is created:

  lbakken@shostakovich ~/development/rabbitmq/rabbitmq-server (main $=)
  $ ./sbin/rabbitmqctl authenticate_user foobar bazbat
  Authenticating user "foobar" ...
  Error:
  Error: failed to authenticate user "foobar"
  user 'foobar' - invalid credentials
  lbakken@shostakovich ~/development/rabbitmq/rabbitmq-server (main $=)
  $ ./sbin/rabbitmqctl authenticate_user guest guest
  Authenticating user "guest" ...
  Error:
  Error: failed to authenticate user "guest"
  user 'guest' - invalid credentials
  

What does work:

• Using just the env vars:

  docker run --pull always --rm --publish 15672:15672 \
      --env RABBITMQ_DEFAULT_USER=foobar --env RABBITMQ_DEFAULT_PASS=bazbat --name rmq-user-test rabbitmq:3-management
  
  $ docker exec rmq-user-test rabbitmqctl authenticate_user foobar bazbat
  Authenticating user "foobar" ...
  Success
  

• Of course, creating users via the definitions file works.

[lukebakken]

We do log an INFO message in this case: https://github.com/rabbitmq/rabbitmq-server/blob/main/deps/rabbit/src/rabbit.erl#L1066

Will not seed default virtual host and user: have definitions to load...

Perhaps this needs to be called out in the documentation, or the above message needs to be more visible.

But, I think that if someone specifies BOTH the env vars and the definitions file, the least-surprising action is to import everything specified.

[dearlordylord]

Let me chime in with a specific use case where both envs and definitions are desirable.

So, my queue is deployed on two different servers - staging and production; I expect their passwords/users to be different for safety (developers could accidentally connect to a wrong queue, and different password is a good protection against it)

I pass those thru docker compose from .env file.

Now, I still would like my queues and exchanges pre-defined on deploy, which definitions file seems to be ideal for (we also don't care about envs there; queues and exchanges are the same)

[michaelklishin]

@Firfi you will be able to accomplish the same thing by using multiple definition files:

definitions.import_backend = local_filesystem
definitions.local.path = /path/to/RabbitMQ/definitions/conf.d/

once #7685 ships in 3.11.12.

[dearlordylord]

Does that mean that I'll be able to include environment variables into definitions, or that I'll be able to import different definition files depending on an environment variable?

[michaelklishin]

Between environment variable support in latest Cuttlefish (rabbitmq.conf) and support for multiple definition files, I consider this to be addressed. All the user needs to be do is to generate and copy a definitions file, or a rabbitmq.conf file (a directory of config files can be used). In many cases
this would be perfectly compatible with what various deployment tools might generate.

[lukebakken]

@michaelklishin as soon as a user specifies that definitions are to be loaded, then there is no other way to add users. You can't do it via the rabbitmq.conf file (or other configuration files), nor can you do it via the environment. The more I think about it the more that this does make sense, but I can also see how it can confuse users (as in docker-library/rabbitmq#150).

I think this is fine as long as it's clearly documented. This is the log message that is shown:

[info] <0.230.0> Will not seed default virtual host and user: have definitions to load...