Re: [tahoe-dev] Precise Puppy (linux) tahoe-lafs 1.10.0 initial report
Hi again, sorry for replying so late... The Pis used for storage nodes are in general not used for anything else, and we try to keep X turned off to save resources. You can also lower the amount of RAM reserved for the GPU to a minimal 16 Mb in the config.txt file in the Pi boot partition. Also, some of our Pis krashed when stressed, e.g. by uploading a bunch of very large files, until the SD card was replaced by a Sandisk SDSDX-016G-X46. The Pi is notoriously sensitive about what card is being used. Finally, if lack of memory is limiting performance, it is possible to set up a swap partition on the Pi. It will slow things down horribly, of course, but may just get the job done. Regards, Anders 28 sep 2013 kl. 05:20 skrev Garonda Rodian : > > Thank you for the report on the Raspberry Pi being used in production - are > you and your friends running just one storage node on the Pi, or are you also > running any other software (second storage node, Tor, I2P, OpenVPN?). My RPi > consistently simply dies during the trial - no errors, it just... stops, but > based on your feedback, I'll continue. > > As I'm hoping to run some medium scale tests, I'm going to have to have > something to generate a lot of nodes all at once, and I hate wasting effort. > At this point, I'm targetting something more like the old terminal/3270/DOS > menus and/or wizards - simple walkthroughs with questions to answer that can > be used to create the files for an entire grid, or add to an existing grid's > files, hopefully with some manner of "wrapper" (Tor, I2P, OpenVPN) > capabilities available as well. > > Does anyone have a good Python tutorial for experienced programmers? My C > and assembly used to be pretty good and my SQL is excellent, but I haven't > picked up a new language in a long time, and I never dealt with > parallelization much. > > P.S. the Precise Puppy 5.7.1 VM at 768MB fails with the GUI, but succeeds at > the command line with everything nonessential (cups printer daemon) disabled, > so the critical memory limit for the trial is very close to there, OS > overhead included. > > > From: anders.gen...@gmail.com > > Date: Thu, 26 Sep 2013 19:54:44 +0200 > > To: zoo...@gmail.com > > CC: tahoe-dev@tahoe-lafs.org > > Subject: Re: [tahoe-dev] Precise Puppy (linux) tahoe-lafs 1.10.0 initial > > report > > > > > > > > > >> P.S. If I'm lucky, the Raspberry Pi has completed its trial run, though > > >> if this is the RAM requirement, I'm not holding out much hope. > > > > > > It is too bad about #1476, because I really like to be able to run > > > unit tests everywhere and all the time. However, I believe that the > > > gateway or storage-server itself will run fine on Raspberry Pi, even > > > if (due to #1476) the tests will fail. > > > > > > > > > > Just to chime in: We have several storage nodes running off of RPis in our > > friendnet, and they seem to work fine as such. > > > > We would absolutely love a setup menu - many of our participating friends > > have never used a terminal. Looking forward to be dazzled!! > > > > Regards, > > Anders > > ___ > > tahoe-dev mailing list > > tahoe-dev@tahoe-lafs.org > > https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: [tahoe-dev] Precise Puppy (linux) tahoe-lafs 1.10.0 initial report
> >> P.S. If I'm lucky, the Raspberry Pi has completed its trial run, though if >> this is the RAM requirement, I'm not holding out much hope. > > It is too bad about #1476, because I really like to be able to run > unit tests everywhere and all the time. However, I believe that the > gateway or storage-server itself will run fine on Raspberry Pi, even > if (due to #1476) the tests will fail. > > Just to chime in: We have several storage nodes running off of RPis in our friendnet, and they seem to work fine as such. We would absolutely love a setup menu - many of our participating friends have never used a terminal. Looking forward to be dazzled!! Regards, Anders ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: [tahoe-dev] Dynamic address
I believe it has been suggested that the Introducer should "detect" incoming connections and thereby keep track of the addresses of connected nodes. If that was implemented you would only need to set the introducer furl and tub.port in your storage node config. The tub.port is of course needed for tahoe to know what port you have opened through your firewall for tahoe data traffic. Until that is implemented, we have a little script running on the storage nodes of out friendnet that automatically updates the node config file and restarts the node if the ipaddress changes. If you're on Linux you are welcome to try it. Regards, Anders 15 sep 2013 kl. 16:04 skrev Jerzy Łogiewa : > Is some hashbased ident + discovery possible instead? > > Take for example the bittorrent sync. A secret look like: > UF5O7G6XIMQKC7OH4J6NIPHDKVONMITO and that is all that is needed to find the > share! > > -- > Jerzy Łogiewa -- jerz...@interia.eu > > On Sep 15, 2013, at 3:24 PM, Pierre Abbat wrote: > >> On Friday, September 13, 2013 13:35:28 Jerzy Łogiewa wrote: >>> If my Tahoe storage node IP change, I must update it in tracker manually? Is >>> there some way to automate it, to make storage node tell tracker new IP? >> >> I have some names pointing to my computer and these lines in tahoe.cfg: >> >> [node] >> tub.port = 14159 >> tub.location = bezitopo.org:14159 >> >> bezitopo.org is not a dynamic DNS name, I have to update it on the rare >> occasions that it changes, but if you have a DDNS name, it should update the >> introducer manually. My storage node is behind a firewall, so it doesn't >> know >> its external IP address. >> >> Pierre >> -- >> Jews use a lunisolar calendar; Muslims use a solely lunar calendar. >> >> ___ >> tahoe-dev mailing list >> tahoe-dev@tahoe-lafs.org >> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev > > ___ > tahoe-dev mailing list > tahoe-dev@tahoe-lafs.org > https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: [tahoe-dev] Random ports
Ok, I created ticket #2073 I haven't used trac or reported ticket before so if I did something wrong please accept my apologies. If there is anything more you'd like me to add or to further investigate, please let me know. Regards, Anders 1 sep 2013 kl. 06:31 skrev Daira Hopwood : > On 25/08/13 12:00, Anders Genell wrote: >> Just to show what we currently have, below is the output of the >> aforementioned script. It >> relies on nmap to test connectivity. >> Currently the script just prints if there is a mismatch between announced >> port and the >> default one (8098), but we can also print announced port and its >> connectivity. >> >> The output on my node (below) currently show one mismatch. The output on the >> introducer >> node currently shows three mismatches. > > Please open a ticket on the Tahoe trac, otherwise this issue is liable to get > lost. > > -- > Daira Hopwood ⚥ > ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: [tahoe-dev] Random ports
Just to show what we currently have, below is the output of the aforementioned script. It relies on nmap to test connectivity. Currently the script just prints if there is a mismatch between announced port and the default one (8098), but we can also print announced port and its connectivity. The output on my node (below) currently show one mismatch. The output on the introducer node currently shows three mismatches. NodeOnline 8098Mismatch guldburken yes openno PIburkenyes openno genell yes openno patrik yes openno mackan no - - monkyes openyes Skogis..no - - Perra yes openno Best regards, /Anders 24 aug 2013 kl. 15:39 skrev Anders Genell : > I just wanted to "bump" this issue in order to clarify if I misinterpret what > to expect. > > I have updated my previously posted awk script > (https://www.dropbox.com/s/e6re3l1sranipuy/check_nodes.awk) to also check > ports. As we consistently set port 8098 as tub.port and in tub.location, I > would expect that port to be the one reported in the WUI in the Address > column, but I might be wrong? Most nodes report port 8098 there most of the > time, but not all of them always. Therefore my awk script checks access to > port 8098 for all reported IPs as well as access to potential alternative > ports that are reported. The latter are basically never accessible because > only 8098 is forwarded through the firewalls in the routers of the friends > running their respective nodes. 8098 seems so far always accessible for all > nodes that are reported to be online. > > At one point (this has since been remedied) one node was being reported as > being online with port reported as 8098 while 8098 was in fact being filtered > by a firewall. > > This all makes me wonder what the requirements are for a node being reported > as online? > > And where is the port number found that is being reported for a node in the > WUI? > > Regards, > /Anders > > > > 12 aug 2013 kl. 14:00 skrev "Zooko O'Whielacronx" : > >> On Sun, Aug 11, 2013 at 2:24 PM, Anders Genell >> 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 ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: [tahoe-dev] Random ports
I just wanted to "bump" this issue in order to clarify if I misinterpret what to expect. I have updated my previously posted awk script (https://www.dropbox.com/s/e6re3l1sranipuy/check_nodes.awk) to also check ports. As we consistently set port 8098 as tub.port and in tub.location, I would expect that port to be the one reported in the WUI in the Address column, but I might be wrong? Most nodes report port 8098 there most of the time, but not all of them always. Therefore my awk script checks access to port 8098 for all reported IPs as well as access to potential alternative ports that are reported. The latter are basically never accessible because only 8098 is forwarded through the firewalls in the routers of the friends running their respective nodes. 8098 seems so far always accessible for all nodes that are reported to be online. At one point (this has since been remedied) one node was being reported as being online with port reported as 8098 while 8098 was in fact being filtered by a firewall. This all makes me wonder what the requirements are for a node being reported as online? And where is the port number found that is being reported for a node in the WUI? Regards, /Anders 12 aug 2013 kl. 14:00 skrev "Zooko O'Whielacronx" : > On Sun, Aug 11, 2013 at 2:24 PM, Anders Genell > 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 ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: [tahoe-dev] awk parser for node status
Glad to hear it! I'm thinking of using this as a starting point for a script that can test connectivity on reported as well as expected ports and auto notify, e.g. through email, if things are not dandy. I'll post whatever I come up with. Regards, Anders 13 aug 2013 kl. 21:45 skrev Ed Kapitein : > Thanks, works like a charm! > > Kind regards, > Ed > > On 08/12/13 17:14, Anders Genell wrote: >> Try it now. >> >> Regards, >> Anders >> >> >> >> 12 aug 2013 kl. 16:35 skrev Ed Kapitein : >> >>> Hi Anders, >>> >>> Nice job, looks better then my quick and dirty cruft. >>> >>> It does mangle the space characters in a nick. >>> ( ZP Test Node became ZPTestNode ) >>> Not really important, but you might like to fix it. >>> >>> Kind regards, >>> Ed >>> >>> >>> On Mon, 2013-08-12 at 16:13 +0200, Anders Genell wrote: >>>> Dear list! >>>> >>>> >>>> I have written a small awk script for parsing the WUI welcome page in >>>> order to easily determine node status from the command line. >>>> >>>> >>>> Typically one would do >>>> >>>> >>>> wget -O - | awk -f check_nodes.awk >>>> >>>> >>>> please feel free to use and abuse as you like. >>>> >>>> >>>> Regards, >>>> Anders >>>> >>>> >>>> https://www.dropbox.com/s/e6re3l1sranipuy/check_nodes.awk >>>> >>>> >>>> >>>> ___ >>>> tahoe-dev mailing list >>>> tahoe-dev@tahoe-lafs.org >>>> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev > ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: [tahoe-dev] Random ports
Sorry, that was my intention but I missed replying to all... 13 aug 2013 kl. 00:27 skrev "Zooko O'Whielacronx" : > 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 > 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" : >> >>> On Sun, Aug 11, 2013 at 2:24 PM, Anders Genell >>> 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 ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
[tahoe-dev] awk parser for node status
Dear list! I have written a small awk script for parsing the WUI welcome page in order to easily determine node status from the command line. Typically one would do wget -O - | awk -f check_nodes.awk please feel free to use and abuse as you like. Regards, Anders https://www.dropbox.com/s/e6re3l1sranipuy/check_nodes.awk ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
[tahoe-dev] How to use /bin/tahoe backup
Dear list! Most of our friendnet members are using duplicati to upload backups to our grid, but I'd like to be able to upload files as they are, not lumping the data into 10Mb zipped (optionally encrypted) packages. I have tentatively investigated the tahoe backup command, but can't really figure out how it works. I tried pointing it to a newly created directory in the grid, and there was a new directory called 'Archives' created in there, but no files showed up while running the backup. Do I need to do something particular to see the files? Also, the info I could find mentions the backup being immutable, but I'd like to be able to perform incremental backups (as I believe duplicati does) and was wondering if tahoe backup can du that too? Ideally I'd like to be able to backup a directory so that I can open the corresponding write-cap uri in the tahoe web interface and plainly see all files. Is that doable? Best regards, Anders ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
[tahoe-dev] Random ports
Dear list! 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? Best regards, Anders ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
[tahoe-dev] Node alert function
Dear devs! We are continuing to deploy our friendnet dubbed RegnmolNET (the rain cloud in Swedish). One thing we thought of in addition to make the web welcome page color blindness proof was to have some daemon monitoring nodes and if they have been disconnected for more than XX hours or days sending a notification to e.g. an email address. Would this be something that would be worth including in tahoe? If not, is there a simple text file listing nodes that are connected/disconnected that we can parse to automate an alert? If not, is there some python API call or similar to that end? Best regards, Anders ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
[tahoe-dev] Fwd: Friendnet tub.location and tub.port
Oh, I just hit reply and completely ignored the missing tahoe-dev list address, sorry for that. New attemp... Regards, Anders Vidarebefordrat brev: > Från: Anders Genell > Datum: 17 juli 2013 18:11:56 CEST > Till: Daira Hopwood > Ämne: Re: [tahoe-dev] Friendnet tub.location and tub.port > > Ok, here goes. Avert you eyes or look through a mirror if you don't want to > turn to stone... > > > #!/bin/sh > #ip_update.sh > #tahoe.conf IP update > > tahoe_bin=/opt/allmydata-tahoe-1.10.0/bin/tahoe > tahoe_path=/mnt/tahoe/tahoe-daemon/.tahoe > tahoe_conf=$tahoe_path/tahoe.cfg > ipupdate_log=$tahoe_path/logs/ip_update.log > > my_ip=`wget -O - http://ipecho.net/plain` > tahoe_ip=`grep tub.location $tahoe_conf | cut -f2 -d= | cut -f1 -d:` > > if [ "$my_ip" != "" ] ; then > if [ "$my_ip" != "$tahoe_ip" ] ; then > ( echo ",s/$tahoe_ip/$my_ip/g" && echo w ) | ed - $tahoe_conf > echo `date` "$tahoe_conf updated with $my_ip IP address" >> $ipupdate_log > su - tahoe-daemon -c ''$tahoe_bin' restart '$tahoe_path/'' > fi > fi > > > > > We rely on one singe external ip lookup site, but I suppose more could be > added and compared... > > Regards, > Anders > > > 17 jul 2013 kl. 16:27 skrev Daira Hopwood : > >> On 12/07/13 10:48, Anders Genell wrote: >>> Dear list! >>> >>> I posted a related question recently and got som useful answers, but I am >>> still somewhat confused as to what is required concerning incoming wan >>> access for friendnet nodes. >>> >>> Our original idea was to just set tub.port on all nodes and make sure that >>> port was forwarded through any routers/firewalls along the way. We would >>> then expect the introducer to detect the IPs of incoming connections from >>> nodes and announce each node with that IP combined with the corresponding >>> port number, as set in each node's tub.port. It would however seem like we >>> actually need to specifically set the tub.location IP address of each node >>> for the nodes to "see" eachother. Without it all nodes see the introducer, >>> and the introducer sees all nodes but the nodes don't see eachother. >>> >>> There have been suggestions here to let the introducer(s) handle IPs, and >>> if I understand correctly that would work in more or less the way we >>> assumed it already did? >>> >>> Right now we have uglyhacked a script to update the tahoe.cfg file and >>> restart the node whenever the IP changes, by regularly checking e.g. >>> myexternalip.com. Most nodes will run on Raspberry Pi hardware so a bash >>> script is sufficient, but a bit of python should make it more platform >>> independent, I suppose. >>> >>> My question is, should we need to set both tub.location and tub.port? >>> Should we need to uglyhack to update IP alternatively use som dyndns >>> equivalent? >>> The introducer detects incoming IPs anyway, couldn't that be reported back >>> to the node? >> >> Can you post the uglyhack script so that we can see precisely what it does, >> and whether it would be worth Tahoe-LAFS doing something equivalent >> automatically? >> >> Yes, the introducer could report IPs back to the node; that is >> https://tahoe-lafs.org/trac/tahoe-lafs/ticket/50 . >> >> -- >> Daira Hopwood ⚥ >> ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
[tahoe-dev] Feature request: Brighter colors
My friend who is running the introducer for our little friendnet is colorblind and he says the particular shades of red and green used to represent nodes being accessible or not in the Web interface are completely indistinguishable. He would like to request a way of listing node status without color coded information, or at least make the colors differ more in brightness (e.g. bright red and camouflage green). I don't know how many Tahoe-users might suffer from the same condition, but I guess it would be fairly easy to change? Best regards, /Anders ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
[tahoe-dev] Friendnet tub.location and tub.port
Dear list! I posted a related question recently and got som useful answers, but I am still somewhat confused as to what is required concerning incoming wan access for friendnet nodes. Our original idea was to just set tub.port on all nodes and make sure that port was forwarded through any routers/firewalls along the way. We would then expect the introducer to detect the IPs of incoming connections from nodes and announce each node with that IP combined with the corresponding port number, as set in each node's tub.port. It would however seem like we actually need to specifically set the tub.location IP address of each node for the nodes to "see" eachother. Without it all nodes see the introducer, and the introducer sees all nodes but the nodes don't see eachother. There have been suggestions here to let the introducer(s) handle IPs, and if I understand correctly that would work in more or less the way we assumed it already did? Right now we have uglyhacked a script to update the tahoe.cfg file and restart the node whenever the IP changes, by regularly checking e.g. myexternalip.com. Most nodes will run on Raspberry Pi hardware so a bash script is sufficient, but a bit of python should make it more platform independent, I suppose. My question is, should we need to set both tub.location and tub.port? Should we need to uglyhack to update IP alternatively use som dyndns equivalent? The introducer detects incoming IPs anyway, couldn't that be reported back to the node? Apart from that, we now have the required minimum of four nodes running, and all seems to work fine. We can upload and download as expected, mostly using Duplicati so far. Best regards, Anders ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: [tahoe-dev] how to find out your own IP address
If I understand things correctly, making the introducer the manager of IPs
would also make sure all nodes can connect to each other even if nodes in a
friendnet use dynamic ip?
The "tub.location" would then only be needed in the introducer(s)?
We just added the third node, adding to the introducer (at my friends place)
and my storage node, and we realized while the introducer knows about both
nodes, my own web interface shows the introducer as online ("green") but the
third node as offline ("red"). Similarity the third node shows my node red.
We have not specifically set any tub.location, but have set a tub.port, and are
forwarding that port through respective routers/firewalls.
Best regards,
Anders
26 jun 2013 kl. 17:24 skrev "Zooko O'Whielacronx" :
> On Wed, Jun 26, 2013 at 2:50 AM, Greg Troxel wrote:
>> I think removing autodetection of IP address would be a significant
>> regression for people running storage nodes that might move.
>
> Okay, thanks for the feedback.
>
>> I think it would be good to figure out what is the problem really. I don't
>> understand why this is so hard. The PATH issue makes me want to have
>> configure-time finding of the right programs, based on OS, and then to
>> invoke them with the configured path, period.
>
> That's what we currently do, except that it isn't at configure-time,
> but at run-time, and it tries only a specific path:
>
> https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/util/iputil.py?rev=08590b1f6a880d51751fdcacea6a007ebc568f2e#L160
>
> alternate hosting of that same code, on github:
>
> https://github.com/tahoe-lafs/tahoe-lafs/blob/08590b1f6a880d51751fdcacea6a007ebc568f2e/src/allmydata/util/iputil.py#L160
>
>> Is anyone having an issue on BSD? There, /sbin/ifconfig is quite stable.
>> So is the issue that various Linux flavors have withdrawn the
>> previously-standard interfaces?
>
> That is one of several problems. Here's the full set:
>
> https://tahoe-lafs.org/trac/tahoe-lafs/query?status=!closed&keywords=~iputil
>
>> An alternative would be to have the introducer look at the address that
>> appears at it when the node connects, and use that to advertise, or perhaps
>> just send it down the wire so the client can decide.
>
> Good idea! I've updated a very old ticket (#50, opened 6 years ago) to
> suggest this instead of the "STUNT/ICE" thing that it formerly
> suggested:
>
> https://tahoe-lafs.org/trac/tahoe-lafs/ticket/50# ask a peer to tell
> you what your IP address is (similar to STUNT/ICE)
>
> Regards,
>
> Zooko
> ___
> tahoe-dev mailing list
> tahoe-dev@tahoe-lafs.org
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
[tahoe-dev] dynamic ip
Dear list! I am slightly uncertain about the inner workings of the tahoe grid when it comes to (storage)nodes with dynamically assigned ip addresses. I would have though that as long as the introducer is running on a static ip, all clients should be able to annouce their respective ip addresses if and when they change? Or does every node need a dyndns-equivalent account? Best regards, -- Anders ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: [tahoe-dev] Remove node?
Hehe, yes, worry is a very human trait :-) But I can also imagine some slight practical use in having an up to date list. We plan to invite friends who are not so very computer savvy, and it would be good to see if their nodes are suddenly disconnected for some reason. If the list starts getting cluttered by legacy nodes I imagine it could be slightly less obvious which ones are a real problem. But if there is no real reason for doing anything about it then I'll survive without a nifty mind soothing clean-up. Best regards, Anders 7 jun 2013 kl. 02:00 skrev "Zooko O'Whielacronx" : > It doesn't bother the Tahoe-LAFS clients to know about old servers > that are no longer connected. The main harm from it is it enlarges the > list of known servers and makes humans worry about whether the old > long-gone ones are causing some kind of trouble by still being in that > list. > > Regards, > > Zooko > ___ > tahoe-dev mailing list > tahoe-dev@tahoe-lafs.org > https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: [tahoe-dev] Remove node?
Yay! I feel proud like a school kid getting his first A :-) While I'm at it, I suggest to use garbage collection among nodes as well. If a node as been inactive longer than XX hours/days/weeks it could be automatically removed from all lists. I'm sure there are a lot of things to consider but it seems to work well for files. Thank you for you help Oleksandr! Best regards, Anders 6 jun 2013 kl. 13:33 skrev Oleksandr Drach : > Hello Anders, > > As you've said there can be only one introducer at the moment (see FAQ Q17), > that's true so far. > BTW the bridge is not far away so we have started our preparations :-) > > Have a nice day! > > Sincerely, > Oleksandr Drach. > > > 2013/6/6 Anders Genell >> Thank you kindly, Gentlemen! >> I will ask my friend with the introducer to do so. >> >> This makes me wonder how it all would work when/if multiple introducers are >> possible in a grid... >> >> Oh we'll, we'll cross that bridge when we come to it (or as a directly >> translated Swedish proverb goes "That day, that sorrow"). >> >> Best regards, >> Anders >> >> 6 jun 2013 kl. 11:26 skrev Oleksandr Drach : >> >>> Hi guys! >>> >>> Ed, you are absolutely right with your reply :) >>> BTW I have added the question to Tahoe-LAFS FAQ. >>> >>> Thanks! >>> >>> Sincerely, >>> Oleksandr Drach. >>> >>> >>> 2013/6/6 Ed Kapitein >>>> >>>> On Thu, 2013-06-06 at 09:43 +0200, Anders Genell wrote: >>>> > Hi list! >>>> > >>>> > I'm new here so please excuse my breaking of any code of conduct. >>>> > >>>> > We are some friends setting up a small Tahoe grid to use as cloud based >>>> > backup solution. A friend runs the introducer and I run a storage node >>>> > connected to it. More nodes to come as more friends join in. When >>>> > testing things I created a node on one machine but then decided to run >>>> > my node on a raspberry pi as a low power server. I didn't manage to move >>>> > the previous node to the pi so I created a new. I now would like to >>>> > remove my old node from the grid but cannot find any instructions about >>>> > how to accomplish that. >>>> > I'm sure I've overlooked something obvious so I humbly ask for someone >>>> > to point me in the right direction. >>>> > >>>> > Best regards, >>>> > Anders >>>> >>>> Hi Anders, >>>> >>>> I am not an expert, but i think restarting the introducer would do the >>>> trick. >>>> >>>> Kind regards, >>>> Ed >>>> >>>> >>>> ___ >>>> tahoe-dev mailing list >>>> tahoe-dev@tahoe-lafs.org >>>> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev >>> >>> ___ >>> tahoe-dev mailing list >>> tahoe-dev@tahoe-lafs.org >>> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev >> >> ___ >> tahoe-dev mailing list >> tahoe-dev@tahoe-lafs.org >> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev > > ___ > tahoe-dev mailing list > tahoe-dev@tahoe-lafs.org > https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: [tahoe-dev] Remove node?
Thank you kindly, Gentlemen! I will ask my friend with the introducer to do so. This makes me wonder how it all would work when/if multiple introducers are possible in a grid... Oh we'll, we'll cross that bridge when we come to it (or as a directly translated Swedish proverb goes "That day, that sorrow"). Best regards, Anders 6 jun 2013 kl. 11:26 skrev Oleksandr Drach : > Hi guys! > > Ed, you are absolutely right with your reply :) > BTW I have added the question to Tahoe-LAFS FAQ. > > Thanks! > > Sincerely, > Oleksandr Drach. > > > 2013/6/6 Ed Kapitein >> >> On Thu, 2013-06-06 at 09:43 +0200, Anders Genell wrote: >> > Hi list! >> > >> > I'm new here so please excuse my breaking of any code of conduct. >> > >> > We are some friends setting up a small Tahoe grid to use as cloud based >> > backup solution. A friend runs the introducer and I run a storage node >> > connected to it. More nodes to come as more friends join in. When testing >> > things I created a node on one machine but then decided to run my node on >> > a raspberry pi as a low power server. I didn't manage to move the previous >> > node to the pi so I created a new. I now would like to remove my old node >> > from the grid but cannot find any instructions about how to accomplish >> > that. >> > I'm sure I've overlooked something obvious so I humbly ask for someone to >> > point me in the right direction. >> > >> > Best regards, >> > Anders >> >> Hi Anders, >> >> I am not an expert, but i think restarting the introducer would do the >> trick. >> >> Kind regards, >> Ed >> >> >> ___ >> tahoe-dev mailing list >> tahoe-dev@tahoe-lafs.org >> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev > > ___ > tahoe-dev mailing list > tahoe-dev@tahoe-lafs.org > https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
[tahoe-dev] Remove node?
Hi list! I'm new here so please excuse my breaking of any code of conduct. We are some friends setting up a small Tahoe grid to use as cloud based backup solution. A friend runs the introducer and I run a storage node connected to it. More nodes to come as more friends join in. When testing things I created a node on one machine but then decided to run my node on a raspberry pi as a low power server. I didn't manage to move the previous node to the pi so I created a new. I now would like to remove my old node from the grid but cannot find any instructions about how to accomplish that. I'm sure I've overlooked something obvious so I humbly ask for someone to point me in the right direction. Best regards, Anders ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: [tahoe-dev] Tahoe-LAFS, Django, RAIC
On 09/02/2010 02:36 AM, Zooko O'Whielacronx wrote: http://blog.mozilla.com/webdev/2010/08/30/from-zope-import-django-persistence/ It mentioned that although Django's native persistence language has always been SQL that there was recent interest in porting it to "NoSQL databases". On a whim, I searched the web for "django tahoe-lafs" and what do you know! Someone named Anders Pearson has written code to make Django use Tahoe-LAFS as a storage backend: http://github.com/thraxil/django-tahoestorage Hi. Sorry I haven't passed this along yet. I'd been hoping to actually get some unit tests written for it and try out one or two other ideas I had for speeding it up before I did a real public announcement. Anders has also written "a django frontend for Tahoe-LAFS": http://github.com/thraxil/canopy What is "a django frontend of Tahoe-LAFS"? Is it a user interface, so basically an alternative to the Tahoe-LAFS Web User Interface (http://pubgrid.tahoe-lafs.org/ )? Yeah, Canopy was mostly supposed to be an alternative front-end. I probably should just delete that project at this point. I really wrote it to just write *something* against Tahoe's web API to get a feel for it. My plan was to get it working and then refactor it into a reusable Django app that could then be included in other Django projects. So the idea is that I'm often building things that are sort of mini-CMSes where users can upload and manage media files and I would like to be able to easily pass the files off to Tahoe. I got that sort of working but then realized that just writing a storage backend would be a better approach so I abandoned Canopy and started on django-tahoestorage instead. I'm planning on continuing work on django-tahoestorage and very interested in hearing thoughts on how it can be improved. Unfortunately right at the moment I'm on vacation in Montana and I have somewhat limited internet access and not as much time to code. ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
