Future release to include Alpine Linux as snapd host?

Hello,

I’m a fan of using Alpine Linux as a docker host due to its tiny footprint and am just wondering if there’s any work being done to implement snapd on Alpine Linux as a host?

Would there be any major caveats re: toolchain, init system? Alpine uses musl + openrc which appear to be somewhat unconventional in today’s glibc + systemd-proliferate world…

Anything else impeding progress on this front I’m not aware of?

Thanks!

Edit: Hope this is the right category in which to post this sort of question, feel free to move it if I have organized in error.

1 Like

Are you interesting in just using snapd inside a docker container based on the Alpine base images or are you interesting in running Alpine linux as a host OS directly?

As running a host directly - I don’t see the point of adding an additional layer through docker, but to be honest I hadn’t thought of that as even being an option.

Why do you ask for the distinction?

I asked the same question on Reddit in the Alpine Linux forum said they tried to build snapd on Alpine and ran into problems, but never said why or what they were exactly: https://www.reddit.com/r/AlpineLinux/comments/d2e1jj/snapd_for_alpine_linux/

Well we’ve already gone through the discussion about running snapd inside docker and it’s very difficult to do considering all the security confinement that has to be disabled for docker in order to allow snapd to run, so if that was your request then it would be a simpler answer.

As to actually building an apk of snapd for Alpine run natively, I don’t know of any efforts there, but certainly this is the right place to ask about it. I will ask around on the team to see if anyone else knows of any issues with building it or if we have any extra cycles to look into it (I am not familiar with apk packaging)

That’s great! Glad I’m finally on the right track

I found some generic APK build instructions with a template in their wiki here: https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package

Hopefully that’s helpful, sometimes their documentation is not very complete.

I really appreciate the correspondence, let me know if there’s any headway!

howdy, it’s the guy from the aforementioned reddit thread
After installing all the c libs (which were all in apk helpfully enough), I ran into problems compiling due to cgo not working properly in the alpine distribution of go.
I built go 1.13 from source, and that fixed the compilation issue(though I had to build it without using cgo in the build process which might prove to be problematic)
From there, it built using the go get command, but when I tried to run dockerd, I got the following error:

AppArmor status: apparmor not enabled

2019/09/11 21:26:31.393539 daemon.go:346: started snapd/unknown (series 16; classic; devmode) alpine/3.11_alpha20190809 (amd64) linux/4.19.68-0-vanilla.

cannot run daemon: state startup errors: [cannot obtain snap-seccomp version information: invalid format of version-info: “43426b4f715267684c314d423644714f573165442f4a35455a3865567168457735753651676a6e49572f6431794e714e496a73586a4c5564706f4e3555792f56485079374a4768413054336b78795736704843 2.4.1 8c73f36d3de1f71977107bf6687514f16787f639058b4db4c67b28dfdb2fd3af bpf-actlog”]

I’m not sure where to go from there beyond looking at how version info is milked from the snap-seccomp bin.

This is a bit surprising, the build ID looks like it’s a sha512 hash. Can you run file /usr/lib/snapd/snap-seccomp (assuming snap-seccomp is under /usr/lib/snapd in your pacakge).

Also, do you know if Alpine toolchain is configured to automatically add build IDs? If so then what hash is used?

I spoke with the team a bit about this (including @mborzecki) and the main blocker to running snapd on Alpine actually is that snapd relies on systemd being available, and it seems that Alpine uses OpenRC which means someone would have to work on writing a compatibility layer for snapd to use OpenRC instead of systemd. We certainly welcome patches in this area, but unfortunately don’t have that work planned any time soon.

In addition, there is still the issue relating to the build ID that was mentioned above, but that’s probably much easier to resolve than the missing systemd.

Interesting. I thought I saw something about how to install systemd on Alpine, but I’m having trouble finding it right now.

Could it be run in unshare just to meet the init dependencies, similar to how it’s run for WSL2? e.g.:

sudo daemonize /usr/bin/unshare --fork --pid --mount-proc /lib/systemd/systemd --system-unit=basic.target

Would probably have to build systemd, too, because I don’t see it in the repos. Oh well, I suppose I could always just start with the Ubuntu mini iso.

Yes you could try that if you have systemd available for alpine, but it’s not a supported way to run snapd so you might run into other subtle issues, but certainly if you run into issues trying to do this let us know or better yet send us patches for it :smile:

I would like to take the challenge. However, I admit, that I don’t know so much about Alpine, OpenRC, and snapd. Could you please send me more information on how snapd and its inner workings for writing a new compatibility layer should be approached.

Thank you.

Does lxc run in Alpine? It’s possible to have LXC => Ubuntu => Snap. LXC containers can be in subdirectories, and there is no layers taking disk space like in Docker.

See:

@xet7, yes it does; https://lunar.computer/posts/lxd-alpine/ show you how.

If you get the error message: RTNETLINK answers: Not supported then, install the missing linux-headers.

Maybe. However, I’ll prefer a clean solution for Alpine and other OpenRC init based (https://www.tecmint.com/best-linux-init-systems/) operating systems as there are for the other major dominating operating systems.

Thank you for your hints. I’ll look into them, too.

Forgot to hint @ijohnson about my proposition.

Probably your first step is to build snapd from source for Alpine using their packaging system, you can take a look at the other distro packaging we have for snapd in the source tree @ https://github.com/snapcore/snapd/tree/master/packaging

After you have built it, then you’ll probably need to tackle these things in order:

  1. You need to setup snapd to run at boot (I assume Alpine has some sort of service capability)
  2. You either need to implement a new systemd backend which actually is not systemd but something else that supports writing out new service units which get treated with the same semantics that systemd does, this includes not just services which run at boot, but also mount units and probably other sorts of things too, and also taking note that we need services to use ordering, so we need to be able to write service units that say “start A after B”, etc. There’s a lot of features here so you will probably spend the bulk of your time here.
  3. You also will probably need to hunt down all the instances over the codebase of calling “systemctl” since we tend to use that extensively for getting the state of services and lots of other operations, and either refactor those to use some other tool to interact with the init system, or you need to write a wrapper systemctl shell script on your system which translates everything in between
  4. If you do manage to get this far with a working snapd that can install snaps with services, congratulations. I’m sure there’s probably more work to be done at this point too, but I don’t know yet. At this stage though you could start looking at adding Alpine as a system in our spread testing matrix and run our integration tests on Alpine to see what else you need to modify to get it fully supported

@ijohnson

Thank you for your hints. I’ll look into these. See you around.