Thanks for the help and support. Always good to have a resident crank. <div>I'm still getting use to tahoe, got files stored and replicated<br><div>comments inline with some feature requests.</div><div><br></div><div>
I've implemented GlusterFS, and Ceph test environments and still in the hunt for</div><div>that enterprise scalable parallel distributed secure file system. There were</div><div>things I thought were better and things I thought were worse. Not to</div>
<div>think that my opinion actually is of much value. Just to</div><div>add my $0.02 to the collective, I liked the simple setup was the best of the 3 </div><div>-- how all files were created for you with minimum number of commands to get </div>
<div>up and going. The focus on non-trusted remote stores was exactly what I needed.</div><div>The things I didn't like is python didn't feel "enterprise" solution to me --</div><div>I would have thought Java or C would have been used. I didn't like</div>
<div>how tahoe was not really well integrated with the operating system such</div><div>as "mkfs -t tahoe" or POSIX support. I'd much rather just have a NFS style</div><div>mount introducer:/tahoe /mnt/tahoe and run my standard "ls /mnt/tahoe" or</div>
<div> "cd /mnt/tahoe; ls" instead of a non-standard "tahoe ls tahoe:".</div><div>The big worry for me is I haven't yet found all the documentation to the</div><div>internal workings of the file storage and my concern is if sht hits the fan</div>
<div>and I have to recover all the data, how do I go about doing that or where</div><div>do I even begin.</div><div><br><div><br><div class="gmail_quote">On Sun, Jul 29, 2012 at 4:46 PM, Greg Troxel <span dir="ltr"><<a href="mailto:gdt@ir.bbn.com" target="_blank">gdt@ir.bbn.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
It's IMHO a bug in tahoe that users get tracebacks for things that are not<br>
internal software failures. (That being my opinion does not help you,<br>
but I'm doing my duty as a resident crank.)<br>
<br>
By default, tahoe looks in $HOME/.tahoo (I think). So you'll have to be<br>
careful about root vs non-root.<br></blockquote><div>always a good rule not to run as root, but when I create file systems, I'm usually</div><div>root, so I think this would be good to put a short warning in the quickstart. My</div>
<div>confusion was that I thought I had to be a node and a client, so my node was</div><div>not in ~/.tahoe, but in /tmp/some-node-test-dir, didn't see the -d option. I seriously</div><div>did look for some environment variable or something to set something like a TAHOEHOME</div>
<div>so I wouldn't need some sort of -d option.</div><div>Would have been helpful to me to tell me this in the starter docs.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you make a directory in other than the standard place ($HOME/.tahoe),<br>
you'll need to use "-d nodedir". Note that the syntax is<br>
tahoe maincommand -d $nodedir --other-options<br>
rather than the -d being first.<br></blockquote><div>Now seriously, is this a feature, not a bug? </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you are trying to use the pubgrid, you don't need an introducer.<br></blockquote><div>Website says pubgrid is no longer available due to hackers, but I thought it</div><div>would be worthless to use the public introducer since I wouldn't be able to </div>
<div>store anything anywhere unless I knew the secret handshakes with the in crowd</div><div>(what I gathered from Zooko's email on Freenet vs Tahoe)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Using the web ui to see the node status is hugely helpful. If your node<br>
isn't connected, nothing useful is going to happen, but looking at the<br>
status will let you figure that out more directly.<br></blockquote><div>I'm old school user and 2nd the need for command line and remote </div><div>shells, so while Web is NICE, I would still like a command line and text version where I could output text</div>
<div>process it through perl or some scripts. Now I could do that with the web</div><div>UI, but just more work for me and everyone else. The web is not meet the criteria of "eye candy".</div><div>I think a command line attracts the old farts and killer GUI client apps attract the youngsters. </div>
<div>Webmin and other tools show that you can always add a web interface.</div><div><br></div><div>I saw some stuff on the web that looked wrong like</div><div>old deprecated test nodes still listed and couldn't see any files from the webui, but being a </div>
<div>newbie my setup is still probably all wrong with lots of experimentation. It gave me a sense that the</div><div>cleanup or timeouts weren't quite handled. I'm sure if I have a clean setup, things would look just fine.</div>
<div>That just tells me things work. If the garbage collection is there, it tells me not only that things work,</div><div>but they work well.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There should be a command-line version of the status page, but there<br>
seems not to be.<br>
I use "wget <a href="http://127.0.0.1:3456/" target="_blank">http://127.0.0.1:3456/</a> && more index.html" :-)<br>
Seriously, am I the only one who runs nodes on computers I am not<br>
sitting at?<br>
<br>
Unless you have a good reason, I'd run tahoe as yourself (or a non-root<br>
special user) rather than root. My own practice is to have a tahoes<br>
('tahoe server' uid) and run storage nodes and introducers with that<br>
uid.<br>
<br>
The pubgrid introducer seems down. But I don't think you've gotten that<br>
far yet.<br>
> telnet 74.207.252.227 50528<br>
Trying 74.207.252.227...<br>
telnet: Unable to connect to remote host: Connection refused<br>
</blockquote></div><br></div></div></div>