8️⃣ Here's the 8th post highlighting key new features of the upcoming v260 release of systemd. #systemd260 #systemd

In the 4th posting of this current series, we introduced the new .mstack/ directory type, for putting together service and container trees from stacks of overlayed directory trees and bind mounts, all in a self-descriptive directory.

In v260 there's also one major user of this new concept: the importctl tool gained a new "pull-oci" verb for downloading OCI containers. What it…

…actually does is talk to the OCI registry, find all the layers, download them and unpacks them into a .mstack/ directory, then converts the OCI metadata into a .nspawn file, and is done.

Or in other words, with this you can download any OCI container you like and then boot it with nspawn. Or in fact run it as a system service via RootMStack= in a unit file.

it's still a bit barebones, since the focus so far has been on acquiring the container trees and getting them into executable shape, but…

…not so much actually adding the glue for integrating this nicely into the OS, but this will come in one of the next releases, hopefully.

Oh, and all of this works unprivileged too, i.e. you can do "importctl --user pull-oci" to download a container image into your home directory.

@pid_eins I have been experimenting with this to see if I can recreate fedora's toolbx using nspawn.

One hurdle I came across is that mstack containers are limited to managed or no user namespacing.

Is this a hard limitation, or something that may be lifted in a future release?

https://github.com/systemd/systemd/blob/fb4bfe651b7dda85b0545d340eac21c7988fe383/src/nspawn/nspawn.c#L6612-L6613

@levitating we kinda see the non-managed userns stuff as legacy, and want to get away from it. Where are you missing something in the managed stuff that the unmanaged stuff gave you

@pid_eins I can't seem to be able to combine --private-users=managed with --bind-user. I get "Failed to clone /home/rein: Operation not permitted", and some overlayfs errors from the kernel.

Furthermore I can't seem to get /run/user/1000 to bind with idmap, which is why I was hoping to identity map the users in the first place.

@levitating those sound like missing features we should cover. can you file bugs about that?

i'd rather fix --bind-user= and stuff for managed userns, than to put work in unmanaged userns

systemd-nspawn: allow for way to bind /run/user/<uid> · Issue #41546 · systemd/systemd

Component systemd-nspawn Is your feature request related to a problem? Please describe --bind-user= allows us to create a user in the guest, with their home container mounted with the user ids mapp...

GitHub