On 10/08/11 06:42, Steve Langasek wrote: > I don't believe there's any bug in ifupdown here. As mentioned in the > upstream Debian bug, you do not need an explicit 127.0.1.1 network > interface to receive requests on that address, *as long as* you are > listening on the "any" address. This is indeed what openssh is doing by > default; being able to ssh to 127.0.1.1 has nothing to do with any > ifupdown changes. > Out of the many services I run, the only ones I find that have problems > with 127.0.1.1 are bind, ntpd, and nmbd. nmbd is entirely > uninteresting, because it's only relevant on broadcast interfaces (which > is part of why it must bind by IP). ntpd's behavior could be considered > a bug, as could bind9. Since you mention bind9 explicitly, I think > reassigning this report to the bind9 package is the reasonable course of > action here. > ** Package changed: ifupdown (Ubuntu) => bind9 (Ubuntu) > ** Tags removed: patch
Steve, Thanks for taking interest. I went quiet because I am very worried about causing undesirable side effects by rushing into conclusions about a fix. I have several different production systems that I can test carefully, but I don't have a lab system to play with. There has been a lot of update activity on ifupdown since our latest stable release, 0.6.10ubuntu4 (0.6.10 on debian sid). The code is currently a moving target in the form of the debian experimental version. (In particular, it seems all interface changes are now made with the ip program, rather than ifconfig and route). ifupdown handles so many different kinds of interface and I can't test most of them. My bug relates specifically to handling of the IPv4 loopback addresses and that logic HAS changed in the new version. The current version explicitly creates lo 127.0.0.1, so my patch explicitly creates lo:0 as 127.0.1.1 to deal with the "new style" debian hosts file. Once I stripped down my own customised hosts files, my simplistic patch really works for all of my own network server software. However, the experimental ifupdown does "the right thing" (in agreement with your statement above) because (I think) it doesn't explicitly define ANY loopback interfaces at all. Server sockets listening on "any interface" (0.0.0.0) certainly work fine and I haven't //yet// found any applications that don't work as desired. Nevertheless, it seems foolhardy to take a snapshot of the experimental package and toss it into any production ubuntu repository. I'm not yet confident enough to simply strip out and backport the IPv4 loopback logic from the current alpha version either. I suspect many people have hacked their hosts files to get round problems in the past, and there are a lot of applications that might have been hacked too. All of these could be at risk if we release a fix - even if we are making the package "work properly at last". I think we should keep this bug filed against ifupdown - it will certainly be changed in the next release and will certainly fix this "bug". I honestly can't say yet whether bind (amongst other applications) is also at fault for listening on the "wrong" local addresses. I think we should leave that supplementary question hanging until ifupdown is working properly with respect to the IPv4 loopback subnet. Regards, Brian -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to bind9 in Ubuntu. https://bugs.launchpad.net/bugs/604283 Title: network servers do not listen on 127.0.1.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/604283/+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
