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