Changes
no edit summary
Tahoe-LAFS is a distributed filesystem which provides redundancy and security for files.Our most recent incarnation was run on [[Infrastructure:Crashoverride|Crashoverride]]
=FAQs=Connecting to VTLUUG's Tahoe Grid==VTLUUG now operates an ''onion grid'', a grid of tor hidden services. All nodes must be tor-enabled using ''torify'' and storage nodes must also advertise a tor hidden service.
# Pass arguments to tahoe start. Default to "--syslog".DAEMONARGS="--syslog"CONFIG_DIR=What does "/srv/tahoe-storage"</pre>* Create a Tahoe user and add it do?=to the tor group** <code>useradd tahoe-lafs</code>** <code>usermod -aG debian-tor tahoe-lafs</code>* Create the appropriate tahoe services, and start them:** <code>sudo -u tahoe-lafs tahoe create-node --listen=tor -n YOUR_NODE_NAME -C /srv/tahoe-storage/vtluug-tor-storage -i GET_THIS_STRING_FROM_AN_OFFICER</code>** <code>systemctl start tahoe-lafs</code>
=== Tuning ===
You should adjust the encoding parameters to strike the desired balance between upload bandwidth and replication.
* shares.needed refers to the number of storage nodes (out of shares.total) need to be available to reconstruct a file.
* shares.happy refers to the minimum number of storage nodes a file should be striped upon
* shares.total refers to how many stripes of a file should be made
Note that in order to upload a file, the ''client'' does the striping. This can cause significant latency if the client is on a consumer internet connection. You can eliminate this issue by relying upon a ''helper'' node which does striping for you. Blobs are still encrypted on the client side, so not much trust needs to be placed in this. Helpers are useful if you have access to a server with significantly higher bandwidth than your client.
==Troubleshooting==
This is a list of various problems I've encountered. --[[User:Mjh|Mjh]] ([[User talk:Mjh|talk]]) 00:47, 30 December 2014 (EST)
=== Tahoe daemonized and then terminated immediately ===
This can be caused by several factors when running with torsocks.
* You're trying to bind to an IP other than localhost and torsocks blocked this. Ensure the tub.port and web.port lines are set to restrict traffic to localhost.
* Tahoe is attempting to establish a UDP connection to identify its local IP address. Torsocks restricts UDP connections, causing Tahoe to throw exceptions and terminate. Ensure you are using the [https://github.com/tahoe-lafs/tahoe-lafs latest trunk version] rather than the version supplied by your OS.
=== Can't connect to introducer ===
* Ensure tor is running and that Tahoe is started through torify.
* Ensure the <code>introducer.furl</code> parameter is not enclosed with quotes in <code>tahoe.cfg</code>. For some reason this has caused connection issues for me.
==FAQs==
Technical documentation on Tahoe can be found on its website. However, for the prospective user, here's a simple explanation in Q&A format:
===What does it do?===
You set up a node with a few hundred gigs of free space and connect it to the tahoe grid. Then, you put files in it. It encrypts each file and puts part of it on ten of the nodes on the grid in such a way as to be able to recover the entire file even if up to 7 of the nodes are unavailable.
===But what if I don't want people seeing my files?===
They're encrypted, remember? Each file has an automatically generated key which also tells where the file is located. You can share this "filecap" with anyone else you'd like to see the file.
===So the nodes aren't trusted?===
No. Files stored on them are encrypted, signed, split into pieces, and distributed among the nodes. The only way to get the file back without the filecap is by finding the storage index, retrieving the pieces from the nodes, breaking the encryption, and reassembling the pieces. This is designed to be difficult.
===And all these nodes are hooked together?===
No. Groups of users set up grids, often arranged by geographical location for improved bandwidth and latency.
===How do I access files?===
When a file is uploaded (using tahoe put or tahoe cp), tahoe gives you a filecap. A filecap looks something like this:
The filecap does NOT include the name of the file or its type. Types may be found using the unix file utility. To retrieve the file, use tahoe get [filecap] [filename]. This will cause tahoe to get the filecap's shares from the nodes, reassemble them, decrypt them, verify the integrity of the file, and write it to filename.
===How do I delete files?===You can't. The nodes are not trusted and therefore cannot be relied upon to remove the file's shares when asked. To render a file inaccessible, destroy all copies of the filecap. After 31 60 days, the file's lease will expire and its shares will be automatically garbage collected, or deleted, by the nodes. ==Wait, files expire? But I thought...==
===Directory?===
Yeah, you can have directories. They are implemented basically as lists of filecaps with associated filenames. They are referenced using dircaps, which come in read-write and write-only forms. As a result of storing the filecaps of the contained files inside the dircap's shares (a dircap, remeber, is treated similarly to a file with regards to storage), all files may be read as a result of knowing only the dircap. This does not, however, work in reverse. If you give another user the filecap of a file (or the dircap of a directory) in a directory, they cannot find the names or contents of the other files in the directory containing the filecap.
===How come there are no mountable filesystem frontends?===There are; they just aren't built-in. Tahoe's high latency makes it rather unwieldy for use as part of a conventional filesystem. Append operations in particular are extremely inefficient. It is recommended that you use the web and CLI interfaces to manage files stored in tahoe.
[[Category:VTLUUG :Projects]][[Category:InfrastructureDeprecated]]