Add configuration option to add user to one or more groups.

[msgilligan]

Description

It would be nice to have an option in the configuration YAML to add the (non-root) user to one or more groups.

In my specific use-case, I'm trying to create a Debian Bookworm Podman instance and in order for podman logs to work properly the non-root user must be added to the systemd-journal group.

If you try to do this in the (system mode) provisioning script the usermod command will run after the user shell has already started and this (typically) requires the VM to be restarted for the change to take effect. If you try in the boot mode provisioning script, the user account has not been created yet.

See Discussion #691

[afbjorklund]

This is called groups in cloud-init.

https://cloudinit.readthedocs.io/en/latest/reference/examples.html

---

But systemd-journal should only be needed for system logs - not for user logs ? Podman normally uses sudo for root, rather than groups.

• Podman: missing group to access container logs #1587

[msgilligan]

I'm using Debian Bookworm and unless I add my user to systemd-journal, when I run a container and then use podman logs, I get the following error:

Error: initial journal cursor: failed to get cursor: cannot assign requested address

See also: https://www.reddit.com/r/debian/comments/145ld8c/share_some_basic_podman_settings_on_debian_12/

(Bookworm has Podman 4.3.1)

[msgilligan]

Here's my complete YAML (with the usermod command that requires rebooting), for reference:

# Based on /opt/homebrew/share/lima/examples/debian.yaml
images:
- location: "https://cloud.debian.org/images/cloud/bookworm/20230711-1438/debian-12-genericcloud-amd64-20230711-1438.qcow2"
  arch: "x86_64"
  digest: "sha512:1aacc645dc1ee2ed9d511e89da8ece7d390ed19c14839a1fcf989e7b5e66511bd538a01cb23c8fd04f1ac662541daaa999ea5bd6fb0676a86e303325328d2b10"
- location: "https://cloud.debian.org/images/cloud/bookworm/20230711-1438/debian-12-genericcloud-arm64-20230711-1438.qcow2"
  arch: "aarch64"
  digest: "sha512:caf7b3015b2c945dd75d1760e0f020239f8f7993e6114360e0b6cfd9536c8a6bc3cbc594f0a1135acfd07b49f2a64e3250eb56114e16b88b2635b9064f3f7ae7"
vmType: "vz"
mountType: "virtiofs"
mounts:
- location: "~"
- location: "/tmp/lima"
  writable: true

# CPUs: if you see performance issues, try limiting cpus to 1.
# 🟢 Builtin default: 4
cpus: 8

# Memory size
# 🟢 Builtin default: "4GiB"
memory: 16GiB

# Disk size
# 🟢 Builtin default: "100GiB"
disk: 200GiB

ssh:
  # This allows access to Github for `git clone`
  forwardAgent: true

containerd:
  # Enable system-wide (aka rootful)  containerd and its dependencies (BuildKit, Stargz Snapshotter)
  # 🟢 Builtin default: false
  # system: false
  # Enable user-scoped (aka rootless) containerd and its dependencies
  # 🟢 Builtin default: true
  user: false

provision:
- mode: system
  script: |
    #!/bin/bash
    set -eux -o pipefail
    apt-get update
    apt-get upgrade -y
    apt-get install -y podman
    usermod -aG systemd-journal $LIMA_CIDATA_USER
    echo 'unqualified-search-registries = ["docker.io"]' > /etc/containers/registries.conf.d/unqualified-dockerhub.conf
    apt-get install -y git
- mode: user
  script: |
    #!/bin/bash
    set -eux -o pipefail
    systemctl --user start dbus
    systemctl --user enable podman-restart
    mkdir -p pods
    mkdir -p git

message: |
  In this configuration Podman is not accessible from the host.
  See "/var/log/cloud-init-output.log" in the guest if you suspect a provisioning problem.

[afbjorklund]

Sounds like a bug in debian (or missing dependency), there is no such need when running podman with fedora.

• Error: initial journal cursor: failed to get cursor: cannot assign requested address containers/podman#12029

Possibly some configuration issue with journald, or some other systemd quirks. Maybe just log to files instead ?

It would be a good feature to add anyway, but not for adding users to privileged system groups because of bugs.

[afbjorklund]

Probably needs more details (or links) on what is required from instance, beyond debian.yaml + apt install podman ?

It seems to be working reasonably, without extra dbus service... It would need some extra setup, of a session etc.

WARN[0000] The cgroupv2 manager is set to systemd but there is no systemd user session available 
WARN[0000] For using systemd, you may need to login using an user session 
WARN[0000] Alternatively, you can enable lingering with: `loginctl enable-linger 1000` (possibly as root) 
WARN[0000] Falling back to --cgroup-manager=cgroupfs    
Client:       Podman Engine
Version:      4.3.1
API Version:  4.3.1
Go Version:   go1.19.8
Built:        Thu Jan  1 00:00:00 1970
OS/Arch:      linux/amd64
WARN[0000] Failed to add pause process to systemd sandbox cgroup: exec: "dbus-launch": executable file not found in $PATH 

And the overlayfs seems to be broken as well, it is falling back to slow graphDriverName: vfs. Even with Linux 6.

[jandubois]

Can we move the specific podman discussion somewhere else; it is tangential at best to support adding additional groups via cloud-init, which may have other use-cases. Note the gymnastics templates/docker-rootful.yaml has to do to work around this problem.

I would hope (but have not tested) that having a way to add this to user-data would solve the problem:

groups:
- docker

users:
- name: $USER
  groups: docker

[msgilligan]

Can we move the specific podman discussion somewhere else

Where? I would like to continue it somewhere. I could create a discussion or issue for it. I would be interested in helping create/test a "template" for Podman on Debian (starting with Bookworm) if there is interest in seeing that happen.

[jandubois]

I could create a discussion or issue for it.

Please create a discussion for it. Issues should be "actionable", with some kind of acceptance criteria (often just implied) on when they can be closed.

The result of the discussion can be turned into a new issue once there is some kind of consensus that "something should be done".

[afbjorklund]

This feature is blocked from being useful for the "docker" group, since:

1. The group must be available at boot time, i.e. when the user is created
2. The docker package is not yet installed then, so the group does not exist
3. The cloud-init groups don't allow creating system groups or specifying gid

It is possible to create a regular group, but it looks silly and shifts the numbers...
That is: if "docker" gets group ID 1000 then the user gets UID 1000 and GID 1001
Also it is not standard, since normally the docker group is a system group (<1000)
So it might as well continue with the current workaround and let user own socket.

• Use "groupadd --system" to create group canonical/cloud-init#4603

Another reason is that podman doesn't even have a group, for podman-rootful.
(so it would still mean doing it one way for docker, and another way for podman)

[jiridanek]

With respect to rootful podman usage, I ended up setting acls to make the podman socket accessible to my user. This does not persist across restarts, but it's good enough for me to deal with the RHOAIENG-17695 thing seen just above this comment here

lima sudo systemctl start podman
lima sudo dnf install acl
lima sudo setfacl -m u:${USER}:x /var/run/podman
lima sudo setfacl -m u:${USER}:rw /var/run/podman/podman.sock

[msgilligan]

I'm running into the same issue trying to setup a VM running Incus. I want to automatically add the user to incus-admin.

[jandubois]

I'm running into the same issue trying to setup a VM running Incus. I want to automatically add the user to incus-admin.

Is there a reason you cannot do this in a system provisioning script?