From: Zooko Wilcox-O'Hearn <zooko@zooko.com> Date: Mon, 11 Nov 2013 22:04:11 +0000 (+0000) Subject: fix warnings from rst2html X-Git-Tag: allmydata-tahoe-1.10.1a1~208^2~2 X-Git-Url: https://git.rkrishnan.org/Site/Content/Exhibitors/install.html?a=commitdiff_plain;h=0bebbe3290614dcb26be2de1c0e9edc3951ac137;p=tahoe-lafs%2Ftahoe-lafs.git fix warnings from rst2html Apparently the in-line link syntax with "<>" in them causes these warnings. I don't know why. I changed them all to a slightly more verbose syntax. Thanks to Mike Kazantzsev's review comment (https://github.com/tahoe-lafs/tahoe-lafs/pull/67#commitcomment-4561370), I moved the links to the end of each section. --- diff --git a/docs/architecture.rst b/docs/architecture.rst index 98c70faa..88eb1f09 100644 --- a/docs/architecture.rst +++ b/docs/architecture.rst @@ -20,7 +20,7 @@ Tahoe-LAFS Architecture Overview ======== -(See the `docs/specifications directory <specifications>`_ for more details.) +(See the `docs/specifications directory`_ for more details.) There are three layers: the key-value store, the filesystem, and the application. @@ -45,10 +45,10 @@ Allmydata.com used it for a backup service: the application periodically copies files from the local disk onto the decentralized filesystem. We later provide read-only access to those files, allowing users to recover them. There are several other applications built on top of the Tahoe-LAFS -filesystem (see the `RelatedProjects -<https://tahoe-lafs.org/trac/tahoe-lafs/wiki/RelatedProjects>`_ page of the -wiki for a list). +filesystem (see the RelatedProjects_ page of the wiki for a list). +.. _docs/specifications directory: specifications +.. _RelatedProjects: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/RelatedProjects The Key-Value Store =================== @@ -316,7 +316,9 @@ commercially-run grid for which all of the storage servers are in a colo facility with high interconnect bandwidth. In this case, the helper is placed in the same facility, so the helper-to-storage-server bandwidth is huge. -See `<helper.rst>`_ for details about the upload helper. +See helper.rst_ for details about the upload helper. + +.. _helper.rst: helper.rst The Filesystem Layer @@ -368,8 +370,10 @@ clients are responsible for renewing their leases on a periodic basis at least frequently enough to prevent any of the leases from expiring before the next renewal pass. -See `<garbage-collection.rst>`_ for further information, and for how to -configure garbage collection. +See garbage-collection.rst_ for further information, and for how to configure +garbage collection. + +.. _garbage-collection.rst: garbage-collection.rst File Repairer diff --git a/docs/configuration.rst b/docs/configuration.rst index a0022df6..26d8c58b 100644 --- a/docs/configuration.rst +++ b/docs/configuration.rst @@ -45,16 +45,17 @@ The item descriptions below use the following types: a Twisted listening-port specification string, like "``tcp:80``" or "``tcp:3456:interface=127.0.0.1``". For a full description of the format, - see `the Twisted strports documentation - <https://twistedmatrix.com/documents/current/api/twisted.application.strports.html>`_. - Please note, if interface= is not specified, Tahoe-LAFS will attempt to - bind the port specified on all interfaces. + see `the Twisted strports documentation`_. Please note, if interface= is + not specified, Tahoe-LAFS will attempt to bind the port specified on all + interfaces. ``FURL string`` a Foolscap endpoint identifier, like ``pb://soklj4y7eok5c3xkmjeqpw@192.168.69.247:44801/eqpwqtzm`` +.. _the Twisted strports documentation: https://twistedmatrix.com/documents/current/api/twisted.application.strports.html + Node Types ========== @@ -103,7 +104,7 @@ set the ``tub.location`` option described below. This controls where the node's web server should listen, providing node status and, if the node is a client/server, providing web-API service as - defined in `webapi.rst <frontends/webapi.rst>_`. + defined in webapi.rst_. This file contains a Twisted "strports" specification such as "``3456``" or "``tcp:3456:interface=127.0.0.1``". The "``tahoe create-node``" or @@ -286,6 +287,8 @@ set the ``tub.location`` option described below. used for files that usually (on a Unix system) go into ``/tmp``. The string will be interpreted relative to the node's base directory. +.. _webapi.rst: frontends/webapi.rst + Client Configuration ==================== @@ -303,7 +306,7 @@ Client Configuration ``helper.furl = (FURL string, optional)`` If provided, the node will attempt to connect to and use the given helper - for uploads. See `<helper.rst>`_ for details. + for uploads. See helper.rst_ for details. ``key_generator.furl = (FURL string, optional)`` @@ -339,7 +342,7 @@ Client Configuration ratios are more reliable, and small ``N``/``k`` ratios use less disk space. ``N`` cannot be larger than 256, because of the 8-bit erasure-coding algorithm that Tahoe-LAFS uses. ``k`` can not be greater - than ``N``. See `<performance.rst>`_ for more details. + than ``N``. See performance.rst_ for more details. ``shares.happy`` allows you control over how well to "spread out" the shares of an immutable file. For a successful upload, shares are @@ -377,8 +380,11 @@ Client Configuration controlled by this parameter and will always use SDMF. We may revisit this decision in future versions of Tahoe-LAFS. - See `<specifications/mutable.rst>`_ for details about mutable file - formats. + See mutable.rst_ for details about mutable file formats. + +.. _helper.rst: helper.rst +.. _performance.rst: performance.rst +.. _mutable.rst: specifications/mutable.rst Frontend Configuration ====================== @@ -395,30 +401,33 @@ HTTP directories and files, as well as a number of pages to check on the status of your Tahoe node. It also provides a machine-oriented "WAPI", with a REST-ful HTTP interface that can be used by other programs - (including the CLI tools). Please see `<frontends/webapi.rst>`_ for full - details, and the ``web.port`` and ``web.static`` config variables above. - The `<frontends/download-status.rst>`_ document also describes a few WUI - status pages. + (including the CLI tools). Please see webapi.rst_ for full details, and + the ``web.port`` and ``web.static`` config variables above. The + `download-status.rst`_ document also describes a few WUI status pages. CLI The main "bin/tahoe" executable includes subcommands for manipulating the filesystem, uploading/downloading files, and creating/running Tahoe - nodes. See `<frontends/CLI.rst>`_ for details. + nodes. See CLI.rst_ for details. SFTP, FTP Tahoe can also run both SFTP and FTP servers, and map a username/password - pair to a top-level Tahoe directory. See `<frontends/FTP-and-SFTP.rst>`_ - for instructions on configuring these services, and the ``[sftpd]`` and + pair to a top-level Tahoe directory. See FTP-and-SFTP.rst_ for + instructions on configuring these services, and the ``[sftpd]`` and ``[ftpd]`` sections of ``tahoe.cfg``. Drop-Upload As of Tahoe-LAFS v1.9.0, a node running on Linux can be configured to automatically upload files that are created or changed in a specified - local directory. See `<frontends/drop-upload.rst>`_ for details. + local directory. See drop-upload.rst_ for details. +.. _download-status.rst: frontends/download-status.rst +.. _CLI.rst: frontends/CLI.rst +.. _FTP-and-SFTP.rst: frontends/FTP-and-SFTP.rst +.. _drop-upload.rst: frontends/drop-upload.rst Storage Server Configuration @@ -441,9 +450,8 @@ Storage Server Configuration that are being decommissioned: the ``storage/`` directory could be mounted read-only, while shares are moved to other servers. Note that this currently only affects immutable shares. Mutable shares (used for - directories) will be written and modified anyway. See ticket `#390 - <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/390>`_ for the current - status of this bug. The default value is ``False``. + directories) will be written and modified anyway. See ticket `#390`_ for + the current status of this bug. The default value is ``False``. ``reserved_space = (str, optional)`` @@ -479,7 +487,10 @@ Storage Server Configuration These settings control garbage collection, in which the server will delete shares that no longer have an up-to-date lease on them. Please see - `<garbage-collection.rst>`_ for full details. + garbage-collection.rst_ for full details. + +.. _#390: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/390 +.. _garbage-collection.rst: garbage-collection.rst Running A Helper @@ -492,12 +503,12 @@ service. ``enabled = (boolean, optional)`` - If ``True``, the node will run a helper (see `<helper.rst>`_ for - details). The helper's contact FURL will be placed in - ``private/helper.furl``, from which it can be copied to any clients that - wish to use it. Clearly nodes should not both run a helper and attempt to - use one: do not create ``helper.furl`` and also define - ``[helper]enabled`` in the same node. The default is ``False``. + If ``True``, the node will run a helper (see helper.rst_ for details). + The helper's contact FURL will be placed in ``private/helper.furl``, from + which it can be copied to any clients that wish to use it. Clearly nodes + should not both run a helper and attempt to use one: do not create + ``helper.furl`` and also define ``[helper]enabled`` in the same node. + The default is ``False``. Running An Introducer @@ -588,7 +599,7 @@ This section describes these other files. ``private/helper.furl`` If the node is running a helper (for use by other clients), its contact - FURL will be placed here. See `<helper.rst>`_ for more details. + FURL will be placed here. See helper.rst_ for more details. ``private/root_dir.cap`` (optional) @@ -650,7 +661,7 @@ Other files files. The web-API has a facility to block access to filecaps by their storage index, returning a 403 "Forbidden" error instead of the original file. For more details, see the "Access Blacklist" section of - `<frontends/webapi.rst>`_. + webapi.rst_. Example @@ -693,4 +704,6 @@ Old Configuration Files Tahoe-LAFS releases before v1.3.0 had no ``tahoe.cfg`` file, and used distinct files for each item. This is no longer supported and if you have configuration in the old format you must manually convert it to the new -format for Tahoe-LAFS to detect it. See `<historical/configuration.rst>`_. +format for Tahoe-LAFS to detect it. See `historical/configuration.rst`_. + +.. _historical/configuration.rst: historical/configuration.rst diff --git a/docs/filesystem-notes.rst b/docs/filesystem-notes.rst index 9c019fbb..939270e2 100644 --- a/docs/filesystem-notes.rst +++ b/docs/filesystem-notes.rst @@ -23,4 +23,6 @@ automatically, but older filesystems may not have it enabled:: If "dir_index" is present in the "features:" line, then you're all set. If not, you'll need to use tune2fs and e2fsck to enable and build the index. See -`<http://wiki.dovecot.org/MailboxFormat/Maildir>`_ for some hints. +`http://wiki.dovecot.org/MailboxFormat/Maildir`_ for some hints. + +.. _`http://wiki.dovecot.org/MailboxFormat/Maildir`: http://wiki.dovecot.org/MailboxFormat/Maildir diff --git a/docs/frontends/drop-upload.rst b/docs/frontends/drop-upload.rst index 8d92052c..bc92609b 100644 --- a/docs/frontends/drop-upload.rst +++ b/docs/frontends/drop-upload.rst @@ -133,10 +133,9 @@ of the same name in the upload directory, it will be unlinked and replaced with an immutable file. (`#1712`_) If a file in the upload directory is changed (actually relinked to a new -file), then the old file is still present on the grid, and any other caps -to it will remain valid. See `docs/garbage-collection.rst -<../garbage-collection.rst>`_ for how to reclaim the space used by files -that are no longer needed. +file), then the old file is still present on the grid, and any other caps to +it will remain valid. See `docs/garbage-collection.rst`_ for how to reclaim +the space used by files that are no longer needed. Unicode names are supported, but the local name of a file must be encoded correctly in order for it to be uploaded. The expected encoding is that @@ -154,3 +153,6 @@ printed by ``python -c "import sys; print sys.getfilesystemencoding()"``. .. _`#1710`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1710 .. _`#1711`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1711 .. _`#1712`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1712 + +.. _docs/garbage-collection.rst: ../garbage-collection.rst + diff --git a/docs/frontends/webapi.rst b/docs/frontends/webapi.rst index 1d3b33c6..b54ad91f 100644 --- a/docs/frontends/webapi.rst +++ b/docs/frontends/webapi.rst @@ -54,8 +54,7 @@ section of $NODEDIR/tahoe.cfg will cause the node to run a webserver on port This string is actually a Twisted "strports" specification, meaning you can get more control over the interface to which the server binds by supplying additional arguments. For more details, see the documentation on -`twisted.application.strports -<https://twistedmatrix.com/documents/current/api/twisted.application.strports.html>`_. +`twisted.application.strports`_. Writing "tcp:3456:interface=127.0.0.1" into the web.port line does the same but binds to the loopback interface, ensuring that only the programs on the @@ -66,18 +65,19 @@ This webport can be set when the node is created by passing a --webport option to the 'tahoe create-node' command. By default, the node listens on port 3456, on the loopback (127.0.0.1) interface. +.. _twisted.application.strports: https://twistedmatrix.com/documents/current/api/twisted.application.strports.html + Basic Concepts: GET, PUT, DELETE, POST ====================================== -As described in `docs/architecture.rst <../architecture.rst>`_, each file -and directory in a Tahoe virtual filesystem is referenced by an identifier -that combines the designation of the object with the authority to do something -with it (such as read or modify the contents). This identifier is called a -"read-cap" or "write-cap", depending upon whether it enables read-only or -read-write access. These "caps" are also referred to as URIs (which may be -confusing because they are not currently `RFC3986 -<https://tools.ietf.org/html/rfc3986>`_-compliant URIs). +As described in `docs/architecture.rst`_, each file and directory in a Tahoe +virtual filesystem is referenced by an identifier that combines the +designation of the object with the authority to do something with it (such as +read or modify the contents). This identifier is called a "read-cap" or +"write-cap", depending upon whether it enables read-only or read-write +access. These "caps" are also referred to as URIs (which may be confusing +because they are not currently RFC3986_-compliant URIs). The Tahoe web-based API is "REST-ful", meaning it implements the concepts of "REpresentational State Transfer": the original scheme by which the World @@ -127,6 +127,9 @@ a plain text stack trace instead. If the Accept header contains ``*/*``, or ``text/*``, or text/html (or if there is no Accept header), HTML tracebacks will be generated. +.. _RFC3986: https://tools.ietf.org/html/rfc3986 +.. _docs/architecture.rst: ../architecture.rst + URLs ==== @@ -501,9 +504,9 @@ Creating a New Directory The metadata may have a "no-write" field. If this is set to true in the metadata of a link, it will not be possible to open that link for writing - via the SFTP frontend; see `<FTP-and-SFTP.rst>`_ for details. - Also, if the "no-write" field is set to true in the metadata of a link to - a mutable child, it will cause the link to be diminished to read-only. + via the SFTP frontend; see FTP-and-SFTP.rst_ for details. Also, if the + "no-write" field is set to true in the metadata of a link to a mutable + child, it will cause the link to be diminished to read-only. Note that the web-API-using client application must not provide the "Content-Type: multipart/form-data" header that usually accompanies HTML @@ -660,6 +663,8 @@ Creating a New Directory This operation will return an error if the parent directory is immutable, or already has a child named NAME. +.. _FTP-and-SFTP.rst: FTP-and-SFTP.rst + Getting Information About a File Or Directory (as JSON) ------------------------------------------------------- @@ -2070,7 +2075,9 @@ Tahoe-1.1; back with Tahoe-1.0 the web client was responsible for serializing web requests themselves). For more details, please see the "Consistency vs Availability" and "The Prime -Coordination Directive" sections of `mutable.rst <../specifications/mutable.rst>`_. +Coordination Directive" sections of mutable.rst_. + +.. _mutable.rst: ../specifications/mutable.rst Access Blacklist @@ -2121,19 +2128,18 @@ the ``logs/twistd.log`` file. .. [1] URLs and HTTP and UTF-8, Oh My HTTP does not provide a mechanism to specify the character set used to - encode non-ASCII names in URLs - (`RFC3986#2.1 <https://tools.ietf.org/html/rfc3986#section-2.1>`_). - We prefer the convention that the ``filename=`` argument shall be a - URL-escaped UTF-8 encoded Unicode string. - For example, suppose we want to provoke the server into using a filename of - "f i a n c e-acute e" (i.e. f i a n c U+00E9 e). The UTF-8 encoding of this - is 0x66 0x69 0x61 0x6e 0x63 0xc3 0xa9 0x65 (or "fianc\\xC3\\xA9e", as python's - ``repr()`` function would show). To encode this into a URL, the non-printable - characters must be escaped with the urlencode ``%XX`` mechanism, giving - us "fianc%C3%A9e". Thus, the first line of the HTTP request will be - "``GET /uri/CAP...?save=true&filename=fianc%C3%A9e HTTP/1.1``". Not all - browsers provide this: IE7 by default uses the Latin-1 encoding, which is - "fianc%E9e" (although it has a configuration option to send URLs as UTF-8). + encode non-ASCII names in URLs (`RFC3986#2.1`_). We prefer the convention + that the ``filename=`` argument shall be a URL-escaped UTF-8 encoded Unicode + string. For example, suppose we want to provoke the server into using a + filename of "f i a n c e-acute e" (i.e. f i a n c U+00E9 e). The UTF-8 + encoding of this is 0x66 0x69 0x61 0x6e 0x63 0xc3 0xa9 0x65 (or + "fianc\\xC3\\xA9e", as python's ``repr()`` function would show). To encode + this into a URL, the non-printable characters must be escaped with the + urlencode ``%XX`` mechanism, giving us "fianc%C3%A9e". Thus, the first line + of the HTTP request will be "``GET + /uri/CAP...?save=true&filename=fianc%C3%A9e HTTP/1.1``". Not all browsers + provide this: IE7 by default uses the Latin-1 encoding, which is "fianc%E9e" + (although it has a configuration option to send URLs as UTF-8). The response header will need to indicate a non-ASCII filename. The actual mechanism to do this is not clear. For ASCII filenames, the response header @@ -2150,17 +2156,15 @@ the ``logs/twistd.log`` file. (note, the last four bytes of that line, not including the newline, are 0xC3 0xA9 0x65 0x22) - `RFC2231#4 <https://tools.ietf.org/html/rfc2231#section-4>`_ - (dated 1997): suggests that the following might work, and - `some developers have reported <http://markmail.org/message/dsjyokgl7hv64ig3>`_ - that it is supported by Firefox (but not IE7):: + `RFC2231#4`_ (dated 1997): suggests that the following might work, and `some + developers have reported`_ that it is supported by Firefox (but not IE7):: #2: Content-Disposition: attachment; filename*=utf-8''fianc%C3%A9e - My reading of `RFC2616#19.5.1 <https://tools.ietf.org/html/rfc2616#section-19.5.1>`_ - (which defines Content-Disposition) says that the filename= parameter is - defined to be wrapped in quotes (presumably to allow spaces without breaking - the parsing of subsequent parameters), which would give us:: + My reading of `RFC2616#19.5.1`_ (which defines Content-Disposition) says + that the filename= parameter is defined to be wrapped in quotes (presumably + to allow spaces without breaking the parsing of subsequent parameters), + which would give us:: #3: Content-Disposition: attachment; filename*=utf-8''"fianc%C3%A9e" @@ -2175,3 +2179,9 @@ the ``logs/twistd.log`` file. into the response header, rather than enforcing the UTF-8 convention. This means it does not try to decode the filename from the URL argument, nor does it encode the filename into the response header. + +.. _RFC3986#2.1: https://tools.ietf.org/html/rfc3986#section-2.1 +.. _RFC2231#4: https://tools.ietf.org/html/rfc2231#section-4 +.. _some developers have reported: http://markmail.org/message/dsjyokgl7hv64ig3 +.. _RFC2616#19.5.1: https://tools.ietf.org/html/rfc2616#section-19.5.1 + diff --git a/docs/garbage-collection.rst b/docs/garbage-collection.rst index 716dcdc2..ad61d231 100644 --- a/docs/garbage-collection.rst +++ b/docs/garbage-collection.rst @@ -30,7 +30,7 @@ next renewal pass. There are several tradeoffs to be considered when choosing the renewal timer and the lease duration, and there is no single optimal pair of values. See -the `<lease-tradeoffs.svg>`_ diagram to get an idea for the tradeoffs involved. +the lease-tradeoffs.svg_ diagram to get an idea for the tradeoffs involved. If lease renewal occurs quickly and with 100% reliability, than any renewal time that is shorter than the lease duration will suffice, but a larger ratio of duration-over-renewal-time will be more robust in the face of occasional @@ -46,6 +46,9 @@ processed) to something other than 31 days. Renewing leases can be expected to take about one second per file/directory, depending upon the number of servers and the network speeds involved. +.. _lease-tradeoffs.svg: lease-tradeoffs.svg + + Client-side Renewal =================== @@ -69,12 +72,14 @@ lease too: the ``--add-lease`` process is only needed to ensure that all older objects have up-to-date leases on them. A separate "rebalancing manager/service" is also planned -- see ticket -`#543 <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/543>`_. The exact -details of what this service will do are not settled, but it is likely to -work by acquiring manifests from rootcaps on a periodic basis, keeping track -of checker results, managing lease-addition, and prioritizing repair and -rebalancing of shares. Eventually it may use multiple worker nodes to perform -these jobs in parallel. +`#543`_. The exact details of what this service will do are not settled, but +it is likely to work by acquiring manifests from rootcaps on a periodic +basis, keeping track of checker results, managing lease-addition, and +prioritizing repair and rebalancing of shares. Eventually it may use multiple +worker nodes to perform these jobs in parallel. + +.. _#543: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/543 + Server Side Expiration ====================== diff --git a/docs/running.rst b/docs/running.rst index 0d3836e6..b2734f97 100644 --- a/docs/running.rst +++ b/docs/running.rst @@ -9,7 +9,7 @@ Intro This is how to run a Tahoe-LAFS client or a complete Tahoe-LAFS grid. First you have to install the Tahoe-LAFS software, as documented in -`quickstart.rst <quickstart.rst>`_. +quickstart.rst_. The ``tahoe`` program in the ``bin`` directory is used to create, start, and stop nodes. Each node lives in a separate base directory, in @@ -20,30 +20,26 @@ A grid consists of a set of *storage nodes* and *client nodes* running the Tahoe-LAFS code. There is also an *introducer node* that is responsible for getting the other nodes talking to each other. -If you're getting started we recommend you try connecting to -the `public test grid -<https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TestGrid>`_ as you only -need to create a client node. When you want to create your own grid -you'll need to create the introducer and several initial storage nodes -(see the note about small grids below). +If you're getting started we recommend you try connecting to the `public test +grid`_ as you only need to create a client node. When you want to create your +own grid you'll need to create the introducer and several initial storage +nodes (see the note about small grids below). If the Tahoe-LAFS ``bin`` directory is not on your PATH, then in all the command lines below, specify the full path to ``bin/tahoe``. -To construct a client node, run "``tahoe create-client``", which will -create ``~/.tahoe`` to be the node's base directory. Acquire the -``introducer.furl`` (see below if you are running your own introducer, -or use the one from the `TestGrid page -<https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TestGrid>`_), and paste it -after ``introducer.furl =`` in the ``[client]`` section of -``~/.tahoe/tahoe.cfg``. Then use "``tahoe run ~/.tahoe``". After that, -the node should be off and running. The first thing it will do is -connect to the introducer and get itself connected to all other nodes -on the grid. +To construct a client node, run "``tahoe create-client``", which will create +``~/.tahoe`` to be the node's base directory. Acquire the ``introducer.furl`` +(see below if you are running your own introducer, or use the one from the +`TestGrid page`_), and paste it after ``introducer.furl =`` in the +``[client]`` section of ``~/.tahoe/tahoe.cfg``. Then use "``tahoe run +~/.tahoe``". After that, the node should be off and running. The first thing +it will do is connect to the introducer and get itself connected to all other +nodes on the grid. By default, "``tahoe create-client``" creates a client-only node, that does not offer its disk space to other nodes. To configure other behavior, -use "``tahoe create-node``" or see `configuration.rst <configuration.rst>`_. +use "``tahoe create-node``" or see configuration.rst_. To construct an introducer, create a new base directory for it (the name of the directory is up to you), ``cd`` into it, and run @@ -52,28 +48,34 @@ name of the directory is up to you), ``cd`` into it, and run ``introducer.furl`` into the ``private/`` subdirectory of that base directory. This file contains the URL the other nodes must use in order to connect to this introducer. (Note that "``tahoe run .``" doesn't -work for introducers, this is a known issue: `#937 -<http://allmydata.org/trac/tahoe-lafs/ticket/937>`_.) +work for introducers, this is a known issue: `#937`_.) The "``tahoe run``" command above will run the node in the foreground. On Unix, you can run it in the background instead by using the "``tahoe start``" command. To stop a node started in this way, use "``tahoe stop``". ``tahoe --help`` gives a summary of all commands. -See `configuration.rst <configuration.rst>`_ for more details about how -to configure Tahoe-LAFS, including how to get other clients to connect -to your node if it is behind a firewall or NAT device. +See configuration.rst_ for more details about how to configure Tahoe-LAFS, +including how to get other clients to connect to your node if it is behind a +firewall or NAT device. + +.. _quickstart.rst: quickstart.rst +.. _public test grid: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TestGrid +.. _TestGrid page: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TestGrid +.. _configuration.rst: configuration.rst +.. _#937: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/937 + A note about small grids ------------------------ By default, Tahoe-LAFS ships with the configuration parameter -``shares.happy`` set to 7. If you are using Tahoe-LAFS on a -grid with fewer than 7 storage nodes, this won't work well for -you -- none of your uploads will succeed. To fix this, see -`configuration.rst <configuration.rst>`_ to learn how to set +``shares.happy`` set to 7. If you are using Tahoe-LAFS on a grid with fewer +than 7 storage nodes, this won't work well for you -- none of your uploads +will succeed. To fix this, see configuration.rst_ to learn how to set ``shares.happy`` to a more suitable value for your grid. + Do Stuff With It ================ @@ -82,9 +84,8 @@ This is how to use your Tahoe-LAFS node. The WUI ------- -Point your web browser to `http://127.0.0.1:3456 -<http://127.0.0.1:3456>`_ -- which is the URL of the gateway running on -your own local computer -- to use your newly created node. +Point your web browser to `http://127.0.0.1:3456`_ -- which is the URL of the +gateway running on your own local computer -- to use your newly created node. Create a new directory (with the button labelled "create a directory"). Your web browser will load the new directory. Now if you want to be @@ -95,48 +96,60 @@ then you can never again come back to this directory. You can do more or less everything you want to do with a decentralized filesystem through the WUI. +.. _http://127.0.0.1:3456: http://127.0.0.1:3456 + + The CLI ------- -Prefer the command-line? Run "``tahoe --help``" (the same command-line -tool that is used to start and stop nodes serves to navigate and use -the decentralized filesystem). To get started, create a new directory -and mark it as the 'tahoe:' alias by running -"``tahoe create-alias tahoe``". Once you've done that, you can do -"``tahoe ls tahoe:``" and "``tahoe cp LOCALFILE tahoe:foo.txt``" to -work with your filesystem. The Tahoe-LAFS CLI uses similar syntax to -the well-known scp and rsync tools. See `CLI.rst <frontends/CLI.rst>`_ -for more details. +Prefer the command-line? Run "``tahoe --help``" (the same command-line tool +that is used to start and stop nodes serves to navigate and use the +decentralized filesystem). To get started, create a new directory and mark it +as the 'tahoe:' alias by running "``tahoe create-alias tahoe``". Once you've +done that, you can do "``tahoe ls tahoe:``" and "``tahoe cp LOCALFILE +tahoe:foo.txt``" to work with your filesystem. The Tahoe-LAFS CLI uses +similar syntax to the well-known scp and rsync tools. See CLI.rst_ for more +details. As with the WUI (and with all current interfaces to Tahoe-LAFS), you are responsible for remembering directory capabilities yourself. If you create a new directory and lose the capability to it, then you cannot access that directory ever again. +.. _CLI.rst: frontends/CLI.rst + + The SFTP and FTP frontends -------------------------- -You can access your Tahoe-LAFS grid via any `SFTP -<http://en.wikipedia.org/wiki/SSH_file_transfer_protocol>`_ or `FTP -<http://en.wikipedia.org/wiki/File_Transfer_Protocol>`_ client. -See `FTP-and-SFTP.rst <frontends/FTP-and-SFTP.rst>`_ for how to set +You can access your Tahoe-LAFS grid via any SFTP_ or FTP_ client. +See `FTP-and-SFTP.rst`_ for how to set this up. On most Unix platforms, you can also use SFTP to plug Tahoe-LAFS into your computer's local filesystem via ``sshfs``. -The `SftpFrontend -<https://tahoe-lafs.org/trac/tahoe-lafs/wiki/SftpFrontend>`_ page on the -wiki has more information about using SFTP with Tahoe-LAFS. +The SftpFrontend_ page on the wiki has more information about using SFTP with +Tahoe-LAFS. + +.. _SFTP: https://en.wikipedia.org/wiki/SSH_file_transfer_protocol +.. _FTP: http://en.wikipedia.org/wiki/File_Transfer_Protocol +.. _FTP-and-SFTP.rst: frontends/FTP-and-SFTP.rst +.. _SftpFrontend: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/SftpFrontend + The WAPI -------- Want to program your Tahoe-LAFS node to do your bidding? Easy! See -`webapi.rst <frontends/webapi.rst>`_. +webapi.rst_. + +.. _webapi.rst: frontends/webapi.rst + Socialize ========= You can chat with other users of and hackers of this software on the -#tahoe-lafs IRC channel at ``irc.freenode.net``, or on the `tahoe-dev -mailing list -<https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev>`_. +#tahoe-lafs IRC channel at ``irc.freenode.net``, or on the `tahoe-dev mailing +list`_. + +.. _tahoe-dev mailing list: https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev diff --git a/docs/specifications/dirnodes.rst b/docs/specifications/dirnodes.rst index 4ea3ae48..9741be38 100644 --- a/docs/specifications/dirnodes.rst +++ b/docs/specifications/dirnodes.rst @@ -102,7 +102,7 @@ just a special way of interpreting the contents of a specific mutable file. Earlier releases used a "vdrive server": this server was abolished in the v0.7.0 release. -For details of how mutable files work, please see `<mutable.rst>`_ in this +For details of how mutable files work, please see mutable.rst_ in this directory. For releases since v0.7.0, we achieve most of our desired properties. The @@ -124,13 +124,15 @@ multiple versions of each mutable file, and you might have some shares of version 1 and other shares of version 2). In extreme cases of simultaneous update, mutable files might suffer from non-monotonicity. +.. _mutable.rst: mutable.rst + Dirnode secret values ===================== As mentioned before, dirnodes are simply a special way to interpret the contents of a mutable file, so the secret keys and capability strings -described in `<mutable.rst>`_ are all the same. Each dirnode contains an RSA +described in mutable.rst_ are all the same. Each dirnode contains an RSA public/private keypair, and the holder of the "write capability" will be able to retrieve the private key (as well as the AES encryption key used for the data itself). The holder of the "read capability" will be able to obtain the diff --git a/docs/specifications/file-encoding.rst b/docs/specifications/file-encoding.rst index b11ef329..571714d7 100644 --- a/docs/specifications/file-encoding.rst +++ b/docs/specifications/file-encoding.rst @@ -129,6 +129,7 @@ delivered to the user. .. image:: file-encoding6.svg + Hashes ====== @@ -145,8 +146,9 @@ Using SHA-256d (instead of plain SHA-256) guards against length-extension attacks. Using the tag protects our Merkle trees against attacks in which the hash of a leaf is confused with a hash of two children (allowing an attacker to generate corrupted data that nevertheless appears to be valid), and is -simply good "cryptograhic hygiene". The `"Chosen Protocol Attack" by Kelsey, -Schneier, and Wagner <http://www.schneier.com/paper-chosen-protocol.html>`_ is -relevant. Putting the tag in a netstring guards against attacks that seek to -confuse the end of the tag with the beginning of the subsequent value. +simply good "cryptograhic hygiene". The `âChosen Protocol Attackâ by Kelsey, +Schneier, and Wagner`_ is relevant. Putting the tag in a netstring guards +against attacks that seek to confuse the end of the tag with the beginning of +the subsequent value. +.. _âChosen Protocol Attackâ by Kelsey, Schneier, and Wagner: http://www.schneier.com/paper-chosen-protocol.html diff --git a/docs/specifications/uri.rst b/docs/specifications/uri.rst index 1953a111..9e6d2336 100644 --- a/docs/specifications/uri.rst +++ b/docs/specifications/uri.rst @@ -85,7 +85,7 @@ representation of the size of the data represented by this URI. All base32 encodings are expressed in lower-case, with the trailing '=' signs removed. For example, the following is a CHK URI, generated from a previous version of -the contents of `<../architecture.rst>`_:: +the contents of architecture.rst_:: URI:CHK:ihrbeov7lbvoduupd4qblysj7a:bg5agsdt62jb34hxvxmdsbza6do64f4fg5anxxod2buttbo6udzq:3:10:28733 @@ -100,6 +100,9 @@ about the file's contents (except filesize), which improves privacy. The URI:CHK: prefix really indicates that an immutable file is in use, without saying anything about how the key was derived. +.. _architecture.rst: ../architecture.rst + + LIT URIs -------- @@ -143,7 +146,7 @@ The format of the write-cap for mutable files is:: Where (writekey) is the base32 encoding of the 16-byte AES encryption key that is used to encrypt the RSA private key, and (fingerprint) is the base32 encoded 32-byte SHA-256 hash of the RSA public key. For more details about -the way these keys are used, please see `<mutable.rst>`_. +the way these keys are used, please see mutable.rst_. The format for mutable read-caps is:: @@ -159,13 +162,16 @@ Historical note: the "SSK" prefix is a perhaps-inaccurate reference to "Sub-Space Keys" from the Freenet project, which uses a vaguely similar structure to provide mutable file access. +.. _mutable.rst: mutable.rst + + Directory URIs ============== The grid layer provides a mapping from URI to data. To turn this into a graph of directories and files, the "vdrive" layer (which sits on top of the grid layer) needs to keep track of "directory nodes", or "dirnodes" for short. -`<dirnodes.rst>`_ describes how these work. +dirnodes.rst_ describes how these work. Dirnodes are contained inside mutable files, and are thus simply a particular way to interpret the contents of these files. As a result, a directory @@ -181,6 +187,9 @@ directory) look much like mutable-file read-caps:: Historical note: the "DIR2" prefix is used because the non-distributed dirnodes in earlier Tahoe releases had already claimed the "DIR" prefix. +.. _dirnodes.rst: dirnodes.rst + + Internal Usage of URIs ====================== diff --git a/docs/stats.rst b/docs/stats.rst index 76310841..75799a4f 100644 --- a/docs/stats.rst +++ b/docs/stats.rst @@ -307,7 +307,9 @@ keep its FURL consistent). To explicitly control which port it uses, write the desired portnumber into a file named "portnum" (i.e. $BASEDIR/portnum), and the next time the gatherer is started, it will start listening on the given port. The portnum file is actually a "strports specification string", -as described in `docs/configuration.rst <configuration.rst>`_. +as described in configuration.rst_. + +.. _configuration.rst: configuration.rst Once running, the stats gatherer will create a standard python "pickle" file in $BASEDIR/stats.pickle . Once a minute, the gatherer will pull stats