© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
9199653
demo site
(Get the code!)
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/
Please, stop adding fragmentation. You're doing a disservice to both your users and your upstreams. The result is that things will stop working on Ubuntu, or you'll convince a few upstreams to incorporate brain damaged Ubuntu-specific hacks, as is commonly the case. Don't do this.
> 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.
Your reasoning here doesn't make sense. If you're removing resolvconf(8), all packages and hooks will stop working. If you're replacing broken Debian resolvconf(8) with compliant openresolv or systemd-resolvconf, it's either the same exact situation, or it's a situation that's slightly less bad. And, fixing the .$suffix notation seems a lot easier than refactoring everything anyway. Either way, you might have to do work. But, seeing as openresolv is *already* something available to users and *already* something that users use frequently, why not ship systemd-resolvconf too? Stop trying to gimp your users.
> Please see previous bugs about this, trying to identify, enumerate and fix all of those usecases.
The bugs that I've seen always seem like the crumby Debian resolvconf has big issues, since that's basically unmaintained and poorly specified. Usually people switch to openresolv and everything works fine. Instead, here, you could switch to systemd-resolvconf. And bam, everything integrates nicely again.
> I'm not quite sure what is the point of wireguard package / wireguard-tools on Ubuntu.
Haha! Yea, maybe you should remove iproute2 from Ubuntu, since doesn't everyone use NetworkManager? /s
> 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.
Yea, this is just super tone deaf on how people *actually* use WireGuard, and what other tooling *actually* provides (or does not provide) for WireGuard. You're not going to get rid of the wireguard-tools tooling in the same way that you're not going to get rid of the iproute2 tooling. Same kind of essential thing to have around for doing anything of relevance.
Please, stop making life harder for both your users and for your upstreams. It looks like things are headed toward a classic Canonical-style calamity, which ends up having to be reverted a few years later, after everyone has suffered and software quality has declined trying to work around everything. Don't do that here, please. Listen to your users and to your upstreams.