Official .deb / .rpm packages for gnatsd

[jfathman]

It would be great if NATS provided official Debian (and RPM?) packages for gnatsd. Just add the NATS repo to the apt sources list on an x86 server or RPi ARM IoT device, and 'apt-get install gnatsd'. Would start gnatsd as a service using default config. Would auto start on reboot. Would log gnats meta activity to a standard location.

Users of gnatsd (outside Docker) must be making their own deployment wrappers using .deb, .rpm, etc. As NATS adoption grows, that represents a lot of duplicate effort.

Ideally, with official packages from NATS.io, we could apt-get update/upgrade on x86 servers and RPi ARM IoT devices to sync up with a new version the day it is released. If we look to the NATS ecosystem to provide the packages, they will be unofficial, and will tend to lag behind NATS.io releases.

Just an idea. Thanks for NATS. It's great.

[jeefberkey]

Has there been any movement on this issue? I won't be able to use NATS until there's an rpm available.

[trevor-vaughan]

I think that this would be a great addition. If you want to get the RPM ready for EPEL, you'll need to make sure that it is built directly from source.

[petemiron]

Agreed on creating .debs and .rpms. This feature must meet the following requirements:

• Create .rpm and .deb
• Create users and groups for running NATS.
• Starting with systemd for daemon management
• Create default, but complete, config with commented out unused config items
• Update releases with .deb and .rpm
• Update documentation for installation on ubuntu-based and redhat-based OSs.

[trevor-vaughan]

@petemiron As a secondary priority, I would highly recommend also adding an SELinux policy to confine the running daemon. This is required by the DISA STIGs among other regulations.

[RedShift1]

Here's a head start: https://github.com/RedShift1/rpmbuild/blob/master/SPECS/gnatsd.spec and https://github.com/RedShift1/rpmbuild/tree/master/SOURCES

[RedShift1]

There appear to be subtle differences between the configuration file posted here and here. Which one is the correct one?

[RedShift1]

I've updated the spec file to build from source. (Found a ready-to-go example here). Can someone please take a look at my comment one up? Once that's done we can submit it to EPEL.

[kozlovic]

@RedShift1 I cannot comment much on the overall work (not my expertise), but to answer your question about the configuration file, the link to the actual repo is probably more up-to-date and accurate.

As for building the executable from source, I would replace the build command found here by this:

env CGO_ENABLED=0 go build -ldflags="-s -w" -o gnatsd .

This will match exactly how the release is built and published on the Github repo.

Let's see if @petemiron has more insight in the gnatsd.spec file.

[RedShift1]

@kozlovic That creates a static binary, which is frowned upon. Can that command be reworked to produce a stripped, but not statically linked binary? (Only for the RPM of course - not for the binaries published on the repo).

[kozlovic]

Then same without env GCO_ENABLED=0 should produced a dynamically linked, stripped, executable.

[RedShift1]

Ok that's settled then. Only need to add documentation and a manpage for gnatsd.

[jeefberkey]

If this is dynamically linked, would it by any chance use system openssl?

I'm not very experienced with packaging or development, but I know that if it uses the system openssl then it will be cryptographically valid for FIPS and other NIST guidelines.

[RedShift1]

Added preliminary versions of the manpage for gnatsd and documented configuration file.

[RedShift1]

@jeefberkey It does NOT use system OpenSSL (irregardless of linking), it uses the Go builtin crypto/tls package. A quick Google reveals there are bindings for OpenSSL, but this should really be discussed in a separate bug.

[RedShift1]

Any comments on the manpage/documented configuration file?

[petemiron]

@RedShift1 this looks really good. I'm going to create a new issue for RPM only. Then, can you create a PR with your RPM files in: gnatsd/scripts/rpm

[quotquot]

Regarding Debian, the easiest and best way to create packages is probably to use Michael Stapelbergs' dh-make-golang available in Debian unstable/sid (https://people.debian.org/~stapelberg/2015/07/27/dh-make-golang.html) and build a package for each component used by gnatsd. For example:

# apt install dh-make-golang golang-golang-x-crypto-dev
# dh-make-golang github.com/nats-io/nuid
# cd golang-github-nats-io-nuid
# dpkg-buildpackage -b -uc
# cd ..
# dpkg -i golang-github-nats-io-nuid-dev_1.0.0+git20180712.3024a71-1_all.deb
# dh-make-golang -type library github.com/nats-io/nkeys
# cd golang-github-nats-io-nkeys
# dpkg-buildpackage -b -uc
# cd ..
# dpkg -i golang-github-nats-io-nkeys-dev_0.0~git20180919.ca441f6-1_all.deb
# dh-make-golang github.com/nats-io/gnatsd
# cd gnatsd
# dpkg-buildpackage -b -uc

Unfortunately the last build fails because of test failures, but gnatsd would be built otherwise, I suppose. Then customizing debian package files and adding systemd scripts would be fairly easy.

Hope it helps.

[derekcollison]

Thanks. Will take a look.

[quotquot]

I may have spoken too fast: it seems to work at first because the build process installs files directly in golang's system directory, but apparently dh-make-golang does not package these files, only the source files. In other words, as far as I can tell, it does not work, though it could serve as a basis to create the final packages, especially by taking care of dependencies. I don't know Go so I can't help, but maybe somebody knowledgeable could get in touch with Michael Stapelbergs and see why the files are not packaged correctly.

[eclipseo]

I wouldn't mind a default conf file with logs enabled for this. Could anyone from the team make one?

[kozlovic]

We have built NATS Server v2.0.4 (https://github.com/nats-io/nats-server/releases/tag/v2.0.4) using Goreleaser which has produced deb and rpm packages. Closing this for now.