- Podman - Podman List Archives

Podman Community Cabal Meeting, Tuesday May 21, 2024, at 11:00 a.m. EDT (UTC-5)
by Tom Sweeney 07 May '24

07 May '24

Hi All! The next Podman Community Cabal meeting is happening in two weeks, on Tuesday, May 21, 2024, at 11:00am EDT (UTC-5). Currently there are no topics, so if you want to discuss something, please add it to the agenda! https://hackmd.io/gQCfskDuRLm7iOsWgH2yrg?both Hope to see you there! t

1 0

Re: podmansh
by Felix Niederwanger 06 May '24

06 May '24

Hey thank you Petr, this works nicely. On a Tumbleweed test system I created my user phoenix and the following podmansh.service file: ``` # /home/phoenix/.config/systemd/user/podmansh.service [Unit] Description=podmansh container After=local-fs.target ExecStartPre=-/bin/mkdir -p %h/data RequiresMountsFor=%t/containers [X-Container] Image=registry.opensuse.org/opensuse/tumbleweed ContainerName=podmansh HostName=arctic-fox RemapUsers=keep-id RunInit=yes User=1000 Volume=%h/data:%h:Z WorkingDir=%h Exec=sleep infinity DropCapability=all NoNewPrivileges=true [Service] ExecStartPre=/usr/bin/mkdir -p %h/data ExecStartPre=-/usr/bin/podman create --name=podmansh --cgroups=split --init --sdnotify=conmon --user 0 -w=%h --userns=keep-id -v %h/data:%h:Z --hostname arctic-fox registry.opensuse.org/opensuse/tumbleweed sleep infinity Environment=PODMAN_SYSTEMD_UNIT=%n KillMode=mixed Delegate=yes Type=notify NotifyAccess=all SyslogIdentifier=%N ExecStart=/usr/bin/podman start podmansh [Install] RequiredBy=default.target ``` Then after changing the login shell to podmansh I get what I wanted to achieve: A persistent container, where my user account has root privileges to install software, but the container runs as user process and has no further privileges. It's still a bit bumpy, and every now and then I get some weird error messages, but it's a good start phoenix@starbuck:~> ssh phoenix@arctic-fox Last login: Mon May 6 19:11:01 UTC 2024 from 2a02:<redacted>:8719 on ssh failed to execvp -podmansh: No such file or directory Connection to arctic-fox.home closed. phoenix@starbuck:~> ssh phoenix@arctic-fox Last login: Mon May 6 19:13:36 UTC 2024 from 2a02:<redacted>:8719 on ssh sh-5.2# exit Connection to arctic-fox.home closed. I brought the discussion also to https://github.com/containers/podman/discussions/19620#discussioncomment-93… so that it can provide a bit more context there as well. Thank you for your help, Best, phoenix :-) On 02/05/24 14:55, Petr Lautrbach wrote: > Lokesh Mandvekar <lmandvek(a)redhat.com> writes: > >> Hello Felix, >> >> podmansh was created with the idea of the admin locking down user shell >> environments, so installing software (to /usr) by the user itself won't >> work. An alternative could be the user installing to a non-standard >> location (I think there are some dnf / package manager tricks for this) in >> a persistent volume that gets mounted. >> >> Maybe toolbx (toolbox) could fit your use case if you want user >> customizable persistent installation. >> >> Copying Dan, Petr and Rishi in case they have further ideas. > > It was discussed in > https://github.com/containers/podman/issues/19497 > https://github.com/containers/podman/discussions/19620 > > AFAIK it's quadlet which generates systemd unit for the container and > which adds "--rm" option to podman [1] so you would need to skip quadlet > and run the container using systemd service. > > e.g. > - use `/usr/lib/systemd/system-generators/podman-system-generator --user --dryrun` > to generate systemd unit configuration and save it to > `~user/.config/systemd/user/podmansh.service` > > - change it so it does not call `podman rm` and does not use `--rm` in > `podman run` > > - use a wrapper which would `run || start` on ExecStart > > Something like the snippet bellow: > > > [Service] > ExecStartPre=/usr/bin/mkdir -p %h/data > Environment=PODMAN_SYSTEMD_UNIT=%n > KillMode=mixed > # ExecStop=/usr/bin/podman rm -v -f -i --cidfile=%t/%N.cid > # ExecStopPost=-/usr/bin/podman rm -v -f -i --cidfile=%t/%N.cid > Delegate=yes > Type=notify > NotifyAccess=all > SyslogIdentifier=%N > # ExecStart=/usr/bin/podman run --name=podmansh --cidfile=%t/%N.cid --replace --rm --cgroups=split --init --sdnotify=conmon -d -w=%h -v %h/data:%h:Z registry.fedoraproject.org/fedora sleep infinity > ExecStart=/usr/bin/bash -c '/usr/bin/podman run --name=podmansh --cidfile=%t/%N.cid --cgroups=split --init --sdnotify=conmon -d -w=%h -v %h/data:%h:Z registry.fedoraproject.org/fedora sleep infinity || /usr/bin/podman start podmansh' > > > Disclaimer: I haven't really tested it, there might be several issues > with this. Persistent containers were not our main goal for `podmansh` > > [1] https://github.com/containers/podman/blob/c9644ebccf14309a77769cba00833cd13… > > > Petr > > >> On Fri, Apr 26, 2024 at 3:20 AM Felix Niederwanger via Podman < >> podman(a)lists.podman.io> wrote: >> >>> Hello, >>> >>> I'm trying to get podmansh to work in such a way, that every user has a >>> persistent container. >>> >>> I've followed the steps of >>> https://docs.podman.io/en/latest/markdown/podmansh.1.html, resulting in a >>> nice setup, where at user login every user get's its own container. >>> Unfortunately the container for the user session is ephemeral, meaning >>> after logging out or system reboot the container is destroyed. >>> >>> I would like to have a setup, where quadlet setups a base container, but >>> then every user can install their own software and environment, which lasts. >>> >>> Here is the quadlet file I'm currently using: >>> >>> ``` >>> # /etc/containers/systemd/users/podmansh.container >>> [Unit] >>> Description=podmansh container >>> After=local-fs.target >>> ExecStartPre=-/bin/mkdir -p %h/data >>> >>> [Container] >>> Image=registry.fedoraproject.org/fedora >>> ContainerName=podmansh >>> HostName=arctic-fox >>> RemapUsers=keep-id >>> RunInit=yes >>> User=0 >>> >>> Volume=%h/data:%h:Z >>> WorkingDir=%h >>> >>> Exec=sleep infinity >>> >>> [Service] >>> ExecStartPre=/usr/bin/mkdir -p %h/data >>> >>> [Install] >>> RequiredBy=default.target >>> ``` >>> >>> Anyone an idea how to achieve persistent podmansh containers? >>> >>> Greetings, >>> phoenix >>> _______________________________________________ >>> Podman mailing list -- podman(a)lists.podman.io >>> To unsubscribe send an email to podman-leave(a)lists.podman.io >>> >> >> >> -- >> Lokesh >> Libera, GitLab, GitHub, Fedora: lsm5 >> Matrix: @lsm5:matrix.org >> GPG: 9E33DD8704CC03E2DEB84D9A1C1EDD7CC7C3A0DD >> https://keybase.io/lsm5 > -- phoenix(a)feldspaten.org, gpg: 0x6E77A590E3F6D71C Consider using plain text | email is not SMS https://email.is-not-s.ms/

1 0

Two new container images available
by Chris Evich 30 Apr '24

30 Apr '24

Two new automated container image builds are now available: * For Podman, Buildah, and Skopeo: "immutable" tags are being added to all "stable" images. These tags will never be overwritten, though they may be removed if a major security/safety issue is detected. In contrast to the other stable tags, which are overwritten daily, these images assume you desire to manage any update vs stability risk. The new tags apply to all combinations of the semantic tool version, so vX-immutable, vX.Y-immutable, and vX.Y.Z-immutable will be available. * quay.io/containers/aio:latest and quay.io/containers/aio:<date stamp> images contain all three tools (Podman, Buildah, and Skopeo). The images are built weekly using a fedora-minimal base to keep the size as small as possible. These are intended as a base-image for development and/or CI/CD use. The <date stamp> is formatted to be used as a semantic version. Old tags expire and will be removed after 1-year. Please direct any issues, discussions, or RFEs toward the https://github.com/containers/image_build repo.

1 0

podmansh
by Felix Niederwanger 26 Apr '24

26 Apr '24

Hello, I'm trying to get podmansh to work in such a way, that every user has a persistent container. I've followed the steps of https://docs.podman.io/en/latest/markdown/podmansh.1.html, resulting in a nice setup, where at user login every user get's its own container. Unfortunately the container for the user session is ephemeral, meaning after logging out or system reboot the container is destroyed. I would like to have a setup, where quadlet setups a base container, but then every user can install their own software and environment, which lasts. Here is the quadlet file I'm currently using: ``` # /etc/containers/systemd/users/podmansh.container [Unit] Description=podmansh container After=local-fs.target ExecStartPre=-/bin/mkdir -p %h/data [Container] Image=registry.fedoraproject.org/fedora ContainerName=podmansh HostName=arctic-fox RemapUsers=keep-id RunInit=yes User=0 Volume=%h/data:%h:Z WorkingDir=%h Exec=sleep infinity [Service] ExecStartPre=/usr/bin/mkdir -p %h/data [Install] RequiredBy=default.target ``` Anyone an idea how to achieve persistent podmansh containers? Greetings, phoenix

1 0

Re: Podlet Migration Questions
by Paul Nettleton 25 Apr '24

25 Apr '24

