dist: build software packages

[matzf]

Create software installation packages for the individual SCION components (router, control service, daemon, dispatcher, gateway and tools).

Platforms: linux amd64, arm64
Package formats: .deb, .rpm.
Minimal system integration by providing systemd. Statically linked binaries and no requirements on libc etc, thus targeting all "modern-ish" distributions (Debian >=8, RHEL >= 7 and derivatives).

This is a first step, supporting other formats, platforms etc. may be added later.
For now, we'll only build the packages. Later we'll investigate where we can publish them. The idea is to build the packages using bazel rules_pkg. This may not lead to the perfect packages, but it should work for a start.

[MatthewCroughan]

Today I have been implementing https://docs.scion.org/en/latest/tutorials/deploy.html as a NixOS Test, so that the freestanding deployment can be independently verified by anyone. This work also necessarily bootstraps the necessary nixosModules for running the SCION go software stack as services on NixOS.

In doing so I found a distro specific quirk, (maybe a debian/ubuntuism?) that prevented me from using the software from the repo as-is. The scion-dispatcher has a default configuration for the socket file it creates, it wants to create it at /run/shm, and so will symlink /dev/shm -> /run/shm, but this seems unnecessary, and googling this sort of thing results in discussions about ubuntu/debian, this symlink appears distro specific, this is also supported by this comment line

scion/scion.sh

Line 93 in 0871860

# Ensure base dir for dispatcher socket exists; on ubuntu this symbolic link to /dev/shm always exists.

Reliance on well-known paths, or distribution specific paths is probably not a good default setting for the dispatcher, or any other program in the stack

[matzf]

Hey @MatthewCroughan, thanks for your feedback. I agree, /run/shm/dispatcher/default.sock seems like an odd odd place to put the dispatcher's socket. The more natural place, to me, would seem to be something like /run/scion-dispatcher.sock (or /var/run). I don't really know why the /run/shm/dispatcher/ path was historically chosen.

The various symlinks in and between /run, /var/run, etc. are indeed confusing, they exist for various historical reasons (see e.g. https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard).

Aside from the odd subdirectory, having a well-known path to a socket in /run/ seems like an established pattern. Perhaps, providing a consistent way to globally override this via some environment variable could still be a good improvement.
However, as the dispatcher socket will disappear entirely hopefully relatively soon with #4344, this question will become moot and I think it's not worth fiddling with the socket path this at this point.

[jiceatscion]

.deb and openwrt are done.

We do not yet have rpm packages, but then, I don't remember anyone asking for it.
Will ask around and of there's no interrest I will close this as done.

[MatthewCroughan]

I should note that SCION support has been added to NixOS for the past few months, and there is some SCIONLab documentation at https://wiki.nixos.org/wiki/SCION.

The PRs to NixOS that implemented this are mostly visible here https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+scion+is%3Aclosed

There are some issues about the lack of licensing on various SCION related projects that prevents their packaging and inclusion on NixOS however, which can be seen here scionproto/awesome-scion#3

[jiceatscion]

Noone clamored for rpms, but since I do use fedora, and since I had a couple of afternoons to kill, I looked into it.
Thanks to updated rpm_pkg rules, that's not as hard as I anticipated, so I'm finishing the job.

[jiceatscion]

...unfortunately rpm packages are x86_64 only for now, though. The other targets are waiting for bazelbuild/rules_pkg#727 (or we need multi-arch CI systems or we need to use legacy rpm rules that suck).