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.