[tahoe-dev] Random ports

[Anders Genell]

Sorry, that was my intention but I missed replying to all...



13 aug 2013 kl. 00:27 skrev "Zooko O'Whielacronx" <zookog at gmail.com>:

> Very cool! I think you should post this description to tahoe-dev!
> 
> Regards,
> 
> Zooko
> 
> On Mon, Aug 12, 2013 at 1:57 PM, Anders Genell <anders.genell at gmail.com> wrote:

I'll be happy to report here as we go along!

I suppose I will be one of the administrators of our friendnet, and that is one of the reasons for me constantly disturbing the peace here.

We have created a Pidora image with a tahoe-daemon user and allmydata-1.10 preinstalled so that friends can get up and running easily with a RPi and a USB disk (1TB is most common for now). We have included the previously posted uglyhack script that updates the tahoe.cfg file when the external IP of the node changes, so people should not need to run any dyndns services, as long as the introducer has a static IP, which it has.

As for the ports, we have set tub.port and the port sections of tub.location to 8098, which is also the port forwarded through the routers/firewalls of all participating friends. Right now 3 of 8 (yay! another friend in the grid!) nodes report "strange" ports in the WUI welcome page of my node - 64884, 56377 and 53545 respectively. They still show up "green", and they are still possible to reach when just testing with telnet IP 8098, so it does not seem to affect functionality, but I can't figure out what the port number in the WUI represents. Actually, when testing just now one node is reporting a different port than 8098 while it is also unreachable on 8098 (likely due to port forward failure), but it is still "green" in the WUI.

I have written an awk script that parses the WUI welcome page and outputs nickname and connection status of each node. My idea is to use this to keep track of nodes that fall off the grid, and prompt the friend hosting the node to take measures. The RPis tend to overheat when placed in a case and running the first full upload (most friends have more than 30 Gb of files to back up, some as much as 400Gb which takes days if not weeks to complete), and since the users are meant to deploy the node and then more or less forget about it - running backups using Duplicati on their main computer(s) - they might not notice for awhile. So if the connection status is not viable for monitoring the availability of nodes, I need to fix something else (like parsing for the node IPs and scan for port 8098).

Best regards,
/Anders

>> 
>> 12 aug 2013 kl. 14:00 skrev "Zooko O'Whielacronx" <zookog at gmail.com>:
>> 
>>> On Sun, Aug 11, 2013 at 2:24 PM, Anders Genell <anders.genell at gmail.com> wrote:
>>>> 
>>>> We now have seven nodes in our friendnet and can soon start to rely on it as a long term cloud backup.
>>>> 
>>>> One thing we have noticed is that the nodes sometimes report different ports in the web interface(s) than what has been set for tub.location and tub.port. Checking /private/storage.furl shows the intended port, and the system seems to work, so it's just a matter of easing our worried minds about why e.g. 2 out of 7 nodes report wrong ports in the web interface?
>>> 
>>> I'm not aware of any bug about this. Are you sure you're not confusing
>>> tub.port with web.port or something?
>>> 
>>> https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/configuration.rst?rev=0a89b738bc05f17597555786b8f59dc05c46be0f#overall-node-configuration
>>> 
>>> Please give more information about the mysterious behavior of the 2
>>> (out of 7) nodes — what port number do they show? Is there anything
>>> listening on that port?
>>> 
>>> I would love to hear how your friendnet goes. Most friendnets fail,
>>> unfortunately. Some of the people don't use the friendnet, and the
>>> ones who aren't using it don't invest a lot of effort in maintaining
>>> the servers (to serve those who do use it). I heard another story of
>>> such a failed friendnet from some people I met at DefCon.
>>> 
>>> If anybody out there reading this has a story of a friendnet (either a
>>> failure or a success), I would love to hear it, to try to figure out
>>> what makes a successful one.
>>> 
>>> Regards,
>>> 
>>> Zooko