Reminder Feb 2nd we will have a Podman community meeting.
by Daniel Walsh
Tom Sweeney will be sending out an agenda.
We would love people to play with the podman 3.0 rc1 and rc2 when it
ships to help us improve its stability. Available on Fedora 33/34 now,
and hopefully other distros.
3 years, 3 months
podman run -It -v /tst:/tst --net=host Xxxx /sbin/Init
by Philip Rhoades
People,
If I build a F33 podman container in a virt-manager built F33 VM, I get
a working podman container but if I try:
ls -al /tst
from there I get:
ls: cannot open directory '/tst/': Permission denied
It appears it is because of selinux in the host VM - if I disable that
and build a new container, I can list /tst as expected . .
Is there a fix or workaround for this situation? Am I finally going to
have to learn about selinux?
Thanks,
Phil.
--
Philip Rhoades
PO Box 896
Cowra NSW 2794
Australia
E-mail: phil(a)pricom.com.au
3 years, 3 months
Would a new option --disable-subuid make sense?
by Erik Sjölund
The upcoming Podman 3.0 looks exciting, especially in regards to
"rootless single mapping".
Regarding the question:
> If you know of "features", that you want to get in, then make them known
> in github.
Would it make sense to add these two new command-line options to "podman run"
--disable-subuid
--disable-subgid
so that it would easy to disable the use of
/usr/bin/newuidmap
/usr/bin/newgidmap
That would be handy when a user wants to run podman and be sure that
no subuids and subgids are used.
If you wonder about the terminology:
"rootless single mapping", I found it here:
[erik@laptop podman]$ grep "using rootless " ./pkg/rootless/rootless_linux.go
logrus.Warnf("using rootless single mapping into the namespace. This
might break some images. Check /etc/subuid and /etc/subgid for adding
sub*ids")
[erik@laptop podman]$
I could add a feature request to Github, if you think these options make sense.
3 years, 3 months
We will be preparing the first release candidate for Podman 3.0 this week.
by Daniel Walsh
Once it is available, we would like to get as many people as possible
playing with the release candidates, to improve the 3.0 quality.
If you know of "features", that you want to get in, then make them known
in github.
If you are working on features/bugfixes you want to get in, please try
to complete them early in the week.
Podman 3.0 should be a great release...
3 years, 3 months
Getting Docker Discourse running with Podman
by Philip Rhoades
People,
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:
/var/discourse/launcher
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?
Thanks,
Phil.
--
Philip Rhoades
PO Box 896
Cowra NSW 2794
Australia
E-mail: phil(a)pricom.com.au
3 years, 3 months
LInux Capabilities for a container
by Jorge Fábregas
Hi,
Is there an easy way to figure out which capabilities are needed for a
container other than playing out with the cap-drop & cap-add options?
Thanks.
--
Jorge
3 years, 3 months
Change in rootful userns container capabilities?
by Joost Molenaar
Hello all,
When I upgraded podman from 2.1.1 to 2.2.1, my wireguard container stopped
working because wg-quick returned a 'permission denied' error. After some
bug hunting, I found out that starting a (rootful) container like this...
podman run --rm --uidmap 0:60000:1000 --gidmap 0:60000:1000 \
docker.io/library/alpine:3.12 \
grep ^Cap /proc/self/status
...on podman 2.1.1 returns a capability mask of a80425fb for all of CapInh,
CapPrm, CapEff, CapBnd and CapAmb, and on podman 2.2.1 returns 800405fb for all
of the capability masks except for CapAmb, which is all zeroes.
So on podman 2.1.1 my rootful usernamespaced container ran with these capabilities:
0x00000000a80425fb=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
And on podman 2.2.1 with these:
0x00000000800405fb=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_sys_chroot,cap_setfcap
So, containers no longer run with CAP_NET_RAW, CAP_MKNOD and CAP_AUDIT_WRITE,
which for for my wireguard container means I now have to `--cap-add`
CAP_NET_RAW in addition to CAP_NET_ADMIN, because `wg-quick` runs `iptables`,
which opens some raw sockets to communicate with the kernel.
I wonder what is the background of this change, is it intentional? And I also
noticed CapAmb is now all zeroes, which seems to have to do with commit bce8f8
[1], but reading the code I don't understand why CapAmb is now empty when it
seems to be the intention to populate it.
Regards,
Joost Molenaar
[1] https://github.com/containers/podman/commit/bce8f851c1e891aa6159e61c56ccd...
3 years, 3 months
can not run ubi7-init systemd container, fedora systemd container works fine
by Jan Hutař
Hello!
I have an issue with running "ubi7-init" based container. When I base mine
container on "fedora", it works fine:
$ cat Containerfile
FROM fedora
RUN dnf -y install httpd; dnf clean all; systemctl enable httpd
EXPOSE 80
CMD [ "/sbin/init" ]
and then:
$ sudo podman build -f Containerfile
$ sudo podman run -ti -p 80:80 20185593d0f96c4dee56e351eae4754cdd429679c1b645dae1b6f24880ce33fc
systemd v246.6-3.fc33 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=unified)
[...]
[ OK ] Started The Apache HTTP Server.
[...]
But when I try the same with ubi7-init based container (or rhel7-init):
$ cat Containerfile
FROM registry.access.redhat.com/ubi7/ubi-init
RUN echo -e "[repo1]\nname=repo1\nbaseurl=http://repos.example.com/RHEL-7/7.9/Server/x8..." >/etc/yum.repos.d/repo1.repo; yum -y install httpd; yum clean all; systemctl enable httpd
EXPOSE 80
CMD [ "/sbin/init" ]
it fails:
$ sudo podman run -ti -p 80:80 d872b16b8d0f9718c60420e3569cb4d5ddd16053fb72903e70d7b62ba3f34964
Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted
[!!!!!!] Failed to mount API filesystems, freezing.
And same with privileged:
$ sudo podman run -ti -p 80:80 --privileged=true d872b16b8d0f9718c60420e3569cb4d5ddd16053fb72903e70d7b62ba3f34964
Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted
[!!!!!!] Failed to mount API filesystems, freezing.
I have these versions:
$ rpm -q fedora-release-common podman
fedora-release-common-33-3.noarch
podman-2.2.1-1.fc33.x86_64
$ sudo podman version
Version: 2.2.1
API Version: 2.1.0
Go Version: go1.15.5
Built: Tue Dec 8 15:37:50 2020
OS/Arch: linux/amd64
Running very similar container on RHEL7 with docker-1.10.3-59.el7.x86_64
(there is 1.13.1 available, but have not tried) works fine.
Please, any idea on what I'm doing wrong?
Thank you in advance and happy new year!
Regards,
Jan
--
Jan Hutar Performance Engineering
jhutar(a)redhat.com Red Hat, Inc.
3 years, 3 months
