Need dnsmasq for podman to create CNI networks

[Ma124]

coreos/fedora-coreos-config#98 removed dnsmasq which is required by podman to create user-defined bridges.

Steps to reproduce:

# podman network create somenet
/etc/cni/net.d/somenet.conflist

# podman run --rm --network somenet alpine:latest
ERRO[0000] Error adding network: unable to locate dnsmasq in path
ERRO[0000] Error while adding pod to CNI network "somenet": unable to locate dnsmasq in path
Error: error configuring network namespace for container de0ff50a8cf34f25d3bd65c463630ba9875cfdadbf84608c29df8541c924f8b9: unable to locate dnsmasq in path

# rpm-ostree status
State: idle
AutomaticUpdates: disabled
Deployments:
● ostree://fedora:fedora/x86_64/coreos/stable
                   Version: 31.20200420.3.0 (2020-05-06T16:19:21Z)
                    Commit: b3fc3a3e8513d7e424d0ced1e2517484cb766d238951f2fdec3da2fed3522efb
              GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4

  ostree://fedora:fedora/x86_64/coreos/stable
                   Version: 31.20200407.3.0 (2020-04-21T19:37:39Z)
                    Commit: 89e17cc21b6aa3bea8959d1e6957fda157168d57ba6805d8a36142184edc2901
              GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4

[dustymabe]

Thanks for the report @Ma124

[jlebon]

Interestingly, it has not even a Recommends on dnsmasq. /cc @lsm5 @mheon Should podman-plugins have a Requires or Recommends on dnsmasq or is that by design?

[lsm5]

@jlebon I don't think we ever had podman-plugins depend on anything prior. If @mheon and others agree, would you mind sending a PR to dist-git? I'm on PTO atm but I can merge :)

[lucab]

Uhm, we don't really want to see users starting to rely on the on-host dnsmasq.service (that's the whole point of the distribution, decoupling OS and applications lifecycle) and I known that for example matchbox is happily running that in a container.

CNI plugins in general are meant to decouple container networking from host networking in a self-contained way.
Why does podman bridging end up depending on the host dnsmasq? To the best of my knowledge, the usual CNI bridging does not need that.

[mheon]

The dnsname plugin requires it. We need the plugin to provide name resolution within user-created networks.

We debated launching the resolver within a container, but the complexity of that compared with just launching it on the host was too high to justify (though this was around a year ago, so I'm forgetting exact details

[lucab]

Forwarded to containers/dnsname#22.

For reference, while looking at this I also found containernetworking/plugins#380 where the CNI maintainers themselves were also pushing back on such plugin (for other reasons).

It looks like there are a bunch of design issues here, which would be nice to see addressed upstream.

[baude]

Just dont install the dnsplugin if you don't want to deal with this. You will loose the dns function but the things that are struggling with will go away.

[cgwalters]

I guess one option is to invent /usr/libexec/dnsmasq-for-podman or so - this would be technically possible (basically mv it in postprocess, though at the cost of breaking other things depending on dnsmasq like libvirt)

A specific problem with dnsmasq too is it's had a bunch of CVEs in the past that we'd be on the hook for shipping even though in this use case most of them haven't been relevant.

[dustymabe]

Since podman 2.1.0 now has a podman -> podman-plugins -> dnsmasq hard requirement chain (see coreos/fedora-coreos-config#625 (comment)) we brought this topic up again in the meeting today. Currently we agreed to:

  * AGREED: We'll try to get the podman team to break the hard
    requirement of podman on podman plugins and continue the discussion
    upstream about potentially revisiting CNI plugin design.
    (dustymabe, 17:04:24)

This PR is starting the discussion down the path of breaking the podman -> podman-plugins hard requirement so we can follow the suggestion by @baude in #519 (comment).

[jamescassell]

I dug in and found that dnsmasq itself doesn't seem to pull in any other dependencies. The dnsmasq package itself is only about 500K in size. I'd suggest if we want to explicitly "not support" the service, that we add a systemd drop-in that disables it there and would require proactive user action to enable it. The dnsmasq executable itself is only 424K in size, so it doesn't make sense to split the dnsmasq package.

[travier]

Requested by another user on the Discourse forum: https://discussion.fedoraproject.org/t/please-consider-reinstating-dnsmasq-in-coreos/23615

[lump]

Requested by another user on the Discourse forum: https://discussion.fedoraproject.org/t/please-consider-reinstating-dnsmasq-in-coreos/23615

Thank you. I posted that. I thought about posting here, but this is about podman. I need dnsmasq for Docker Swarm.

I fear that people won't actually click the link. Should I copy/paste it here?

[dustymabe]

We discussed this in the meeting today.

13:17:46 dustymabe | #agreed we will include the dnsmasq rpm in the host to enable integrations with
                   | services that utilize the dnsmasq binary. We will add an override to disalbe the
                   | dnsmasq service and add documentation that explains how to re-enable it and
                   | explain why it's preferred that users not use the service directly.

[dustymabe]

docs PR coreos/fedora-coreos-docs#197

[dustymabe]

The fix for this went into testing stream release 32.20201018.2.0. Please try out the new release and report issues.

[dustymabe]

The fix for this went into stable stream release 32.20201018.3.0.