Differences between revisions 9 and 12 (spanning 3 versions)
Revision 9 as of 2019-11-18 06:36:48
Size: 3914
Editor: ?DmitryBorodaenko
Comment:
Revision 12 as of 2020-06-18 00:11:16
Size: 6490
Editor: Crsi
Comment: Added a paragraph about using X and basic requirements
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
= systemd containers = = systemd-nspawn =
Line 5: Line 5:
systemd-nspawn and machinectl are lightweight container management tools. <<TableOfContents(3)>>
Line 7: Line 7:
They are deployed as part of systemd with the DebianPts:systemd-container package.
== system preparing ==
we should enable namespaces kernel feature
== About systemd-nspawn ==

systemd-nspawn may be used to run a command or OS in a light-weight namespace container. In many ways it is similar to [[DebianMan:chroot]], but more powerful since it fully virtualizes the file system hierarchy, as well as the process tree, the various IPC subsystems and the host and domain name.

This mechanism is also similar to [[LXC]], but is much simpler to configure and most of the necessary software is already installed on contemporary Debian systems.

== Host Preparation ==

The ''host'' (i.e. the system hosting one or more containers) needs to have the [[DebianPackage:systemd-container]] package installed.

{{{#!highlight bash numbers=disable
$ apt-get install systemd-container
}}}

The host should also have unprivileged user namespaces enabled (see the [[https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#-U|documentation]] for an explanation of why, note that some consider this a [[https://lwn.net/Articles/673597/|security risk]]):
Line 14: Line 27:
It's require action to make work UIDs mapping. You can read more from official [[https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#-U|documentation]].
== creating Debian container ==
Require DebianPts:debootstrap package to get basic environment for our container

== Creating a Debian Container ==

Each ''guest'' OS should also have the [[DebianPackage:systemd-container]] package installed. A suitable guest OS installation may created using the DebianPackage:debootstrap or DebianPackage:cdebootstrap tools. For example, to create a new guest OS called `debian`:
Line 24: Line 39:
systemd-container package required to login container using machinectl
Line 26: Line 40:
After bootstrapping we can login to container to make additional changes After DebianPackage:debootstrap finishes, it is necessary to login to the newly created container and make some changes to allow root logins:
Line 29: Line 43:
Spawning container buster on /var/lib/machines/buster. Spawning container buster on /var/lib/machines/debian.
Line 34: Line 48:
root@stable:~# passwd root@debian:~# passwd
Line 40: Line 54:
root@stable:~# echo 'pts/0' >>/etc/securetty root@debian:~# echo 'pts/1' >> /etc/securetty  # May need to set 'pts/0' instead
Line 42: Line 56:
# logout from container using ctrl+D
root@buster:~# logout
Container buster exited successfully.
# logout from container
root@debian:~# logout
Container debian exited successfully.
Line 46: Line 60:
now we can boot container using systemd-nspawn@.service unit
{{{

== Booting a Container ==

Once it has been setup, it is possible to boot a container using an instantiated [[DebianMan:systemd.service]]:
{{{#!highlight bash numbers=disable
# The part after the @ must match the container name used in the previous step
Line 51: Line 69:
@debian - that name should be same as machine folder name in /var/lib/machines/ == Checking Container State ==
Line 53: Line 71:
checking state of machine To check the state of containers, use one of the following commands:
Line 61: Line 79:
$ systemctl status systemd-nspawn@buster
● systemd-nspawn@buster.service - Container buster
$ systemctl status systemd-nspawn@debian
● systemd-nspawn@debian.service - Container debian
Line 67: Line 85:
now we can login to console
{{{
$ machinectl login buster
== Logging into a Container ==

To login to a running container:
{{{#!highlight bash numbers=disable
$ machinectl login debian
Line 77: Line 97:
== Stopping a Container ==

To stop a running container from the host, do:
{{{#!highlight bash numbers=disable
$ systemctl stop systemd-nspawn@debian
}}}

Alternatively, you can stop the container from within the guest OS by running e.g. `halt`:
{{{#!highlight bash numbers=disable
$ machinectl login debian
Connected to machine debian. Press ^] three times within 1s to exit session.

Debian GNU/Linux 10 debian pts/0

debian login: root
Password: <something>
Last login: Wed Jan 22 21:53:00 CET 2020 on pts/1
Linux debian 5.4.0-3-amd64 #1 SMP Debian 5.4.13-1 (2020-01-19) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@debian:~# halt
...
Machine debian terminated
}}}
Line 78: Line 128:
container communicates with host machine using virtual interface named ve-{container_name}
The h
ost communicates with the guest container using a virtual interface named `ve-<container_name>@if<X>` while the guest uses a virtual interface named `host@if<Y>` for the same purposes:
Line 80: Line 131:
$ ip a show dev ve-buster
77: ve-buster@if2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
$ ip a show dev ve-debian
77: ve-debian@if2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
Line 87: Line 138:
TODO: Describe advanced networking configuration Alternatively the interfaces can be configured manually, e.g. to setup IP forwarding, masquerading, etc.
Line 89: Line 140:
== Usage example == == Using programs with Xorg ==
Line 91: Line 142:
Deploy FreedomBox on a Sid container. This will take around 1.2 GB of disk space. The container does not have any knowledge of your host's X server at first. If you want to run applications inside your container that should be able to use your host's X server and session, you need to specify the `DISPLAY` environment variable. A good way to do so interactively is using the `-E` option:
Line 94: Line 145:
# create a new container using debootstrap
$ CDIR=/var/lib/machines/freedombox
$ sudo debootstrap --include=systemd-container sid $CDIR
$ sudo systemd-nspawn -D $CDIR --machine FreedomBox
root@FreedomBox:~# apt-get install -y freedombox
$ systemd-nspawn -E DISPLAY="$DISPLAY" ...
}}}
Line 100: Line 148:
# set root password and stop the container
root@FreedomBox:~# passwd root
root@FreedomBox:~# ^D
However, the container now knows about the display but does not have any privileges. For testing purposes only, you can use [[xhost]]:
Line 104: Line 150:
# start the container and its services
$ sudo systemd-nspawn -D $CDIR --machine FreedomBox -b
{{{#!highlight bash numbers=disable
$ xhost +
}}}
Line 107: Line 154:
# Browse to https://127.0.0.1/ Note that ''this is insecure'' as it disables X access control (anybody has access). To revert it use `xhost -`.
Line 109: Line 156:
# To stop the container, either issue:
$ sudo machinectl stop FreedomBox
If you use a single-user machine, you may want to use the following variant which allows any connection from localhost only:
Line 112: Line 158:
# or log in and run "halt". Simply logging out does not stop a container started with "-b" {{{
$ xhost +local:
non-network local connections being added to access control list
Line 114: Line 162:

It's possible to passthrough the configuration needed in the container. See [[https://wiki.archlinux.org/index.php/Systemd-nspawn#Avoiding_xhost|the Arch Linux wiki]] for one option.

systemd-nspawn

About systemd-nspawn

systemd-nspawn may be used to run a command or OS in a light-weight namespace container. In many ways it is similar to chroot, but more powerful since it fully virtualizes the file system hierarchy, as well as the process tree, the various IPC subsystems and the host and domain name.

This mechanism is also similar to LXC, but is much simpler to configure and most of the necessary software is already installed on contemporary Debian systems.

Host Preparation

The host (i.e. the system hosting one or more containers) needs to have the systemd-container package installed.

$ apt-get install systemd-container

The host should also have unprivileged user namespaces enabled (see the documentation for an explanation of why, note that some consider this a security risk):

$ echo 'kernel.unprivileged_userns_clone=1' >/etc/sysctl.d/nspawn.conf
$ systemctl restart systemd-sysctl.service

Creating a Debian Container

Each guest OS should also have the systemd-container package installed. A suitable guest OS installation may created using the debootstrap or cdebootstrap tools. For example, to create a new guest OS called debian:

$ debootstrap --include=systemd-container stable /var/lib/machines/debian
I: Target architecture can be executed
I: Retrieving InRelease
I: Checking Release signature
...

After debootstrap finishes, it is necessary to login to the newly created container and make some changes to allow root logins:

$ systemd-nspawn -D /var/lib/machines/debian -U --machine debian
Spawning container buster on /var/lib/machines/debian.
Press ^] three times within 1s to kill container.
Selected user namespace base 818610176 and range 65536.

# set root password
root@debian:~# passwd
New password:
Retype new password:
passwd: password updated successfully

# allow login via local tty
root@debian:~# echo 'pts/1' >> /etc/securetty  # May need to set 'pts/0' instead

# logout from container
root@debian:~# logout
Container debian exited successfully.

Booting a Container

Once it has been setup, it is possible to boot a container using an instantiated systemd.service:

# The part after the @ must match the container name used in the previous step
$ systemctl start systemd-nspawn@debian

Checking Container State

To check the state of containers, use one of the following commands:

$ machinectl list
MACHINE CLASS     SERVICE        OS     VERSION ADDRESSES
debian container systemd-nspawn debian 10      -

# or
$ systemctl status systemd-nspawn@debian
● systemd-nspawn@debian.service - Container debian
   Loaded: loaded (/lib/systemd/system/systemd-nspawn@.service; disabled; vendor preset: enabled)
   Active: active (running) since ...

Logging into a Container

To login to a running container:

$ machinectl login debian
Connected to machine debian. Press ^] three times within 1s to exit session.

Debian GNU/Linux 10 debian pts/0

debian login:

Stopping a Container

To stop a running container from the host, do:

$ systemctl stop systemd-nspawn@debian

Alternatively, you can stop the container from within the guest OS by running e.g. halt:

$ machinectl login debian
Connected to machine debian. Press ^] three times within 1s to exit session.

Debian GNU/Linux 10 debian pts/0

debian login: root
Password: <something>
Last login: Wed Jan 22 21:53:00 CET 2020 on pts/1
Linux debian 5.4.0-3-amd64 #1 SMP Debian 5.4.13-1 (2020-01-19) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@debian:~# halt
...
Machine debian terminated

Networking

The host communicates with the guest container using a virtual interface named ve-<container_name>@if<X> while the guest uses a virtual interface named host@if<Y> for the same purposes:

$ ip a show dev ve-debian
77: ve-debian@if2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether ... brd ff:ff:ff:ff:ff:ff link-netnsid 1

Enable and start systemd-networkd.service on the host and in the container to automatically provision the virtual link via DHCP with routing onto host's external network interfaces.

Alternatively the interfaces can be configured manually, e.g. to setup IP forwarding, masquerading, etc.

Using programs with Xorg

The container does not have any knowledge of your host's X server at first. If you want to run applications inside your container that should be able to use your host's X server and session, you need to specify the DISPLAY environment variable. A good way to do so interactively is using the -E option:

$ systemd-nspawn -E DISPLAY="$DISPLAY" ...

However, the container now knows about the display but does not have any privileges. For testing purposes only, you can use ?xhost:

$ xhost +

Note that this is insecure as it disables X access control (anybody has access). To revert it use xhost -.

If you use a single-user machine, you may want to use the following variant which allows any connection from localhost only:

$ xhost +local:
non-network local connections being added to access control list

It's possible to passthrough the configuration needed in the container. See the Arch Linux wiki for one option.


CategorySoftware | CategoryVirtualization | CategorySystemAdministration