systemd package missing resolvconf(8) compatibility symlink, and a Provides: resolvconf

Thanks for bringing this to my attention. I believe your assessment is correct. Do you know which Ubuntu first started using resolved? How far back do we need to make changes?

There are two facets of this:

1) The Ubuntu systemd package should install the resolvconf compatibility symlink. I have no idea why this isn't already the case, and that seems like a bug that should be remedied ASAP. resolvconf(8) is the standard interface for programs to interact with DNS, which is why systemd provides it. Not providing it is super confusing.

2) The Recommends in the wireguard package should be adjusted.

I believe apw@ can handle (2). Somebody on the systemd team should handle (1).

In ubuntu everything should feed DNS information direct into resolved whenever possible.
We are working on improving it, for example in groovy isc-dhcp-client & ifupdown started to do that too.

Unfortunately systemd's resolved's resolvctl is not compatible with Debian's/Ubuntu's historical resolvconf.

Specifically Debian/Ubuntu has a lot of $interface.$suffix where $suffix is arbitrary, such syntax is widely used and not supported by systemd.

So for the time being it is not possible to switch /sbin/resolvconf to be the one provided by systemd.

wireguard package => please feed DNS data direct to systemd-resolved using either dbus or the cli.

> wireguard package => please feed DNS data direct to systemd-resolved using either dbus or the cli.

Absolutely not. We're not going to add vendor-specific hacks for broken distros that are unable to include the standard interface for this kind of thing, resolvconf(8). This is a pretty clear case of downstream being broken.

> Unfortunately systemd's resolved's resolvctl is not compatible with Debian's/Ubuntu's historical resolvconf.

First of all, we're not talking about systemd's resolvectl. We're talking about systemd's resolvconf compatibility symlink which provides the same interface as openresolv or the debian resolvconf monster.

With that clarified, if you still think there's a problem due to Debian's resolvconf using an interface prefix list, I think you're incorrect there too. Firstly, openresolv doesn't act that way, and things work fine. Secondly, systems that have moved to systemd-resolved (that is, Ubuntu itself) have in the process _broken_ resolvconf anyway. Replacing broken resolvconf with one that is less broken -- even if it doesn't do priority interface prefixes -- is still a marked improvement. And thirdly, every script I've seen that uses resolvconf actually continues to work fine with systemd's compatibility symlink of resolvconf; if any you see don't, why not fix them?

So, in other words, I don't think you've presented a very compelling argument at all. I can't see any correct technical reasoning in what you wrote. It seems like adding the resolvconf compatibility symlink is a marked improvement over the current broken status quo.

By the way, Arch manages the possibility of openresolv colliding with systemd's resolvconf by providing a package called "systemd-resolvconf": https://www.archlinux.org/packages/core/x86_64/systemd-resolvconf/ https://github.com/archlinux/svntogit-packages/blob/packages/systemd/trunk/PKGBUILD#L239-L251

This seems like a perfectly reasonable way to accomplish this. Simply package the symlink in a separate package, and then the "Recommends:" for wireguard just includes systemd-resolvconf in the list alongside openresolv and resolvconf.

That seems like an exceedingly reasonable way of going about things. Why not just do the same thing here?

Ubuntu/Debian has never used openresolv, and yes systemd-resolved had a contribution to have openresolv compatible input interface.

I am not asking for wireguard to implement any legacy/compat interfaces, but use directly systemd-resolved standard interface which has abi guarantees.

There is a lot more things and options one can provide to systemd-resolved via native API that is impossible to specify via openresolv or compat-openresolv.

I do not wish to ship any openresolv/resolvconf/compat symlinks at all going forward.

Integration with resolvconf _without_ using .$suffix of where the DNS information is originating is incorrect integration on Debian/Ubuntu, because of how resolvconf is shipped and configured on Debian/Ubuntu and used by other packages.

Arch used to use openresolv, openresolv compat was added to systemd-resolved, and yes hence they were able to switch to systemd-resolved providing openresolv symlink / compat / integration. Either by default, or as an option.

That is not possible for Debian/Ubuntu because of more than three dozen of packaging & hooks, calling resolvconf with .$suffix notation.

Please see previous bugs about this, trying to identify, enumerate and fix all of those usecases.

Also see prior discussions on similar topic at https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1713803

I'm not quite sure what is the point of wireguard package / wireguard-tools on Ubuntu.

Our kernel ships wireguard modules by default anyway, and one can configure wireguard via networkd and soon via netplan. Which is our default tooling to interact with the wireguard kernel module.

wg / wg-quick seem like specific to wireguard tooling, which should not be integrated or used by default on Ubuntu. Since all of the regular and standard networking tooling now supports wireguard out of the box.

Your four appended comments are super full of just plain wrong information. I'll try to unpack these all piecemeal:

> Ubuntu/Debian has never used openresolv

This is not the case. Ubuntu and Debian have provided openresolv for a very long time, and resolvconf has mostly been an unmaintained mess. Most users who do DNS stuff wind up switching from resolvconf to openresolv if their OS comes preinstalled with resolvconf, and you'll find a lot of blogs advocating that too. Openresolv has definitely been part of the Debian/Ubuntu verse for a long time.

> and yes systemd-resolved had a contribution to have openresolv compatible input interface.

"had a contribution" what? Lennart wrote that code. It wasn't just some random third party contribution that got accidentally merged or something. The maintainer of the project wrote it and merged it. Why did he do that? Because resolvconf(8) is the standard stack-agnostic CLI interface for managing DNS on Linux. It's not some "legacy" thing or a "compatibility" thing, but a standard thing. Ensuring that systemd provides that was important for systemd to be able to become a drop in replacement for standard uniform resolver infra.

> I am not asking for wireguard to implement any legacy/compat interfaces, but use directly systemd-resolved standard interface which has abi guarantees.

Wha?! You've got it all backwards here. WireGuard uses resolvconf(8), because that's the standard Linux mechanism for managing DNS resolution. It will *not* use some specific backend, or write support for 20 different backends, because the resolvconf(8) is a successful abstraction over these so that application writers need not include a massive list of various things to try. So no, sorry, asking an upstream to implement some random newfangled thing isn't going to fly: Linux has a standard interface already for this kind of thing, which systemd implements because systemd is a caring citizen in the Linux-verse, and you're just crippling your users by *not* providing this standard interface. Please quit trying to introduce more fragmentation and shoving the burden of that upstream to application writers, in order to support your OS. Rather, play nicely with others, and provide the standard interfaces. Two of your upstreams are working together for this -- systemd provides a resolvconf(8), and wireguard uses a resolvconf(8). But for some bad reason you want to take away the standard link between the two and instead impose vendor-specific things on upstreams. This is a waste of everybody's time and makes code harder to maintain.

> There is a lot more things and options one can provide to systemd-resolved via native API that is impossible to specify via openresolv or compat-openresolv.

So what? resolvconf(8) provides a good acceptable abstraction for most use cases, which is why application writers use it. If somebody needs to dip down below the abstraction, so be it, but that's mostly not the case, and it certainly isn't the case here.

> I do not wish to ship any openresolv/resolvconf/compat symlinks at all going forward.

Please, stop adding fragmentation. You're doing a disservice to both your users and your upstreams. The...

> Our kernel ships wireguard modules by default anyway, and one can configure wireguard via networkd and soon via netplan. Which is our default tooling to interact with the wireguard kernel module.

How should we generate the wireguard keys without `wg`? openssl? It's a significant deviation from upstream and what you will find documented out there, and puts the burden on us to make sure the keys were correctly generated, with the correct entropy source, number of rounds (if applicable), etc.

@ahasenack I feel a bit lost here. This bug report is about how one should or shouldn't propagate DNS servers after establishing a wireguard based connection.

This has nothing to do w.r.t. creating keys.

I think he meant to post this on https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1950317

On Tue, Nov 23, 2021 at 1:40 PM Jason A. Donenfeld
<email address hidden> wrote:
>
> I think he meant to post this on
> https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1950317
>

That makes a lot more sense. Commented my opinion there about the need
for key generation tooling.

Regards,

Dimitri.