The Redhat support site updated today with the following: 

So the documentation is wrong and the podman tool does not work if you su or sudo.

 

RedHat support site is updated as below today.

Resolution 

·         It is currently not supported by Red Hat to use rootless podman via another other means than using ssh to access the user you intend to execute podman as. Using su or su - is not a currently supported mechanism of rootless podman. 

·         The following steps show a completely unsupported method of working around this, and as every user environment has the potential to be different, cannot be guaranteed to work or even troubleshot by Red Hat Support at this time. 

·         Request for Feature Enhancement has been opened to allow for Rootless Podman to execute with su or su - to a non-root user.

https://access.redhat.com/solutions/6204862

 

 

 

Kent Collins

Office:  817.352.0251 | Enterprise Information Management | Cell: 817.879.7764

Data Solutions Architect/Scientist – Published Author and Conference Speaker

ibm-champion-analytics-7-year-milestone

“Death and life are in the power of the tongue: and they that love it shall eat the fruit thereof.”

Prov 18:21

 

BNSF_CW_Top_100_2016

 

From: Scott McCarty [mailto:smccarty@redhat.com]
Sent: Thursday, August 19, 2021 5:21 AM
To: Collins, Kent <Robert.Collins@BNSF.com>
Cc: jeremy.valcourt@gmail.com; Walsh, Daniel <dwalsh@redhat.com>; podman mailing list <podman@lists.podman.io>
Subject: Re: [Podman] Re: Podman on Redhat

 

EXTERNAL EMAIL

Kent,

    That at least gives me a hair to work with. It sounds like this was a RHEL 8.0 or 8.1 box which was upgraded to RHEL 8.4. In those esrly versions of RHEL, there were still some manual steps to getting rootless working.

 

In RHEL 8.4 rootless should work quite well with no extra steps necessary. We've done a lot of work to make sure it works out of the box.

 

In addition to the upgrade problem, I suspect your corporate standard might make security changes which could make rootless.more fragile.

 

Do you have permissions to add a new user? If so, could you add a test user and try to run your command with that? 

 

This would give us a baseline to ensure that it's not something in the default configuration of your user account.

 

Best Regards

Scott M

 

 

 

On Wed, Aug 18, 2021, 3:48 PM Collins, Kent <Robert.Collins@bnsf.com> wrote:

Hi

The Unix setup was correct already.  No issues.

 

If you do not setup the subuid and subgid files you get the error below.

 

ERRO[0000] cannot find UID/GID for user b000980: No subuid ranges found for user "b000980" in /etc/subuid - check rootless mode in man pages.

WARN[0000] using rootless single mapping into the namespace. This might break some images. Check /etc/subuid and /etc/subgid for adding sub*ids

Error: stat /db/admin/rest/images/db2rest.tar: permission denied

 

So all the steps were done perfectly following  ( Steps 1-3 were done )

https://github.com/containers/podman/blob/main/docs/tutorials/rootless_tutorial.md#etcsubuid-and-etcsubgid-configuration

 

So far no luck getting podman to work.

 

I ran the failing command using debug

 

DEBU[0000] Workdir "/opt/ibm/dbrest" resolved to host path "/home/db2rest1/.local/share/containers/storage/overlay/719f222c5894b8b113d90bae2d0a64dffba8b3303bc0513617e3176bf6ea6200/merged/opt/ibm/dbrest"

DEBU[0000] Not modifying container 9a7e3a501de24c4afb08f105817d3e443a7f381cd7441b7b861b64ad3b77677c /etc/passwd

DEBU[0000] Not modifying container 9a7e3a501de24c4afb08f105817d3e443a7f381cd7441b7b861b64ad3b77677c /etc/group

DEBU[0000] /etc/system-fips does not exist on host, not mounting FIPS mode subscription

DEBU[0000] Setting CGroups for container 9a7e3a501de24c4afb08f105817d3e443a7f381cd7441b7b861b64ad3b77677c to user.slice:libpod:9a7e3a501de24c4afb08f105817d3e443a7f381cd7441b7b861b64ad3b77677c

DEBU[0000] reading hooks from /usr/share/containers/oci/hooks.d

DEBU[0000] Created OCI spec for container 9a7e3a501de24c4afb08f105817d3e443a7f381cd7441b7b861b64ad3b77677c at /home/db2rest1/.local/share/containers/storage/overlay-containers/9a7e3a501de24c4afb08f105817d3e443a7f381cd7441b7b861b64ad3b77677c/userdata/config.json

DEBU[0000] /usr/bin/conmon messages will be logged to syslog

