Difference between revisions of "Talk:Systemd-nspawn"

From ArchWiki
Jump to navigation Jump to search
(Added discussion section about recently added accuracy annotation.)
Line 49: Line 49:
-- [[User:Chleh|Chleh]] ([[User talk:Chleh|talk]]) 22:51, 2 January 2019 (UTC)
-- [[User:Chleh|Chleh]] ([[User talk:Chleh|talk]]) 22:51, 2 January 2019 (UTC)
:I confirm it works with normal binding. Also the linked bug report is closed and apparently solved since 2017. -- [[User:Bonob|Bonob]] ([[User talk:Bonob|talk]]) 17:36, 27 November 2019 (UTC)

Latest revision as of 17:37, 27 November 2019

user namespaces

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 [1]. -- 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)

The devtools package implements this for Arch packaging, and is used for building everything in the repositories. It's as simple as replacing makepkg with extra-i686-build + extra-x86_64-build. -- thestinger 18:41, 19 January 2015 (UTC)
Cool, i'll give that a try. Thanks :) Captaincurrie (talk) 10:05, 20 January 2015 (UTC)

systemd-nspawn usage examples

This page needs lots of awesome usage examples because its such an awesome tool. Please give suggestions. Captaincurrie (talk) 10:08, 20 January 2015 (UTC)

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 [Network] or [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.)

--Rizsotto (talk) 13:40, 26 September 2017 (UTC)

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.

—This unsigned comment is by Unb0rn (talk) 20:07, 23 June 2018‎. Please sign your posts with ~~~~!

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?

—This unsigned comment is by Buovjaga (talk) 09:12, 25 October 2018‎. Please sign your posts with ~~~~!

/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?

-- Chleh (talk) 22:51, 2 January 2019 (UTC)

I confirm it works with normal binding. Also the linked bug report is closed and apparently solved since 2017. -- Bonob (talk) 17:36, 27 November 2019 (UTC)