Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dist: build software packages #4425

Closed
matzf opened this issue Oct 27, 2023 · 7 comments · Fixed by #4632
Closed

dist: build software packages #4425

matzf opened this issue Oct 27, 2023 · 7 comments · Fixed by #4632
Assignees

Comments

@matzf
Copy link
Contributor

matzf commented Oct 27, 2023

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.

@matzf matzf self-assigned this Oct 27, 2023
@nixinator

This comment was marked as off-topic.

@MatthewCroughan
Copy link
Contributor

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
Copy link
Contributor Author

matzf commented Feb 19, 2024

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
Copy link
Contributor

.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
Copy link
Contributor

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
Copy link
Contributor

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 added a commit that referenced this issue Oct 10, 2024
Unfortunately, the new style rpm_rules (the ones that I find remotely
usable) do not appear to support cross-architecture packaging yet. So,
this is x86_64 only for now.

Fixes #4425

---------

Co-authored-by: FR4NK-W <[email protected]>
@jiceatscion
Copy link
Contributor

...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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants