Alpine Packaging

[andar1an]

Hello,

It is pretty straight forward to get up and running with cargo, but it would be neat to see some major distros such Alpine/Gentoo, Arch, and Nix supported.

I personally use Alpine right now, and wonder if there plans to create packages/releases to support running the service under openrc on Alpine/Gentoo-like distros?

For example typical daemons in Alpine Package Keeper generally have an openrc and a binary package which can make it a breeze to get up and running without containerization (can check out HAProxy of Nginx as examples)

[ximon18]

Hi @andar1an,

Thankyou very much for taking the time to tell us about your idea.

We don’t have any experience in building such packages but if someone wants to contribute support for them to Ploutos (which we use for building packages) that would be very welcome.

Ximon

[andar1an]

Does Ploutus manage PR's for upstream distro package manager repositories? I am unsure how Ploutous works with distro package managers, but I will read more.

I was thinking more along the lines of publishing the package in the package managers of other distros that also enable configuration of services. This is an example of Garage, a cool Rust project by deux fleurs in the aports repo for alpine.

Here, installing the package also brings in init and config files for the openrc that is then possible to easily add to openrc init and supervise daemon.

The APKBUILD file basically will pull in the built cargo binary, or build from source and make sure that they are placed in the correct place for the specific distro, while enabling configuration of the service through openrc config and init files. Iirc emerge, nix, and arch package managers will do similar.

I personally have been working more towards immutable deployments (e.g. https://grahamc.com/blog/erase-your-darlings/), and being able to manage a world file and config through a distro's package manager can make that much more simple and accessible.

I do imagine that is more work to maintain, especially if you want to add 3-4 other distros under the umbrella, but I thought it may be worth consideration, because the value of visibility and simplicity to users is pretty substantial.

I have a bit of experience with Aports, and if you would like can try to put up a PR there as I tinker on this, if that is acceptable.

[ximon18]

Does Ploutus manage PR's for upstream distro package manager repositories? I am unsure how Ploutous works with distro package managers, but I will read more.

No.

Ploutos is a GH workflow that creates packages as GitHub Actions artifacts for Rust projects in DEB, RPM and Docker formats. It can also publish to Docker Hub.

We then have a separate in-house process that takes the produced DEB and RPM packages from the workflow artifacts and publishes them on packages.nlnetlabs.nl.

I was thinking more along the lines of publishing the package in the package managers of other distros that also enable configuration of services. This is an example of Garage, a cool Rust project by deux fleurs in the aports repo for alpine.

I'm not aware of Garage.

We don't build any packages for upstreams nor do we ensure (but also don't intend to hinder) that our produced packages comply with upstream distro packaging requirements. We are a small team so ideally others take our code and package it for upstreams. We only produce packages at all because there are those who want packages for our software that are not yet packaged by upstreams.

Here, installing the package also brings in init and config files for the openrc that is then possible to easily add to openrc init and supervise daemon.

The APKBUILD file basically will pull in the built cargo binary, or build from source and make sure that they are placed in the correct place for the specific distro, while enabling configuration of the service through openrc config and init files. Iirc emerge, nix, and arch package managers will do similar.

