- Podman - Podman List Archives

Podman Community Cabal Meeting Thu 9/21/2023 11:00 a.m. EDT (UTC-4)
by Tom Sweeney 08 Sep '23

08 Sep '23

Hi All, The next Podman Community Cabal meeting is in just under two weeks. We'll meet on Thu Sept 21, 2023, at 11:00am EDT (UTC-4). We currently have a few topics on Podman v4.7 but we would love to get more. If you have a topic, please add it to the agenda! https://hackmd.io/gQCfskDuRLm7iOsWgH2yrg?both Hope to see you there! t

1 0

Why do use podman machine on Mac?
by Mehdi Haghgoo 07 Sep '23

07 Sep '23

The container experience with podman machine on Windows and mac is not optimal because the containers are slow. Mac is a Linux-based OS. So, why can't we create native containers on it as we do on Linux? That applies to WSL. It's kind of Linux. Why cannot we create native Linux containers on it without resorting to Podman machine and podman clients?

4 3

Re: Why do use podman machine on Mac?
by Jason Greene 07 Sep '23

07 Sep '23

That’s right Darren. The short answer is “containers are Linux”. The longer answer is you need two key elements: a Kernel name-spacing facility, and second a user-land ecosystem. On the former MacOS doesn’t have something comparable. The closest is App Sandbox, but that is primarily a syscall/ permission filtering mechanism (something also important for containers, but only part of the problem). On the latter, this is what we know of as containers, the user-land is the OS without the kernel, and as such is very much tied to the kernel implementation. Darwin libraries and apps use a different ABI and syscall interface than Linux, so basically every container you use today would be incompatible even if there was kernel support. This is the situation with Windows containers (not to be confused with using Podman on Windows or other container envs that run Linux containers). Windows containers have kernel support and a win32 user-land, so to produce them you have to port everything in the image to be native windows code. They are useful but not anywhere near as predominant, since a big part of the value is the portability a Linux container brings. In contrast, WSL2 does run a Linux kernel in a shared VM, and internally it is using Linux namespaces itself, with all distributions of a user sharing the same Kernel. They ultimately abandoned the previous syscall emulation approach since the NT kernel and Linux are just too different and the behaviors don’t map cleanly. We leverage WSL2 for the Podman on Windows implementation. On Sep 7, 2023, at 11:51 AM, Darren Dupre <darren.dupre(a)gmail.com> wrote: OS X has a Mach kernel and a BSD user land. Don’t think Apple is interested in adding containers framework to that. I guess someone could write a kernel extension but it’s a niche use case. WSL 2 uses a real Linux kernel doesn’t it? But it’s still a VM inside of Hyper V so I don’t think the performance is any different. WSL 1 is a posix emulation with binary compatibility but no container support under the hood. Correct me if I'm wrong about that. - Darren On Thu, Sep 7, 2023 at 11:19 Mehdi Haghgoo via Podman < podman(a)lists.podman.io> wrote: > The container experience with podman machine on Windows and mac is not > optimal because the containers are slow. > Mac is a Linux-based OS. So, why can't we create native containers on it > as we do on Linux? > > That applies to WSL. It's kind of Linux. Why cannot we create native Linux > containers on it without resorting to Podman machine and podman clients? > > > _______________________________________________ > Podman mailing list -- podman(a)lists.podman.io > To unsubscribe send an email to podman-leave(a)lists.podman.io > _______________________________________________ Podman mailing list -- podman(a)lists.podman.io To unsubscribe send an email to podman-leave(a)lists.podman.io

1 0

Fwd: Re: What to use instead of RemapUsers/RemapUid/RemapGid in Quadlet now?
by jklaiho＠iki.fi 06 Sep '23

06 Sep '23

