1 =============================
2 Configuring a Tahoe-LAFS node
3 =============================
5 1. `Overall Node Configuration`_
6 2. `Client Configuration`_
7 3. `Storage Server Configuration`_
8 4. `Frontend Configuration`_
10 6. `Running An Introducer`_
11 7. `Other Files in BASEDIR`_
13 9. `Backwards Compatibility Files`_
16 A Tahoe-LAFS node is configured by writing to files in its base
17 directory. These files are read by the node when it starts, so each time you
18 change them, you need to restart the node.
20 The node also writes state to its base directory, so it will create files on
23 This document contains a complete list of the config files that are examined
24 by the client node, as well as the state files that you'll observe in its
27 The main file is named "``tahoe.cfg``", and is an ".INI"-style configuration
28 file (parsed by the Python stdlib 'ConfigParser' module: "``[name]``" section
29 markers, lines with "``key.subkey: value``", rfc822-style
30 continuations). There are also other files containing information that does
31 not easily fit into this format. The "``tahoe create-node``" or "``tahoe
32 create-client``" command will create an initial ``tahoe.cfg`` file for
33 you. After creation, the node will never modify the ``tahoe.cfg`` file: all
34 persistent state is put in other files.
36 The item descriptions below use the following types:
40 one of (True, yes, on, 1, False, off, no, 0), case-insensitive
44 a Twisted listening-port specification string, like "``tcp:80``" or
45 "``tcp:3456:interface=127.0.0.1``". For a full description of the format,
46 see `the Twisted strports documentation
47 <http://twistedmatrix.com/documents/current/api/twisted.application.strports.html>`_.
51 a Foolscap endpoint identifier, like
52 ``pb://soklj4y7eok5c3xkmjeqpw@192.168.69.247:44801/eqpwqtzm``
55 Overall Node Configuration
56 ==========================
58 This section controls the network behavior of the node overall: which ports
59 and IP addresses are used, when connections are timed out, etc. This
60 configuration is independent of the services that the node is offering: the
61 same controls are used for client and introducer nodes.
63 If your node is behind a firewall or NAT device and you want other clients to
64 connect to it, you'll need to open a port in the firewall or NAT, and specify
65 that port number in the tub.port option. If behind a NAT, you *may* need to
66 set the ``tub.location`` option described below.
70 ``nickname = (UTF-8 string, optional)``
72 This value will be displayed in management tools as this node's
73 "nickname". If not provided, the nickname will be set to "<unspecified>".
74 This string shall be a UTF-8 encoded Unicode string.
76 ``web.port = (strports string, optional)``
78 This controls where the node's webserver should listen, providing
79 filesystem access and node status as defined in `webapi.rst
80 <frontends/webapi.rst>`_. This file contains a Twisted "strports"
81 specification such as "``3456``" or "``tcp:3456:interface=127.0.0.1``".
82 The "``tahoe create-node``" or "``tahoe create-client``" commands set the
83 ``web.port`` to "``tcp:3456:interface=127.0.0.1``" by default; this is
84 overridable by the ``--webport`` option. You can make it use SSL by
85 writing "``ssl:3456:privateKey=mykey.pem:certKey=cert.pem``" instead.
87 If this is not provided, the node will not run a web server.
89 ``web.static = (string, optional)``
91 This controls where the ``/static`` portion of the URL space is
92 served. The value is a directory name (``~username`` is allowed, and
93 non-absolute names are interpreted relative to the node's basedir), which
94 can contain HTML and other files. This can be used to serve a
95 Javascript-based frontend to the Tahoe-LAFS node, or other services.
97 The default value is "``public_html``", which will serve
98 ``BASEDIR/public_html`` . With the default settings,
99 ``http://127.0.0.1:3456/static/foo.html`` will serve the contents of
100 ``BASEDIR/public_html/foo.html`` .
102 ``tub.port = (integer, optional)``
104 This controls which port the node uses to accept Foolscap connections
105 from other nodes. If not provided, the node will ask the kernel for any
106 available port. The port will be written to a separate file (named
107 ``client.port`` or ``introducer.port``), so that subsequent runs will
108 re-use the same port.
110 ``tub.location = (string, optional)``
112 In addition to running as a client, each Tahoe-LAFS node also runs as a
113 server, listening for connections from other Tahoe-LAFS clients. The node
114 announces its location by publishing a "FURL" (a string with some
115 connection hints) to the Introducer. The string it publishes can be found
116 in ``BASEDIR/private/storage.furl`` . The ``tub.location`` configuration
117 controls what location is published in this announcement.
119 If you don't provide ``tub.location``, the node will try to figure out a
120 useful one by itself, by using tools like "``ifconfig``" to determine the
121 set of IP addresses on which it can be reached from nodes both near and
122 far. It will also include the TCP port number on which it is listening
123 (either the one specified by ``tub.port``, or whichever port was assigned
124 by the kernel when ``tub.port`` is left unspecified).
126 You might want to override this value if your node lives behind a
127 firewall that is doing inbound port forwarding, or if you are using other
128 proxies such that the local IP address or port number is not the same one
129 that remote clients should use to connect. You might also want to control
130 this when using a Tor proxy to avoid revealing your actual IP address
131 through the Introducer announcement.
133 The value is a comma-separated string of host:port location hints, like
136 123.45.67.89:8098,tahoe.example.com:8098,127.0.0.1:8098
140 * Emulate default behavior, assuming your host has IP address
141 123.45.67.89 and the kernel-allocated port number was 8098::
144 tub.location = 123.45.67.89:8098,127.0.0.1:8098
146 * Use a DNS name so you can change the IP address more easily::
149 tub.location = tahoe.example.com:8098
151 * Run a node behind a firewall (which has an external IP address) that
152 has been configured to forward port 7912 to our internal node's port
156 tub.location = external-firewall.example.com:7912
158 * Run a node behind a Tor proxy (perhaps via ``torsocks``), in
159 client-only mode (i.e. we can make outbound connections, but other
160 nodes will not be able to connect to us). The literal
161 '``unreachable.example.org``' will not resolve, but will serve as a
162 reminder to human observers that this node cannot be reached. "Don't
163 call us.. we'll call you"::
166 tub.location = unreachable.example.org:0
168 * Run a node behind a Tor proxy, and make the server available as a Tor
169 "hidden service". (This assumes that other clients are running their
170 node with ``torsocks``, such that they are prepared to connect to a
171 ``.onion`` address.) The hidden service must first be configured in
172 Tor, by giving it a local port number and then obtaining a ``.onion``
173 name, using something in the ``torrc`` file like::
175 HiddenServiceDir /var/lib/tor/hidden_services/tahoe
176 HiddenServicePort 29212 127.0.0.1:8098
178 once Tor is restarted, the ``.onion`` hostname will be in
179 ``/var/lib/tor/hidden_services/tahoe/hostname``. Then set up your
183 tub.location = ualhejtq2p7ohfbb.onion:29212
185 Most users will not need to set ``tub.location``.
187 ``log_gatherer.furl = (FURL, optional)``
189 If provided, this contains a single FURL string that is used to contact a
190 "log gatherer", which will be granted access to the logport. This can be
191 used to gather operational logs in a single place. Note that in previous
192 releases of Tahoe-LAFS, if an old-style ``BASEDIR/log_gatherer.furl``
193 file existed it would also be used in addition to this value, allowing
194 multiple log gatherers to be used at once. As of Tahoe-LAFS v1.9.0, an
195 old-style file is ignored and a warning will be emitted if one is
196 detected. This means that as of Tahoe-LAFS v1.9.0 you can have at most
197 one log gatherer per node. See ticket `#1423`_ about lifting this
198 restriction and letting you have multiple log gatherers.
200 .. _`#1423`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1423
202 ``timeout.keepalive = (integer in seconds, optional)``
204 ``timeout.disconnect = (integer in seconds, optional)``
206 If ``timeout.keepalive`` is provided, it is treated as an integral number
207 of seconds, and sets the Foolscap "keepalive timer" to that value. For
208 each connection to another node, if nothing has been heard for a while,
209 we will attempt to provoke the other end into saying something. The
210 duration of silence that passes before sending the PING will be between
211 KT and 2*KT. This is mainly intended to keep NAT boxes from expiring idle
212 TCP sessions, but also gives TCP's long-duration keepalive/disconnect
213 timers some traffic to work with. The default value is 240 (i.e. 4
216 If timeout.disconnect is provided, this is treated as an integral number
217 of seconds, and sets the Foolscap "disconnect timer" to that value. For
218 each connection to another node, if nothing has been heard for a while,
219 we will drop the connection. The duration of silence that passes before
220 dropping the connection will be between DT-2*KT and 2*DT+2*KT (please see
221 ticket `#521`_ for more details). If we are sending a large amount of
222 data to the other end (which takes more than DT-2*KT to deliver), we
223 might incorrectly drop the connection. The default behavior (when this
224 value is not provided) is to disable the disconnect timer.
226 See ticket `#521`_ for a discussion of how to pick these timeout values.
227 Using 30 minutes means we'll disconnect after 22 to 68 minutes of
228 inactivity. Receiving data will reset this timeout, however if we have
229 more than 22min of data in the outbound queue (such as 800kB in two
230 pipelined segments of 10 shares each) and the far end has no need to
231 contact us, our ping might be delayed, so we may disconnect them by
234 .. _`#521`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/521
236 ``ssh.port = (strports string, optional)``
238 ``ssh.authorized_keys_file = (filename, optional)``
240 This enables an SSH-based interactive Python shell, which can be used to
241 inspect the internal state of the node, for debugging. To cause the node
242 to accept SSH connections on port 8022 from the same keys as the rest of
247 ssh.authorized_keys_file = ~/.ssh/authorized_keys
249 ``tempdir = (string, optional)``
251 This specifies a temporary directory for the web-API server to use, for
252 holding large files while they are being uploaded. If a web-API client
253 attempts to upload a 10GB file, this tempdir will need to have at least
254 10GB available for the upload to complete.
256 The default value is the ``tmp`` directory in the node's base directory
257 (i.e. ``BASEDIR/tmp``), but it can be placed elsewhere. This directory is
258 used for files that usually (on a Unix system) go into ``/tmp``. The
259 string will be interpreted relative to the node's base directory.
267 ``introducer.furl = (FURL string, mandatory)``
269 This FURL tells the client how to connect to the introducer. Each
270 Tahoe-LAFS grid is defined by an introducer. The introducer's FURL is
271 created by the introducer node and written into its base directory when
272 it starts, whereupon it should be published to everyone who wishes to
273 attach a client to that grid
275 ``helper.furl = (FURL string, optional)``
277 If provided, the node will attempt to connect to and use the given helper
278 for uploads. See `<helper.rst>`_ for details.
280 ``key_generator.furl = (FURL string, optional)``
282 If provided, the node will attempt to connect to and use the given
283 key-generator service, using RSA keys from the external process rather
284 than generating its own.
286 ``stats_gatherer.furl = (FURL string, optional)``
288 If provided, the node will connect to the given stats gatherer and
289 provide it with operational statistics.
291 ``shares.needed = (int, optional) aka "k", default 3``
293 ``shares.total = (int, optional) aka "N", N >= k, default 10``
295 ``shares.happy = (int, optional) 1 <= happy <= N, default 7``
297 These three values set the default encoding parameters. Each time a new
298 file is uploaded, erasure-coding is used to break the ciphertext into
299 separate pieces. There will be ``N`` (i.e. ``shares.total``) pieces
300 created, and the file will be recoverable if any ``k``
301 (i.e. ``shares.needed``) pieces are retrieved. The default values are
302 3-of-10 (i.e. ``shares.needed = 3``, ``shares.total = 10``). Setting
303 ``k`` to 1 is equivalent to simple replication (uploading ``N`` copies of
306 These values control the tradeoff between storage overhead, performance,
307 and reliability. To a first approximation, a 1MB file will use (1MB *
308 ``N``/``k``) of backend storage space (the actual value will be a bit
309 more, because of other forms of overhead). Up to ``N``-``k`` shares can
310 be lost before the file becomes unrecoverable, so assuming there are at
311 least ``N`` servers, up to ``N``-``k`` servers can be offline without
312 losing the file. So large ``N``/``k`` ratios are more reliable, and small
313 ``N``/``k`` ratios use less disk space. Clearly, ``k`` must never be
316 Large values of ``N`` will slow down upload operations slightly, since
317 more servers must be involved, and will slightly increase storage
318 overhead due to the hash trees that are created. Large values of ``k``
319 will cause downloads to be marginally slower, because more servers must
320 be involved. ``N`` cannot be larger than 256, because of the 8-bit
321 erasure-coding algorithm that Tahoe-LAFS uses.
323 ``shares.happy`` allows you control over the distribution of your
324 immutable file. For a successful upload, shares are guaranteed to be
325 initially placed on at least ``shares.happy`` distinct servers, the
326 correct functioning of any ``k`` of which is sufficient to guarantee the
327 availability of the uploaded file. This value should not be larger than
328 the number of servers on your grid.
330 A value of ``shares.happy`` <= ``k`` is allowed, but does not provide any
331 redundancy if some servers fail or lose shares.
333 (Mutable files use a different share placement algorithm that does not
334 currently consider this parameter.)
337 Frontend Configuration
338 ======================
340 The Tahoe client process can run a variety of frontend file-access protocols.
341 You will use these to create and retrieve files from the virtual filesystem.
342 Configuration details for each are documented in the following
343 protocol-specific guides:
347 Tahoe runs a webserver by default on port 3456. This interface provides a
348 human-oriented "WUI", with pages to create, modify, and browse
349 directories and files, as well as a number of pages to check on the
350 status of your Tahoe node. It also provides a machine-oriented "WAPI",
351 with a REST-ful HTTP interface that can be used by other programs
352 (including the CLI tools). Please see `<frontends/webapi.rst>`_ for full
353 details, and the ``web.port`` and ``web.static`` config variables above.
354 The `<frontends/download-status.rst>`_ document also describes a few WUI
359 The main "bin/tahoe" executable includes subcommands for manipulating the
360 filesystem, uploading/downloading files, and creating/running Tahoe
361 nodes. See `<frontends/CLI.rst>`_ for details.
365 Tahoe can also run both FTP and SFTP servers, and map a username/password
366 pair to a top-level Tahoe directory. See `<frontends/FTP-and-SFTP.rst>`_
367 for instructions on configuring these services, and the ``[ftpd]`` and
368 ``[sftpd]`` sections of ``tahoe.cfg``.
372 As of Tahoe-LAFS v1.9.0, a node running on Linux can be configured to
373 automatically upload files that are created or changed in a specified
374 local directory. See `<frontends/drop_upload.rst>`_ for details.
378 Storage Server Configuration
379 ============================
383 ``enabled = (boolean, optional)``
385 If this is ``True``, the node will run a storage server, offering space
386 to other clients. If it is ``False``, the node will not run a storage
387 server, meaning that no shares will be stored on this node. Use ``False``
388 for clients who do not wish to provide storage service. The default value
391 ``readonly = (boolean, optional)``
393 If ``True``, the node will run a storage server but will not accept any
394 shares, making it effectively read-only. Use this for storage servers
395 that are being decommissioned: the ``storage/`` directory could be
396 mounted read-only, while shares are moved to other servers. Note that
397 this currently only affects immutable shares. Mutable shares (used for
398 directories) will be written and modified anyway. See ticket `#390
399 <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/390>`_ for the current
400 status of this bug. The default value is ``False``.
402 ``reserved_space = (str, optional)``
404 If provided, this value defines how much disk space is reserved: the
405 storage server will not accept any share that causes the amount of free
406 disk space to drop below this value. (The free space is measured by a
407 call to statvfs(2) on Unix, or GetDiskFreeSpaceEx on Windows, and is the
408 space available to the user account under which the storage server runs.)
410 This string contains a number, with an optional case-insensitive scale
411 suffix like "K" or "M" or "G", and an optional "B" or "iB" suffix. So
412 "100MB", "100M", "100000000B", "100000000", and "100000kb" all mean the
413 same thing. Likewise, "1MiB", "1024KiB", and "1048576B" all mean the same
416 "``tahoe create-node``" generates a tahoe.cfg with
417 "``reserved_space=1G``", but you may wish to raise, lower, or remove the
418 reservation to suit your needs.
424 ``expire.override_lease_duration =``
426 ``expire.cutoff_date =``
428 ``expire.immutable =``
432 These settings control garbage collection, in which the server will
433 delete shares that no longer have an up-to-date lease on them. Please see
434 `<garbage-collection.rst>`_ for full details.
440 A "helper" is a regular client node that also offers the "upload helper"
445 ``enabled = (boolean, optional)``
447 If ``True``, the node will run a helper (see `<helper.rst>`_ for
448 details). The helper's contact FURL will be placed in
449 ``private/helper.furl``, from which it can be copied to any clients that
450 wish to use it. Clearly nodes should not both run a helper and attempt to
451 use one: do not create ``helper.furl`` and also define
452 ``[helper]enabled`` in the same node. The default is ``False``.
455 Running An Introducer
456 =====================
458 The introducer node uses a different ``.tac`` file (named
459 "``introducer.tac``"), and pays attention to the ``[node]`` section, but not
462 The Introducer node maintains some different state than regular client nodes.
464 ``BASEDIR/introducer.furl``
466 This is generated the first time the introducer node is started, and used
467 again on subsequent runs, to give the introduction service a persistent
468 long-term identity. This file should be published and copied into new
469 client nodes before they are started for the first time.
472 Other Files in BASEDIR
473 ======================
475 Some configuration is not kept in ``tahoe.cfg``, for the following reasons:
477 * it is generated by the node at startup, e.g. encryption keys. The node
478 never writes to ``tahoe.cfg``.
479 * it is generated by user action, e.g. the "``tahoe create-alias``" command.
481 In addition, non-configuration persistent state is kept in the node's base
482 directory, next to the configuration knobs.
484 This section describes these other files.
488 This contains an SSL private-key certificate. The node generates this the
489 first time it is started, and re-uses it on subsequent runs. This
490 certificate allows the node to have a cryptographically-strong identifier
491 (the Foolscap "TubID"), and to establish secure connections to other nodes.
495 Nodes that host StorageServers will create this directory to hold shares of
496 files on behalf of other clients. There will be a directory underneath it
497 for each StorageIndex for which this node is holding shares. There is also
498 an "incoming" directory where partially-completed shares are held while
499 they are being received.
503 This file defines the client, by constructing the actual Client instance
504 each time the node is started. It is used by the "``twistd``" daemonization
505 program (in the ``-y`` mode), which is run internally by the "``tahoe
506 start``" command. This file is created by the "``tahoe create-node``" or
507 "``tahoe create-client``" commands.
509 ``tahoe-introducer.tac``
511 This file is used to construct an introducer, and is created by the
512 "``tahoe create-introducer``" command.
514 ``tahoe-key-generator.tac``
516 This file is used to construct a key generator, and is created by the
517 "``tahoe create-key-gernerator``" command.
519 ``tahoe-stats-gatherer.tac``
521 This file is used to construct a statistics gatherer, and is created by the
522 "``tahoe create-stats-gatherer``" command.
524 ``private/control.furl``
526 This file contains a FURL that provides access to a control port on the
527 client node, from which files can be uploaded and downloaded. This file is
528 created with permissions that prevent anyone else from reading it (on
529 operating systems that support such a concept), to insure that only the
530 owner of the client node can use this feature. This port is intended for
531 debugging and testing use.
533 ``private/logport.furl``
535 This file contains a FURL that provides access to a 'log port' on the
536 client node, from which operational logs can be retrieved. Do not grant
537 logport access to strangers, because occasionally secret information may be
540 ``private/helper.furl``
542 If the node is running a helper (for use by other clients), its contact
543 FURL will be placed here. See `<helper.rst>`_ for more details.
545 ``private/root_dir.cap`` (optional)
547 The command-line tools will read a directory cap out of this file and use
548 it, if you don't specify a '--dir-cap' option or if you specify
551 ``private/convergence`` (automatically generated)
553 An added secret for encrypting immutable files. Everyone who has this same
554 string in their ``private/convergence`` file encrypts their immutable files
555 in the same way when uploading them. This causes identical files to
556 "converge" -- to share the same storage space since they have identical
557 ciphertext -- which conserves space and optimizes upload time, but it also
558 exposes file contents to the possibility of a brute-force attack by people
559 who know that string. In this attack, if the attacker can guess most of the
560 contents of a file, then they can use brute-force to learn the remaining
563 So the set of people who know your ``private/convergence`` string is the
564 set of people who converge their storage space with you when you and they
565 upload identical immutable files, and it is also the set of people who
566 could mount such an attack.
568 The content of the ``private/convergence`` file is a base-32 encoded
569 string. If the file doesn't exist, then when the Tahoe-LAFS client starts
570 up it will generate a random 256-bit string and write the base-32 encoding
571 of this string into the file. If you want to converge your immutable files
572 with as many people as possible, put the empty string (so that
573 ``private/convergence`` is a zero-length file).
581 Each Tahoe-LAFS node creates a directory to hold the log messages produced
582 as the node runs. These logfiles are created and rotated by the
583 "``twistd``" daemonization program, so ``logs/twistd.log`` will contain the
584 most recent messages, ``logs/twistd.log.1`` will contain the previous ones,
585 ``logs/twistd.log.2`` will be older still, and so on. ``twistd`` rotates
586 logfiles after they grow beyond 1MB in size. If the space consumed by
587 logfiles becomes troublesome, they should be pruned: a cron job to delete
588 all files that were created more than a month ago in this ``logs/``
589 directory should be sufficient.
593 this is written by all nodes after startup, and contains a base32-encoded
594 (i.e. human-readable) NodeID that identifies this specific node. This
595 NodeID is the same string that gets displayed on the web page (in the
596 "which peers am I connected to" list), and the shortened form (the first
597 few characters) is recorded in various log messages.
603 The following is a sample ``tahoe.cfg`` file, containing values for some of
604 the keys described in the previous section. Note that this is not a
605 recommended configuration (most of these are not the default values), merely
611 nickname = Bob's Tahoe-LAFS Node
613 tub.location = 123.45.67.89:8098,44.55.66.77:8098
615 log_gatherer.furl = pb://soklj4y7eok5c3xkmjeqpw@192.168.69.247:44801/eqpwqtzm
616 timeout.keepalive = 240
617 timeout.disconnect = 1800
619 ssh.authorized_keys_file = ~/.ssh/authorized_keys
623 introducer.furl = pb://ok45ssoklj4y7eok5c3xkmj@tahoe.example:44801/ii3uumo
624 helper.furl = pb://ggti5ssoklj4y7eok5c3xkmj@helper.tahoe.example:7054/kk8lhr
630 sizelimit = 10000000000
637 Old Configuration Files
638 =======================
640 Tahoe-LAFS releases before v1.3.0 had no ``tahoe.cfg`` file, and used
641 distinct files for each item. This is no longer supported and if you have
642 configuration in the old format you must manually convert it to the new
643 format for Tahoe-LAFS to detect it. See `<historical/configuration.rst>`_.