[rabbitmq-discuss] Multiple local-usernames for federation

[Roman Gaufman]

Maybe I'm misunderstanding how this is meant to work - I have 3 RabbitMQs:

Cloud (10.9.0.1)
London (10.9.0.2)
Moscow (10.9.0.3)

I want to federate messages from London and Moscow to Cloud. I create 2
username/passwords on the "Cloud" rabbitmq (with appropriate permissions):

london:password1
moscow:password2

I then add 1 upstream for the London and 1 upstream for the Moscow RabbitMQ:

London: amqp://london:password1@10.9.0.1/oracle
Moscow: amqp://moscow:password1@10.9.0.1/oracle

The upstreams point to the Cloud RabbitMQ IP which has the appropriate
usernames/passwords and permissions.

Now when I crate a federate-me policy, I get an error
"{error,user_does_not_exist}" unless I set a local-username on the Cloud
RabbitMQ with:

rabbitmqctl -p oracle set_parameter federation local-username '"London"'

Then the London RabbitMQ is able to connect, but Moscow still says
user_does_not_exist. My question is why is this and how do I accept both
usernames?

Roman


On 14 May 2013 11:11, Simon MacMullen <simon at rabbitmq.com> wrote:

> On 13/05/13 18:18, Roman Gaufman wrote:
>
>> I want to have 20 or so clients reading/writing to a local rabbitmq
>> which will federate to a central server (in both directions). Each
>> client has a separate username, password and permissions.
>>
>> Reason it is done this way is the servers are on very unstable
>> connections on the move.
>>
>> Right now, when I try to connect more than 1 federation upstream, I
>> get:  ** {error,user_does_not_exist}
>>
>> It seems all of these servers need to be forced to use the same
>> username? - Why is this? - Is there any way not to have a
>> "local-username" but rather to accept all usernames?
>>
>
> I am not sure I understand what you are saying. The "local-username"
> parameter is used by the federation mechanism as the local user as which to
> publish messages which have been received over federation. It doesn't have
> anything to do with the remote user (which is encoded in the upstream URL).
>
> Cheers, Simon
>
> --
> Simon MacMullen
> RabbitMQ, Pivotal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130514/c8ca4370/attachment.htm>