Help Wanted: Podman Documentation contributors, suggestions, and more....
by Tom Sweeney
Recently the community discovered that the Podman
Whatis?(https://podman.io/whatis.html) page had badly lagged behind the
reality of Podman. For example, the page talked about the
soon-to-be-released REST API (released a few months ago), and other
upcoming features that were already in play. Additionally, over the
past few months, inquiries have been made over the availability of
several documents: specific "how-to's", a user guide, rootless container
tutorials, networking tutorials, and a few issues have been lodged
against various parts of the existing documentation.
The maintainers of Podman have recognized that the documentation for the
project is not at the level it should be, even though we have made our
best effort to do so. At this point, we are hoping to get help from the
community. The level of help that we would like to get is varied. At
the top of the list would be creating issues
(https://github.com/containers/podman/issues) for any missing or
incorrect documentation. If someone in the community likes going
through man pages and making sure they're formatted consistently, we'd
love their help. If you ever wanted a big documentation project that
you could stamp your name on, then the Podman Users Guide might be a
great way to increase your documentation chops. Any help that you would
be willing to offer to better Podman's documentation would be gratefully
accepted.
Also, if you or someone you know is not terribly technical yet wants to
contribute to an Open Source project, this might be a great opportunity
to get your foot in the door. We'd be more than happy to walk someone
through the git submission processes in exchange for documentation
improvements for the project. Or if they're more comfortable sending in
something via email, we'd be happy to deal with the git side of things.
So if you have documentation improvement ideas or suggestions, please
add a comment to the discussion here
(https://github.com/containers/podman/discussions/10336), or send an
email to the Podman mailing list
(https://lists.podman.io/admin/lists/podman.lists.podman.io/).
Paraphrasing Richard Branson: No idea is too small, and all sorts of
ideas have the potential to change the project as we know it for the better.
We have an absolutely terrific and growing Podman community. Hopefully,
this effort will garner more contributors and create better
documentation for Podman. Thanks for your attention, and feel free to
contact me if you have any questions.
Best Wishes,
Tom Sweeney
tsweeney(a)redhat.com
3 years, 3 months
CIFS share as a volume
by rem＠llgc.org.uk
Hi,
I have a problem mapping a cifs network share to a container.
It's an auto-mount and from the /etc/auto.mnt I can see it's mounted with: -fstype=cifs,rw,noperm,vers=3.0
The mount is attached to the /mnt/share-name
I run image of the container with:
sudo podman run --pod pod-name --detach --name container-name -v /mnt/share-name:/usr/src/app/share:rw,z .........
I get:
Error: failed to set file label on /mnt/share-name: operation not supported
Wonder if anybody could help me and point me to the right direction.
Thanks
3 years, 3 months
OCI permission denied from '--uidmap'
by lejeczek
Hi guys.
If I use 'uidmap' then container in a pod fails to start/run
with:
Error: error stat'ing file
`/var/lib/containers/storage/overlay-containers/18df20ff42cbe9c48807ccd1a529696b93638d81a431161a94d7caeb1f2b6c2b/userdata/shm`:
Permission denied: OCI permission denied
Quite a few "OCI permission" around the net but none
relating to that above I could find.
What might be a solution for the issue?
many thanks, L.
3 years, 3 months
flaky slirp4netns - tweak it?
by lejeczek
Hi guys.
I have a container which "suffers" from quite inacceptable
link quality to host's iface - container apps timeout often
- but that "same" container (in both cases in a pod) when
rootful and on cni works apparently perfectly, certainly
does not see issues rootless sees.
Is it possible, in or outside of podman to tweak bits, maybe
kernel's, in order to troubleshoot it?
many thanks, L.
podman-3.0.1-6.module_el8.5.0+736+58cc1a5a.x86_64
4.18.0-301.1.el8.x86_64
3 years, 3 months
extra tap iface in rootless container - ?
by lejeczek
Hi guys.
Either it was there always and I was blind, though I go
rootless very rarely, or my podman recently started this:
# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state
UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: eth0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
qdisc noqueue state UP group default
link/ether d2:d4:62:b4:d7:61 brd ff:ff:ff:ff:ff:ff
link-netnsid 0
inet 10.88.2.3/24 brd 10.88.2.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::d0d4:62ff:feb4:d761/64 scope link
valid_lft forever preferred_lft forever
4: tap0: <BROADCAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel
state UNKNOWN group default qlen 1000
link/ether 6e:f7:55:d0:42:91 brd ff:ff:ff:ff:ff:ff
inet 10.0.2.100/24 brd 10.0.2.255 scope global tap0
valid_lft forever preferred_lft forever
inet6 fe80::6cf7:55ff:fed0:4291/64 scope link
valid_lft forever preferred_lft forever
You can see 'eth0@if5' came from cni network but what that
'tun0' is doing there?
Every rootless container on my box gets it.
many thanks, L.
3 years, 3 months
post-mortem: podman v3.2.0-rc1 in fedora stable updates
by Lokesh Mandvekar
Hi list,
First off, my apologies to all users for shipping a bad podman update in the
yum repos.
What Happened
-------------
Few days ago, podman v3.2.0-rc1 mistakenly got pushed to the stable updates
repositories on Fedora 33 and 34.
Why It Happened
---------------
The packaging automation for container tools regularly tries to push any
bodhi updates in testing state to stable.
While I had already disabled autokarma for any bodhi update containing an RC build, I
forgot to disallow `request push to stable` for any bodhi containing an RC build via
the automation. Also, there were no gating test failures for said bodhi updates so the stable
pushes completed without complaints.
Current Resolution
------------------
Since a stable podman v3.2.0 is still quite a few days away,
I have reverted podman rpm to v3.1.2 with an Epoch bump 2 -> 3. Bodhi updates for
those can be found here:
Fedora 33: https://bodhi.fedoraproject.org/updates/FEDORA-2021-0ce79fff2a
Fedora 34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-51708c90bc
Future Steps
------------
I have added a check in the packaging automation to block any RC builds from
being pushed to stable, so this issue should never occur again.
If anybody is interested, the automation script can be found here:
https://gitlab.com/rhcontainerbot/pkg-builder/-/tree/fedora
Next month, I plan to work on moving the packaging automation into Podman upstream with
Packit integration (https://packit.dev/) which should provide further improvements in quality
control.
Thanks and apologies once again.
--
Lokesh
IRC, GitHub: lsm5
GPG: 0xC7C3A0DD
https://keybase.io/lsm5
3 years, 3 months
Delta 8 Products
by Roxanna Granger
One of the best Delta cordless drills is the Proactor model. The proactor model features a one-year warranty and is constructed of high quality materials. This Delta product definitely lives up to its name. It has received many favorable comments from both Delta customers and those who have purchased other brands of Delta power tools.
The Delta brand is well known for reliability, durability and being able to take on tough jobs with ease. While you are searching for the best Delta cordless drill, you will find they are available in several different sizes and models. If you are in the market for purchasing one of these power tools, you should definitely consider the Proactor model. You are sure to receive many positive comments and reviews once you start using this popular Delta cordless drill. If you are interested in trying other good delta 8 products, have a look at https://area52.com/products/delta-8-tincture/
3 years, 4 months
no logs from container
by lejeczek
Hi guys
I'm trying a popular image, perhaps very popular(not sure if
with podman consumers though) off which a rootful container
produces no logs.
I've tried podman vers 2.0 & 3.1, with the same results.
Adding debug to:
-> $ podman container restart cni-net.disc --log-level=debug
...
INFO[0000] Running conmon under slice
machine-libpod_pod_6ef5202d6954f3616a530f188954465e27ff4730dfad32b68d9467c26e789d18.slice
and unitName
libpod-conmon-7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97.scope
DEBU[0000] Received: 310116
INFO[0000] Got Conmon PID as 310113
DEBU[0000] Created container
7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97
in OCI runtime
DEBU[0000] Starting container
7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97
with command [/bin/bash]
DEBU[0000] Started container
7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97
7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97
DEBU[0000] Called restart.PersistentPostRunE(podman
container restart cni-net.discourse --log-level=debug)
does not reveal much as you can see.
I can:
-> $ podman exec -it cni-net.disc sh
and shell is availble.
How to troubleshoot issues like this?
many thanks, L.
3 years, 4 months
rootless-cni-infra - when & how?
by lejeczek
Hi guys.
I assume that 'rootless-cni-infra' gets created somewhere
under the hood without user intervention and I wonder how
and when, as I see this:
..
ERRO[0000] error starting some container dependencies
ERRO[0000] "rootless CNI infra image not present - please
build image from
https://github.com/containers/podman/blob/v3.0.1-rhel/contrib/rootless-cn...
and tag as \"rootless-cni-infra\""
Error: error starting some containers: internal libpod error
Would somebody care to shed some light on it?
many thanks, L.
3 years, 4 months
Capabilities and rootless containers
by Vincent QUEMENER
Hi,
I am looking for some guidance on how to securely containerize an
application that depends on the `CAP_SYS_NICE` capability to work.
Outside of the container world, one would probably just set the capability
on the binary so that a non-privileged user could run it :
```
$ my_app
Error!
$ sudo setcap 'cap_sys_nice+ep' my_app
$ my_app
Success!
```
When working with containers, the easiest solution would be to execute
Podman as root with the `--cap-add` parameter :
```
$ sudo podman run --rm --cap-add "sys_nice" -v "$PWD/my_app:/my_app"
fedora:34 /my_app
Success!
```
A somewhat more secure option would consist in switching to a
non-privileged user with the `--user` parameter :
```
$ sudo podman run --rm --cap-add "sys_nice" -v "$PWD/my_app:/my_app"
--user nobody fedora:34 /my_app
Success!
```
Now, in order to mitigate potential container-breakout vulnerabilities, I
would like to go a bit further and set up a rootless container.
I have recently learned about ambient capabilities and I have started
experimenting with the `capsh` command. This seems to work :
```
$ sudo capsh --caps="cap_sys_nice+eip
cap_setpcap,cap_setuid,cap_setgid+ep" --keep=1 --user="${USER}"
--addamb=cap_sys_nice -- -c ./my_app
Success!
```
But this does not (the ambient capability is not set in the container and
`strace` indicates that the `setpriority` system call fails with a
`Permission denied`) :
```
$ sudo capsh --caps="cap_sys_nice+eip
cap_setpcap,cap_setuid,cap_setgid+ep" --keep=1 --user="${USER}"
--addamb=cap_sys_nice -- -c "HOME=${HOME} podman run --rm --cap-add
sys_nice -v $PWD/my_app:/my_app fedora:34 /my_app"
Error!
```
Is this a podman limitation (Could it be improved?)? Is there a better
approach?
Thank you,
Vincent Quéméner.
3 years, 4 months
