Recently, I believe an update or packaging problem has been causing
podman to throw errors like:
```
level=error msg="running `/usr/bin/newuidmap ...`: newuidmap: open of
uid_map failed: Permission denied\n"
```
This seems to have something to do with the shadow-utils package, which
owns this binary. I've examined the file attribuites and permissions
along with /etc/sub{uid,gid} contents. The only thing that seems to
resolve the issue is reinstalling shadow-utils. Attempt that fix here
and hope it clears up the problem (present in v2.0.0)
Signed-off-by: Chris Evich <chris_gitlab@icuc.me>
* Add note about volume-mounts being cumulative with base-image
* Fix register & run labels to use (correct) base image's
`/home/podman/.local/share/containers/` instead of defining
a new (wrong/useless) `storage` volume.
* Fix register & run labels to mask over `/var/lib/containers`
with a read-only tmpfs to block any nested rootful use of
podman as a security precaution.
Signed-off-by: Chris Evich <chris_gitlab@icuc.me>
The podman base-image is intended to support running nested-podman both
root and rootless. Since pipglr only ever runs rootless, eliminate the
nested usernamespace mapping needed to support nested-root usage.
Signed-off-by: Chris Evich <chris_gitlab@icuc.me>
The function was defined but never called, resulting in immediate exit
of the maintenance script. Fix this, also add a configuration build-arg and
ENV to control the cleaning interval.
Signed-off-by: Chris Evich <chris_gitlab@icuc.me>
When given the "run" argument, in addition to launching `podman system
service` in the background, also start a small periodic maintenance
script. It's only job is to clean up stale images, containers, and
volumes from old jobs. Currently hard-coded to trigger every 2 days,
this could be tweaked via build-args or env. var.
Signed-off-by: Chris Evich <cevich@redhat.com>