Thanks! If publishing the podlet container to quay.io/containers is a no-go, another option is to publish it to the GitHub Packages Container registry, so it would be available at ghcr.io/containers/podlet. Ok so I'll move the current contribution docs (building and CI stuff) from the README.md to CONTRIBUTING.md and add information about DCO sign-off. -- Paul Nettleton k9(a)k9withabone.dev On Thursday, April 25, 2024 09:23 CDT, Brent Baude <bbaude(a)redhat.com> wrote: Paul, I'm happy to help you with the GH things. Your asks seem reasonable to me. I'll talk with the team about the quay.io/containers stuff but I don't believe we have given folks access to that before; so there is no precedent. Of the core containers repositories, we do require DCO signoff and will generally fail the PR if it is not included. If you are indifferent about it, my preference would be to require it. On Thu, Apr 25, 2024 at 9:20 AM Paul Nettleton via Podman <podman(a)lists.podman.io> wrote:Hello everyone! I'm not sure if this is the best place to ask, but I have a few questions regarding finalizing the migration of podlet to the containers org. I would like to create a "podlet-maintainers" team so that I can add it as an owner of podlet on crates.io. This would allow anyone on the team to publish new versions, improving the bus factor. Is it ok for me to do this? I asked about it on the migration issue, but didn't receive a reply. I was thinking that it would make sense to move the podlet container image from quay.io/k9withabone/podlet to the quay.io/containers org. What would be the process for getting that started? It seems that I have lost some privileges in the transfer of the podlet repo as I can no longer access the repository settings, including setting secrets for use in CI. I will probably need to be able to update those if quay.io/containers/podlet is created. Would it be possible to give me the "maintain" role for the podlet repo? I noticed on my PR for switching compose libraries that a check for commit sign off was added. Is this a requirement for all repositories in the containers org? I don't mind having to sign off commits, but a CONTRIBUTING.md file should be added to the podlet repo explaining this if it is required. Thanks for your time, Paul / k9withabone -- Paul Nettleton k9(a)k9withabone.dev _______________________________________________ Podman mailing list -- podman(a)lists.podman.io To unsubscribe send an email to podman-leave(a)lists.podman.io

1 0

Podlet Migration Questions
by Paul Nettleton 25 Apr '24

25 Apr '24

Hello everyone! I'm not sure if this is the best place to ask, but I have a few questions regarding finalizing the migration of podlet to the containers org. I would like to create a "podlet-maintainers" team so that I can add it as an owner of podlet on crates.io. This would allow anyone on the team to publish new versions, improving the bus factor. Is it ok for me to do this? I asked about it on the migration issue, but didn't receive a reply. I was thinking that it would make sense to move the podlet container image from quay.io/k9withabone/podlet to the quay.io/containers org. What would be the process for getting that started? It seems that I have lost some privileges in the transfer of the podlet repo as I can no longer access the repository settings, including setting secrets for use in CI. I will probably need to be able to update those if quay.io/containers/podlet is created. Would it be possible to give me the "maintain" role for the podlet repo? I noticed on my PR for switching compose libraries that a check for commit sign off was added. Is this a requirement for all repositories in the containers org? I don't mind having to sign off commits, but a CONTRIBUTING.md file should be added to the podlet repo explaining this if it is required. Thanks for your time, Paul / k9withabone -- Paul Nettleton k9(a)k9withabone.dev

2 1

Podman v5.0.2 Released
by Matt Heon 17 Apr '24

17 Apr '24

Hi all, We've just released Podman v5.0.2. This is a bugfix release focusing on networking fixes. You can see exact details in the release notes [1]. Artifacts are being built now and will be available in the next few hours. Thanks, Matt Heon [1] https://github.com/containers/podman/releases/tag/v5.0.2

1 0

Podman Community Cabal Meeting, Tues, April 16, 2024 11:00 am EDT (UTC-5)
by Tom Sweeney 12 Apr '24

12 Apr '24

Hey All! The next Podman Community Cabal meeting is this Tuesday, April 16, 2024, at 11:00 am EDT (UTC-5). At the moment we only have a topic about backup appliances and would love to have another topic or two! Agenda with video link: https://hackmd.io/gQCfskDuRLm7iOsWgH2yrg?both If you have another topic that you'd like to talk about, please let me know and/or add it to the agenda. Hope to see you there! t

1 0

Podman EOL /EOS
by Cody Currens 10 Apr '24

10 Apr '24

Hello All, I was wondering if you could help me find any documentation showing which versions of Podman are no longer supported or considered End of life or support. I checked the github blogs and some mentioned only the current version is however I’d like to be sure before forcing an upgrade. Thanks. Best Regards, Cody C

2 3

Podman v5.0.1 Released!
by Matt Heon 01 Apr '24

01 Apr '24

Hi all, Podman v5.0.1 has just been released. This release addresses a few important issues we've been seeing with Podman v5, including important bugs with building using the remote client and using Pasta with localhost DNS servers. You can read more at the release notes here: https://github.com/containers/podman/releases/tag/v5.0.1 Thanks, Matt Heon

2 2