[WIP] Add LXC package

[rbrownwsws]

Motivation: Add a package for LXC. Unlike the existing docker package which focuses on application containers LXC allows for the easy creation of system containers that have a more VM like experience.
Linked issues:

Checklist

• Build rule all-supported completed successfully
• Package upgrade completed successfully
• New installation of package completed successfully

For the last couple of days I have been playing with LXC to see if I can use the limited resources of my NAS more efficiently when I do not need full VM levels of isolation. I don't know if I will get around to making this a fully polished package but I thought I would share what I have done so far in case anyone else is interested.

Privileged containers with a bridge+NAT network seem to be working fine. I have not tried unprivileged containers or other network configurations yet.

N.B. This package does not activate the AppArmor profiles at the moment so will be less secure than docker containers. You should not use it to host any possibly risky services as it will be easier for malicious users to escape the container than normal.

So far I have only been been building for my DS918+ (arch-apollolake-6.2) but the LXC github claims it should work on at least the following architectures:

• i686
• x86_64
• ppc, ppc64, ppc64le
• s390x
• armvl7, arm64

Quick instructions if you want to have a go but have not used LXC before:

# Create the container "my-container-name" using the template "download"
sudo lxc-create -t download -n my-container-name

# Choose the image to download when prompted. I've been using:
# Ubuntu
# Focal
# amd64

# Start the container
sudo lxc-start -n my-container-name

# Check the container is running
sudo lxc-ls -f

# Attach to (get a shell in) the container
sudo lxc-attach -n my-container-name

# Do stuff in your container!

# Get back to the host shell
exit

# Stop the container
sudo lxc-stop -n my-container-name

# Delete the container
sudo lxc-destroy -n my-container-name

P.S. Thanks for your great project. It made things so much easier than having to faff around with the Synology package toolkit.

[th0ma7]

This is a really interesting PR, well done. I will certainly give it a shot when I find cycles.
Things that's worth looking:

• Check at using a conf/privilege (@hgy59 or @publicarray may be able to give pointers)
• For apparmor I haven't found much in the DSM7 dev manual (https://global.download.synology.com/download/Document/Software/DeveloperGuide/Firmware/DSM/7.0/enu/DSM_Developer_Guide_7_0_Beta.pdf). Perhaps worth contacting Synology to get advices?

[rbrownwsws]

* Check at using a `conf/privilege` (@hgy59 or @publicarray may be able to give pointers)

I'm not sure what the correct way is to do this. This package is a bit weird in that it needs the spksrc.service.privilege-startasroot template because it messes with kernel modules and the network in the SSS script but it has no real "service" process.

I did not know how to use the "generic service support" variables when I do not actually have some kind of daemon to run so I wrote a temporary workaround. Unfortunately it conflicted with a recent commit so I just removed it when I rebased my work for the pull request.

[hgy59]

@rbrownwsws have you already solved the cross compile issue in the configure step of lxc?

checking host distribution... checking for /etc/redhat-release... configure: error: cannot check for file existence when cross compiling

[rbrownwsws]

@hgy59 I've not had a go at cross-compiling yet. So far I have only been trying to get it working on my own machine.

In this case it might just be as simple as adding something like --with-distro=debian to CONFIGURE_ARGS to stop it from trying to detect the distro.

[rbrownwsws]

I tried the fix and compiled arch-hi3535-6.1 without any errors. I haven't got anything to try it on so who knows if it actually works, but I got a finished lxc_hi3535-6.1_4.0.6-1.spk out.

[rbrownwsws]

From the GitHub action it seems like I was lucky with my choice and there are some other problems with cross compiling.

It looks to be mainly related to compiling the iptables stuff. Iptables and the xt_CHECKSUM kernel module are not strictly necessary but I included them to get the default networking running. If the default networking was disabled LXC might work fine on them, you would just have to set up the network yourself (or ideally patch the network script so that does not need xt_CHECKSUM).

Annoyingly a lot of the other failures seem to be unrelated to my code. I bumped the version of libcap so github is trying to build ntopng which depends on it. The ntopng build then seems to be failing because it depends on a vulnerable version of expat which has been taken down to prevent people from using it.

