From: Zooko O'Whielacronx Date: Sun, 19 Sep 2010 01:16:36 +0000 (-0700) Subject: docs: a few simple updates to links and naming, and also recommend torsocks instead... X-Git-Tag: allmydata-tahoe-1.8.0~13 X-Git-Url: https://git.rkrishnan.org/%5B/%5D%20/webapi.txt?a=commitdiff_plain;h=6eba4a2f8c3aa47f84894134f602ddb8ccc1a78c;p=tahoe-lafs%2Ftahoe-lafs.git docs: a few simple updates to links and naming, and also recommend torsocks instead of the old, unmaintained tsocks, for use with Tor --- diff --git a/docs/about.html b/docs/about.html index 6df6610d..bf1cd7de 100644 --- a/docs/about.html +++ b/docs/about.html @@ -31,7 +31,7 @@

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).

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.

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.

-

For more technical detail, please see architecture.txt and the The Doc Page on the Wiki.

+

For more technical detail, please see the The Doc Page on the Wiki.

Get Started

To use Tahoe-LAFS, please see quickstart.html.

diff --git a/docs/configuration.txt b/docs/configuration.txt index 5428252a..7f9d531d 100644 --- a/docs/configuration.txt +++ b/docs/configuration.txt @@ -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: diff --git a/docs/frontends/FTP-and-SFTP.txt b/docs/frontends/FTP-and-SFTP.txt index 883e660e..8facc09e 100644 --- a/docs/frontends/FTP-and-SFTP.txt +++ b/docs/frontends/FTP-and-SFTP.txt @@ -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. diff --git a/relnotes.txt b/relnotes.txt index faa29f97..6848e56d 100644 --- a/relnotes.txt +++ b/relnotes.txt @@ -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