[tahoe-dev] Can Tahoe works well in this scenario?

[Shu Lin]

Greg,

Thanks a lot you for pointing out Coda project. I have a brief glance at it.
Yep, Coda is a great project which doesn't a good job in server
automatically replicate/rebalancing, and client caching. But, I like some
features in Tahoe but not in Coda:

   1. Files saved encrypted in the server. This feature I like is because if
   I put the server in a hosting/cloud provider which I am not quite trust.
   Then, I protect my data in some level at least the provider needs gain
   root privilege to run the Tahoe code to access my data. Instead of simply
   reading the hard disk sector by sector.
   2. The communication between servers are secured by transferring only
   encrypted data. I didn't find Coda supports that. It might be solved by just
   using SSL or IPSec tunnel for the RPC channel among Coda servers. But, I
   don't know if it is already implemented or if not, how easy to add this
   feature into Coda architect.
   3. The communication between client and server, Tahoe supports all kinds
   of up-to-date protocols. I can force using HTTPS and SFTP if I really need
   secure channel. I didn't see Coda supports that.
   4. File/Directory sharing between different clusters/grids. In Tahoe,
   this is just as easy as giving a filecap of the directory you want to share
   to others. In Coda, I don't know if the file system can be shared easily in
   any level of the file system. From my current understanding, the sharing and
   mounting point is happening on the volume level now.

Certainly, I am still learning both projects to see what will be best fit
for my deployment. What kind of trade-off I need to pay if I pick up one and
if I need twist the code eventually to meet my goal.

For fixing the firewall, I don't quite understand you suggestion. Even
through, I fixed my setup by opening a port in my firewall last time as you
suggest if you remember. But, I don't think opening a port is eventually
acceptable in my deployment. I prefer a zero firewall configuration effort
as NAT traversal is so a popular technology already. I don't think Skype
will get success if it has to ask everybody to twist their firewall ports at
home. :-)

Thanks with regards,
-Shu

On Thu, Dec 2, 2010 at 5:18 AM, Greg Troxel <gdt at ir.bbn.com> wrote:

>
> For your use case tahoe is not yet baked enough.
> It's also possible tahoe is not the right tool for your problem.
> Also check out coda:
>  http://www.coda.cs.cmu.edu/
>
> tahoe doesn't currently have servers do resyncing automatically.  That's
> done by clients running repair.
>
> You might want to decouple the concept of client nodes and servers, even
> though by default a server is a client.
>
>  In my deployment, I would consider it is not acceptable that a1 can only
> be
>  accessed from A WUI because all my 3 servers are running in the different
>  places in the world behind their own firewalls. Accessing a file from
> remote
>  server from WUI is not acceptable and against the original security design
>  of Tahoe project.
>
> Your clients all need to be able to connect to all servers.  You'll have
> to fix the firewall :-)
>
> share placement is not particularly well controlled, and in the tahoe
> vision is not super important - you have many servers and put shares on
> a number of them.
>
> I think you could change tahoe's code to do what you want; with 1/1/3
> sharing you can upload to 1 server (not having any redundancy) and then
> repair should try to copy to more servers as it is able.  While 1/1/3
> would be viewed as odd by most, 2/4/7 might be more normal and would
> still benefit from improved share placement and repair code.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20101202/d10da71f/attachment.html>