On Mon, 2022-05-30 at 12:49 +0200, Petr Menšík wrote:
> On 5/28/22 22:22, Thomas Haller wrote:
> > As you say, NetworkManager can run dnsmasq as DNS plugin by
> > configuring
> > `[main].dns=dnsmasq` in `man NetworkManager.conf`.
> >
> > In that mode, NetworkManager will spawn the dnsmasq process.
> > Doing that is undesirable, for several reasons.
> >
> > I agree, it would be much better, if dnsmasq could run as a
> > separate
> > service. In the best case, dnsmasq could be D-Bus activated, then
> > it
> > doesn't even have to be a systemd service (altough, on systemd
> > systems,
> > of course systemd would start the dnsmasq service).
> >
> > When would dnsmasq reload those files? Usually, we would prefer
> > that
> > everything can be configured via D-Bus. Of course, if dnsmasq by
> > default runs without D-Bus, then that wouldn't work. What would
> > those
> > configuration snippes contain beside `enable-dbus`?
> I thought it could contain dnssec for selected networks. However that
> is
> not possible to set via dbus (or alternatives). It requires restart,
> because some structures are initialized different way. Just pure
> reconfiguration by re-reading config file is not enough. It would
> require no small changes in dnsmasq to allow enabling validation
> runtime.
If we had a system wide dnsmasq instance (that NetworkManager talks
to), then I think it would be up to the admin (or the distro default)
to set dnssec.
Likewise for enable-dbus. Just as the admin has to set `dns=dnsmasq2`
in NetworkManager.conf, they would also have to make sure that D-Bus is
enabled. IMO, D-Bus is just a useful and basic IPC mechanism, it's not
a cumbersome dependency that users need to avoid. So, I'd be fine if
that dnsmasq service is shipped with "enable-dbus" on by default. And
if not, it's up to the admin to change that.
What NetworkManager provides is per-interface configuration,
nameservers, DNS searches, and maybe some nameserver specific dnssec
settings. But not the basic dnssec/enable-dbus settings. Then,
NetworkManager would not need to drop conf snippets and not restart the
service.
If you compare with wpa_supplicant.service, it also is D-Bus
activatable and has D-Bus enabled... at least on distros where users
expect to use NetworkManager with wpa_supplicant. See `systemctl cat
wpa_supplicant.service`.
> > /etc/NetworkManager/dnsmasq.d is a semidocumented thing, where
> > users
> > could hack the setup by dropping snippets. I wonder how bad it
> > would be
> > to move away from the way how we do it currently. Maybe we could
> > symlink all files there from /run. Or maybe we would need to add a
> > separate dns=dnsmasq2 plugin for the new way.
> >
> >
> > I would prefer the notion that dnsmasq is just running as a stand-
> > alone
> > service, and NetworkManager can push interface-specific DNS
> > configuration to it (basically, like with systemd-resolved) and
> > also
> > with the notion that there could be other services that configure
> > their
> > part. For example, WireGuard's wg-quick could configure the DNS
> > server
> > on the WireGuard interface (though, currently I think that would
> > call
> > /usr/sbin/resolvconf -- unless systemd-resolved is detected).
>
> There is a problem that no generic interface good for reconfiguration
> of
> running services exist. resolvconf can configure something and
> openresolv package attempts to do such thing.
/usr/sbin/resolvconf would be such a generic API. It doesn't have to be
openresolv. For example, Fedora has no openresolv package. However
there is a resolvconf compat binary which directly talks to systemd-
resolved.
NetworkManager itself can be configured to call resolvconf and talk to
systemd-resolved's native API. But NetworkManager won't ever be a
provider of an resolvconf API. That is because NetworkManager is a
service that can configure your local caching DNS service, but it does
not pretend to be that service itself. If you currently use
`dns=dnsmasq` in NetworkManager, then you'll get a split-DNS setup, but
that is not extendable/accessible to to be configured by other tools.
Which can be a very fine thing for certain uses!! But we won't extend
that. What we could do, is that dnsmasq itself becomes a central
service that NetworkManager talks to ("dns=dnsmasq2").
If dnsmasq would want to fill the space of systemd-resolved, it either
needs a resolvconf backend, or provide a general API that independent
services can cooprerate on. NetworkManager won't need to talk
resolvconf however, it can directly implement dnsmasq's native API (as
it does today). For NetworkManager this API also doesn't need to be
"very general" either. That then just means, it would be less likely
that other services would also use it.
Btw, dnsmasq is a very fine and useful tool that can already do many
things. It's not clear to me, that it also needs to become an
alternative for systemd-resolved. dnsmasq supports many use-cases that
systemd-resolved never will, and the opposite is fine as well ("do one
thing, well"). What is the actual problem you'd like to solve?
> It is possible to make
> generic query to dbus (or varlink?) which services provide some
> interface?
Programs/services can provide a well-known D-Bus name, that others can
introspect. Run `d-feet` and see what is on your system-bus.
> Then VPN could send required configuration to all interested
> providers. I am not working with dbus often. What would be the best
> way
> for other services to provide unified API?
>
> I doubt we want each VPN provider to implement all possible DNS
> caches.
> Can generic api be used instead?
yes, that's a problem. Either
- /usr/sbin/resolvconf, either by integrating in openresolv (which
isn't currently in Fedora) or by providing an alternative
implementation like systemd-resolved does.
(I don't like resolvconf very much).
- Make the API similar or even identical to systemd-resolved's API.
For example, ConsoleKit2 provides a very similar API as logind.
That can make implementation for users simpler.
- invent a new one generic API :)
- have a dnsmasq specifc API
- any combination of the above.
best,
Thomas
_______________________________________________
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
