[rabbitmq-discuss] eacces error in RabbitMQ when trying to set up federation
Daniel Ashton
jdashton at ashtonfam.org
Mon Feb 3 17:26:45 GMT 2014
Question partially answered: I ran "sudo setenforce 0" and suddenly the
exchanges connect to the intended upstream.
So . . . how to give them permission to do this when SELinux is enforcing?
On Mon, Feb 3, 2014 at 12:10 PM, Daniel Ashton <jdashton at ashtonfam.org>wrote:
> Thanks so much for the response, Simon.
>
> I've tweaked the network configuration, so the IP addresses are
> different. But the results are the same, whether connecting to the
> upstream or to myself:
>
> [root at localhost jdashton]# rabbitmqctl eval
> 'gen_tcp:connect("192.168.199.2", 5672, []).'
> {error,eacces}
> ...done.
> [root at localhost jdashton]# rabbitmqctl eval
> 'gen_tcp:connect("192.168.199.1", 5672, []).'
> {error,eacces}
> ...done.
>
> *.2 is myself, *.1 is my intended upstream host.
>
> From the Mac side this works beautifully. Exchanges are seeing the
> Fedora20 host as their upstream, federation status shows them all as
> running, and the above command gets {ok,#Port<5233.*some_number*>} as the
> response when connecting to *.2 (Fedora) or *.1 (Mac/self).
>
> Thanks again for your help. I would love to get this working.
>
>
>
>
> On Mon, Feb 3, 2014 at 11:18 AM, Simon MacMullen <simon at rabbitmq.com>wrote:
>
>> I doubt it's a firewall, that should lead to "connection timed out" or
>> "connection refused" type errors.
>>
>> SELinux is maybe a possibility.
>>
>> If you invoke:
>>
>> # rabbitmqctl eval 'gen_tcp:connect("172.30.42.19", 5672, []).'
>>
>> on the Fedora host then that will attempt to establish a vanilla TCP
>> connection to the Mac. What response does it give?
>>
>> Cheers, Simon
>>
>>
>> On 03/02/2014 4:01PM, Daniel Ashton wrote:
>>
>>> I see no evidence that it ever reaches the upstream. The upstream's log
>>> files have nothing about being connected to from the Fedora broker.
>>> That's why I wondered about Fedora (or upstream Mac host, for that
>>> matter) firewalls or SELinux on Fedora. eacces . . . can that indicate
>>> an SELinux problem?
>>>
>>>
>>> On Mon, Feb 3, 2014 at 10:57 AM, Simon MacMullen <simon at rabbitmq.com
>>> <mailto:simon at rabbitmq.com>> wrote:
>>>
>>> That's quite odd. 'eacces' is an OS-level error, nothing in RabbitMQ
>>> should be generating that error for anything AMQPish.
>>>
>>> Is there anything interesting in the logs on the upstream?
>>>
>>> Cheers, Simon
>>>
>>> On 03/02/2014 2:35PM, J. Daniel Ashton wrote:
>>>
>>> I'm trying to prototype federated message queuing between a Mac
>>> host and
>>> a Fedora 20 image running under VirtualBox. After a certain
>>> amount of
>>> head banging I managed to get the Mac exchanges federated from
>>> the
>>> Fedora exchanges, meaning that messages sent to the Fedora
>>> upstream
>>> broker are received on the Mac (downstream) broker.
>>>
>>> However, when trying to go the other way (Fedora sees Mac as
>>> upstream),
>>> I get error messages about "eacces".
>>>
>>> |==> rabbit at localhost.log <==
>>>
>>> =WARNING REPORT==== 29-Jan-2014::21:18:11 ===
>>> Federation exchange 'amq.direct' in vhost '/' did not connect to
>>> exchange 'amq.direct' in vhost '/' on amqp://172.30.42.19
>>> <http://172.30.42.19>
>>>
>>> {error,eacces}
>>>
>>> ==> rabbit at localhost-sasl.log <==
>>>
>>> =SUPERVISOR REPORT==== 29-Jan-2014::21:18:11 ===
>>> Supervisor: {<0.15681.0>,
>>>
>>> rabbit_federation_link_sup}
>>> Context: child_terminated
>>> Reason: {shutdown,restart}
>>> Offender: [{pid,<0.21716.0>},
>>> {name,
>>> {upstream,
>>> [<<"amqp://guest:guest@172.30.__42.19
>>> <mailto:guest%3Aguest at 172.30.42.19>">>],
>>>
>>> <<"amq.direct">>,<<"amq.__direct">>,1000,1,1,36000000,
>>>
>>> none,false,'on-confirm',none,<__<"mac_host">>}},
>>> {mfargs,
>>> {rabbit_federation_exchange___
>>> link,start_link,
>>> [{{upstream,
>>>
>>> [<<"amqp://guest:guest@172.30.__42.19
>>> <mailto:guest%3Aguest at 172.30.42.19>">>],
>>>
>>> <<"amq.direct">>,<<"amq.__direct">>,1000,1,1,
>>>
>>> 36000000,none,false,'on-__confirm',none,
>>> <<"mac_host">>},
>>>
>>> {resource,<<"/">>,exchange,<<"__amq.direct">>}}]}},
>>>
>>> {restart_type,{permanent,1}},
>>> {shutdown,4294967295},
>>> {child_type,worker}]
>>> |
>>>
>>> My Google-fu is failing me. What may be causing the above error
>>> (/e.g./
>>> SELinux?) and how should I go about fixing it?
>>>
>>> BTW, on the theory that it might be the Linux or Mac firewalls,
>>> I tried
>>> opening a browser on the Fedora box and requesting
>>> |http://172.30.42.19:5672|. I got a (tiny) answer in return, so
>>> the
>>> firewall looks less likely to be the problem.
>>>
>>>
>>>
>>> _________________________________________________
>>> rabbitmq-discuss mailing list
>>> rabbitmq-discuss at lists.__rabbitmq.com
>>> <mailto:rabbitmq-discuss at lists.rabbitmq.com>
>>> https://lists.rabbitmq.com/__cgi-bin/mailman/listinfo/__
>>> rabbitmq-discuss
>>>
>>> <https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/
>>> rabbitmq-discuss>
>>>
>>>
>>> --
>>> Simon MacMullen
>>> RabbitMQ, Pivotal
>>>
>>>
>>>
>>>
>>> --
>>> Daniel Ashton PGP key available http://Daniel.AshtonFam.org
>>> mailto:jdashton at AshtonFam.org <mailto:jdashton at AshtonFam.org>
>>> http://ChamberMusicWeekend.org
>>>
>>
>> --
>> Simon MacMullen
>> RabbitMQ, Pivotal
>>
>
>
>
> --
> Daniel Ashton PGP key available http://Daniel.AshtonFam.org
> mailto:jdashton at AshtonFam.org http://ChamberMusicWeekend.org
>
--
Daniel Ashton PGP key available http://Daniel.AshtonFam.org
mailto:jdashton at AshtonFam.org http://ChamberMusicWeekend.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20140203/454d3166/attachment.html>
More information about the rabbitmq-discuss
mailing list