tags:
- systemd
- nspawn
categories:
- informational
comments: true
date: 2022-07-01 00:00:00
Create a Debian systemd container in Ubuntu using nspawn
Backgrpund
- Containers run on the same operating system kernel as the host
- The best way to imagine what containers do is to think in terms of namespaces
- There are several namespaces in your system that you can restrict access
Filesystem
- restrict filesystem access
- Containers provide chroot-like functionality - specify an arbitrary filesystem
root
- programs installed in container is fully independent from the host
- a second OS tree for the container containing the tools an operating system
needs to run
Process IDs (PIDs)
- ps -ef - every process running on the system
- container should not see processes from the host or other containers
- a process in the container should not have PID 1 (init)
- PID 1 on the host
User IDs (UIDs)
- users on a system has a user ID
- The root user has ID 0
- normal user IDs start at 1000
- User namespacing is mostly a precaution
- should someone be able to break out of your container into the host system
that user will not have the UID of an existing user on the host
- Without user namespacing, e.g. the root user in a container will also appear
to the host system as UID 0
- This will enable the feature adds an arbitrary high number to all UIDs inside
a container
- For example: the container’s root user (appearing as UID 0 in the container)
will actually have UID 64789232 in the host system
Network interfaces
Controlling the ‘namespaces’
- All the namespaces are managed by the Linux kernel
- It is possible to enable or disable support for these namespaces at kernel
compile time
- If they are not working as expeced, those features may have been turned off
during kernel compile time or the kernel is old
Issue with single process containers
- Is the ‘one process per container’ model ideal
- each container is dedicated to running exactly one process
- However, the container should have at least a minimal init system
- processes may fork() child processes
- when a parent does not properly wait() for its children, the process with PID 1
(the init process) becomes responsible for cleanup
- But if there is no init process, these orphaned child processes will become
zombies
- Some processes rely on init as a zombie reaper, e.g. daemons when double forking
- In this setup, systemd will be the init system inside our container
Create a Debian systemd nspawn container
apt install debootstrap systemd-container bridge-utils
cd /var/lib/machines
mkdir -p /var/lib/machines/helloworld
chown root:root /var/lib/machines
chmod 700 /var/lib/machines
debootstrap stable /var/lib/machines/helloworld http://deb.debian.org/debian/
Login and accessing
systemd-nspawn -UM helloworld
password
useradd -s /bin/bash -m hello1
password hello1
systemd-nspawn -UMb helloworld
echo 'auto host0' >> /etc/network/interfaces
echo 'iface host0 inet dhcp' >> /etc/network/interfaces
apt update
An overview of systemd’s container commands
systemd-nspawn
- used to directly start a container
- spawns a root shell inside the container’s environment
- Using the -b switch will boot the container and afterwards give a login shell
- However, as soon as the command terminates, the container shuts down as well
- to use user namespacing launch with the -U switch, it enables user namespacing
- first time this is done, systemd will adjust all file permissions inside
the container
- disabling user namespacing later can lead to some very weird errors
(files being owned by nobody:nogroup)
- with the -M machine_name switch, you specify the container to launch
machinectl
it is very similar to systemd’s systemctl but is used specifically to work with
containers
containers can be started, stopped and enabled just like any other systemd
service
The service template file is located at /lib/systemd/system/systemd-nspawn@.service
[Service]
ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --link-journal=try-guest --network-veth -U --settings=override --machine=%i
/etc/systemd/nspawn
a directory which can contain configuration files for container-specific
settings
All the settings can also be specified via the systemd-nspawn command
- but having a file is convenient and efficient
the configuration files are also honored when using machinectl to start
containers
If the directory does not create it
mkdir -p /etc/systemd/nspawn
Enable/manage container via machinectl
To start a container in the background:
machinectl start helloworld
To get status information for a running container:
machinectl status helloworld
To obtain a login shell on a running container (requires dbus on both host and container):
machinectl login helloworld
To leave the session: press Ctrl + ] 3 times within one second
To shut down a running container:
machinectl stop helloworld
To configure a container to boot every time the system boots:
machinectl enable helloworld
machinectl disable helloworld
Error due to Debian keyring
W: Cannot check Release signature; keyring file not available /usr/share/keyrings/debian-archive-keyring.gpg
I: Retrieving InRelease
I: Retrieving Release
E: Failed getting release file http://deb.debian.org/debian/dists/stable/Release
Installing the debian keyring did not help
apt install debian-keyring debian-archive-keyring
Fixing the Debian keyring issue for debootstrap
wget https://ftp-master.debian.org/keys/archive-key-10.asc
wget https://ftp-master.debian.org/keys/archive-key-10-security.asc
mkdir /usr/share/keyrings/
gpg --no-default-keyring --keyring=/usr/share/keyrings/debian-archive-keyring.gpg --import archive-key-10.asc
gpg --no-default-keyring --keyring=/usr/share/keyrings/debian-archive-keyring.gpg --import archive-key-10-security.asc
ls -lF /usr/share/keyrings/debian-archive-keyring.gpg
debootstrap stable /var/lib/machines/helloworld http://deb.debian.org/debian/
Reference
https://medium.com/@huljar/setting-up-containers-with-systemd-nspawn-b719cff0fb8d
https://pub.nethence.com/xen/debootstrap
https://wiki.archlinux.org/title/systemd-nspawn