This is the recommended way with Erlang.mk.
By default, the version is inherited from rabbitmq-server-release when
the source archive is created, or computed from git-describe(1) (see
`rabbitmq-components.mk`). One can override the version from the command
line by setting the `PROJECT_VERSION` variable.
[#130992027]
That is, SSL socket options that reside in the broker's OTP
environment. These are reverted in the plugin's `cleanup`
procedure. Indirect dependencies can then be restarted without their
SSL listeners interfacing with the trust-store.
TLS sockets (OTP's SSL) must be configured to interface with the
Trust-Store before they start listening. The boot-steps make sure that
the trust store makes the necessary amendments to the configuration
options in time. We put the initial SSL configuration options in the
OTP Application environment so that they can be restored if the plugin
is disabled.
Don't default to the (user's) home directory, this is far from ideal
on Linux systems, but worse with Windows because a home directory
doesn't exist there. Instead we dismantle the Mnesia directory and
root the default whitelist directory nearby. This is because Rabbit
doesn't use environment variables (e.g. RABBITMQ_HOME and
RABBITMQ_BASE) elsewhere in the source, as the definitive place to
root directories for application/pluging data.
NOTE: paths continue to append a "/" so commit is not Windows
friendly.
This fixes a bug when removing certificate details, which would cause
the trust-store server to crash, though the test set succeeded because
it got restarted by it's supervisor.
Refactor branching, procedure and case clauses, into simple matches
which'll fail on a bad result. The OTP Application no longer re-checks
preconditions, like the existance of the whitelist directory &
interface module/procedure, which are put in place at Rabbit Plugin
boot.
Fix buggy Application start when we get an empty list of SSL options.
A refresh interval of 0 SECONDS configures the trust-store for manual
whitelist refresh, i.e. to reflect the certificates currently in the
whitelist directory, via call to `rabbit_trust_store:refresh/0`. An
interval >= 1 SECONDS configures automatic refresh, as before, through
timers.
This fixes a related BUG: the degree of time accuracy was not
consistent between the application, server, and test set. The intended
unit is SECONDS, NOT milliseconds, to make configuration more
friendly. I.e. `60` seconds instead of `60 * 1000` milliseconds.
Store the filename along with certificate issuer name and serial
number, so as to perform a diff on the directory contents, then only
install and remove those entries which need it. We were deleting all
entries + reading in the entire (newer) contents of the directory when
directory modification time had changed.
Along the way it made more sense to optimise ETS for querying the
whitelist than it did to refresh it: the key is still the
unique/distinctive certificate value (issuer name & serial
number). While installing and removing certificates rely on a
`select`.
The client facing interface, `whitelisted/3`, ultimately makes a call
to the ETS table directly. That is, it no longer goes through the
`trust_store` process, which was unecessary.
Building the whitelist with a list is practicle initially but not
performant. Introduce a record `entry` which will contain a filename +
modification time in the whitelist.
This completes the client facing procedure `whitelisted/3` with which
SSL sockets effectively query the trust-store, introducing basic
functionality for the server internals, but simplifies matters by
using a list to store the whitelist information. Error logging for
debugging purposes is removed.
A `stop` procedure isn't necessary if the server will always find
itself in a supervision tree. We trap exits upon initialisation and
handle the reason `shutdown` in the procedure `terminate/2`, instead.
Clean the procedures `handle_call` and `handle_cast`.
* Give the interface procedure a meaningful name.
* Order the procedure's clauses by relevance.
* Log something informative for each clause.
* Dialyzer type & signature for the procedure.
This is a better choice than having the server retrieve the directory
name itself: (1) we can have guarentees earlier from the application,
and (2) it makes testing easier and clearer.
The test set would fail before it began because the application
couldn't retrieve a path to a whitlist directory from it's
configuration data. This change makes the application look for
whitelisted certificates in a default directory. The corresponding
test stops the application, changes the configuration, and starts it
to test with given configuration parameters.