Podman on Redhat
by Collins, Kent
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]
3 years, 5 months
volume permission issues after deleting / recreating container
by Jeremy V
Hi,
I am sometimes experiencing an issue where a new container can't write to
an existing volume after removing the old container. The containers are
running rootless on RHEL8.
I tried resetting the permissions on the volume by running the "podman
unshare" command again, but it seems to have no effect. If I create a new
volume and mount it to the new container, the new container can write to
the new volume.
Why is the new container unable to write to the existing volume, but able
to write to a new volume with supposedly identical permissions?
Sequence of events:
1. create volume and container
podman volume create <volume_name>
podman unshare chown 1000:1000 -R <path_to_volume>
podman run -d --name <container_name> ... --volume <volume_name>:/var/log:Z
... <container_image>
2. Some point in the future I get a new container image
podman container stop <container_name>
podman container rm <container_name>
podman run -d --name <container_name> ... --volume <volume_name>:/var/log:Z
... <new_container_image>
3. The new container logs show it is unable to write to the volume
Regards,
--
Jeremy V.
3 years, 5 months
Access container via hostname instead of IP address
by Marcel van Leeuwen
Hi community,
I use Podman on CentOS 7.9 based distro. I use ClearOS 7.9 for my needs. Now I’m dabbling with Podman and have the following question when I used Docker I could use the hostname to call for another container instead of the IP address. How is this done with Podman? I must admit I’m not very experienced with using Docker or Podman on the CLI. I know some basic stuff but enjoy learning.
Regards,
Marcel van Leeuwen
3 years, 6 months
Python process unable to write files
by Josh Berkus
All,
I'm porting a legacy app to containers, and having an issue where
apparently it can't write files while running in podman.
Is there any reason why a python process, or child process, running as
container-root would be unable to write to either the ephemeral
filesystem of the container, or to mounted volumes?
Basically, here's the situation:
- pyhton app with many child processes
- all of them run as container-root
- app is supposed to write logs to files (yes, I know)
- app does not write any logs to any files; in fact, the log-dir
initialization appears to fail (no error messages, though, because it's
not logging)
- one other process which is supposed to write cache to a dir does not do so
- all of these directories are under /app/ a directory COPYd into the
image definition, not /var/ or home
- have tried both with these dirs as local to the container, and as
mounted volumes on the host system
- if I exec in to the container as container-root, I can write files to
those dirs
- SELinux denial log on the host does not show any denials
It is entirely possible that this is a problem with the legacy app and
is not a podman thing at all. I'm asking here because I want to
eliminate podman as a potential cause of the problem.
--
-- Josh Berkus
Kubernetes Community Architect
OSPO, OCTO
3 years, 6 months