Hi, (Apologies, my last e-mail I think I accidentally sent to Erik, not the list; missing bits quoted below) OK, I did not realize that the Remap* commands used --userns behind the scenes, I thought they used --uidmap and --gidmap. That brings me back to my original need, which I'll reiterate: "When using a regular host user to run a rootless container, map the container user as the host user." That's really basic, right? Surely works without PodmanArgs already. My only addition to that is: "If the container user is root (or sudoed to root), allow it to drop privileges so it can install apt packages." Still sounds really basic, and where I work, it's really common. If there's problems, we exec into a deployed container and install some troubleshooting tools with apt that the minimalistic image doesn't contain by default. Based on previous discussions, the apt privilege drop needs one extra subordinate UID/GID to be available. While I'm currently using the Remap* options to achieve these, I'm not married to them – they're just the first thing that I got to work. I've used PodmanArgs before, but in each case only as a stopgap measure while waiting for an option to appear in Quadlet. So, hopefully my final question in this thread: is this "map user and allow dropping privileges" scenario doable with the Quadlet UserNS option, or do I need to open an issue? - JK > Begin forwarded message: > > From: Erik Sjölund <erik.sjolund(a)gmail.com (mailto:erik.sjolund@gmail.com)> > Date: Tuesday, Sep 05, 2023 at 10:37 AM > To: Me <jklaiho(a)iki.fi (mailto:jklaiho@iki.fi)> > Subject: [Podman] Re: What to use instead of RemapUsers/RemapUid/RemapGid in Quadlet now? > > Hi, > > > Yeah, I'm fairly sure that would work, but am I to understand from your reply > > that it is not possible to achieve with the UserNS quadlet option the things that the Remap* quadlet options did? > Correct. It's not possible. > > If we just look at the use of --uidmap there is an enormous amount of > possibilities of how to map those. > Each container UID can be mapped to an arbitrary "intermediate UID" > but the mappings must be unique. By that I mean that different > container UIDs must not be mapped to the same intermediate UID. Also > different intermediate UIDs must not be mapped to the same container > UID. The number of possible ways of providing --uidmap corresponds to > a factorial in mathematics. > > See how n! grows with n: > https://en.wikipedia.org/wiki/Factorial > > The argument --userns=keep-id does not carry so much information. For instance > --userns=keep-id:uid=$uid,gid=$gid > can only be provided one time and has two numbers. > > Another option to consider is > --userns=auto > but that option is quite different from --uidmap. > It provides different functionality. > The situation is a bit similar to static IP addresses vs dynamic IP > addresses in DHCP. > > I see there is some discussion in > https://github.com/containers/podman/issues/17984 > and > https://github.com/containers/podman/pull/17961 > > Erik > > > > > On Mon, Sep 4, 2023 at 9:46 PM jklaiho(a)iki.fi <jklaiho(a)iki.fi> wrote: > > > > Hi Erik, > > > > Yeah, I'm fairly sure that would work, but am I to understand from your reply that it is not possible to achieve with the UserNS quadlet option the things that the Remap* quadlet options did? > > > > If so, why on earth did the Remap* options go away if a) they're still fully supported 'podman run' command-line options, and b) they serve a legit use case that UserNS doesn't fill? > > > > > > - JK > > > > > > > > > > On Monday, Sep 04, 2023 at 10:36 PM, Erik Sjölund <erik.sjolund(a)gmail.com> wrote: > > I think the directive "PodmanArgs" can be used to set podman arguments > > that don't have any > > container option counterpart. > > See man page: > > https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html > > > > Maybe something like this could work? > > PodmanArgs=--uidmap 0:0:1 --uidmap 100:1:1 --gidmap 0:0:1 --gidmap 65534:1:1 > > (untested) > > > > Erik

2 1

HELP! recover files from a deleted container
by Alvin Thompson 04 Sep '23

04 Sep '23

