Talk:Systemd-nspawn

From ArchWiki

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)
The workflow is described in DeveloperWiki:Building in a clean chroot, closing. -- Lahwaacz (talk) 13:34, 23 August 2020 (UTC)
That's for building on arch. What about creating an environment that will be used by other platforms ? (reopen) Louson (talk) 11:48, 15 September 2020 (UTC)
There is systemd-nspawn#Build and test packages with a link. Of course there are not such nice wrappers as devtools provides. -- Lahwaacz (talk) 11:55, 15 September 2020 (UTC)
You can also freeze a systemd-nspawn archlinux container that you can reuse later in order to keep the same environment. I used to combine systemd-nspawn with the archlinux archive but it's broken (changing the password returns an error: Authentication token manipulation error). It can be useful to build a kernel or a system with yocto or buildroot which are dependant of the gcc version. Louson (talk) 12:18, 15 September 2020 (UTC)

Missing configuration of allowed devices

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)

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)

I asked in the systemd IRC and user 'grawity' mentioned that the X server also listens on an abstract socket at @/tmp/.X11-unix/X0, which is available inside the container if you haven't isolated its network, and thus can still be used inside the container. This means that if you don't isolate the container's network, you don't even need to bind-mount /tmp/.X11-unix to get X applications running, and I guess you also get all the X security issues for free too, which might be worth mentioning in the article. --Tomaz (talk) 13:21, 25 November 2021 (UTC)

Using machinectl without root permissions

In the Using machinectl without root permissions section of the systemd-nspawn wiki, the two PolKit rules that allow PolKit actions that start with org.freedesktop.machine1. enable the subject user to login as any other user including root without password using the following machinectl command:

$ machinectl shell --uid=root

Most of the default actions of the org.freedesktop.machine1.policy are backed with the auth_admin element which requires the PolKit defined administrator to identify itself. Note that the PolKit defined administrator defaults to any user who is in the wheel group and this is already reasonably flexible.

Nicolas Bouchinet (talk) 10:49, 18 March 2021 (UTC)

Use an X environment - Move to Xorg page

Most of the information in this section applies to a broader set of use-cases and can be referenced in other parts of the wiki. LXC Xorg considerations, for instance, does not properly discuss running X clients inside containers, and suggests setting the very unsafe xhost + rather than the the cookie authentication method detailed method in this page. I'm planning to expand the LXC article once the page is moved. Jokersus (talk) 13:08, 19 January 2022 (UTC)

The information does not fit into the Xorg page. It's revolving around the pages like xhost and Xephyr. Most of it seems bound to systemd-nspawn (at least via examples), but if you have a different idea, feel free to propose a specific draft. — Lahwaacz (talk) 09:46, 23 January 2022 (UTC)
My bad, I should've clarified I was referring specifically to the xhost bits. Perhaps an article in Xorg about authenticating remote machines and containers or multiple users would be more appropriate? If not, I will just prepare a similar section for LXC if redundancy is not an issue. Jokersus (talk) 19:48, 23 January 2022 (UTC)
You can't have an article in an article. xhost already has an article in xhost. — Lahwaacz (talk) 21:01, 23 January 2022 (UTC)
The section is discussing a method of avoiding xhost, not xhost itself. In any case, I don't think it's fair that the only mention of cookie authentication in the wiki (to my knowledge) is in the systemd-nspawn article. Jokersus (talk) 16:31, 24 January 2022 (UTC)

Containers can start without PID 1 running

Containers does not always start a PID 1, for example when invoking systemd-nspawn directly, only a shell is started. Yemoran (talk) 17:56, 6 February 2022 (UTC)

See systemd-nspawn(1) § Execution Options (emphasis mine):
-a, --as-pid2
Invoke the shell or specified program as process ID (PID) 2 instead of PID 1 (init). By default, if neither this option nor --boot is used, the selected program is run as the process with PID 1 [...]
Lahwaacz (talk) 18:02, 6 February 2022 (UTC)
Okay, I was wrong about PID 1. The shell program runs as PID 1 by default. -b is about running an automatically searched PID 1 program, which is not the shell but usually /sbin/init which itself is symlink to /lib/systemd/systemd).
Yemoran (talk) 18:08, 6 February 2022 (UTC)

Domain name resolution: /etc/resolv.conf should have its own subsection; this section needs expansion

The "Domain name resolution" section is only about /etc/resolv.conf, but the current section doesn't clearly express what can --resolv-conf (or ResolvConf= in .nspawn file) can do: it can only changes /etc/resolv.conf, not everything. Yemoran (talk) 17:56, 6 February 2022 (UTC)

It's useless to have a section with one introductory sentence and one subsection. In any case, it is not a reason to add a Template:Expansion, because this problem does not indicate anything missing—Template:Style should be used for that. What do you think the section is missing? — Lahwaacz (talk) 18:07, 6 February 2022 (UTC)
About missing: the section does not discuss options other than "auto". For some cases DNS automatically works, but not all, and adding other confusing cases can help.
About one introductory sentence and one subsection: for this alone this is Template:Style. But the section is more about incomplete article, so its Template:Expansion. Template:Expansion at least resides in three points:
1. "Domain name resolution" is a larger topic than /etc/resolv.conf, and I believe there are more cases where DNS does not automatically work even after fixing /etc/resolv.conf, especially in the case of virtual network between host and container.
2. Even if the section is only about /etc/resolv.conf, the current description is confusing: the current situation is that the title is "Domain name resolution", which is a much broader one than configuring /etc/resolv.conf, but the current description does not describe it explicitly: the current description does not say the functions of the option --resolv-conf clearly, and can make the illusion that --resolv-conf makes systemd-nspawn magically configure DNS, but it's not. (I believe this section expresses itself pretty unclearly)
3. This section does not discuss possible values of --resolv-conf, and only describes "auto", which is unhelpful (because if it works, nobody search over the Internet for solutions). At least --resolv-conf=replace-host can be helpful in the case when no init program is launched but the container expects systemd-resolved.
Yemoran (talk) 18:36, 6 February 2022 (UTC)
First, the section links to the manual (systemd-nspawn(1) § Integration Options) and only then it describes what auto means. If the user finds that it does not work for them, they can see the manual and configure the option accordingly for their container. The wiki does not duplicate manuals just for completeness.
It is also pretty obvious from the section that if --private-network is used (which is implied by --network-veth and other options), the configuration of /etc/resolv.conf is left up to the user according to the Domain name resolution page.
Also I don't see a problem with the section title "Domain name resolution" and omitting "/etc/resolv.conf" in the heading. If there was something other than /etc/resolv.conf to be described in the section, it would be mentioned, but since it does not seem to be the case, I'll reiterate that it's useless to have a section with one introductory sentence and one subsection.
Lahwaacz (talk) 19:02, 6 February 2022 (UTC)

Unprivileged container and user namespace

systemd-nspawn's unprivileged container needs user namespace support. Its only common point with LXC is about user namespaces. A link should be given as Linux_Containers#Unprivileged_containers_on_linux-hardened_and_custom_kernels.

Note that systemd-nspawn must be root so it requires user namespace but not necessarily unprivilged user namespace, unlike LXC and other applications like browsers.

There is no wiki page for user namespace. The only places I found for user namespace are here, Linux_Containers#Unprivileged_containers_on_linux-hardened_and_custom_kernels and Security#Sandboxing_applications (the two scary note and warning).

Yemoran (talk) 20:09, 6 February 2022 (UTC)