fix: Handle libpod rootless containers, use sqlite as the source of info #237
Conversation
vadorovsky
force-pushed
the
podman-rootless
branch
2 times, most recently
from
590e56b to
67a9ee8
Compare
| let image_id = config.rootfs_image_id; | ||
|
|
||
| let image_store_file = | ||
| File::open(&image_store_path).map_err(|source| ContainerError::ReadFile { |
There was a problem hiding this comment.
@banditopazzo To be fair - I'm not entirely happy with the solution, but I couldn't come up with anything better.
This is reading the images.json, which contains the list of all images that podman ever pulled. And unfortunately, here I'm doing this for every container, which is of course bad (O(n) lookup for the image digest for every container...).
But unfortunately, I couldn't find any file which would contain an information about a single image. There is also no information about images in the sqlite database - I tried looking at all tables:
❯ sqlite3 ~/.local/share/containers/storage/db.sql
SQLite version 3.42.0 2023-05-16 12:36:15
Enter ".help" for usage hints.
sqlite> .tables
ContainerConfig ContainerState PodConfig
ContainerDependency ContainerVolume PodState
ContainerExecSession DBConfig VolumeConfig
ContainerExitCode IDNamespace VolumeState
and the only useful table is ContainerConfig, which we are using here, but it contains only rootfsImageID and rootfsImageName - there is no digest.
The only alternative which comes to my mind is some kind of caching, or even keeping the information about every podman image internally in Pulsar - we could try to read images.json only on the initial run and when someone is pulling the image - but the second part would be tricky and not so trivial to implement.
| db_files.push((db_root_path, image_store_root_path)); | ||
| } | ||
|
|
||
| let file = File::open(ETC_PASSWD).map_err(|source| ContainerError::ReadFile { |
There was a problem hiding this comment.
And same here - this is parsing /etc/passwd to get the potential /home directories where we look up for podman files.
The only alternative which comes up to my mind is keeping an internal mapping of users and homedirs. We could have a probe detecting new user creation. Not very easy, but also not very difficult to implement, but I didn't want to jump to it immediately before discussing.
Before this change, we were using `podman inspect` command to get information about libpod containers. But since Pulsar is running as root, using CLI is not going to show any information about rootless containers. This is fixed by using sqlite (which is used internally by libpod) and `images.json` file to resolve all necessary information about containers. To handle rootless containers gracefully, we check whether any user with their own home directory has a libpod database.
vadorovsky
force-pushed
the
podman-rootless
branch
from
59d316c to
8d45f96
Compare
On such system, the following cgroup info was found: ``` 0::/machine.slice/libpod-conmon-551ccf517b3394[...].scope ``` Handle it in our regular expression.
vadorovsky
force-pushed
the
podman-rootless
branch
from
dab063a to
53e6d35
Compare
banditopazzo
merged commit a0004f2
into
exein-io:improve-container-support
Before this change, we were using
podman inspectcommand to get information about libpod containers. But since Pulsar is running as root, using CLI is not going to show any information about rootless containers.This is fixed by using sqlite (which is used internally by libpod) and
images.jsonfile to resolve all necessary information about containers. To handle rootless containers gracefully, we check whether any user with their own home directory has a libpod database.