is OpenPGP the only supported image signing open supported by podman /
skopeo or are there other options? Using OpenGPG works quite fine for me
so far but in the end we are trying to sign an image using an IBM 4765
crypto card and so far have not figured out how this can play together.
I can run the discourse image with docker, export the container and
import it as an image into podman.
The script that manages docker discourse containers is:
and is attached. It would be good if it were possible to just replace
all the occurrences of "docker" with "podman", fix version numbers etc
and be able to use the script - but can any gurus see dockerisms in the
script that will cause podman gotchas for this idea?
PO Box 896
Cowra NSW 2794
I am starting a container using the following command
`sudo podman run -p 80:80 -v ./envoy.yaml:/etc/envoy/envoy.yaml:Z
--name dev-envoy --network dev --security-opt
The application starts but exits. It cannot bind to container's port
80.Here is an excerpt from logs:
`cannot bind '0.0.0.0:80': Permission denied`
The SEModule policy was generated using Udica. It can be reviewed here
<https://pastebin.com/3Du3GTzt>. Steps for this process are discussed in
an earlier thread named 'Logs show permission denied error'.
The containerfile used to created this container image executes the
application as a non-root user. As the container exits right after it
starts, it is impossible to access the container's terminal and attempt
elementary troubleshooting steps.
How to bind to HTTP(S) and other lower ports in a rootful container when
the application executes as a non-root user?
Today, we're releasing updates to fix CVE-2020-14370 , a security
issue in Podman. This is a medium-severity information disclosure
vulnerability that affects containers created using Podman’s Varlink
API or the Docker-compatible version of its REST API. If two or more
containers are created using these APIs, and the first container had
environment variables added to it when it was created, all subsequent
containers created using the Varlink or Docker-compatible REST APIs
will also have these environment variables added. This effect does not
persist after restarting the Podman API service.
Podman v2.0.5 and higher contain a fix for the CVE. If you use either
of these APIs, please update to Podman v2.0.5 or later. We will also
be patching the long-term support v1.6.4 release used in RHEL and
Hoping for clarification(s) from the source ...
I'm trying to get the following to run:
* In a QubesOS Xen VM running Fedora 31, I'm
* using podman to run a rootless docker.io/rocker/tidyverse container
podman run -d -p 127.0.0.1:8787:8787 -v /tmp:/tmp -e ROOT=TRUE -e
From the podman host I can test the setup using curl like so:
curl -I --user-agent 'GoogleChrome' http://localhost:8787
with the following result:
HTTP/1.1 200 OK
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Date: Wed, 09 Sep 2020 22:38:46 GMT
That looks OKish, no?
When I try however (again in the podman hosting Xen VM) to access
localhost:8787 using a browser (tried firefox and chromium), the tab
shows the appropriate RStudio label, yet the loading-indicating applet
spins endlessly to be replaced by a message stating that R takes longer
than usual to load, accompagnied by buttons for reloading, starting in
safe mode and restarting the R session (none of which make any
Does anyone have an inkling why I might be unable to browse to the
RStudio Server installation? Is this a case of browser incompatibility
fixable by using Google Chrome proper (or adjusting the user agent
string (to what?))?
Thanks for any hints.
If I pull a RHEL UBI image like so (On Windows using cygwin and podman),
$podman pull registry.access.redhat.com/ubi8/ubi
Is there a command I can run on the host system (Windows) to create a file
on the host (Windows) that would be a rootfs.tar of the UBI image that was
I want to then use that rootfs.tar to run on the Windows host under WSL2.
If anyone has done this *or if there is another way* to fetch the UBI image
as a rootfs.tar, it would be greatly helpful.
This is something I want to do regularly (pull the latest UBI image, on the
day of each new update/release of the image), and run under Windows WSL2.
After receiving a number of requests, we've decided to hold a
Podman Community Meeting on the first Tuesday of every month starting on
October 6, 2020. At the moment the meetings are planned to be held at
11:00 a.m. and we'll be holding the meeting via a video conference. We
will publish an agenda and will ask people to send in questions prior
and we will also set aside a chunk of time at the end of the meeting for
an open question and answer session.
These meetings will be free to attend and all are welcome. We are
still working out the details of the agenda and the video software to
use, so please stay tuned for more details in the next week or two. We
just primarily wanted to get this announcement out so you could set
aside the time if you wanted to attend.
We look forward to seeing many of you in the meeting on October 6th!
We have been discussing setting up a bi-weekly community/contributors
meeting on the container engines. Would people/contributors be
interested in participating in this?
We are debating doing it either via bluejeans or just in IRC on the
#podman channel in #freenode.
We would like to have open communications about what we plan on working
on in the Container Engines team and would like to get feedback
requirements and other ideas from the greater community.
What do people think? Our goal would be to do this at a time that is
open to Full US and Europe at least to start.
Maybe around 14:00 or 15:00 UTC.
There may not be a good answer to this question, but I was
wondering if anyone has a suggestion. I'm using rootless podman
for local development environments for Node.js and PHP projects.
I can't wait to rebuild an image after each file is changed, so
I'm bind mounting my project's working directory into the
container so changes are reflected instantly. A consequence of
this is that all of the project files are owned by the root user
inside the container (since they are owned by my regular user
outside). This means that I need to run any commands as root in
the container in order to have access to the project files. That,
in itself, is not a big deal. The problem is that a lot of
software doesn't like to be run as root. I have run into problems
- PHP-FPM requires a special flag to run as root and config changes
- WP-CLI requires a special flag added to any command to run as root
- Compiling software can fail as part of npm install (specifically with gulp-imagemin)
None of these issues are really show stoppers, but they do slow
down development, and each time I run into a new one it can take
time to debug.
Are there any workarounds that allow for fast development, the
user running in the container to not be root, and reasonable
security (e.g. I don't really want to chmod 777 all of my project