iputil: finding IP addresses fails on kfreebsd

[davidsarah]

From ​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700239:

tahoe start fails on kfreebsd:

NevowSite starting on 3456
Starting factory <nevow.appserver.NevowSite instance at 0x1a62fc8>
My pid: 29925
DatagramProtocol starting on 55322
Starting protocol <twisted.internet.protocol.DatagramProtocol instance at 0x1a73248>
Unhandled Error
#011Traceback (most recent call last):
#011  File "/usr/lib/python2.7/threading.py", line 525, in __bootstrap
#011    self.__bootstrap_inner()
#011  File "/usr/lib/python2.7/threading.py", line 552, in __bootstrap_inner
#011    self.run()
#011  File "/usr/lib/python2.7/threading.py", line 505, in run
#011    self.__target(*self.__args, **self.__kwargs)
<exception caught here> ---
#011  File "/usr/lib/python2.7/dist-packages/twisted/python/threadpool.py", line 207, in _worker
#011    result = context.call(ctx, function, *args, **kwargs)
#011  File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", line 118, in callWithContext
#011    return self.currentContext().callWithContext(ctx, func, *args, **kw)
#011  File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", line 81, in callWithContext
#011    return func(*args,**kw)
#011  File "/usr/lib/python2.7/dist-packages/allmydata/util/iputil.py", line 214, in _synchronously_find_addresses_via_config
#011    raise UnsupportedPlatformError(sys.platform)
#011allmydata.util.iputil.UnsupportedPlatformError: gnukfreebsd8
Node._startService failed, aborting
[Failure instance: Traceback: <class 'allmydata.util.iputil.UnsupportedPlatformError'>: gnukfreebsd8
/usr/lib/python2.7/threading.py:525:__bootstrap
/usr/lib/python2.7/threading.py:552:__bootstrap_inner
/usr/lib/python2.7/threading.py:505:run
<exception caught here> ---
/usr/lib/python2.7/dist-packages/twisted/python/threadpool.py:207:_worker
/usr/lib/python2.7/dist-packages/twisted/python/context.py:118:callWithContext
/usr/lib/python2.7/dist-packages/twisted/python/context.py:81:callWithContext
/usr/lib/python2.7/dist-packages/allmydata/util/iputil.py:214:_synchronously_find_addresses_via_config
]
calling os.abort()
calling os.abort()

The following patch fixes the issue:

--- tahoe-lafs-1.9.2.orig/src/allmydata/util/iputil.py
+++ tahoe-lafs-1.9.2/src/allmydata/util/iputil.py
@@ -161,6 +161,7 @@
     "netbsd4": "bsd",
     "netbsd5": "bsd",
     "netbsd6": "bsd",
+    "gnukfreebsd8": "bsd",
     "sunos5": "sunos",
     "cygwin": "cygwin",
     }

[davidsarah]

We're far too picky about recognizing the operating system in order to decide which command to use to find IP addresses. In practice, we could just try a couple of common syntaxes that would work for all Unices that are currently supported, and be very likely to work for others. Then we'd only need to distinguish between Windows and everything else.

[zooko]

Replying to davidsarah:

We're far too picky about recognizing the operating system in order to decide which command to use to find IP addresses. In practice, we could just try a couple of common syntaxes that would work for all Unices that are currently supported, and be very likely to work for others. Then we'd only need to distinguish between Windows and everything else.

That sounds like a reasonable approach, davidsarah. On the other hand, it feels kind of icky to be attempting to execute programs on every computer which aren't even part of that operating system. I used to have some code to do that sort of thing in Tahoe-LAFS and Brian pushed back on it.

I guess I'm +0 on it, now.

I mean, the current situation is that Tahoe-LAFS fails to start up on a new operating system until someone adds a 1-line patch like this one. Maybe that's okay for now?

[zooko]

See #1988

[gdt]

I am -1 on running a list of commands that are not known to be correct, particularly at runtime. That leads to unreliable behavior, especially if someone has one of the other commands in their PATH.

This is pointing out that the configure/build process needs to have a reliable way to determine how to do various OS things, and that's something autoconf has done for years. It does require writing a feature test, but that seems to be the price of reasonably reliably figuring out what to do.

Also, just because there's a program called "ifconfig" doesn't mean it will necessarily do what you want.

[daira]

Oops, I accidentally committed the patch for this while committing the reviewed fix for #1717. Sorry :-(

[daira]

Replying to gdt:

This is pointing out that the configure/build process needs to have a reliable way to determine how to do various OS things, and that's something autoconf has done for years.

autoconf works by trying various things and seeing which appear to work. There's not very much difference apart from doing it at install time vs run time.

[daira]

Replying to daira:

autoconf works by trying various things and seeing which appear to work. There's not very much difference apart from doing it at install time vs run time.

And of course, we're certainly not going to add a dependency on autoconf or anything similarly complicated.

[Daira Hopwood <david-sarah@…>]

In a493ee0bb641175ecf918e28fce4d25df15994b6/trunk:

iputil.py: add tests for recent changes. refs #1381, #1988, #982, #1064, #1536, #1935, #898, #1707, #1918

Signed-off-by: Daira Hopwood <david-sarah@…>

[daira]

iputil on trunk no longer distinguishes between Unix variants, which fixes this bug.