Help! Is there any way to recover files from a deleted container? Long story short, I found the behavior of `podman network rm -f` unexpected, and it wound up deleting most of my containers. One in particular had a month of work in it (I was using it as a development environment), and it turns out only part of it was backed up. I’m desperate! This is Podman for Windows, so most of the files on the “host” are in the WSL environment. I can get into that no problem with `wsl -d podman-machine-default`. As an added wrinkle, my default connection was `podman-machine-default-root`, but I was was not running Podman rootful. I’m not sure this is particularly relevant. grep-ing for strings which are unique to the development environment shows one hit in Windows, in %HOME%/.local/containers/podman/machine/wsl/wsldist/podman-machine-default/ext4.vhdx - which I assume is the file system for the WSL layer itself. I made a copy of it. A grep within WSL itself doesn’t show so any hits, so it’s possible the files were deleted as far as WSL is concerned. I tried searching for an EXT4 undelete tool, but the only one I found (extundelete) is from 10+ years ago and doesn’t appear to work anymore. I haven’t stopped WSL (I’m using /tmp as a staging area) or restarted the computer. I’m at wit’s end. I really don’t know where to begin or look to recover these files, which I really, really need. Any recovery suggestions (no matter how tedious) would be welcome. I know it’s too late to change now, but man, the behavior of `podman network remove` is unexpected. Thanks, Alvin

5 8

What to use instead of RemapUsers/RemapUid/RemapGid in Quadlet now?
by jklaiho＠iki.fi 04 Sep '23

04 Sep '23

I'm running a bunch of rootless Podman containers. I noticed that the RemapUsers, RemapUid and RemapGid options (and possibly others that I haven't used) disappeared from the documentation of podman-systemd.unit in 4.5.0. I barely and partially understood what the options did in the 4.4.0 days when we started using them, but got them working through trial and error. Here's what we have across the board right now in our Quadlet generators. They still work in 4.5.0, but I'm assuming they'll go away eventually: RemapUsers=manual RemapUid=0:0:1 RemapUid=100:1:1 RemapGid=0:0:1 RemapGid=65534:1:1 With the 0:0:1 options, the root user/group inside the containers are mapped to the regular (non-root) host user/group. We need this, since the container bind mounts volumes from the host and must appear to the host as the regular user while doing so. The 100:1:1 and 65534:1:1 options have to do with the special _apt user in Debian-based containers; apt drops privileges to that user in some circumstances. I couldn't tell you why remapping those are needed, but not having them caused problems when installing packages inside the containers. What Quadlet options in Podman >=4.5.0 would be equivalent to the above legacy options?

3 5

podmansh demo on YouTube
by Tom Sweeney 01 Sep '23

01 Sep '23

Hi All, If you want a little more info on the new podmansh login utility that is part of Podman v4.6, Lokesh Mandvekar has put an excellent short video together that is now up on our YouTube Channel. Give it a look, and if you like it, a like! t https://www.youtube.com/watch?v=9I887DKB6x8&t=8s

1 0

After reboot, Container not responding to connection requests
by Jacques Jessen 01 Sep '23

01 Sep '23

Running Podman as root and created a container for Symantec's HSM Agent. When manually started, it reports as working: [root@PoC ~]# podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES b53be5503ca7 localhost/symantec_hsm_agent:2.1_269362 catalina.sh run 4 minutes ago Up 4 minutes 0.0.0.0:8080->8080/tcp, 0.0.0.0:8082->8082/tcp, 0.0.0.0:8443->8443/tcp symhsm_agent [root@PoC ~]# podman stats ID NAME CPU % MEM USAGE / LIMIT MEM % NET IO BLOCK IO PIDS CPU TIME AVG CPU % b53be5503ca7 symhsm_agent 3.55% 216MB / 4.112GB 5.25% 1.93kB / 1.09kB 249.2MB / 0B 29 3.759969275s 3.55% You can successfully access the 8080, 8082, 8443 ports with a browser. However, if the server is rebooted, while Podman will show results as above that it is working, from a browser you will be told: ERR_CONNECTION_TIMED_OUT If you manually Stop and Start the container, you can successfully access the 8080, 8082, 8443 ports with a browser. Given there's no change in the configuration, this feels like there's a timing issue with the initial start. I used the Podman provided response to create the Service file: [root@PoC ~]# podman generate systemd --new --name symhsm_agent # container-symhsm_agent.service # autogenerated by Podman [Unit] Description=Podman container-symhsm_agent.service Documentation=man:podman-generate-systemd(1) Wants=network-online.target After=network-online.target RequiresMountsFor=%t/containers [Service] Environment=PODMAN_SYSTEMD_UNIT=%n Restart=on-failure TimeoutStopSec=70 ExecStart=/usr/bin/podman run \ --cidfile=%t/%n.ctr-id \ --cgroups=no-conmon \ --rm \ --sdnotify=conmon \ --replace \ -d \ --name symhsm_agent \ -p 8443:8443 \ -p 8082:8082 \ -p 8080:8080 \ -v /opt/podman/:/usr/local/luna symantec_hsm_agent:2.1_269362 ExecStop=/usr/bin/podman stop \ --ignore -t 10 \ --cidfile=%t/%n.ctr-id ExecStopPost=/usr/bin/podman rm \ -f \ --ignore -t 10 \ --cidfile=%t/%n.ctr-id Type=notify NotifyAccess=all [Install] WantedBy=default.target Having to manually login and restart the container kind of defeats the purpose. Thoughts and feedback appreciated.

2 1

quay.io podman/buildah/skopeo image safety
by Chris Evich 29 Aug '23

29 Aug '23

All, On August 23rd it was discovered that the credentials for several robot service accounts with write-access to the container-images could have leaked. Upon discovery, the credentials were invalidated. The earliest possible leak opportunity was around March 10th, 2022. While the investigation is ongoing, initial inspection of the images seem to indicate it is unlikely any credentials had actually been discovered and/or used to manipulate images. Nevertheless, out of an abundance of caution, all possibly-affected images will be disabled. quay.io/containers/podman : tags v3 - v4 quay.io/containers/buildah : tags v1.23.1 - v1.31.0 quay.io/containers/skopeo : tags v1.5.2 - v1.13.1 quay.io/podman/stable : tags v1.6 - v4.6.0 quay.io/podman/hello:latest SHA256 afda668e706a (<= Aug 2, 2023) quay.io/buildah/stable : tags v1.23.3 - 1.31.0 quay.io/skopeo/stable : tags v1.3.0 - 1.13.1 We realize this issue has the potential to impact not only direct, but also indirect use, such as base-images. The safety and integrity of these images has and must take priority. At this time, all images have been disabled. We will restore originals and/or rebuild fresh copies based on further safety analysis. We expect analysis to be complete and/or known-safe images restored, before Sept. 8th. Though please keep in mind the research is ongoing, and the situation remains somewhat fluid. When the examination work is complete, or if any manipulation is discovered, we will issue further updates. Thank you in advance for your patients and understanding.

1 0

Podman v4.6.2 Released!
by Ashley Cui 28 Aug '23

28 Aug '23

Hi all, Podman v4.6.2 <https://github.com/containers/podman/releases/tag/v4.6.2> has been released! This is a small but mighty bugfix release, which includes a key performance improvement fix. Release Notes: - Fixed a performance issue when calculating diff sizes in overlay. The podman system df command should see a significant performance improvement. ( #19467 <ttps://github.com/containers/podman/issues/19467>) - Fixed a bug where containers in a pod would use the pod restart policy over the set container restart policy. (#19671 <https://github.com/containers/podman/issues/19671>) - Fixed a bug in the Compat Build endpoint where the pull query parameter did not parse 0/1 as a boolean. (#17778 <https://github.com/containers/podman/issues/17778>) - Updated the containers/storage library to v1.48.1 Thanks for checking it out!

1 0