To install Podman, notably this time as the rootuser, we will first add a source to the aptpackage manager this way as one long command which should go on one line:

$ echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/xUbuntu _20.04/ /" | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list

If you're not using Ubuntu 20.04, then alter the 20.04 string in the previous command. If you want to try other Linux distributions, then you can use this page: podman.io/getting-started/installation.

Next, we need to add the repository's key to our keyring as a trusted source (changing 20.04 if required again) which is one line command:

$ curl -L

https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/xUbuntu_18.04/Release.key | sudo apt-key add -

A successful response is OK.

Now, refresh your packages and upgrade any that require upgrading:

$ sudo apt-get update; sudo apt-get upgrade -y

We should now be able to install Podman as follows:

$ apt-get -y install podman

Note the output from that command, shown here, so you can get an idea of the underlying components used:

Recommended packages: crun slirp4netns varlink The following NEW packages will be installed catatonit conmon containernetworking-plugins containers-common containers-golang containers-image crun libyajl2 podman podman-plugins runc slirp4netns uidmap varlink

Check that Podman has installed correctly:

$ podman -v podman version 2.0.4

We need to check our UID and GID mapping settings files to run rootless containers next. Run these commands and delete any entries (only on a development system!) to check that they are empty:

$ cat /etc/subuid $ cat /etc/subgid

This is the point where you might want to create a specific user for running rootless containers. Simply use the addusercommand with a username of your choice, such as poduser, and follow the prompts:

$ sudo adduser poduser

We will stick with user chris, however, for continuity.

Now we want to populate the subuidand subgidfiles in the /etcdirectory. Use this command to set the ranges of UIDs and GIDS that you want to use, changing the name of the user at the end to suit your requirements:

$ sudo usermod --add-subuids 200000-201000 --add-subgids 200000-201000 chris

Without any more tweaking or fiddling, we are ready to run Podman in rootless mode. It has been a particularly painless process so far.

First, however, remember that Podman is not running as a daemon. Take a look with this command (to be really sure, run this as the rootuser to see any hidden processes in the process table, and not only as the chrisuser):

$ ps -ef | grep podman

The only output you should see is the grepcommand that you've just run. But, if we run this Podman command, we should see a service ready and waiting:

$ podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

It looks remarkably familiar, just as Docker Engine would output. Using the chrisuser we can start up a container using another familiar command for Apache:

$ podman run -it -p 8000:80 httpd:latest

We have not added the -dswitch to that command, and Listing 2.4 shows the STDOUTlogging (output straight to the terminal).

Listing 2.4:Podman Running Rootless with Little Effort

AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 10.0.2.100. Set the 'ServerName' directive globally to suppress this message AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 10.0.2.100. Set the 'ServerName' directive globally to suppress this message [Tue Aug 29 14:09:20.303062 2020] [mpm_event:notice] [pid 1:tid 140532155102336] AH00489: Apache/2.4.46 (Unix) configured -- resuming normal operations [Tue Aug 29 14:09:20.304849 2020] [core:notice] [pid 1:tid 140532155102336] AH00094: Command line: 'httpd -D FOREGROUND'

Just as we did before with Docker in rootless mode, let's see how our networking is set up. We will open up another terminal (as the chrisuser) and try this command:

$ podman ps CONTAINER ID IMAGE COMMAND CREATED e09883662c2b docker.io/library/httpd:latest httpd-foreground

The abbreviated output proves we have httpdrunning as hoped. It is worth noting that other standard users will not have visibility of Podman container processes, but the user chriscertainly does. We can see the container is definitely running, and not as the rootuser:

$ ps -ef | grep podman

The abbreviated output from that command shows, among other entries:

chris 6069 6035 podman run -it -p 8000:80 httpd:latest

Do we need to access the container via the host's network, as we did with Docker? We can test with this command:

$ curl localhost 8000

It works!

The answer is yes, we've exposed a nonprivileged port (TCP port 8000) and can access the container via the localhost. If you get stuck, check firewalling rules or other container runtimes that are still installed.

One difference between Docker and Podman in rootless mode is that Podman does not allocate an IP address by default. Using the previous podman pscommand, we can see our container's hash ID is e09883662c2b. The next command should offer us internal IP addresses, but not in Podman containers:

$ podman inspect e098 | grep IP "IPAddress": "", "IPPrefixLen": 0, "IPv6Gateway": "", "GlobalIPv6Address": "", "GlobalIPv6PrefixLen": 0, "LinkLocalIPv6Address": "", "LinkLocalIPv6PrefixLen": 0,

The top line in the output demonstrates that an IP address doesn't appear to be allocated, even though from a container's perspective an IP address is actually allocated via slirp4netns(the component that provides userspace networking functionality that was installed earlier). The container can apparently only communicate over the network with the host and beyond (and not other containers). There is more information at github.com/rootless-containers/slirp4netns. Thanks to the fact that Podman provides no default networking bridge, this is a limitation when using slirp4netns, which is part and parcel or using rootless mode.

If you need to run the pingcommand from a rootless container for any reason, you might need to tweak the kernel. You can temporarily adjust the tunable kernel setting with this syntax:

$ sysctl -w "net.ipv4.ping_group_range=0 2000000"

To make sure this setting survives reboots, you should add the following command to copy it to a file:

$ echo "net.ipv4.ping_group_range=0 2000000" >> /etc/sysctl.conf

The documentation encourages you to delve into the /usr/share/containersdirectory. As a low-privileged user, you should be able to read the files but not necessarily edit them, as these are for the sysadmin to edit. The files are as follows:

containers.conf seccomp.json

If you look inside the directory /etc/containers, then you can apparently override the settings in the previous directory. The file listing looks like this:

containers.conf policy.json registries.conf registries.d/ storage.conf

Note that Podman reads these configuration files in this order, with the last overriding the previous file's settings potentially:

/usr/share/containers/containers.conf /etc/containers/containers.conf $HOME/.config/containers/containers.conf

The containers.conffile contains a number of user-tunable settings. You can configure cgroups (control groups) and resource quotas such as RAM and CPU, and you can also define which kernel capabilities are included. In Listing 2.5 we can see many default capabilities have been commented out, which means they are not in use but are instead replaced by Podman's corresponding default settings.