In the previous post, I was debugging a discrepancy between the local preview of this blog and the published version. To figure out what was going on, I had to use the Docker image that the CI uses to build the site, so I decided to give Podman a shot, to try using rootless containers.

The problem was that I couldn't get Podman to build the image or run other containers. Considering that Docker would do fine, I built the image with Docker and solved the bug with the preview before coming back to this issue.

Let's see the Dockerfile:

FROM alpine:3.19

RUN apk --update add --no-cache zola ripgrep make

The build command is as straightforward:

podman build --tag blog-ci:dev .

This command should build the image from a Dockerfile present in the current directory and tag it as blog-ci:dev so we can easily reference it. Except I got an error as it started pulling the layers (split for reading convenience, it was a single line):

Error: creating build container:
copying system image from manifest list:
writing blob:
adding layer with blob <blob's sha>:
processing tar file
(potentially insufficient UIDs or GIDs available in user namespace
  (requested 0:42 for /etc/shadow):
    Check /etc/subuid and /etc/subgid if configured locally
    and run "podman system migrate":
      lchown /etc/shadow: invalid argument
):
exit status 1

A long error message but it contains a clear lead: Check /etc/subuid and /etc/subgid if configured locally.

As explained by Rootless Containers, implementations use user namespaces to provide rootless containers, where UIDs inside the container are mapped to UIDs on the host. We can start by mapping the container's root user to the user's UID, but if we need more users (and UIDs) inside the container we also need more UIDs on the host. We use subuids for this: we allocate a set of subuids to the user, usually outside the regular range of UIDs (0 - 65535), that Podman can use to map the container's users to.

Rootless Containers also has a section on how to configure /etc/subuid and /etc/subgid, which says that these are usually configured by the system. A quick check revealed that this is not the case on my machine: both files exist but are completely empty. I checked a Fedora machine that is not enrolled in my FreeIPA domain and that local user does have a range of subuids assigned to it in both files. So I just had to find a way to configure this with FreeIPA.

I remembered that at some point while configuring the FreeIPA server I came across an option to configure subuids: looking in the web UI I found it under Identity/Users/Subordinate IDs. There you can add or delete ranges for FreeIPA users. And apparently while playing with the configuration I auto-assigned myself a range! So now the problem was to learn how to tell my system to use that range.

A search lead me to this thread which points to the with-subid SSSD option which must be enabled in /etc/nsswitch.conf. Before enabling the option, I confirmed with authselect current that the current profile did not have the option enabled. Then I ran authselect enable-feature with-subid to enable it.

This alone did not fix the problem, as the error kept occurring so I ran getsubids julioloayzam which seemingly refreshed the subuids, and I was able to build the Podman image. :D

As a short conclusion, I came across this FreeIPA issue that shows the --subid option of ipa-client-install, which enables the feature when enrolling a machine. It's also present in the ipaclient role of the FreeIPA Ansible collection, so definitely something I'll enable when enrolling machines.

The picture

One time when out for lunch I saw this tree with bright pink, feather-like leaves. I think it's a Toona Sinensis: I searched for "tree with pink leaves" and it seems to match. Looking for other pictures to confirm it, I found this article with photos of the same species on a different street in Paris. And it says that the leaves quickly turn green after growing, so I discovered at the right time!

A picture of a Toona Sinensis, a tree with pink feather-like leaves.