- 1 user namespaces
- 2 systemd-nspawn as a build environment
- 3 systemd-nspawn usage examples
- 4 Missing configuration overview
- 5 Wayland desktop environment inside nspawn
- 6 linux-firmware causing issues with systemd-tmpfiles-setup.service - still relevant?
- 7 /tmp/.X11-unix contents have to be bind-mounted as read-only - still relevant?
systemd-nspawn never uses user namespaces, as you can see from the source. User namespaces do not appear to work with a chroot at all right now, because you can't enter one while in a chroot and you can't use chroot while in a user namespace. - thestinger (talk) 19:35, 23 April 2014 (UTC)
- The report is still open, I'm restoring the link here just in case: FS#36969. The removed content is . -- Kynikos (talk) 01:45, 25 April 2014 (UTC)
- In conclusion from above mentioning user namespaces was not relevant on this page (pity really). So the only way to restrict the nspawn-container appears to be limiting its capabilities on start-up (as per man systemd-nspawn). Regarding FS#36969: it was originally opened for lxc-containers anyway and those appear to support user namespaces now. Hence, the only question remaining for this article at this point would be, if there are any remaining issues arising for systemd in general when activating CONFIG_USER_NS for lxc (opinion on that?).
- I have added the bug and a couple links with background info to talk:linux containers so the reference does not get lost.
- --Indigo (talk) 08:56, 3 May 2014 (UTC)
systemd-nspawn as a build environment
I've been struggling trying to set this up and i assume others will as well. Would be nice to have an example of a build workflow using this tool on this or on a seperate page. Captaincurrie (talk) 18:32, 19 January 2015 (UTC)
extra-x86_64-build. -- thestinger 18:41, 19 January 2015 (UTC) package implements this for Arch packaging, and is used for building everything in the repositories. It's as simple as replacing
systemd-nspawn usage examples
Missing configuration overview
First, thanks to everyone who contributed to this page. It's one of the best I could have found on the net about the topic.
I had trouble to understand how can I configure my containers. Was started to copy the
/usr/lib/systemd/system/systemd-nspawn@.service file to
/etc/systemd/system and made changes for network changes. This was not as good as to add the
/etc/systemd/nspawn/mycontainer.nspawn file and edit the relevant
[Files] parts there... So, I would recommend to hint with a small section at the top, to use the
.nspawn file rather than the command line parameters. And emphase those exceptions when only the command line can help.
The other thing I have not find here is, how can I use devices from the container... Was set up an mpd server which needs network connection and an audio sink. My case the audio sink was ALSA devices (and not pulse socket). Had problem to undersand that I need to bind the device files to the container. (In the
.nspawn file.) And also need
DeviceAllow=char-alsa rwm line in the
.service file. (Or to be precise in the
override.conf of the service file.)
- For the first point there is already a systemd-nspawn#Specify_per-container_settings section. -- Lahwaacz (talk) 14:43, 26 September 2017 (UTC)
Wayland desktop environment inside nspawn
It would be great if someone with expertise wrote a section regarding starting graphical environments inside nspawn containers. It looks like there is some info on Github. This example shows how to run desktop environments in nspawn containers win kwin_wayland compositor. It should be possible to achieve this with mutter too, as it even supports nested mode with something like mutter --wayland --nested. Also we should be able to open new dbus session with something like eval $(dbus-launch --sh-syntax). Also it would be great if someone explained which packages could be omitted inside the container (like we don't need xorg org wayland installed if I get it right) on some popular distros.
linux-firmware causing issues with systemd-tmpfiles-setup.service - still relevant?
The systemd bug report connected with the issue was closed 27 Apr 2018: https://github.com/systemd/systemd/issues/791 Do issues remain or is the fix good enough to remove the note?
/tmp/.X11-unix contents have to be bind-mounted as read-only - still relevant?
For me (systemd version 239) X applications also work if /tmp/.X11-unix is bound rw. Can anybody confirm that?