docs: a few simple updates to links and naming, and also recommend torsocks instead of the old, unmaintained tsocks, for use with Tor

This commit is contained in:
Zooko O'Whielacronx 2010-09-18 18:16:36 -07:00
parent 0cc0d19f57
commit 6eba4a2f8c
4 changed files with 18 additions and 16 deletions

View File

@ -31,7 +31,7 @@
<p>There are two kinds of files: immutable and mutable. Immutable files have the property that once they have been uploaded to the storage grid they can't be modified. Mutable ones can be modified. A user can have read-write access to a mutable file or read-only access to it (or no access to it at all).</p>
<p>A user who has read-write access to a mutable file or directory can give another user read-write access to that file or directory, or they can give read-only access to that file or directory. A user who has read-only access to a file or directory can give another user read-only access to it.</p>
<p>When linking a file or directory into a parent directory, you can use a read-write link or a read-only link. If you use a read-write link, then anyone who has read-write access to the parent directory can gain read-write access to the child, and anyone who has read-only access to the parent directory can gain read-only access to the child. If you use a read-only link, then anyone who has either read-write or read-only access to the parent directory can gain read-only access to the child.</p>
<p>For more technical detail, please see <a href="architecture.txt">architecture.txt</a> and the <a href="http://tahoe-lafs.org/trac/tahoe-lafs/wiki/Doc">The Doc Page</a> on the Wiki.</p>
<p>For more technical detail, please see the <a href="http://tahoe-lafs.org/trac/tahoe-lafs/wiki/Doc">The Doc Page</a> on the Wiki.</p>
<h2>Get Started</h2>
<p>To use Tahoe-LAFS, please see <a href="quickstart.html">quickstart.html</a>.</p>

View File

@ -130,7 +130,7 @@ tub.location = (string, optional)
tub.port = 8098
tub.location = external-firewall.example.com:7912
Run a node behind a Tor proxy (perhaps via tsocks), in client-only mode
Run a node behind a Tor proxy (perhaps via torsocks), in client-only mode
(i.e. we can make outbound connections, but other nodes will not be able to
connect to us). The literal 'unreachable.example.org' will not resolve, but
will serve as a reminder to human observers that this node cannot be
@ -141,7 +141,7 @@ tub.location = (string, optional)
Run a node behind a Tor proxy, and make the server available as a Tor
"hidden service". (this assumes that other clients are running their node
with tsocks, such that they are prepared to connect to a .onion address).
with torsocks, such that they are prepared to connect to a .onion address).
The hidden service must first be configured in Tor, by giving it a local
port number and then obtaining a .onion name, using something in the torrc
file like:

View File

@ -1,7 +1,7 @@
= Tahoe FTP and SFTP Frontends =
= Tahoe-LAFS FTP and SFTP Frontends =
1. FTP/SFTP Background
2. Tahoe Support
2. Tahoe-LAFS Support
3. Creating an Account File
4. Configuring FTP Access
5. Configuring SFTP Access
@ -27,15 +27,15 @@ and passwords, octal file modes (user/group/other, read/write/execute), and
ctime/mtime timestamps.
== Tahoe Support ==
== Tahoe-LAFS Support ==
All Tahoe client nodes can run a frontend FTP server, allowing regular FTP
All Tahoe-LAFS client nodes can run a frontend FTP server, allowing regular FTP
clients (like /usr/bin/ftp, ncftp, and countless others) to access the
virtual filesystem. They can also run an SFTP server, so SFTP clients (like
/usr/bin/sftp, the sshfs FUSE plugin, and others) can too. These frontends
sit at the same level as the webapi interface.
Since Tahoe does not use user accounts or passwords, the FTP/SFTP servers
Since Tahoe-LAFS does not use user accounts or passwords, the FTP/SFTP servers
must be configured with a way to first authenticate a user (confirm that a
prospective client has a legitimate claim to whatever authorities we might
grant a particular user), and second to decide what root directory cap should
@ -43,7 +43,7 @@ be granted to the authenticated username. A username and password is used
for this purpose. (The SFTP protocol is also capable of using client
RSA or DSA public keys, but this is not currently implemented.)
Tahoe provides two mechanisms to perform this user-to-rootcap mapping. The
Tahoe-LAFS provides two mechanisms to perform this user-to-rootcap mapping. The
first is a simple flat file with one account per line. The second is an
HTTP-based login mechanism, backed by simple PHP script and a database. The
latter form is used by allmydata.com to provide secure access to customer
@ -61,7 +61,7 @@ space-separated line of (USERNAME, PASSWORD, ROOTCAP), like so:
alice password URI:DIR2:ioej8xmzrwilg772gzj4fhdg7a:wtiizszzz2rgmczv4wl6bqvbv33ag4kvbr6prz3u6w3geixa6m6a
bob sekrit URI:DIR2:6bdmeitystckbl9yqlw7g56f4e:serp5ioqxnh34mlbmzwvkp3odehsyrr7eytt5f64we3k9hhcrcja
Future versions of Tahoe may support using client public keys for SFTP.
Future versions of Tahoe-LAFS may support using client public keys for SFTP.
The words "ssh-rsa" and "ssh-dsa" after the username are reserved to specify
the public key format, so users cannot have a password equal to either of
these strings.
@ -103,7 +103,7 @@ accept connections from localhost.
== Configuring SFTP Access ==
The Tahoe SFTP server requires a host keypair, just like the regular SSH
The Tahoe-LAFS SFTP server requires a host keypair, just like the regular SSH
server. It is important to give each server a distinct keypair, to prevent
one server from masquerading as different one. The first time a client
program talks to a given server, it will store the host key it receives, and
@ -163,13 +163,13 @@ clients and with the sshfs filesystem, see
== Dependencies ==
The Tahoe SFTP server requires the Twisted "Conch" component (a "conch" is a
The Tahoe-LAFS SFTP server requires the Twisted "Conch" component (a "conch" is a
twisted shell, get it?). Many Linux distributions package the Conch code
separately: debian puts it in the "python-twisted-conch" package. Conch
requires the "pycrypto" package, which is a Python+C implementation of many
cryptographic functions (the debian package is named "python-crypto").
Note that "pycrypto" is different than the "pycryptopp" package that Tahoe
Note that "pycrypto" is different than the "pycryptopp" package that Tahoe-LAFS
uses (which is a Python wrapper around the C++ -based Crypto++ library, a
library that is frequently installed as /usr/lib/libcryptopp.a, to avoid
problems with non-alphanumerics in filenames).
@ -177,9 +177,9 @@ problems with non-alphanumerics in filenames).
The FTP server requires code in Twisted that enables asynchronous closing of
file-upload operations. This code was landed to Twisted's SVN trunk in r28453
on 23-Feb-2010, slightly too late for the Twisted-10.0 release, but it should
be present in the next release after that. To use Tahoe's FTP server with
be present in the next release after that. To use Tahoe-LAFS's FTP server with
Twisted-10.0 or earlier, you will need to apply the patch attached to
http://twistedmatrix.com/trac/ticket/3462 . The Tahoe node will refuse to
http://twistedmatrix.com/trac/ticket/3462 . The Tahoe-LAFS node will refuse to
start the FTP server unless it detects the necessary support code in Twisted.
This patch is not needed for SFTP.

View File

@ -2,7 +2,9 @@
The Tahoe-LAFS team is pleased to announce the immediate
availability of version 1.8.0c4 of Tahoe-LAFS, an extremely
reliable distributed storage system.
reliable distributed storage system. Get it here:
http://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.html
Tahoe-LAFS is the first distributed storage system which
offers "provider-independent security"—meaning that not even