[rbrownwsws]

As part of working on getting the LXC AppArmor profiles working I've made a package for the AppArmor user space tools:

https://github.com/rbrownwsws/spksrc/tree/apparmor/pr

Edit: I have merged a more up-to-date version of this with the branch lxc/pr now

It looks like it works but I have not really taken it for a spin yet. I'm leaving further testing for the weekend.

I'm afraid it's probably a bit yucky as I have no idea what I am doing with cross-compiling the python binding code. I just took a stab at different CFLAGS etc. until I stopped getting errors and then bundled all of python to make it easier for me.

I don't know if I'm doing something wrong but you also have to compile in two passes:

• The first time it will build a python cross compile environment and then fail at building libapparmor because it could not load the cross-python variables when you first called make
• The second time it will compile successfully (at least for arch-apollolake-6.2)

I've not done a proper pull request at the moment because I worry that I'll waste a lot of your GitHub Actions budget with it just spending ages building python then failing 11 times. Is there some way to opt-out from a pull request being built by GitHub Actions?

I have only tried building for arch-apollolake-6.2 so far because the long build time and having to do two passes is a bit annoying.

[hgy59]

I've not done a proper pull request at the moment because I worry that I'll waste a lot of your GitHub Actions budget with it just spending ages building python then failing 11 times. Is there some way to opt-out from a pull request being built by GitHub Actions?

There is no opt-out for github actions implemented now, but you are free to cancel the github action when you are ignoring the results anyway (just one click on cancel workflow to cancel all jobs).

sometimes we wish to opt-out packages that are known to fail like ffsync...

[rbrownwsws]

It turns out that --with-distro=debian actually breaks the default network for new containers so if you want to try it out make sure you use the new version I just pushed.

I have made some changes to the build so it will hopefully build for all arches. 88f281 and generic arches will attempt to create the default network without using xt_CHECKSUM. I don't know how important that rule is but they must have had a reason for it so the default networking on 88f281 and generic arches may be broken / act a bit weird.

I have not put a conf/privilege in yet so it will not work on DSM7.

apparmor is still disabled. I had intended to use the aa-logprof I built on Friday to help me fix up the profiles but it looks like Synology are using an old profile syntax that the current version of aa-logprof does not like.

BTW @hgy59 I cannot see the cancel workflow button. I assume only people with write access / some kind of elevated permissions for the repo can cancel workflows.

[rbrownwsws]

FYI @th0ma7 and @hgy59 I am probably going to stop here for now.

Privileged containers seem to work fine but I cannot get the AppArmor profiles or unprivileged containers to work. I think I have hit a wall where the Synology provided kernel is just too old for those features to work as intended without significant workarounds.

An older version of LXC might work better with the current Synology provided kernel but it would probably mean going back from LXC 4.0 to LXC 2.0 which is EOL on 1st June 2021.

I might come back to this when the DSM7 kernel is released to see if they have updated to a new enough kernel for things to work better.

I am happy to make tweaks if you are interested in merging any parts of this.

[ymartin59]

I wonder if it should be "easier" to use LXC inside "debian chroot" (instead of natively on DSM) - as far as this package/concept is refactored to work again in DSM 6 and/or 7

[rbrownwsws]

@ymartin59 I am afraid I do not think "debian chroot" will help.

I could not get unprivileged containers working because it relies on user namespaces. Unfortunately Synology did not enable them in their kernel and I do not think you can "module" that feature in. This leaves you with needing to compile a custom kernel with CONFIG_USER_NS=y which I think is going a bit too far for a Synology package.

Something funny is going on with the AppArmor profiles. They use a syntax too new for the Synology version of apparmor_parser so I cross-compiled a newer version. This newer apparmor_parser "worked" in that the profiles compiled and were accepted by the kernel. Unfortunately lxc-start will then immediately crash even if the profiles are set to "complain" because it thinks AppArmor has not labelled its process correctly. I am guessing this means that lxc-start is relying on some feature of AppArmor that the old Synology kernel does not support. I have not managed to dig too deeply into that issue though so it could equally be something I did wrong.

[ymartin59]

It would be worth to give it another try today with DSM 7