DEBU[0000] running conmon: /usr/bin/conmon               args="[--api-version 1 -c 9a7e3a501de24c4afb08f105817d3e443a7f381cd7441b7b861b64ad3b77677c -u 9a7e3a501de24c4afb08f105817d3e443a7f381cd7441b7b861b64ad3b77677c -r /usr/bin/runc -b /home/db2rest1/.local/share/containers/storage/overlay-containers/9a7e3a501de24c4afb08f105817d3e443a7f381cd7441b7b861b64ad3b77677c/userdata -p /tmp/runtime-u1/containers/overlay-containers/9a7e3a501de24c4afb08f105817d3e443a7f381cd7441b7b861b64ad3b77677c/userdata/pidfile -n db2rest_dsn08d --exit-dir /tmp/runtime-u1/libpod/tmp/exits --socket-dir-path /tmp/runtime-u1/libpod/tmp/socket -s -l k8s-file:/home/db2rest1/.local/share/containers/storage/overlay-containers/9a7e3a501de24c4afb08f105817d3e443a7f381cd7441b7b861b64ad3b77677c/userdata/ctr.log --log-level debug --syslog -t --conmon-pidfile /tmp/runtime-u1/containers/overlay-containers/9a7e3a501de24c4afb08f105817d3e443a7f381cd7441b7b861b64ad3b77677c/userdata/conmon.pid --exit-command /usr/bin/podman --exit-command-arg --root --exit-command-arg /home/db2rest1/.local/share/containers/storage --exit-command-arg --runroot --exit-command-arg /tmp/runtime-u1/containers --exit-command-arg --log-level --exit-command-arg debug --exit-command-arg --cgroup-manager --exit-command-arg systemd --exit-command-arg --tmpdir --exit-command-arg /tmp/runtime-u1/libpod/tmp --exit-command-arg --runtime --exit-command-arg runc --exit-command-arg --storage-driver --exit-command-arg overlay --exit-command-arg --storage-opt --exit-command-arg overlay.mount_program=/usr/bin/fuse-overlayfs --exit-command-arg --events-backend --exit-command-arg file --exit-command-arg --syslog --exit-command-arg container --exit-command-arg cleanup --exit-command-arg 9a7e3a501de24c4afb08f105817d3e443a7f381cd7441b7b861b64ad3b77677c]"

INFO[0000] Running conmon under slice user.slice and unitName libpod-conmon-9a7e3a501de24c4afb08f105817d3e443a7f381cd7441b7b861b64ad3b77677c.scope

DEBU[0000] Received: -1

DEBU[0000] Cleaning up container 9a7e3a501de24c4afb08f105817d3e443a7f381cd7441b7b861b64ad3b77677c

DEBU[0000] Tearing down network namespace at /tmp/runtime-u1/netns/cni-13220a15-ad73-aec3-3ef7-7f7a08eb50f0 for container 9a7e3a501de24c4afb08f105817d3e443a7f381cd7441b7b861b64ad3b77677c

DEBU[0000] unmounted container "9a7e3a501de24c4afb08f105817d3e443a7f381cd7441b7b861b64ad3b77677c"

DEBU[0000] ExitCode msg: "time=\"2021-08-18t14:22:06-05:00\" level=error msg=\"read unix @->/run/systemd/private: read: connection reset by peer\"\ntime=\"2021-08-18t14:22:06-05:00\" level=error msg=\"container_linux.go:367: starting container process caused: process_linux.go:340: applying cgroup configuration for process caused: read unix @->/run/systemd/private: read: connection reset by peer\": oci runtime error"

Error: OCI runtime error: time="2021-08-18T14:22:06-05:00" level=error msg="read unix @->/run/systemd/private: read: connection reset by peer"

time="2021-08-18T14:22:06-05:00" level=error msg="container_linux.go:367: starting container process caused: process_linux.go:340: applying cgroup configuration for process caused: read unix @->/run/systemd/private: read: connection reset by peer"

 

 

Kent Collins

Office:  817.352.0251 | Enterprise Information Management | Cell: 817.879.7764

Data Solutions Architect/Scientist – Published Author and Conference Speaker

ibm-champion-analytics-7-year-milestone

“Death and life are in the power of the tongue: and they that love it shall eat the fruit thereof.”

Prov 18:21

 

BNSF_CW_Top_100_2016

 

From: Collins, Kent
Sent: Wednesday, August 18, 2021 9:16 AM
To: jeremy.valcourt@gmail.com; dwalsh@redhat.com
Cc: podman@lists.podman.io
Subject: Podman on Redhat

 

So far running Podman ( non-Root ) on Redhat has been a horrible experience.  It seems to take very little to break Podman.

 

From breaking when using su or sudo to the directory length issue, these simple normal Unix everyday operations seem to be difficult for development of podman.

 

I am trying to run a very simple API container using Podman as non-root and at this point I cannot start any containers.

 

On top of that, workarounds found in searching for solutions also never work. 

 

For example  these two work arounds do not work.

 

export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$(id -u)/bus

 

systemd-run --scope --user $SHELL

 

I will admit I am not a Podman expert.  My goal in using Podman over Docker should not require it.  It only needs to perform basic container operations.  Stop/start/rm/run/load

 

Any help to get this working would be appreciated.

 

==> podman --version

podman version 3.0.2-dev

 

x    /etc/*ease[1]: NAME="Red Hat Enterprise Linux"                                                                                                 x

x    /etc/*ease[2]: VERSION="8.4 (Ootpa)"                                                                                                           x

x    /etc/*ease[3]: ID="rhel"                                                                                                                       x

x    /etc/*ease[4]: ID_LIKE="fedora"                 

 

 

 

Kent Collins

Office:  817.352.0251 | Enterprise Information Management | Cell: 817.879.7764

Data Solutions Architect/Scientist – Published Author and Conference Speaker

ibm-champion-analytics-7-year-milestone

“Death and life are in the power of the tongue: and they that love it shall eat the fruit thereof.”

Prov 18:21

 

BNSF_CW_Top_100_2016

 

_______________________________________________
Podman mailing list -- podman@lists.podman.io
To unsubscribe send an email to podman-leave@lists.podman.io