Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Running systemd-nspawn Containers (2022)

benjamintoll.com

Post reply on HN
Print view View original

31–40 of 59 posts

Re: On Running systemd-nspawn Containers (2022)

#31

Post by fburnaby »

josteink wrote: post #26
throwaway894345 wrote: post #17

Earlier quoted context omitted.

I was thinking similarly. All of those steps to circumvent the OCI image infrastructure just to use systemd…

OCI is for running prepackaged software in black boxes from the internet, where you have no interest or ownership of the container internals. Most of my containers are not like that. Well, actually none are. systemd-nspawn is for running your own containers, with a VM-like usage pattern (ie not immutable), deployed as part of your overall systemd based infrastructure for when the thing you need to manage is "too big"…

This distinction is a more useful one that the article made. I love dockerfiles and immutability, but there are good cases for mutable containers, too.

Re: On Running systemd-nspawn Containers (2022)

#32

Post by Imustaskforhelp »

vlowrian wrote: post #24
Imustaskforhelp wrote: post #4

Earlier quoted context omitted.

hmm this is very interesting. I am wondering though? Is there something like systemd-nspawn that doesn't require root?

If file system level isolation is enough for you, take a loot at schroot ( https://linux.die.net/man/1/schroot ) which allows root-less chroot. You can use something like debootstrap to get a complete userland into a user controlled directory and use schroot to chroot into it without root level access.

this is crazy , trying this out right now.

But is there a way to also run OCI compatible directly on this as well?

Re: On Running systemd-nspawn Containers (2022)

#33

Post by Imustaskforhelp »

vlowrian wrote: post #24
Imustaskforhelp wrote: post #4

Earlier quoted context omitted.

hmm this is very interesting. I am wondering though? Is there something like systemd-nspawn that doesn't require root?

If file system level isolation is enough for you, take a loot at schroot ( https://linux.die.net/man/1/schroot ) which allows root-less chroot. You can use something like debootstrap to get a complete userland into a user controlled directory and use schroot to chroot into it without root level access.

EDIT: it seems that for creating a chroot you still require root.

I don't have root on that system and so I can't create a chroot , there is fakeroot but it doesn't work since it uses qemu on that locked system.

Are there any other alternatives

Re: On Running systemd-nspawn Containers (2022)

#34

Post by mst »

Imustaskforhelp wrote: post #32
vlowrian wrote: post #24

Earlier quoted context omitted.

If file system level isolation is enough for you, take a loot at schroot ( https://linux.die.net/man/1/schroot ) which allows root-less chroot. You can use something like debootstrap to get a complete userland into a user controlled directory and use schroot to chroot into it without root level access.

this is crazy , trying this out right now. But is there a way to also run OCI compatible directly on this as well?

You could use docker export to sluro the container contents (see article for example)

Re: On Running systemd-nspawn Containers (2022)

#35

Post by ttyprintk »

Imustaskforhelp wrote: post #33
vlowrian wrote: post #24

Earlier quoted context omitted.

If file system level isolation is enough for you, take a loot at schroot ( https://linux.die.net/man/1/schroot ) which allows root-less chroot. You can use something like debootstrap to get a complete userland into a user controlled directory and use schroot to chroot into it without root level access.

EDIT: it seems that for creating a chroot you still require root. I don't have root on that system and so I can't create a chroot , there is fakeroot but it doesn't work since it uses qemu on that locked system. Are there any other alternatives

Fakeroot is good for the debootstrap step, and then schroot runs unprivileged.

Re: On Running systemd-nspawn Containers (2022)

#36

Post by yjftsjthsd-h »

1oooqooq wrote: post #13
Imustaskforhelp wrote: post #4

Earlier quoted context omitted.

hmm this is very interesting. I am wondering though? Is there something like systemd-nspawn that doesn't require root?

all containers require root. docker and the rootless nonsense is just root daemons and suid. ...would never have believed marketing lies would reach linux tools if anyone told me this before 2018.

Linux user namespaces can be used to create containers without having root access, see ex. https://unix.stackexchange.com/questions/66084/simulate-chro...

There's also https://github.com/termux/proot-distro which may or may not count as containers depending on how you define the word but I think it does count

Re: On Running systemd-nspawn Containers (2022)

#37

Post by orbisvicis »

I use nspawn but many of the helpers featured here are new, so I appreciate this article. I've only ever booted from directories rather than images, and wasn't aware that an image could mount its own partitions, even swap!

Also I'm a little unclear on the security implications of "--private-users=id". Yes the user IDs are the same, but it is technically running in a separate user namespace. In terms of security is this mode equivalent to privileged containers, or is it safer?

Re: On Running systemd-nspawn Containers (2022)

#38

Post by igor47 »

Imustaskforhelp wrote: post #33
vlowrian wrote: post #24

Earlier quoted context omitted.

If file system level isolation is enough for you, take a loot at schroot ( https://linux.die.net/man/1/schroot ) which allows root-less chroot. You can use something like debootstrap to get a complete userland into a user controlled directory and use schroot to chroot into it without root level access.

EDIT: it seems that for creating a chroot you still require root. I don't have root on that system and so I can't create a chroot , there is fakeroot but it doesn't work since it uses qemu on that locked system. Are there any other alternatives

fakeroot has nothing to do with qemu -- it simply uses LD preload to make commands think they're uid 0

Re: On Running systemd-nspawn Containers (2022)

#40

Post by exabrial »

There are lot of ridiculous things in systemd (I'll avoid mentioning specific things to avoid a flame war), but auto containerization of services is by far the most useful thing they've ever come out with. It's a far easier workflow than docker or anything else and is built in "for free"
Post reply on HN