> > I believe that it should do something saner instead of overwriting. > > I must disagree. If resolvconf is absent, overwriting is the most sane, or > least insane thing to do. There just is not a lot that can be done without > mediation for writing the resolver configuration.
Here I must disagree. I don't use NetworkManager, in case it matters. As I explained, rdnssd is unusable for me as-is. With my (fairly simple) patch, it at least works for me, so clearly there is something that can be done. > > It should verify if the file contains the DNS servers it detected > > and add them if they are missing. But it should definitely not blindly > > overwrite the file... > > There are currently no ways to know which entries were inserted by rdnssd > (possibly by a previous incantation of it) and which by other tools. Maybe not by a previous incantation, but definitely be the current one. And if the current one contains only nameserver entries, it can just refrain from modifying/deleting any other kind of entries, whether they were generated by rdnssd previously (perhaps with a different configuration in order to query other data) or someone/something else. Indeed, my patch doesn't actually check the current entries, and hardcodes "nameserver" only, but that shouldn't be too hard to fix. If that's what you like I can try to amend my patch. > Furthermore, I doubt we can safely assume that all resolv.conf tools remove > their entries when uninstalled. I think this suggestion is worse than the bug > from a reliability perspective. Do you think reliably wrong is better? (Well, as a programmer I'd actually kind of agree -- reliably wrong is better in order to find a bug, but now that we have found the bug, it's time to fix it. :) > Really, any pair of two tools writing resolv.conf will screw stuff up without > resolvconf present and supported by both tools. That problem affects ppp, > dhcp- > client3, network-manager, wicd, connman, systemd(-networkd) just to name a > few. And I don´t dare mention most if not all VPN clients. Or the admin, not to forget. For all I know, rdnssd doesn't "own" /etc/resolv.conf. In fact, for a file that resides in /etc, without a special notice, I'd expect that I can modify it as an admin (which I did, and then I had to debug what killed my changes). An alternative that would also work for me (not sure about combination with other tools) would be if merge-hook used some template to produce its output (which should then include a comment pointing to the template for manual changes), so I could put my local settings there instead. Frank -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