I personally have been working more towards immutable deployments (e.g. https://grahamc.com/blog/erase-your-darlings/), and being able to manage a world file and config through a distro's package manager can make that much more simple and accessible.

I do imagine that is more work to maintain, especially if you want to add 3-4 other distros under the umbrella, but I thought it may be worth consideration, because the value of visibility and simplicity to users is pretty substantial.

I have a bit of experience with Aports, and if you would like can try to put up a PR there as I tinker on this, if that is acceptable.

As we have limited resources but also limited knowledge of and ability to create and test packages for distro packaging processes, having others with that knowledge and the time to maintain such packaging indeed has our preference, and is how distro packaging is done for other NLnet Labs products such as NSD and Unbound.

So if you think you can help in some way we would very much welcome that.

Ximon

[andar1an]

I can't commit to long term maintenance, as I have not yet tested krill, but I can put together a PR for Aports as I put together build files for myself, and at the very least the files can always be used to host package in a private apk repository.

Will update when I have done this.

[andar1an]

@ximon18, Sorry it has taken me so long to get to this, I have finally started to work on it. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/86707

Would if be okay if I use this issue for feedback, specifically to do with what the best default and service config? I haven't gotten to those yet but I will try to soon.

[andar1an]

Hi @ximon18,

I could have sworn I saw tini as a build dependency at some point, but I don't anymore and am not using. Is that okay?

While building I am noticing that there are many binaries and files, and I want to make sure I install them properly.

The list is:

krill
krill.d
krillc
krillc.d
krillta
krillta.d
krillup
krillup.d
libkrill.d
libkrill.rlib

Based on cargo.toml, it seems that the main krill package should install krill and krillc while krillta, and krillup should be subpackages. Is this correct thinking?

Also, are the *.d makefile-compatible dependency lists necessary post build for some reason?

Do I need to move libkrill.rlib somewhere?

Update: Parking this link here as a good reference summary for cargo build artifacts: https://stackoverflow.com/questions/47528244/which-files-from-the-target-directory-are-actually-required-by-the-executable

[ximon18]

Hi @andar1an,

tini relates to Docker and is installed as an apk package inside the Docker image of Krill.

For DEB and RPM packages there is no tini dependency and we indeed separate out krillup and krillta into their own packages, but for Docker all executables are included in a single image.

libkrill is not an executable and is not something you need to use.

I'm afraid I'm not sure what you mean regarding makefiles. We build Krill using the Rust cargo tool and we build O/S packages using cargo-deb and cargo-generate-rpm.

As an end user of Krill you should only need to follow the installation instructions in the documentation here: https://krill.docs.nlnetlabs.nl/en/stable/

I hope that answers your questions.

Ximon

[andar1an]

Thanks @ximon18, I am just not sure what the *.d files are in the release directory, at the moment I am just ignoring, but didn't know if they were important. I did not notice them being referenced in the cargo.toml install instructions.

One last question, with the starting and stopping of krill, I notice a log file defined as "SCRIPT_OUT" variable. Why is it called that? Is it just a log file, or is there some special use?

I just pushed some changes in above link if you would like to see also. Not complete, but making progress.

having 1 test failure at the moment that I need to figure out, but getting there:

failures:

---- commons::eventsourcing::test::event_sourcing_framework stdout ----

thread 'commons::eventsourcing::test::event_sourcing_framework' panicked at src/commons/eventsourcing/test.rs:452:51:
called `Result::unwrap()` on an `Err` value: Custom("unknown entity: alice")
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    commons::eventsourcing::test::event_sourcing_framework

test result: FAILED. 159 passed; 1 failed; 1 ignored; 0 measured; 0 filtered out; finished in 11.01s

[ximon18]

Hi @andar1an,

You can ignore the .d files, you only need the executable binaries.

The reference to SCRIPT_OUT is a temporary shell variable name used to redirect output in an example start/stop script in the Krill docs which only serves to capture STDOUT in a file named something other than nohup.out I think.

That script is only a documentation example, it is not part of what we provide as part of Krill packages. For the actual O/S packages they use systemd to start and stop Krill, and log output is controlled by Krill configuration file settings.

Ximon

[ximon18]

Hi @andar1an,

That test failure is not expected.

However, I haven't worked on Krill for quite a while, if you can't resolve the issue then @partim and @Koenvh1 may be able to better help than I.

Ximon

[ximon18]

Hi @andar1an,

You may also find the pre and post O/S package install scripts in https://github.com/NLnetLabs/krill/tree/main/pkg/debian and https://github.com/NLnetLabs/krill/tree/main/pkg/rpm useful.

Ximon

[andar1an]

Cool, sorry to keep tagging, I assumed you were best point of contact from previous messages.

Alpine doesn't use systemd, by default it uses openrc, so I will integrate with syslog for logging.

I do plan to also test with dinit in future so I can give some feedback there eventually too. I am not part of alpine team, just a user who thinks this would be great addition and trying to get this into aports.

Will take a look at those scripts, also needed to see if there were pre and post upgrade scripts. Now I know where to look! Thank you!