# in environment ?
by lejeczek
Hi guys.
Do you use # in your envs?
I wonder if it's just me having issues with those.
For a test, to reproduce the issue, 'ghost' web solution
would be easy & quick:
-> $ podman run -dt ...................... --env
database__client=mysql --env
database__connection__host=11.1.0.1 --env
database__connection__user=ghostadm --env
database__connection__password='xyz#admghost' --env
database__connection__database=ghost_xyz --env
url=https://ghost.xyz
So far all I've tried with 'database__connection__password'
failed, quoting &| escaping.
I often use # - does anybody have a way to make it work?
many thanks, L.
1 week, 6 days
RunRoot & mistaken IDs
by lejeczek
Hi guys.
I experience this:
-> $ podman images
WARN[0000] RunRoot is pointing to a path
(/run/user/1007/containers) which is not writable. Most
likely podman will fail.
Error: creating events dirs: mkdir /run/user/1007:
permission denied
-> $ id
uid=2001(podmania) gid=2001(podmania) groups=2001(podmania)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
I think it might have something to do with the fact that I
changed UID for the user, but why would this be?
How troubleshoot & fix it, ideally without system reboot?
many thanks, L.
1 month, 2 weeks
shouldn't the current directory be the default context for "podman build"?
by Robert P. J. Day
"man podman-build" suggests that the context argument is optional:
SYNOPSIS
podman build [options] [context]
podman image build [options] [context]
...
If no context directory is specified, then Podman will assume
the current working directory as the build context, which
should contain the Containerfile.
but if i have a directory with nothing but a Containerfile, i get:
$ podman build
Error: no context directory specified, and no containerfile specified
$
OTOH, specifying context of current directory:
$ podman build .
STEP 1: FROM alpine:latest
... etc etc ...
thoughts?
rday
8 months, 1 week
ro sysfs doesn't affect spc_t?
by Peter Hunt
Hey team,
I've got some odd behavior on a podman in Openshift use case I am trying to
figure out. I am trying to run podman in openshift without privilege, extra
capabilities and ideally a custom SELinux label that isn't `spc_t`. I have
managed to adapt the `container_engine_t` type to get past any denials, but
now I'm hitting an issue where the sysfs of the container is read only:
I am running with this yaml:
```
apiVersion: v1
kind: Pod
metadata:
name: no-priv
annotations:
io.kubernetes.cri-o.Devices: "/dev/fuse"
spec:
containers:
- name: no-priv-rootful
image: quay.io/podman/stable
args:
- sleep
- "1000000"
securityContext:
runAsUser: 1000
seLinuxOptions:
type: "container_engine_t"
```
and using a container-selinux based on
https://github.com/haircommander/container-selinux/tree/engine_t-improvem...
when I run this container, and then run podman inside, I get this error:
```
$ oc exec -ti pod/no-priv-rootful -- bash
[podman@no-priv-rootful /]$ podman run ubi8 ls
WARN[0005] Path "/run/secrets/etc-pki-entitlement" from
"/etc/containers/mounts.conf" doesn't exist, skipping
Error: crun: set propagation for `sys`: Permission denied: OCI permission
denied
```
What I find odd, and what is the subject of this email, is that when I
adapt the selinux label to be "spc_t":
```
type: "spc_t"
```
the container runs fine. There are no denials in AVC when I run
`container_engine_t`, but clearly something is different. Can anyone help
me identify what is happening?
Thanks
Peter
--
Peter Hunt, RHCE
They/Them or He/Him
Senior Software Engineer, Openshift
Red Hat <https://www.redhat.com>
<https://www.redhat.com>
1 year, 8 months
lsetxattr with GlusterFS ?
by lejeczek
Hi guys
I'm trying to run a container with some vols on a GlusterFS
volume:
-> $ { export _NAME="ko.xyz"; export
_PATH=/00-APKI//${_NAME}; echo; mkdir -p
${_PATH}/{,root,media,files,apps,themes,images,settings,data,public};
}; podman run -dt --restart=always --volume
${_PATH}/config.production.json:/var/lib/ghost/config.production.json
--volume ${_PATH}/root:/root:z
Error: lsetxattr /00-APKI/ko.xyz/media: operation not supported
..
GF vol is:
Volume Name: APKI
Type: Replicate
Volume ID: b90bc19a-9636-44f7-9b72-453ca9713b6a
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x (2 + 1) = 3
Transport-type: tcp
Bricks:
Brick1: 10.1.1.100:/devs/00.GLUSTERs/APKI
Brick2: 10.1.1.101:/devs/00.GLUSTERs/APKI
Brick3: 10.1.1.99:/devs/00.GLUSTERs/APKI-arbiter (arbiter)
Options Reconfigured:
performance.client-io-threads: off
transport.address-family: inet
storage.fips-mode-rchecksum: on
cluster.granular-entry-heal: on
storage.owner-uid: 2002
storage.owner-gid: 2002
cluster.shd-max-threads: 3
features.cache-invalidation-timeout: 900
performance.cache-invalidation: on
performance.nl-cache: on
performance.nl-cache-timeout: 600
performance.parallel-readdir: on
performance.readdir-ahead: on
performance.stat-prefetch: on
cluster.self-heal-daemon: enable
_autofs_ makes the moutpoing with:
/00-APKI
-fstype=glusterfs,capability,kernel-writeback-cache=1,acl,log-file=/var/log/glusterfs/mount.APKI.log
10.1.1.100,10.1.1.99,10.1.1.101:/APKI
I fiddled with both autofs & gluster but cannot figure it
out - would somebody know what's wrong/missing here?
I suspect it's due to SE labeling - which would be great to
have, naturally.
many thanks, L.
1 year, 8 months
subuids in sync across ?
by lejeczek
Hi guys.
I thought this must be trivial & common yet I failed to find
here on the list & the net, any info on:
how to keep subuid & subgid in sync across different PCssystems?
Would it be simply a matter of keeping all relevant /etc
bits in sync - naturally I'm thinking all the bits which are
important to _podman_
many thanks, L.
1 year, 8 months
docker registry token authentication and podman
by Михаил Иванов
Hallo, not sure if this is the right place for such question, but still.
I'm trying to set up a token authentication for docker registry and using
podman login to test it. As per description podman should receive
'401 Unauthorized' error and headers in the reply should contain
'Www-Authenticate:' entry. As far as I understand, podman should then
automatically try to access url, specified in this entry to get the token.
But it just terminates with 401 error. I verified registry access with curl
and I see, that Www-Authenticate is present.
Should podman actually request the token automatically or do I misunderstand this?
Best regards,
--
Michael Ivanov
1 year, 8 months
