12:21 p.m.
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(a)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_tu...
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
[image: 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
[image: BNSF_CW_Top_100_2016]
*From:* Collins, Kent
*Sent:* Wednesday, August 18, 2021 9:16 AM
*To:* jeremy.valcourt(a)gmail.com; dwalsh(a)redhat.com
*Cc:* podman(a)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
[image: 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
[image: BNSF_CW_Top_100_2016]
_______________________________________________
Podman mailing list -- podman(a)lists.podman.io
To unsubscribe send an email to podman-leave(a)lists.podman.io
8:55 p.m.
New subject: Podman on Redhat
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.
• A Request for Feature
Enhancement<https://bugzilla.redhat.com/show_bug.cgi?id=1996757> 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(a)BNSF.com>
Cc: jeremy.valcourt(a)gmail.com; Walsh, Daniel <dwalsh(a)redhat.com>; podman mailing
list <podman(a)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<mailto: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_tu...
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<mailto:jeremy.valcourt@gmail.com>;
dwalsh@redhat.com<mailto:dwalsh@redhat.com>
Cc: podman@lists.podman.io<mailto: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<mailto:podman@lists.podman.io>
To unsubscribe send an email to
podman-leave@lists.podman.io<mailto:podman-leave@lists.podman.io>
971
days inactive
975
days old
1 comments
2 participants
participants (2)
-
Collins, Kent -
Scott McCarty