Podman runtime

Podman is a daemon-less architecture that allows an unprivileged user to run containers without root access (rootless), further enhancing system security.

This documentation is for running Onboarding stack rootless on Podman, if you want to run it as root, then login as root user or if the user have sudo permission, then change terminal to root with sudo -i.

Podman

On Fedora Linux distribution following packages need to be installed on the system.

dnf install podman

After installing the packages, verify the system service is running

podman run --rm hello-world

Upon success some text including “!… Hello Podman World …!” will appear on your screen.

Warning

Running podman cli commands with or without sudo prefix, can give you different outcome since Podman allow container to run rootless.

Podman-compose

We use podman-compose to translate docker-compose file to podman commands, since we use docker-compose to manage the Onboarding application stack.

Podman-compose can be installed with python package manager pip3

pip3 install --upgrade pip
pip3 install podman-compose --user

Note

you might need to install pip3, if it is not already installed on your system.

dnf update
dnf install python3-pip

Or manually from their github repository https://github.com/containers/podman-compose#installation or if your Linux distribution support podman-compose use dnf install podman-compose.

podman-compose --version

It should output something like “podman-composer version 1.0.3”.

Firewall

Because Podman is running rootless, we need to open port 443 manually on the server, since unprivileged user on the system do not have access to ports below 1024, only root have.

First we need to a lower unprivileged port access to 443, open /etc/sysctl.conf as root and add following line to the file

net.ipv4.ip_unprivileged_port_start=443

follow by

sudo sysctl --system

Will reload settings from config files without rebooting the server.

This now allow unprivileged user to bind to port 443, this can lead to a potential security problem, since unprivileged users may now bind to the other privileged ports (444-1024).

If you are using firewall-cmd we can solve it by blocking the other ports, after that we need to allow access to port 443 from outside in the firewall.

sudo firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -p udp -m udp --dport 444:1024 -j REJECT
sudo firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 1 -p udp -m udp --dport 444:1024 -j REJECT
sudo firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -p tcp -m tcp --dport 444:1024 -j REJECT
sudo firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 1 -p tcp -m tcp --dport 444:1024 -j REJECT
sudo firewall-cmd --zone=public --add-port=443/tcp --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --list-ports
sudo iptables -L -v -n

The last command should output your iptables rules, which should include rejection for udp and tcp on ports betweem 444 and 1024. The command before that will output text including 443/tcp.

Auto restart

Since Podman is a daemon-less architecture, the containers will not restart automatically after a server reboot. For that we can use systemd to start your conatiners, first we need to create a onboarding-restart.service service file, with following content.

[Unit]
Description=Podman Start All Onboarding Containers
Documentation=man:podman-start(1)
StartLimitIntervalSec=0
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
RemainAfterExit=true
Environment=LOGGING="--log-level=info"
ExecStart=/usr/bin/podman $LOGGING start --all --filter label=io.podman.compose.project=onboarding
ExecStop=/bin/sh -c '/usr/bin/podman $LOGGING stop $(/usr/bin/podman container ls --filter label=io.podman.compose.project=onboarding -q)'

[Install]
WantedBy=default.target

Afterward we will add it to systemd and start the service.

mv -v onboarding-restart.service ~/.config/systemd/user/
systemctl --user daemon-reload
systemctl --user enable onboarding-restart.service
systemctl --user start onboarding-restart.service
systemctl --user status onboarding-restart.service

It should output failed in Active field, which is as expected, since we have not deployed the Onboarding stack yet. If you had deployed Onboarding stack, then ouput will have been active in Active field.

Note

To run the service as root with Podman in root mode, move the onboarding-restart.service to /etc/systemd/system/ and remove --user from systemctl command

The service is being run by a normal user and not the root user. That means that user needs to be logged in at boot to trigger the service and should stay active afterward, which is not an ideal solution.

We can bypass this by using loginctl command. From the terminal as root run following command, by replacing $USER with the user deploying Onboarding stack:

loginctl enable-linger $USER

This command will ensure that a user session for your user is spawned at boot and kept active even after logouts from GUI or tty session(s).

Recap, a server reboot will automatically restart the containers of which we have created a systemd service for and enabled. You can try verify everything works by restarting the server after deploying Onboarding stack.