Comment 9 for bug 604283

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