Rabbitmq: Listen to all interfaces

Created on 19 Jun 2017  路  10Comments  路  Source: docker-library/rabbitmq

When I start a rabbitmq container with -p 5671:5671 (and configure SSL), the port is published but the rabbitmq process in the container does not listen to the public network interface. In short, this does not work (the config created by entrypoint.sh):

...
{ ssl_listeners, [ 5671 ] },`
...

but this does when installing RabbitMQ on a plain VM:

...
{ ssl_listeners, [ {"0.0.0.0", 5671} ] },
...

I need this to be able to access rabbitmq from another machine over the internet. Is there any way to configure this with an environment variable?

Most helpful comment

OK, I re-read @ppawiggers' comment and now I see that I answered the wrong one.

@tianon there's a relevant note in RabbitMQ source code :) https://github.com/rabbitmq/rabbitmq-common/blob/5a6d690aca27215cde5384e61e14bd000eba3d5d/src/rabbit_networking.erl#L401.

All 10 comments

RabbitMQ will bind to all available interfaces by default, for both IPv4 and IPv6.

As of https://github.com/docker-library/rabbitmq/pull/159 you can configure many things via RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS (this applies to listeners, although it's fairly annoying) but I'm not sure why this should be necessary. Perhaps I'm missing something this image does when port settings are used.

I think if { ssl_listeners, [ 5671 ] } isn't listening on all available interfaces, we ought to debug what's going on. :confused:

(If SSL isn't used, we use { tcp_listeners, [ 5672 ] } instead, so it'd have the same issue.)

I've just tested the default config, which ends up being the following:

[ { rabbit, [
    { loopback_users, [ ] },
    { tcp_listeners, [ 5672 ] },
    { ssl_listeners, [ ] },
    { hipe_compile, false }
] } ].

And here's the output of netstat:

bash-4.3# netstat -ln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 0.0.0.0:4369            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:25672           0.0.0.0:*               LISTEN     
tcp6       0      0 :::4369                 :::*                    LISTEN     
tcp6       0      0 :::5672                 :::*                    LISTEN     
Active UNIX domain sockets (only servers)
Proto RefCnt Flags       Type       State         I-Node   Path

(Which all looks correct, and appears to be working properly.)

@tianon my netstat -tlpn output only shows the IPv6 address for port 5672, as is the case in your test. Is your instance (remotely) reachable on IPv4?

Nope -- it's common for daemons to listen on ::, as that covers both IPv6 _and_ IPv4 (it's the equivalent of 0.0.0.0 in IPv6, but the kernel normally uses it for IPv4 as well). I believe there might be a sysctl to disable that ":: is also IPv4 all-interfaces" behavior; any chance something like that is set on your host?

@ppawiggers @tianon's config above doesn't have a single TLS listener configured. If you expect the node to bind on port 5671, that's not supposed to happen with this config.

OK, I re-read @ppawiggers' comment and now I see that I answered the wrong one.

@tianon there's a relevant note in RabbitMQ source code :) https://github.com/rabbitmq/rabbitmq-common/blob/5a6d690aca27215cde5384e61e14bd000eba3d5d/src/rabbit_networking.erl#L401.

Sorry for my late reply, but it's been some debugging for me. Thanks for your replies btw.

The issues was that I was using the wrong certificates for the client. I use Sensu and there's a tool that generates certificates for you: 3 server certificates and 2 client certificates. I accidentally used the server's cert and key in the client configuration. I fixed that and Sensu client was able to communicate with RabbitMQ.

However, RabbitMQ was still refusing the user access to the vhost. On docker runtime, I set the RABBITMQ_DEFAULT_VHOST to sensu (as it says in the RabbitMQ Docker image documentation). In Sensu, the default vhost to use is /sensu and I assumed that that prepending slash would be automatically added in RabbitMQ, but that was not the case. Setting the RabbitMQ vhost to /sensu solved the issue.

So this is a non-issue (maybe fix the docs, or is the prepending slash a Sensu-specific thing?) and the issue can be closed.

Sorry for the slow reply but the / in the hostname seems specific to sensu but I am not that familiar with rabbitmq clients. Anyone else know?

I'll close since it doesn't seem to be a problem with the image, but instead a general rabbit question.

Was this page helpful?
0 / 5 - 0 ratings