Tracing connection has credentials hardcoded to "guest"

[pimlinders]

Using any other user with the same permissions as guests results in

     Supervisor: {<0.646.0>,
                                           rabbit_tracing_consumer_sup}
     Context:    start_error
     Reason:     {{badmatch,{error,{auth_failure,"Refused"}}},
                  [{rabbit_tracing_consumer,init,1,
                       [{file,
                            "rabbitmq-tracing/src/rabbit_tracing_consumer.erl"},
                        {line,52}]},
                   {gen_server,init_it,6,[{file,"gen_server.erl"},{line,304}]},
                   {proc_lib,init_p_do_apply,3,
                       [{file,"proc_lib.erl"},{line,239}]}]}
     Offender:   [{pid,undefined},
                  {name,consumer},
                  {mfargs,
                      {rabbit_tracing_consumer,start_link,
                          [[{vhost,<<"/">>},
                            {name,<<"test">>},
                            {format,<<"text">>},
                            {pattern,<<"publish.#">>}]]}},
                  {restart_type,transient},
                  {shutdown,4294967295},
                  {child_type,worker}]

[michaelklishin]

You can configure permissions on the amq.rabbitmq.trace exchange for any user. There's nothing special about rabbitmq-tracing's consumer.

[michaelklishin]

If you can tell what specifically you had to do to see the crash report posted, we may be able to come up with a better way to report such issues.

[michaelklishin]

The line in the report is

    {ok, Conn} = amqp_connection:start(
                   #amqp_params_direct{virtual_host = VHost}),

which suggests that we indeed have hardcoded credentials.

[pimlinders]

If the guest users exists any user with the proper permission can create traces in the admin section. If the guest user does not exist you get a message in the management panel "Something went wrong trying to start the trace - check the logs.". I checked the logs to find that error message

[rbu]

Could you at least improve the error message? This bug is most surprising in real world setups where guest access is disabled. You end up spending time debugging the tracing plugin instead of using the tracing plugin to debug a real issue.

[michaelklishin]

@rbu the right thing to do here is to make the credentials configurable.

[rbu]

Yes, of course. But since nobody seems to care about that (including myself, I resorted to other debugging mechanisms), I was thinking at least putting a big warning there might help. It's probably the one bug that most every first-time user of this plugin will see before they abandon it.

[dwt]

FYI: Just got stumped by this as well. Now I'm also debugging via printf again.

[michaelklishin]

I wouldn't say "nobody cares about that": tracing is just not as high a priority as some other issues and our team is very small. We don't see this reported often, for example.

I'll add credential configuration for 3.5.7.

[michaelklishin]

I doubt that tracing was originally designed to be used in production environments but fair enough.

[dwt]

Please consider that many people like to have their development environment as similar to the production environment as possible to minimize conflicts because of different versions (or any other difference). This means that the guest user is also disabled on production systems setup like this.

[michaelklishin]

Going to try squeezing this into 3.5.7.

[mohaFazel]

I have installed RabbitMQ 3.6.0 on Linux CentOS server and try to create a trace file over a new virtual host that is not under permission of the Guest user from the management plugin remotely. Unfortunately, I encounter a same problem like this.
The detail of my problem explain here: http://stackoverflow.com/questions/35008083/centos-running-rabbitmq-failed-to-create-a-trace-file-and-log-on-other-vhost-rem

[michaelklishin]

@mohaFazel credentials used by this plugin can be configured using rabbitmq_tracing.username and rabbitmq_tracing.password. Please ask questions on rabbitmq-users.