Re: [Buildroot] [PATCH 9/9 v3] package/podman: new package

["Yann E. MORIN" <yann.morin.1998@free.fr>]

Raphael, All,

On 2025-03-07 14:40 +0100, Raphael Pavlidis spake thusly:
> On 3/1/25 16:05, Yann E. MORIN wrote:
> > The documentation [0] states that seccomp can be disabled (i.e. not
> > enabled), but we were unable to start a container without seccomp
> > support in podman. So we make that mandatory.
> You can start a container without seccomp by passing the
> --security-opt=seccomp=unconfined` option. But it is okay for me if it is
> mandatory.

Ok, good to know. But it means that, by default, podman uses seccomp,
and there is no way (that I could find, like in containers/conf for
example) to disble it unless with a non-trivial --option. Also, having
seccomp support does not preclude not using it. So I would still
consider that, for the Buildroot integration, we can make it mandatory.

Thanks for the hint about the --option!

> > Similar to Docker, podman can inject a minimalist init as PID1 in
> > containers, and like Docker, this is optional; podman however can only
> > use catatonit as such an init [2]. Given the size of catatonit (1.3%
> > that of podman!), we do not bother to make it optional, and always
> > enable it as well.
> I think systemd can also be used as a init. According to the documentation
> [1].

    https://docs.podman.io/en/latest/markdown/podman-run.1.html#init

As far as I understand it, using --init is what will cause catatonit to
be mounted into the container, and then called as PID 1, with catatonit
then spawning the actual command (or entrypoing etc...).

Using --systemd=XXX is "just" a way to tell podman to automatically do
a few preliminary setup (mounting tmpfs where needed, etc...) before
spawning the command in the container (i.e. either the one specified on
the podman copmmand line, or the entrypoint etc...) With --systemd=true
the setup is done if the commadn is systemd, /usr/sbin/init, /sbin/init
or /usr/local/sbin/init (whether those are actually systemd or not, by
the way!); with --systemd=false, the setup is never done, and with
--systemd=always, the setup is always done.

Of course, I would expect that using --init (and thus catatonit as PID
1), with a systemd in the container, will not play nicely, as systemd
would not be PID 1...

So, I think the catatonit init is unrelated to systemd, and one can not
use systemd as the process used by podman --init. Of course, it is
entirely possible that I misunderstood that part of podman too. ;-)

> > +	select BR2_PACKAGE_IPTABLES  # runtime
> I am sure that you do not need iptables if you are using nftables.

I briefly tried with nftables, it did not work, so I did not investigate
further; IIRC it was before I had to write containers.conf, so maybe we
can specify the firewall driver there... Ah, yes, it seems we can do
that:

    firewall_driver=""

    The firewall driver to be used by netavark. [...] supported drivers
    are "iptables", "nftables" [...]

I can regive it a spin, and add a blurb in the commit log if the outcome
is still negative.

But either way, it can be an improvement afterwards, once the series is
applied.

> > +		$(PODMAN_PKGDIR)/containers.conf \
> > +		$(TARGET_DIR)/etc/containers/containers.conf
> > +	$(Q)$(INSTALL) -D -m 0644 \
> > +		$(PODMAN_PKGDIR)/policy.json \
> > +		$(TARGET_DIR)/etc/containers/policy.json
> > +	$(Q)$(INSTALL) -D -m 0644 \
> > +		$(PODMAN_PKGDIR)/registries.conf \
> > +		$(TARGET_DIR)/etc/containers/registries.conf
> Just for curiosity, why not installing those files under
> /usr/share/containers?

The first such file I wrote was policy.json, and the documentation for it
states [0]:

    By default, the policy is read from $HOME/.config/containers/policy.json,
    if it exists, otherwise from /etc/containers/policy.json ; [...]

So I did not look further and put it in /etc/containers/. Then I had to
write registries.conf (for seemless access to the docker hub), and again
the documentation also states [1]:

    By default, the policy is read from $HOME/.config/containers/policy.json,
    if it exists, otherwise from /etc/containers/policy.json ; [...]

So again, I put it /etc/containers/ without much ado. And when it came
to write containers.conf to use slirp4netns instead of pasta, it seemed
like a good idea to pu it there too, and as the documentatiopn also
states this is a valid location [2], I decided to put all config files
together.

I now looked at my Fedora, and policy.json and registries.json are
indeed in /etc, but containers.conf is in /usr/share/. I'll move it.

Thanks for the good and interesting feedback! :-)

Regards,
Yann E. MORIN.

[0] https://github.com/containers/image/blob/main/docs/containers-policy.json.5.md#description
[1] https://github.com/containers/image/blob/main/docs/containers-registries.conf.5.md#description
[2] https://github.com/containers/common/blob/main/docs/containers.conf.5.md#description

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot