enabled_plugins file should be stored in /var/lib/rabbitmq

[lukebakken]

[159039271]

System daemons should not expect to write to /etc. This causes issues in environments like docker where /etc is frequently on a read-only FS.

https://groups.google.com/d/topic/rabbitmq-users/DuxRP0zrMdA/discussion

It's unusual for an application to write to /etc, and as the above mailing list discussion shows, /etc is sometimes mounted read-only.

We should investigate supporting the plugins file first in /var/lib/rabbitmq, falling back to /etc/rabbitmq.

[michaelklishin]

Makes sense 👍

[HoloRin]

@lukebakken @michaelklishin I believe the broker won't start without a writable /var/lib/rabbitmq, so when we say fallback, do we mean to first look for /var/lib/rabbitmq/enabled_plugins, and if it does not exist look for it at the current location? I presume we would also want to log a warning if it is in /etc that the default has now changed (not to mention update all the docs).

[HoloRin]

So the behavior that I now have in mind is:
IF /var/lib/rabbitmq/enabled_plugins is present
we use it
ELSE
IF /etc/rabbitmq/enabled_plugins is present and writable
we use the /etc location, but log a console message that the location is deprecated
ELSE
we use the new /var location, but log a message that the file was ignored because it was not writable.

I believe this should be safe for upgrades, as with an existing read and writable file in /etc, the behavior is unchanged aside from the log messages.

[michaelklishin]

That sounds reasonable to me.

[lukebakken]

OK!

[HoloRin]

Work in progress is here: rabbitmq/rabbitmq-common#369
In short, I want to validate it's effects on the docker images before calling the PR ready.

[HoloRin]

After some further consideration, if the file is present in /etc but not writable, I think rather than ignoring it, we should copy it to the new location. Since it seems possible that if one never changes the enabled plugins through the cli, the broker could have been working for them with that file not writable. Doing the copy means that we won't suddenly disable their plugins, and if they later enable/disable and restart, that state will be honored as the new location would be writable.

[HoloRin]

I have solved the docker issue that I was running into, and the fix is here rabbitmq/rabbitmq-server-release#126

I believe these changes are now ready to go.

[HoloRin]

#2298 handles the change in the broker, but I'll need to make a corresponding change to the cli to handle use of the rabbitmq-plugins cli when used with --offline