[rabbitmq-discuss] shovel auth change in 3.3.0?
Laing, Michael
michael.laing at nytimes.com
Fri Apr 4 16:37:15 BST 2014
Here's an example - one shovel fails and the other works. The difference is
the colon which, strictly speaking, perhaps shouldn't have been there - but
used to work:
[
> {rabbitmq_shovel, [
> {shovels, [
> {'fails', [
> {sources, [
> {broker, "amqp://fabrik.user.test:@/
> test.fabrik.dev.nytimes.com"}
> ]},
> {destinations, [
> {brokers, [
> "amqp://fabrik.user.test:@/
> core.fabrik.dev.nytimes.com"
> ]}
> ]},
> {queue, <<"ha.fabrik">>}
> ]},
> {'works', [
> {sources, [
> {broker, "amqp://fabrik.user.test@/
> test.fabrik.dev.nytimes.com"}
> ]},
> {destinations, [
> {brokers, [
> "amqp://fabrik.user.test@/
> core.fabrik.dev.nytimes.com"
> ]}
> ]},
> {queue, <<"ha.fabrik">>}
> ]}
> ]} % /shovels
> ]} % /rabbitmq_shovel
> ].
Here's the output from the management console for the failed shovel:
{{badmatch,{error,{auth_failure,"Refused"}}},
> [{rabbit_shovel_worker,make_conn_and_chan,1,
>
> [{file,"rabbitmq-shovel/src/rabbit_shovel_worker.erl"},
> {line,226}]},
> {rabbit_shovel_worker,handle_cast,2,
>
> [{file,"rabbitmq-shovel/src/rabbit_shovel_worker.erl"},
> {line,60}]},
> {gen_server2,handle_msg,2,[{file,"src/gen_server2.erl"},{line,1022}]},
> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]}
On Fri, Apr 4, 2014 at 7:52 AM, Laing, Michael <michael.laing at nytimes.com>wrote:
> Thanks I'll try to make a test case - I've already added passwords to our
> dev environment so all works as it did before now. It was an auth error.
>
> As I was updating them, I noticed that, although the passwords had been
> left out, the colon was still there, so it may have been a parsing
> difference. Of course the colon shouldn't have been there.
>
> ml
>
>
> On Fri, Apr 4, 2014 at 6:31 AM, Simon MacMullen <simon at rabbitmq.com>wrote:
>
>> On 03/04/14 18:30, Laing, Michael wrote:
>>
>>> It appears that either the the source brokers or the destination brokers
>>> must now have a password provided even when using direct connection to
>>> both vhosts, i.e. the shovel is connecting vhosts on the same cluster.
>>>
>>> Formerly no password was required for either.
>>>
>>
>> That really should not be happening - and in fact I just tested it and I
>> could still set up a shovel specifying username but no password over a
>> direct connection.
>>
>> Furthermore, in 3.3.0 if you specify no username for a direct connection
>> it should always work rather than requiring the guest user to exist.
>>
>> So I'm curious: how exactly are you doing this? What error do you see?
>>
>> Cheers, Simon
>>
>> --
>> Simon MacMullen
>> RabbitMQ, Pivotal
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20140404/12db4666/attachment.html>
More information about the rabbitmq-discuss
mailing list