We don't know yet if it is actually the case, but this is a safety for
the day Erlang 22.0 will be released, so that users are not in trouble
before we validated that RabbitMQ works with the new release.
[#160088605]
erlang-nox is a meta-package which pulls in most useful Erlang
applications for a developer. Unfortunately, it doesn't pin the version
of those packages. So for instance, erlang-nox 19.3 could pull in
erlang-base 21.0 without a warning.
This patch replaces this meta-package by all the "leaf" packages
RabbitMQ really depends on. By "really depends on", the list was reduced
compared to all the packages installed by erlang-nox, but it's still
conservative (i.e. it could probably be cleaned up further).
[#160232286]
The requirement is used to determine which version to pin. Before it had
to match exactly an available package version.
Now the script improved and it will use this requirement as a pattern
instead to figure out which package matches it. That's why the revision
must be dropped.
[#159273314]
https://www.rabbitmq.com/install-windows-manual.html#erlang-cookieFixes#81
packaging/windows: Look at Erlang 20.2+ cookie's location as well
While here, check if the cookie exists before copying it. This fixes an
uninformative error message in the installer output.
Use NSIS variable $SYSDIR
Adm should be group owner of everything in /var/log according to Debian/Ubuntu guidelines. Makes it possible for users in the adm group to read logs without sudo:ing.
Before this, this was working by chance because those dependencies were
brought by plugins. But if we build the package without any plugins, the
script complains about requires missing applications (kernel and
stdlib), and if we add hard-code them, it complains about other Erlang
applications not listed (sasl, mnesia, os_mon, ...).
See rabbitmq/rabbitmq-server#1359
This gives guidances for those users who wish to automatically restart RabbitMQ in the event of a failure. Tested by using the `Restart=on-failure` setting, then running `rabbitmqctl eval "erlang:halt(abort)."`
Ubuntu's Software Center reports a warning and Lintian reports the
following error:
E: rabbitmq-server: non-standard-toplevel-dir ets/
Reported by Giuliano Franchetto on #rabbitmq IRC channel.
On a fresh install, we want to limit access to the log directory to the
owner and group. This is in case sensitive data are logged.
We don't enforce the permissions on upgrade because:
1. We don't want to break exising installs by reducing
permissions.
2. The admin may want to setup different permissions.
References rabbitmq/rabbitmq-management#474.
[#150970897]
SLES 11 provides RPM 4.4 which fails to verify package signatures. It's
unclear what is the real cause, but all settings we tried were rejected
(v4/v3 signatures, MD5 or SHA1 digests).
So for now, disable package signing entirely for SLES 11.
[#150792874]
(cherry picked from commit c54728f51a)
Using GPG v3/v4 signatures wasn't the problem. My test was wrong: the
tested package was not signed. So even a GPG v3 signature is refused by
RPM.
In fact, it looks like RPM 4.4 has issues with package signature
verifications. Perhaps related to the SHA1 digest (but using an MD4
digest doesn't solve the problem). The cause is unclear.
Only RPM 4.4 is available on SLES 11. So for now, revert this change.
This reverts commit dc783c737a.
(cherry picked from commit 703081cdc0)
SLES 11 provides RPM 4.4 which fails to verify package signatures. It's
unclear what is the real cause, but all settings we tried were rejected
(v4/v3 signatures, MD5 or SHA1 digests).
So for now, disable package signing entirely for SLES 11.
[#150792874]
Using GPG v3/v4 signatures wasn't the problem. My test was wrong: the
tested package was not signed. So even a GPG v3 signature is refused by
RPM.
In fact, it looks like RPM 4.4 has issues with package signature
verifications. Perhaps related to the SHA1 digest (but using an MD4
digest doesn't solve the problem). The cause is unclear.
Only RPM 4.4 is available on SLES 11. So for now, revert this change.
This reverts commit dc783c737a.
It looks like RPM on SLES 11 fails to handle GPG v4 signatures, even
though it happily signed it:
# rpm -K -vvv ./rabbitmq-server-3.7.0~alpha.378-1.sles11.noarch.rpm
./rabbitmq-server-3.7.0~alpha.378-1.sles11.noarch.rpm:
Header V4 RSA/SHA1 signature: BAD, key ID 6026dfca
Header SHA1 digest: OK (895933d0ba5eca00759ebdfaa0d4e5d156ad0985)
V4 RSA/SHA1 signature: BAD, key ID 6026dfca
MD5 digest: OK (422c5b455a0f63055d5cd8701da8064b)
After forcing a GPG v3 signature, the signature check is successful:
# rpm -v -K ./rabbitmq-server-3.6.12.rc2+1.gf3f347e.dirty-1.sles11.noarch.rpm
./rabbitmq-server-3.6.12.rc2+1.gf3f347e.dirty-1.sles11.noarch.rpm:
Header SHA1 digest: OK (a9235a3ec1f7a893bd1fe2ec20c011542cfe88d4)
MD5 digest: OK (fd555d5b73180efcb8232f1f0a5a8a61)
[#150792874]
(cherry picked from commit 051f230096)
It looks like RPM on SLES 11 fails to handle GPG v4 signatures, even
though it happily signed it:
# rpm -K -vvv ./rabbitmq-server-3.7.0~alpha.378-1.sles11.noarch.rpm
./rabbitmq-server-3.7.0~alpha.378-1.sles11.noarch.rpm:
Header V4 RSA/SHA1 signature: BAD, key ID 6026dfca
Header SHA1 digest: OK (895933d0ba5eca00759ebdfaa0d4e5d156ad0985)
V4 RSA/SHA1 signature: BAD, key ID 6026dfca
MD5 digest: OK (422c5b455a0f63055d5cd8701da8064b)
After forcing a GPG v3 signature, the signature check is successful:
# rpm -v -K ./rabbitmq-server-3.6.12.rc2+1.gf3f347e.dirty-1.sles11.noarch.rpm
./rabbitmq-server-3.6.12.rc2+1.gf3f347e.dirty-1.sles11.noarch.rpm:
Header SHA1 digest: OK (a9235a3ec1f7a893bd1fe2ec20c011542cfe88d4)
MD5 digest: OK (fd555d5b73180efcb8232f1f0a5a8a61)
[#150792874]
This matches the distribution name and version we want to target (i.e.
SLES 11). In the future, we might want to also create an SLES 12
package.
Also, enable the new package in the default build. Before this, the
default target (`all`) would call `package-rpm-opensuse`. So
`package-rpm-suse` and `package-rpm-opensuse1012` were unused.
While here, the RPM-specific targets were reworked a bit. Here is the
dependency tree:
package
`-- package-rpm
|-- package-rpm-redhat
| |-- package-rpm-rhel6
| `-- package-rpm-rhel7
`-- package-rpm-suse
|-- package-rpm-opensuse
`-- package-rpm-sles11
For some reason, package-rpm-fedora isn't called at all. I don't know
why, this needs to be investigated.
This reverts part of commit 851561953a.
We need to hard-code the dependency on init-system-helpers to support
Ubuntu 14.04.
(cherry picked from commit 12d2edad42)
... which are added by debhelper. In this case, this is
init-system-helpers which is added by dh-systemd.
While here, bump the standard version to 3.9.6.
(cherry picked from commit 851561953a)
... which are added by debhelper. In this case, this is
init-system-helpers which is added by dh-systemd.
While here, bump the standard version to 3.9.6.
Recent openSUSE releases have been migrated to systemd so use the
%{suse_version} macro to detect if we are building on openSUSE
so we can include the necessary systemd files and also perform the
needed systemd steps. This also defines the 'suse_version' to 1315
which is what openSUSE Leap 42.x use. This also drops the buggy rhel7
conditional for the sysvinit script and use another 'find' command
instead. The previous condition was wrong since it would also try
to include the sysvinit file on openSUSE and Fedora which do not
define the %rhel macro and as such the 0 < 7 conditional was always
true.
(cherry picked from commit 2211e5fe44)
Shortcuts for `rabbitmq-service.bat` should run as admin
because system control tools require admin.
Also make shortcuts run a command prompt and do not exit if there
is an error, so the error can be seen by an operator.
Part of rabbitmq/rabbitmq-server#1324
[#149953545]
In the old release build script, Erlang is already provided. However in
CI, Erlang is installed later in the Makefile recipe. Thus, display its
version only once we are sure Erlang is available.
(cherry picked from commit 5cb41b9434)
This should help us diagnose situations where the version of Erlang used
to compile is greater than the minimum supported.
(cherry picked from commit 679518f911)
In the old release build script, Erlang is already provided. However in
CI, Erlang is installed later in the Makefile recipe. Thus, display its
version only once we are sure Erlang is available.
systemd considers that, when the ExecStop commands exit, the service is
stopped. If there are remaining processes in the cgroup, they are
killed.
Unfortunately, `rabbitmqctl stop` doesn't wait for the Erlang VM to
exit, it just notifies RabbitMQ to stop. Because it doesn't wait,
systemd kills other processes such as `erl_child_setup`. When this
happens, the Erlang VM crashes (because it can't reach `erl_child_setup`
anymore) and the service enters the failed state in systemd. Note the
"erl_child_setup closed" message in the following output:
[root@ip-172-31-29-47 package-testing]# systemctl status rabbitmq-server
● rabbitmq-server.service - RabbitMQ broker
Loaded: loaded (/usr/lib/systemd/system/rabbitmq-server.service; disabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Mon 2017-07-31 14:54:42 UTC; 1s ago
Process: 26763 ExecStop=/usr/sbin/rabbitmqctl stop (code=exited, status=0/SUCCESS)
Process: 26398 ExecStart=/usr/sbin/rabbitmq-server (code=exited, status=1/FAILURE)
Main PID: 26398 (code=exited, status=1/FAILURE)
Status: "Initialized"
Jul 31 14:54:30 ip-172-31-29-47 rabbitmq-server[26398]: completed with 0 plugins.
Jul 31 14:54:40 ip-172-31-29-47 systemd[1]: Stopping RabbitMQ broker...
Jul 31 14:54:41 ip-172-31-29-47 rabbitmqctl[26763]: Stopping and halting node 'rabbit@ip-172-31-29-47'
Jul 31 14:54:41 ip-172-31-29-47 rabbitmq-server[26398]: Gracefully halting Erlang VM
Jul 31 14:54:41 ip-172-31-29-47 rabbitmq-server[26398]: erl_child_setup closed
Jul 31 14:54:42 ip-172-31-29-47 rabbitmq-server[26398]: Crash dump is being written to: erl_crash.dump...done
Jul 31 14:54:42 ip-172-31-29-47 systemd[1]: rabbitmq-server.service: main process exited, code=exited, status=1/FAILURE
Jul 31 14:54:42 ip-172-31-29-47 systemd[1]: Stopped RabbitMQ broker.
Jul 31 14:54:42 ip-172-31-29-47 systemd[1]: Unit rabbitmq-server.service entered failed state.
Jul 31 14:54:42 ip-172-31-29-47 systemd[1]: rabbitmq-server.service failed.
Now, we add a second ExecStop which simply waits for the Erlang VM PID
to disappear. This looks to fix the issue.
[#149807109]
The erlang-* 1:16.b.3 packages family (note the absence of the package
revision) was only partially uploaded to the Erlang Solutions Debian
repository... For instance, we have erlang-nox 1:16.b.3 and 1:16.b.3-3,
but only erlang-base 1:16.b.3-3 :-/
[#131645781]
We use mk-build-deps(1) from the `devscripts` package to help us with
this. This helper script looks at `debian/control` and creates a
meta-package which depends on the build dependencies. Then we only have to
install it to get those dependencies.
We only do this if `$(INSTALL_BUILD_DEPS)` is set to `yes`. We want to
use this feature in CI, but not with the old build script where we cheat
a lot around Erlang and Elixir packages.
[#131645781]
Recent openSUSE releases have been migrated to systemd so use the
%{suse_version} macro to detect if we are building on openSUSE
so we can include the necessary systemd files and also perform the
needed systemd steps. This also defines the 'suse_version' to 1315
which is what openSUSE Leap 42.x use. This also drops the buggy rhel7
conditional for the sysvinit script and use another 'find' command
instead. The previous condition was wrong since it would also try
to include the sysvinit file on openSUSE and Fedora which do not
define the %rhel macro and as such the 0 < 7 conditional was always
true.
The `PRODUCTVERSION` must be four integers. So try to replace
everything following the first three integers in the the
semver-formatted `$(VERSION)` by `.0`. For instance if `$(VERSION)` is
`3.6.8+1.g1dcb221`, `PRODUCTVERSION` will be set to `3.6.8.0`.
This should make Windows installer builds successful out-of-the-box.
This is still possible to override this behavior by setting the
`$(PRODUCT_VERSION)` Make variable.
[#142391637]
This boot script is required by escript(1). Without it, escript(1) fails
with the following error:
{"init terminating in do_boot",{'cannot get bootfile','start_clean.boot'}}
init terminating in do_boot ()
[#141679931]
(cherry picked from commit 7ffe744d66)
The problem is that xargs(1) has a limit on the number of bytes
it reads on stdin and we reach it. This leads to an archive
containing half of the expected files and xargs(1) never complains.
We apply the same fix which was previously appled in commit
b9dd874671.
[#141674113]
(cherry picked from commit 178fa534ea)
This boot script is required by escript(1). Without it, escript(1) fails
with the following error:
{"init terminating in do_boot",{'cannot get bootfile','start_clean.boot'}}
init terminating in do_boot ()
[#141679931]
The problem is that xargs(1) has a limit on the number of bytes
it reads on stdin and we reach it. This leads to an archive
containing half of the expected files and xargs(1) never complains.
We apply the same fix which was previously appled in commit
b9dd874671.
[#141674113]
The `standalone-linux-x86_64` package will be used as a base for our BOSH
release. At least we'll experiment with this approach.
The `standalone-freebsd-x86_64` package is mostly for my local tests.
[#141141909]
The RPM's changelog is now updated automatically if no entry match the
version being built. This is being handled by the parse-changelog.sh and
update-changelog.sh scripts.
Both VERSION and RPM_VERSION are still accepted. If the latter is
unspecified, it is derived from VERSION.
Package signing is now handled here, instead of the Umbrella. This makes
this Makefile on par with the Debian package's Makefile. This Makefile
still accepts KEYSDIR or GNUPG_PATH, but they are deprecated: one should
simply set GNUPGHOME.
In the end, the Makefile is still compatible with the current way of
building a RabbitMQ release but it will simplify the job of Concourse.
As a bonus, there is a new script called compare-rpm-versions.py: it
compares two given versions (including the package revision) using RPM.
This helps when testing versioning.
[#131645695]
The `check-changelog.sh` script is transformed to `update-changelog.sh`.
It doesn't care anymore if $UNOFFICIAL_RELEASE is set or not. It simply
verifies if the given version matches the last entry of
`debian/changelog` (without taking the package revision into account).
If the last entry doesn't match, it prepends a new automatically
generated entry.
Also, the Makefile takes both `VERSION` and `DEBIAN_VERSION` as input
variables. `VERSION` is the RabbitMQ version (eg. `3.6.7-alpha.62`)
and `DEBIAN_VERSION` is the same version formatted for Debian (eg.
`3.6.7~lpha.62`). If the latter is missing, it's computed from `VERSION`.
Regarding package signing, `GNUPG_PATH` is deprecated. The caller should
instead directly use `GNUPGHOME`, the documented variable expected by
GnuPG.
In the end, the Makefile is still compatible with the current way of
building a RabbitMQ release but it will simplify the job of Concourse.
As a bonus, there are two new scripts:
o scripts/get-debian-package-files-list.sh: List all files making a
Debian package, based on a specified `.changes` file.
o scripts/compare-debian-versions.py: Compare two given versions
(including the package revision) using APT. This helps when testing
versioning.
[#131645209]
Otherwise erl.diff cannot be applied:
patch -o rabbitmq_server-3.7.0.milestone8/release/rabbitmq_server-3.7.0.milestone8/erts-8.2/bin/erl rabbitmq_server-3.7.0.milestone8/release/rabbitmq_server-3.7.0.milestone8/erts-8.2/bin/erl.src < erl.diff
patch: **** Can't create file rabbitmq_server-3.7.0.milestone8/release/rabbitmq_server-3.7.0.milestone8/erts-8.2/bin/erl : Permission denied
The default mode of `$prefix/lib/erlang/bin/erl` is 0755.
Because we compile Erlang from sources as part of a release build, there
is no issue. Debian and FreeBSD packages follow the official mode too,
so when testing on those, it still works. However, Homebrew changes the
mode to 0555, which breaks our `Makefile` expectation.
Otherwise erl.diff cannot be applied:
patch -o rabbitmq_server-3.7.0.milestone8/release/rabbitmq_server-3.7.0.milestone8/erts-8.2/bin/erl rabbitmq_server-3.7.0.milestone8/release/rabbitmq_server-3.7.0.milestone8/erts-8.2/bin/erl.src < erl.diff
patch: **** Can't create file rabbitmq_server-3.7.0.milestone8/release/rabbitmq_server-3.7.0.milestone8/erts-8.2/bin/erl : Permission denied
The default mode of `$prefix/lib/erlang/bin/erl` is 0755.
Because we compile Erlang from sources as part of a release build, there
is no issue. Debian and FreeBSD packages follow the official mode too,
so when testing on those, it still works. However, Homebrew changes the
mode to 0555, which breaks our `Makefile` expectation.
With this patch it's possible to run `dpkg-buildpackage` any number
number of times from single source directory. Otherwise `dpkg-source`
thinks that sources were modified and fails to execute.
`clean-unpacked-source-dist` is needed because `make clean` doesn't
descend into `deps/` folder, and doing `make clean APPS_DIR=deps` breaks
on `licensing/` which doesn't have makefile.
Calling `patch-sockjs` is necessary to be sure that no files in source dist
tarball will not be touched during build.
Our packaging Makefiles already take care of not exporting `DEPS_DIR`.
This is to make sure a user setting (eg. `DEPS_DIR` set globally in the
environment) doesn't break the package build either.
A Debian package is built with a Makefile, `debian/rules`. This Makefile
inherited all variables defined on the command line, even though we
unexported the dangerous ones.
We need to unset `MAKEOVERRIDES` to prevent GNU Make from passing them
in `MAKEFLAGS`.
Everything comes from the rabbitmq-server repository. The goals of this
move are:
1. separate unrelated files: the broker sources and release
handling comprising plugins;
2. resolve an important dependency cycle: plugins depend on the
broker to run, but the broker depends on plugins to build a
release.
[#130659985]