[tahoe-lafs-trac-stream] [tahoe-lafs] #1988: don't stop the process if you can't execute "ifconfig" or "route.exe"

[tahoe-lafs]

#1988: don't stop the process if you can't execute "ifconfig" or "route.exe"
---------------------------------------------+---------------------------
 Reporter:  zooko                            |          Owner:
     Type:  defect                           |         Status:  new
 Priority:  normal                           |      Milestone:  undecided
Component:  code-network                     |        Version:  1.10.0
 Keywords:  iputil portability transparency  |  Launchpad Bug:
---------------------------------------------+---------------------------
 Currently, the tahoe-lafs process tries to learn its IP address by
 creating a socket
 ([source:trunk/src/allmydata/util/iputil.py?annotate=blame&rev=1b84612fdf6623885ad4999fa245f9c87ccb53f6#L101
 iputil.get_local_ip_for()]), and also by executing either {{{ifconfig}}}
 (on unix) or {{{route.exe}}} (on windows)
 ([source:trunk/src/allmydata/util/iputil.py?annotate=blame&rev=1b84612fdf6623885ad4999fa245f9c87ccb53f6#L137
 iputil code]).

 Even if it doesn't learn its IP address, or if it learns and incorrect IP
 address, it can still work, provided that the other processes that it
 needs to talk to have announced ''their'' IP addresses and it is able to
 open TCP connections to them.

 Now the problem is that if it can't execute {{{ifconfig}}}/{{{route.exe}}}
 successfully, then it stops the process.

 This is the number one problem that prevents people from running Tahoe-
 LAFS on new platforms (#898, #1536, #1918, #1707). In fact, it may be the
 ''only'' thing that prevents Tahoe-LAFS from being portable to all sorts
 of unix-likes! It also causes various other problems due to security
 constraints (#982), and subprocesses being finicky (#854, #1064, #1381,
 #1935)

 What if instead, if the call to the subprocess ({{{ifconfig}}} or
 {{{route.exe}}}) fails, that it logs this fact and then moves on. This
 would change the failure mode from the user's perspective from "It stopped
 at startup" to one of the following:

 1. "I can't connect to anyone."
 2. "I can't connect to some servers/clients but can connect to others."
 3. "I can connect to all servers/clients and everything works."

 I don't like, in principle, changing a hard "stop loudly" failure into a
 soft "misbehave confusingly" failure, but in this case it might be worth
 it. The thing is that the confusing 3-way failure mode from (partial)
 inability to connect to other processes already happens due to other
 reasons. We wouldn't be ''adding'' that failure mode, we would be
 converting certain situations (previously unsupported platform, {{{PATH}}}
 is set weirdly, security feature prevent access to {{{ifconfig}}}, etc.)
 from the hard-stop failure mode to the latter failure mode.

 This ticket supercedes #854 and #1536. Oh! And I see that #1536 has a
 patch from mk.fg! Good...

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1988>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage