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. .. code-block:: bash dnf install podman After installing the packages, verify the system service is running .. code-block:: bash 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 .. code-block:: bash 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``. .. code-block:: bash 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 .. code-block:: text net.ipv4.ip_unprivileged_port_start=443 follow by .. code-block:: bash 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. .. code-block:: bash 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. .. code-block:: text [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. .. code-block:: bash 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: .. code-block:: bash 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 :ref:`Onboarding stack `.