[Podman] Re: Deprecation announcement for CNI plugins
by Doug Rabson
Right now, the CNI plugins are the only option for networking on FreeBSD.
The new stack seems very exciting though and FreeBSD has recently added
netlink support so porting it seems quite possible (and is probably a good
excuse to learn a bit of rust).
On Tue, 10 Jan 2023 at 13:31, Brent Baude <bbaude(a)redhat.com> wrote:
> Folks,
>
> I wrote a short blog about Podman adding a deprecation announcement for
> CNI plugins. With the success of the new network stack, not only do we
> eventually want the new stack to be the default but also the only option.
> For more information, check out the blog post itself:
>
> https://blog.podman.io/2023/01/podman-begins-cni-plugins-deprecation/
> _______________________________________________
> Podman mailing list -- podman(a)lists.podman.io
> To unsubscribe send an email to podman-leave(a)lists.podman.io
>
3 years, 2 months
[Podman] Re: Installation & First Pull
by jimsaxton1＠comcast.net
Hey Chris,
So, redhat / quay mention the redis site the repo is on is being eliminated / removed. Soon as I get a sec, will try a different repo and reply.
Thanks for the information.
Jim
-----Original Message-----
From: Chris Evich <cevich(a)redhat.com>
Sent: Tuesday, August 1, 2023 4:00 PM
To: podman(a)lists.podman.io
Subject: [Podman] Re: Installation & First Pull
On 8/1/23 13:28, jimsaxton1(a)comcast.net wrote:
> Adding this debug info... PS C:\Users\<xxUSERxx>> podman login quay.io
> Authenticating with existing credentials for quay.io Existing
> credentials are valid. Already logged in to quay.io
I'm pretty sure you wouldn't get that 'credentials are valid' success message if the networking was broken. IIRC it's just http basic auth being used.
> time="2023-08-01T13:20:12-04:00" level=debug msg="DoRequest Method: POST URI: http://d/v4.4.4/libpod/images/pull"
> Trying to pull quay.io/quay/busybox:latest...
> Error: initializing source docker://quay.io/quay/busybox:latest:
> pinging container registry quay.io: Get https://quay.io/v2/: proxyconnect tcp: dial tcp 10.164.200.30:8080: i/o timeout time="2023-08-01T13:24:15-04:00" level=debug msg="Shutting down engines"
This is very odd, since the login worked. You original mail mentioned "I've added the proxies and...". The behavior strikes me as something that could come from a bad/broken http proxy setup, by chance are you using one?
If you ssh into the machine, are you able to use curl or wget to fetch anything over http? For example http://www.quay.io ?
Note: I get a redirect page when doing this, "301 Moved Permanently".
This is expected.
_______________________________________________
Podman mailing list -- podman(a)lists.podman.io To unsubscribe send an email to podman-leave(a)lists.podman.io
2 years, 7 months
[Podman] Re: What to use instead of RemapUsers/RemapUid/RemapGid in Quadlet now?
by Valentin Rothberg
On Mon, Sep 4, 2023 at 12:54 PM jklaiho(a)iki.fi <jklaiho(a)iki.fi> wrote:
> Hi,
>
> Thanks for the commit ref for context, Valentin.
>
> Nonetheless, I would really appreciate help with how to express these old
> style mappings with the new UserNS option in Quadlet:
>
> RemapUsers=manual
> RemapUid=0:0:1
> RemapUid=100:1:1
> RemapGid=0:0:1
> RemapGid=65534:1:1
>
> Like I said, I arrived to these with trial and error, not properly
> understanding what I'm doing, and would rather not try to convert from one
> poorly understood syntax to another.
>
The syntax is `container ID: host ID: range`. So `100:1:1` means that
container UID 100 is mapped to host UID 1 for the range of length 1.
`100:1:10` would mean that 10 UIDs starting at 100 inside the container are
mapped to 10 outside the container at UID 1.
That being said, are you sure what you specified above is correct? In case
you are not sure, can you elaborate why you want to achieve? I am hesitant
to give an answer as the ranges look strange to me.
> - JK
>
>
> On Monday, Sep 04, 2023 at 10:05 AM, Valentin Rothberg <
> vrothberg(a)redhat.com> wrote:
> Thanks for reaching out!
>
> The following commit has removed the fields from the documentation:
> https://github.com/containers/podman/commit/f6a50311c56d
>
> The fields have been deprecated in favor of the new `UserNS` field which
> is more symmetric to the CLI. The old fields are still functional but we
> decided to drop them from the docs to not encourage use.
>
> Kind regards,
> Valentin
>
>
2 years, 6 months
[Podman] Re: How does podman "initialize" after a reboot?
by Ashley Cui
If you would like podman-machine to start at boot, then using
podman-desktop would be the route to go.
On Thu, Aug 3, 2023 at 7:51 AM Daniel Walsh <dwalsh(a)redhat.com> wrote:
> On 8/3/23 04:43, Александр Илюшкин wrote:
> > I also noticed that podman-machine does not start after reboot, I have
> > to start it manually.
> > There is also a bug fixed in 4.6 version.
> >
> > https://github.com/containers/podman/pull/18328
> > https://github.com/containers/podman/issues/16945
> >
> > Check status of podman machine after reboot using this command
> >
> > podman machine list
> >
> > чт, 3 авг. 2023 г. в 08:57, Pratham Patel <thefirst1322(a)gmail.com>:
> >> **Any** discussions--including me being an idot and not understanding
> >> things--are welcome. Please comment/reply so I can understand what is
> >> happening! :)
> >>
> >>
> >> - Pratham Patel
> >> _______________________________________________
> >> Podman mailing list -- podman(a)lists.podman.io
> >> To unsubscribe send an email to podman-leave(a)lists.podman.io
> >
> >
> Podman runs as a service under systemd, so systemd starts podman. If
> you question is how does Podman start containers that are autostarted at
> boot, then podman has a a podman-restart.service which systemd
> automatcially starts, and this service looks at the podman database and
> starts any autostart services.
>
>
> /usr/lib/systemd/system/podman-restart.service
> /usr/lib/systemd/user/podman-restart.service
>
> If you are asking about podman-machine, then someone else will need to
> answer that question.
> _______________________________________________
> Podman mailing list -- podman(a)lists.podman.io
> To unsubscribe send an email to podman-leave(a)lists.podman.io
>
2 years, 7 months
[Podman] Re: Fwd: Re: What to use instead of RemapUsers/RemapUid/RemapGid in Quadlet now?
by Valentin Rothberg
On Wed, Sep 6, 2023 at 7:47 AM jklaiho(a)iki.fi <jklaiho(a)iki.fi> wrote:
> 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.
>
That sounds like `UserNS=keep-id`:
~ $ id -u && podman run --rm --userns=keep-id busybox id -u
1000
1000
> 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.
>
Yes, you can still do a `podman exec --user=0 $CONTAINER apt-get install
...`.
> 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?
>
I think `UserNS=keep-id` is what you are looking for. If something is
missing that forces you to use `PodmanArgs`, feel free to open an issue and
we can add it.
Kind regards,
Valentin
>
>
>
>
> Begin forwarded message:
>
> From: Erik Sjölund <erik.sjolund(a)gmail.com>
> Date: Tuesday, Sep 05, 2023 at 10:37 AM
> To: Me <jklaiho(a)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
>
> _______________________________________________
> Podman mailing list -- podman(a)lists.podman.io
> To unsubscribe send an email to podman-leave(a)lists.podman.io
>
2 years, 6 months
[Podman] Re: Deprecation announcement for CNI plugins
by Anders F Björklund
The only objection was that we didn't want to have two network stacks for
minikube, since we were already using CNI for kubernetes (with CRI-O)
Also didn't want to add a Rust toolchain. But for now using Podman 3.4 will
work for a while yet, and I guess it is inevitable considering conmon-rs....
For our limited use case of "podman build", --network=host also works ?
At least they don't have to fight over /etc/cni/net.d directory, anymore
:-)
/Anders
Den tis 10 jan. 2023 kl 14:30 skrev Brent Baude <bbaude(a)redhat.com>:
> Folks,
>
> I wrote a short blog about Podman adding a deprecation announcement for
> CNI plugins. With the success of the new network stack, not only do we
> eventually want the new stack to be the default but also the only option.
> For more information, check out the blog post itself:
>
> https://blog.podman.io/2023/01/podman-begins-cni-plugins-deprecation/
>
>
3 years, 2 months
[Podman] Re: podman image for ngninx
by Matthias Apitz
Robin,
Sorry for the delay in replying, but I was out for vacation in Havana,
Cuba. Now I'm back to business.
El día Wednesday, December 06, 2023 a las 08:41:28AM -0800, Robin Lee Powell escribió:
> That's pretty weird. Just to double check,
> 'curl http://deb.debian.org/debian/dists/buster/InRelease" works on
> the machine you're running podman from, yeah?
Yeah, your command would not work, because it starts with a single quote
and ends with a double quote :-)
But, you point in the right direction: this hosts sits behind a firewall
and it seems that outbound port 80 and 443 are blocked. I wasn't aware of
this.
Thanks for your hint
matthias
> On Mon, Dec 04, 2023 at 01:31:33PM +0100, Matthias Apitz wrote:
> >
> > Hello,
> >
> > I'm trying to build a podman image as described here:
> >
> > https://docs.podman.io/en/latest/Introduction.html
> >
> > with the command:
> >
> > podman build -t nginx https://git.io/Jf8ol
> >
> > on SuSE LINUX SLES 15 SP5. This fails with the attached nohup log. It
> > fails mostly due to this:
> > ...
> > Adding system user `nginx' (UID 101) ...
> > Adding new user `nginx' (UID 101) with group `nginx' ...
> > Not creating home directory `/nonexistent'.
> > + apt-get update
> > Err:1 http://deb.debian.org/debian buster InRelease
> > Connection failed [IP: 146.75.118.132 80]
> > Err:2 http://deb.debian.org/debian-security buster/updates InRelease
> > Connection failed [IP: 146.75.118.132 80]
> > Err:3 http://deb.debian.org/debian buster-updates InRelease
> > Connection failed [IP: 146.75.118.132 80]
> > Reading package lists...
> > W: Failed to fetch http://deb.debian.org/debian/dists/buster/InRelease Connection failed [IP: 146.75.118.132 80]
> > ...
> >
> > What can I do?
> >
> > Thanks
> >
> > matthias
> >
> > --
> > Matthias Apitz, ✉ guru(a)unixarea.de, http://www.unixarea.de/ +49-176-38902045
> > Public GnuPG key: http://www.unixarea.de/key.pub
--
Matthias Apitz, ✉ guru(a)unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
I am not at war with Russia. Я не воюю с Россией.
Ich bin nicht im Krieg mit Russland.
2 years, 2 months
[Podman] Re: Deprecation announcement for CNI plugins
by Daniel Walsh
On 1/10/23 08:44, Anders F Björklund wrote:
> The only objection was that we didn't want to have two network stacks
> for minikube, since we were already using CNI for kubernetes (with CRI-O)
>
> Also didn't want to add a Rust toolchain. But for now using Podman 3.4
> will work for a while yet, and I guess it is inevitable considering
> conmon-rs....
>
> For our limited use case of "podman build", --network=host also works ?
>
> At least they don't have to fight over /etc/cni/net.d directory,
> anymore :-)
>
> /Anders
>
We are not dropping CNI right away, we are just announcing it so that we
don't need to ship it in RHEL10 and Fedora 39. So Podman 4.4 and later
will continue to have CNI support for a while yet.
> Den tis 10 jan. 2023 kl 14:30 skrev Brent Baude <bbaude(a)redhat.com>:
>
> Folks,
>
> I wrote a short blog about Podman adding a deprecation
> announcement for CNI plugins. With the success of the new network
> stack, not only do we eventually want the new stack to be the
> default but also the only option. For more information, check out
> the blog post itself:
>
> https://blog.podman.io/2023/01/podman-begins-cni-plugins-deprecation/
>
>
> _______________________________________________
> Podman mailing list --podman(a)lists.podman.io
> To unsubscribe send an email topodman-leave(a)lists.podman.io
3 years, 2 months
[Podman] Fwd: Re: What to use instead of RemapUsers/RemapUid/RemapGid in Quadlet now?
by jklaiho＠iki.fi
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 years, 6 months
