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
- The workflow is described in DeveloperWiki:Building in a clean chroot, closing. -- Lahwaacz (talk) 13:34, 23 August 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.)
- As of this writing, does 188.8.131.52 Nvidia GPUs answer these questions? 5.8 Run docker in systemd-nspawn also looks to me a similar, related, example. Regid (talk) 20:53, 28 March 2023 (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.
- As of this writing, does Systemd-nspawn#Use an X environment answer some of the questions? Regid (talk) 20:53, 28 March 2023 (UTC)
/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?
- 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.
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)
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
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-confclearly, and can make the illusion that
--resolv-confmakes 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-hostcan 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 (
automeans. 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.
) and only then it describes what
- It is also pretty obvious from the section that if
--private-networkis used (which is implied by
--network-vethand other options), the configuration of
/etc/resolv.confis 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.confto 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)
- First, the section links to the manual (
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).
SystemCallFilter add_key not needed?
I experimented with Docker in systemd-nspawn a bit, and it seems that `add_key` is not used. I couldn't find any references to it nor from (likely wrong) source codes. Following up on this...
Add info for 32 bit containers on 64 bit systems
For a great way to compile in 32 bit environment on 64 bit installs there exists an nspawn way. Can it be added to this wiki page? It's very straightforward using this https://bbs.archlinux.org/viewtopic.php?pid=2066205#p2066205 (use a custom pacman.conf with i686 for architecture, add 32 bit mirror, install 32 bit keyring, pacstrap that, launch with 32 bit personaliity flag).
Topic related section 6.4 Systemd-nspawn#Mounting_a_NFS_share_inside_the_container
I create this new topic to discuss because one user updates a trick way about how to share NFS mounting to the container in the Chinese page. I am not sure should I sync it to this original English page.
This way is to use the host to mount the NFS and then map it to the container directory. After mounting, you will encounter permission errors, this is because the user ID of the container is mapped by the host. There are various ways to solve this problem, such as the following.
- Use administrator permissions on the host to change the user ID belonging to the NFS mount directory to the actual user ID for the container.
- Use the
--private-usersparameter to specify the user to be used as a privileged user when the container is started.
- Use the
--bind-user parameterwhen mounting a directory to specify that the user to which the NFS directory belongs is mapped to the container.
As we see, this way is not mounting inside one container but host. I think it would be better that we add this way into section 5.4 Systemd-nspawn#Access host filesystem, and mention it in section 6.4 .
root login fails
Is the section still accurate? On my system, adding
/etc/securetty on the container works properly and allows root login even after a container reboot. -- Cvlc (talk) 15:45, 13 February 2023 (UTC)