You've got the basic idea. The nsswitch.conf file is where Name Service services are configured, and "hosts" is one of them. DNS is *one* way to look up hosts, but so is "files" (/etc/hosts) and "mdns4" (avahi). Anything that extends how names are translated to addresses should, imnho, be done through NSS. This is because *everything* supports NSS. For instance, NIS and NIS+ hosts are done through NSS, and this is supported by essentially everything, because it's the standard. All of the "enterprise" directory services I've come across use an NSS plugin (usually the "nis" one). It's just simply the right way to do it.
I wouldn't worry about resolver libraries that don't use glibc. They're typically DNS-specific, and are typically configured by their own files anyway. Dig, for instance, will use whatever server you tell it to, and ignore resolv.conf (though it uses it as a default). Same goes for the "host" tool -- they're used for querying specific DNS servers. However, those resolvers *also* ignore /etc/hosts, because that's referenced by the "files" NSS plugin. Any service that uses gethostbyname(3) is using glibc, and that's going to be everything except edge cases that are intentionally doing their own thing anyway. Things that try to emulate glibc behavior by first checking /etc/hosts and then /etc/resolv.conf are simply doing it wrong, and will miss (for instance) avahi, NIS, and any other directory service that may be installed. I'm surprised at the idea that it will be less work to modify glibc. Even if it's technically easier to make a change in the glibc code than to create your own NSS plugin, you have a myriad of problems: NM functionality would now have a dependency on a nonstandard patch of glibc, the documentation for /etc/resolv.conf will be inconsistent for only this distribution, there could (will) be resistance by the glibc folks, who knows what you'll break when you alter how glibc behaves, etc. However, with an NSS module, we have a huge number of advantages: * It's the standard way of achieving this type of thing and is hence supported by most everything * It's the standard way of achieving this type of thing so it's very well documented * It's the standard way of achieving this type of thing so it's very modularized and isolated, and if NM stops working it will continue along the chain without screwing up plugins further up like (unlike when dnsmasq dies with the proposed glibc change) * It's the standard way of achieving this type of things so the things that don't support it are, in general, doing it wrong and that's a bug on their end * It's the standard way of achieving this type of thing so there's already a package (libnss-mdns) that adds a hosts NSS module, meaning both that we know it works and that it is "officially supported by ubuntu" * It could be owned by the NM project instead of creating a dependency on a glibc patch that would not be taken up by distributions very quickly * You could make it do other interesting things like have static /etc/hosts-like entries per connection. You get the idea. If you want to see an example of an NSS hosts plugin packaged for ubuntu, that hooks into /etc/nsswitch.conf, look at the nss-mdns source package. The debian/libnss-mdns.postinst script that runs upon installation is what handles inserting it into /etc/nsswitch.conf, and can easily be adapted to handle inserting a NM plugin. If you want another example of an ubuntu package dealing with NSS plugins look at the auth-client-config package, though this one only handles the passwd, group, and shadow services. In short: An NSS plugin has vastly less risk of breaking software because Ubuntu already uses it and things aren't breaking (and it's also the standard, anyway), could actually be part of the NM project as opposed to owned by glibc, and will likely be easier than modifying glibc anyway due to fewer dependencies. This seems like win-win-win to me. To be clear, I'm advocating that we make a small NSS plugin wrapper around calls to a dnsmasq (or other) "mini name server" controlled by NM, that runs on a non-privileged port and can be spawned per-user. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
