5:02 p.m.
Kent,
That is correct, you cannot log into a system as root, then use su -
$USER to become a user and expect Rootless to work. You must login as the
user account you want to use so that the correct login variables get set.
When you first asked I thought you .want logging in as a user, then using
su or su - to become root.
Email is a really bad forum for trying to answer these questions while
global support is also trying to answer them. It creates a lot of confusion
and chatter between a bunch of different teams trying to solve your problem.
I don't know what you are trying to do with systemd so I'm going to have to
encourage you to continue to work that through support.
Best Regards
Scott M
On Mon, Aug 23, 2021, 2:55 PM Collins, Kent <Robert.Collins(a)bnsf.com> wrote:
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
[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:* 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(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...
<https://imsva91-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3...
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
1:31 p.m.
New subject: Podman on Redhat
Bottom line is `su -` does not remove the environment variables that are
set, and this confuses Podman, to attempt to write to XDG_RUNTIME_DIR of
root, when the process is running as non root and this causes podman to
fail. Podman expects the environment of the user running Podman to be
setup correctly for their login shell.
On 8/23/21 17:02, Scott McCarty wrote:
Kent,
That is correct, you cannot log into a system as root, then use su
- $USER to become a user and expect Rootless to work. You must login
as the user account you want to use so that the correct login
variables get set.
When you first asked I thought you .want logging in as a user, then
using su or su - to become root.
Email is a really bad forum for trying to answer these questions while
global support is also trying to answer them. It creates a lot of
confusion and chatter between a bunch of different teams trying to
solve your problem.
I don't know what you are trying to do with systemd so I'm going to
have to encourage you to continue to work that through support.
Best Regards
Scott M
On Mon, Aug 23, 2021, 2:55 PM Collins, Kent <Robert.Collins(a)bnsf.com
<mailto:Robert.Collins@bnsf.com>> wrote:
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
<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
<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
<mailto:jeremy.valcourt@gmail.com>; Walsh, Daniel
<dwalsh(a)redhat.com <mailto:dwalsh@redhat.com>>; podman mailing
list <podman(a)lists.podman.io <mailto: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(a)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...
<https://imsva91-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3...
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(a)gmail.com
<mailto:jeremy.valcourt@gmail.com>; dwalsh(a)redhat.com
<mailto:dwalsh@redhat.com>
*Cc:* podman(a)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(a)lists.podman.io
<mailto:podman@lists.podman.io>
To unsubscribe send an email to podman-leave(a)lists.podman.io
<mailto:podman-leave@lists.podman.io>
1:02 a.m.
New subject: Podman on Redhat
As usual, the real problem is not "Podman doesn't work" when something
other than the simplest, single container is deployed. The real problem is
orchestration.
To deploy a container that uses REST API 2 requirements:
1. The Podman service is started - i.e. Podman service must be synchronized
with container using systemd units dependencies "Requires" and
"After"
2. The real socket path must be known. There are several places in the
Podman documentation and containers.conf where this is explained but it can
be retrieved in the deployment time using *podman info --format='{{json
.}}' | jq .host.remoteSocket.path* if somebody is too lazy to read the
far-to-be-perfect Podman documentation or depends on the DevOps team..
podman info --format='{{json .}}' | jq .host.remoteSocket.path
On Tue, Aug 24, 2021 at 8:33 PM Daniel Walsh <dwalsh(a)redhat.com> wrote:
Bottom line is `su -` does not remove the environment variables that
are
set, and this confuses Podman, to attempt to write to XDG_RUNTIME_DIR of
root, when the process is running as non root and this causes podman to
fail. Podman expects the environment of the user running Podman to be
setup correctly for their login shell.
On 8/23/21 17:02, Scott McCarty wrote:
Kent,
That is correct, you cannot log into a system as root, then use su -
$USER to become a user and expect Rootless to work. You must login as the
user account you want to use so that the correct login variables get set.
When you first asked I thought you .want logging in as a user, then using
su or su - to become root.
Email is a really bad forum for trying to answer these questions while
global support is also trying to answer them. It creates a lot of confusion
and chatter between a bunch of different teams trying to solve your problem.
I don't know what you are trying to do with systemd so I'm going to have
to encourage you to continue to work that through support.
Best Regards
Scott M
On Mon, Aug 23, 2021, 2:55 PM Collins, Kent <Robert.Collins(a)bnsf.com>
wrote:
> 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
>
> [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:* Scott McCarty [mailto:smccarty@redhat.com]
> *Sent:* Thursday, August 19, 2021 5:21 AM
> *To:* Collins, Kent <Robert.Collins(a)BNSF.com> <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(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...
>
<https://imsva91-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3...
>
>
>
> 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
>
>
>
>
_______________________________________________
Podman mailing list -- podman(a)lists.podman.io
To unsubscribe send an email to podman-leave(a)lists.podman.io
1185
days inactive
1188
days old
2 comments
3 participants
participants (3)
-
Daniel Walsh -
Pavel Sosin -
Scott McCarty