Skip to content
This repository has been archived by the owner on Nov 18, 2020. It is now read-only.

RABBITMQ_ERLANG_COOKIE environment variable takes precedence over .erlang.cookie file #443

Closed
gerhard opened this issue Jul 1, 2020 · 1 comment · Fixed by #445
Closed
Assignees
Milestone

Comments

@gerhard
Copy link
Contributor

gerhard commented Jul 1, 2020

If RABBITMQ_ERLANG_COOKIE environment variable is set, the CLI commands will use this value instead of the .erlang.cookie file value.

If these 2 values do not match, the CLI commands will fail to communicate with the rabbit node. This has been mentioned in #252 before, and has a relevant rabbitmq-users thread.

To reproduce:

  1. Start RabbitMQ in development mode
$ pwd
/Users/gerhard/github.com/rabbitmq/3.9.x/deps/rabbit
$ make run-broker
...
  1. rabbitmqctl prefers the env var and fails to cluster with rabbit node
$ RABBITMQ_ERLANG_COOKIE=foo sbin/rabbitmqctl eval 'rabbit:status().'
Error: unable to perform an operation on node 'rabbit@focker'. Please see diagnostics information and suggestions below.

Most common reasons for this are:

 * Target node is unreachable (e.g. due to hostname resolution, TCP connection or firewall issues)
 * CLI tool fails to authenticate with the server (e.g. due to CLI tool's Erlang cookie not matching that of the server)
 * Target node is not running

In addition to the diagnostics info below:

 * See the CLI, clustering and networking guides on https://rabbitmq.com/documentation.html to learn more
 * Consult server logs on node rabbit@focker
 * If target node is configured to use long node names, don't forget to use --longnames with CLI tools

DIAGNOSTICS
===========

attempted to contact: [rabbit@focker]

rabbit@focker:
  * connected to epmd (port 4369) on focker
  * epmd reports node 'rabbit' uses port 25672 for inter-node and CLI tool traffic
  * TCP connection succeeded but Erlang distribution failed
  * suggestion: check if the Erlang cookie identical for all server nodes and CLI tools
  * suggestion: check if all server nodes and CLI tools use consistent hostnames when addressing each other
  * suggestion: check if inter-node connections may be configured to use TLS. If so, all nodes and CLI tools must do that
   * suggestion: see the CLI, clustering and networking guides on https://rabbitmq.com/documentation.html to learn more


Current node details:
 * node name: 'rabbitmqcli-49409-rabbit@focker'
 * effective user's home directory: /Users/gerhard
 * Erlang cookie hash: rL0Y20zC+Fzt72VPzMSk2A==
  1. The erl equivalent ignores the RABBITMQ_ERLANG_COOKIE env var and works as expected
$ RABBITMQ_ERLANG_COOKIE=foo erl -sname rabbitmqcli-49409-rabbit -eval 'io:format("~p~n", [rpc:call(rabbit@focker, rabbit, status, [])]), init:stop().'
Erlang/OTP 23 [erts-11.0.2] [source] [64-bit] [smp:20:20] [ds:20:20:10] [async-threads:1] [hipe] [dtrace]

Eshell V11.0.2  (abort with ^G)
(rabbitmqcli-49409-rabbit@focker)1> [{pid,48497},
 {running_applications,
     [{rabbit,"RabbitMQ","3.8.0+rc.1.349.g167c376"},
      {mnesia,"MNESIA  CXC 138 12","4.17"},
      {lager,"Erlang logging framework","3.8.0"},
...

The proposal is to deprecate RABBITMQ_ERLANG_COOKIE in RabbitMQ release series 3.8, and remove in 3.9

As a better alternative, --set-cookie flag should be added to address the use-cases where RABBITMQ_ERLANG_COOKIE was needed (see #180 & the related #182). This flag is similar to erl's -setcookie

As discussed with @michaelklishin & @dumbbell


gerhard added a commit to rabbitmq/rabbitmq-prometheus that referenced this issue Jul 1, 2020
Context: we want to move away from environment variables and use either
config files or env files (such as the rabbitmq-env.conf).

Since .erlang.cookie is neither, the official RabbitMQ Docker image
handles this by writing the value from the RABBITMQ_ERLANG_COOKIE env
var into the file if it does not exist. The problem is that if this file
exists, and the value is different from the RABBITMQ_ERLANG_COOKIE env
var, CLI tools will not be able to communicate with the rabbit node, as
described here: rabbitmq/rabbitmq-cli#443

The only gotcha is that this file must be owned by the user, and
privileges should not be too open (git should have captured this). If
not, RabbitMQ will fail to boot. This is somewhat similar to how OpenSSH
reacts when private key permissions are too open.

re docker-library/rabbitmq#422 (comment)

Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
@michaelklishin
Copy link
Member

michaelklishin commented Jul 1, 2020

--erlang-cookie is already supported.

@michaelklishin michaelklishin self-assigned this Jul 1, 2020
@michaelklishin michaelklishin added this to the 3.8.6 milestone Jul 1, 2020
michaelklishin added a commit that referenced this issue Jul 2, 2020
It's not worth the confusion it causes in practice since
the server does not support it.

Per discussion with @gerhard @dumbbell.

Closes #443.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants