Hi Mathieu, The idea is to do it when the new network-manager installed which listens at 127.01.1 instead of at 127.0.0.1. The old NM worked with an empty or absent /etc/resolv.conf; the new one doesn't.
Yes, it is resolvconf's job to do take care of /etc/resolv.conf, but the sudden termination of name service will only arise when NM is also being used. So it's convenient if network-manager maintainer scripts performs the check. It could also be implement in a resolvconf maintainer script. It doesn't really matter where it's implemented. We are extremely respectful of the nonstandard configuration where /etc/resolv.conf is not a symlink to ../run/resolvconf/resolv.conf. The /sbin/resolvconf program never touches /etc/resolv.conf at all and the resolvconf package makes one and only one attempt to convert /etc/resolv.conf into a symlink, doing this only if an affirmative answer is given to a debconf question. This is all fine. But this respectfulness just expands the problem I am addressing here, the problem of there being a significant number of systems out there which --- unintentionally --- are missing /etc/resolv.conf, which currently have name service via nm-dnsmasq, but which won't have name service after upgrading to 12.10, resulting in some unhappy admins. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1060200 Title: Detect in the postinst that resolvconf is installed but /etc/resolv.conf is not a symlink to ../run/resolvconf/resolv.conf Status in “network-manager” package in Ubuntu: Triaged Bug description: I would like to start a discussion about a danger I see for 12.10. Resolvconf was introduced to Ubuntu core rather shortly before 12.04. Although resolvconf has been in Debian since 2003, popcon statistics suggest that this optional package is only installed on about 5% of Debian systems. Resolvconf proper hasn't been adopted by other major distros. Consequently resolvconf is not very well known yet. Consequently there are quite a few admins out there who don't know how to configure it. From the fact that there are so few resolvconf-related bug reports I think we can conclude that in the majority of cases the transition to resolvconf went fairly smoothly. The issues giving rise to bug #1000244 are, however, not negligible: there are images and tools out there that have set up Ubuntu 12.04 systems lacking the /etc/resolv.conf symlink. We can only imagine what has been done to fix up name resolving on those systems. I believe further that a significant number of admins out there have disabled resolvconf on their systems by deleting the /etc/resolv.conf symbolic link --- this was the quick way to get their system working without having to learn out how to configure resolvconf properly. The danger is that 12.10 will break a significant number of machines out there that lack symlink /etc/resolv.conf. Because of what was done to solve bug#959037, namely changing nm-dnsmasq's listen address to 127.0.1.1, any system that lacks the symlink and uses NetworkManager will have broken name service after upgrade. And it won't be obvious why name service is broken, either. Will we save ourselves and others a lot of trouble if we detect such cases and say in the network-manager postinst: "If resolvconf is installed and there is no symlink to ../run/resolvconf/resolv.conf at /etc/resolv.conf then put up a debconf warning telling the admin to address the issue, preferably by running 'dpkg-reconfigure resolvconf'"? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1060200/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
