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`_
15 A Tahoe-LAFS node is configured by writing to files in its base
16 directory. These files are read by the node when it starts, so each time you
17 change them, you need to restart the node.
19 The node also writes state to its base directory, so it will create files on
22 This document contains a complete list of the config files that are examined
23 by the client node, as well as the state files that you'll observe in its
26 The main file is named "``tahoe.cfg``", and is an ".INI"-style configuration
27 file (parsed by the Python stdlib 'ConfigParser' module: "``[name]``" section
28 markers, lines with "``key.subkey: value``", rfc822-style
29 continuations). There are also other files containing information that does
30 not easily fit into this format. The "``tahoe create-node``" or "``tahoe
31 create-client``" command will create an initial ``tahoe.cfg`` file for
32 you. After creation, the node will never modify the ``tahoe.cfg`` file: all
33 persistent state is put in other files.
35 The item descriptions below use the following types:
39 one of (True, yes, on, 1, False, off, no, 0), case-insensitive
43 a Twisted listening-port specification string, like "``tcp:80``" or
44 "``tcp:3456:interface=127.0.0.1``". For a full description of the format,
45 see `the Twisted strports documentation
46 <http://twistedmatrix.com/documents/current/api/twisted.application.strports.html>`_.
50 a Foolscap endpoint identifier, like
51 ``pb://soklj4y7eok5c3xkmjeqpw@192.168.69.247:44801/eqpwqtzm``
54 Overall Node Configuration
55 ==========================
57 This section controls the network behavior of the node overall: which ports
58 and IP addresses are used, when connections are timed out, etc. This
59 configuration is independent of the services that the node is offering: the
60 same controls are used for client and introducer nodes.
62 If your node is behind a firewall or NAT device and you want other clients to
63 connect to it, you'll need to open a port in the firewall or NAT, and specify
64 that port number in the tub.port option. If behind a NAT, you *may* need to
65 set the ``tub.location`` option described below.
69 ``nickname = (UTF-8 string, optional)``
71 This value will be displayed in management tools as this node's
72 "nickname". If not provided, the nickname will be set to "<unspecified>".
73 This string shall be a UTF-8 encoded Unicode string.
75 ``web.port = (strports string, optional)``
77 This controls where the node's webserver should listen, providing
78 filesystem access and node status as defined in
79 `<frontends/webapi.rst>`_. This file contains a Twisted "strports"
80 specification such as "``3456``" or "``tcp:3456:interface=127.0.0.1``".
81 The "``tahoe create-node``" or "``tahoe create-client``" commands set the
82 ``web.port`` to "``tcp:3456:interface=127.0.0.1``" by default; this is
83 overridable by the ``--webport`` option. You can make it use SSL by
84 writing "``ssl:3456:privateKey=mykey.pem:certKey=cert.pem``" instead.
86 If this is not provided, the node will not run a web server.
88 ``web.static = (string, optional)``
90 This controls where the ``/static`` portion of the URL space is
91 served. The value is a directory name (``~username`` is allowed, and
92 non-absolute names are interpreted relative to the node's basedir), which
93 can contain HTML and other files. This can be used to serve a
94 Javascript-based frontend to the Tahoe-LAFS node, or other services.
96 The default value is "``public_html``", which will serve
97 ``BASEDIR/public_html`` . With the default settings,
98 ``http://127.0.0.1:3456/static/foo.html`` will serve the contents of
99 ``BASEDIR/public_html/foo.html`` .
101 ``tub.port = (integer, optional)``
103 This controls which port the node uses to accept Foolscap connections
104 from other nodes. If not provided, the node will ask the kernel for any
105 available port. The port will be written to a separate file (named
106 ``client.port`` or ``introducer.port``), so that subsequent runs will
107 re-use the same port.
109 ``tub.location = (string, optional)``
111 In addition to running as a client, each Tahoe-LAFS node also runs as a
112 server, listening for connections from other Tahoe-LAFS clients. The node
113 announces its location by publishing a "FURL" (a string with some
114 connection hints) to the Introducer. The string it publishes can be found
115 in ``BASEDIR/private/storage.furl`` . The ``tub.location`` configuration
116 controls what location is published in this announcement.
118 If you don't provide ``tub.location``, the node will try to figure out a
119 useful one by itself, by using tools like "``ifconfig``" to determine the
120 set of IP addresses on which it can be reached from nodes both near and
121 far. It will also include the TCP port number on which it is listening
122 (either the one specified by ``tub.port``, or whichever port was assigned
123 by the kernel when ``tub.port`` is left unspecified).
125 You might want to override this value if your node lives behind a
126 firewall that is doing inbound port forwarding, or if you are using other
127 proxies such that the local IP address or port number is not the same one
128 that remote clients should use to connect. You might also want to control
129 this when using a Tor proxy to avoid revealing your actual IP address
130 through the Introducer announcement.
132 The value is a comma-separated string of host:port location hints, like
135 123.45.67.89:8098,tahoe.example.com:8098,127.0.0.1:8098
139 * Emulate default behavior, assuming your host has IP address
140 123.45.67.89 and the kernel-allocated port number was 8098::
143 tub.location = 123.45.67.89:8098,127.0.0.1:8098
145 * Use a DNS name so you can change the IP address more easily::
148 tub.location = tahoe.example.com:8098
150 * Run a node behind a firewall (which has an external IP address) that
151 has been configured to forward port 7912 to our internal node's port
155 tub.location = external-firewall.example.com:7912
157 * Run a node behind a Tor proxy (perhaps via ``torsocks``), in
158 client-only mode (i.e. we can make outbound connections, but other
159 nodes will not be able to connect to us). The literal
160 '``unreachable.example.org``' will not resolve, but will serve as a
161 reminder to human observers that this node cannot be reached. "Don't
162 call us.. we'll call you"::
165 tub.location = unreachable.example.org:0
167 * Run a node behind a Tor proxy, and make the server available as a Tor
168 "hidden service". (This assumes that other clients are running their
169 node with ``torsocks``, such that they are prepared to connect to a
170 ``.onion`` address.) The hidden service must first be configured in
171 Tor, by giving it a local port number and then obtaining a ``.onion``
172 name, using something in the ``torrc`` file like::
174 HiddenServiceDir /var/lib/tor/hidden_services/tahoe
175 HiddenServicePort 29212 127.0.0.1:8098
177 once Tor is restarted, the ``.onion`` hostname will be in
178 ``/var/lib/tor/hidden_services/tahoe/hostname``. Then set up your
182 tub.location = ualhejtq2p7ohfbb.onion:29212
184 Most users will not need to set ``tub.location``.
186 ``log_gatherer.furl = (FURL, optional)``
188 If provided, this contains a single FURL string that is used to contact a
189 "log gatherer", which will be granted access to the logport. This can be
190 used to gather operational logs in a single place. Note that in previous
191 releases of Tahoe-LAFS, if an old-style ``BASEDIR/log_gatherer.furl``
192 file existed it would also be used in addition to this value, allowing
193 multiple log gatherers to be used at once. As of Tahoe-LAFS v1.9.0, an
194 old-style file is ignored and a warning will be emitted if one is
195 detected. This means that as of Tahoe-LAFS v1.9.0 you can have at most
196 one log gatherer per node. See ticket `#1423`_ about lifting this
197 restriction and letting you have multiple log gatherers.
199 .. _`#1423`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1423
201 ``timeout.keepalive = (integer in seconds, optional)``
203 ``timeout.disconnect = (integer in seconds, optional)``
205 If ``timeout.keepalive`` is provided, it is treated as an integral number
206 of seconds, and sets the Foolscap "keepalive timer" to that value. For
207 each connection to another node, if nothing has been heard for a while,
208 we will attempt to provoke the other end into saying something. The
209 duration of silence that passes before sending the PING will be between
210 KT and 2*KT. This is mainly intended to keep NAT boxes from expiring idle
211 TCP sessions, but also gives TCP's long-duration keepalive/disconnect
212 timers some traffic to work with. The default value is 240 (i.e. 4
215 If timeout.disconnect is provided, this is treated as an integral number
216 of seconds, and sets the Foolscap "disconnect timer" to that value. For
217 each connection to another node, if nothing has been heard for a while,
218 we will drop the connection. The duration of silence that passes before
219 dropping the connection will be between DT-2*KT and 2*DT+2*KT (please see
220 ticket `#521`_ for more details). If we are sending a large amount of
221 data to the other end (which takes more than DT-2*KT to deliver), we
222 might incorrectly drop the connection. The default behavior (when this
223 value is not provided) is to disable the disconnect timer.
225 See ticket `#521`_ for a discussion of how to pick these timeout values.
226 Using 30 minutes means we'll disconnect after 22 to 68 minutes of
227 inactivity. Receiving data will reset this timeout, however if we have
228 more than 22min of data in the outbound queue (such as 800kB in two
229 pipelined segments of 10 shares each) and the far end has no need to
230 contact us, our ping might be delayed, so we may disconnect them by
233 .. _`#521`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/521
235 ``ssh.port = (strports string, optional)``
237 ``ssh.authorized_keys_file = (filename, optional)``
239 This enables an SSH-based interactive Python shell, which can be used to
240 inspect the internal state of the node, for debugging. To cause the node
241 to accept SSH connections on port 8022 from the same keys as the rest of
246 ssh.authorized_keys_file = ~/.ssh/authorized_keys
248 ``tempdir = (string, optional)``
250 This specifies a temporary directory for the web-API server to use, for
251 holding large files while they are being uploaded. If a web-API client
252 attempts to upload a 10GB file, this tempdir will need to have at least
253 10GB available for the upload to complete.
255 The default value is the ``tmp`` directory in the node's base directory
256 (i.e. ``BASEDIR/tmp``), but it can be placed elsewhere. This directory is
257 used for files that usually (on a Unix system) go into ``/tmp``. The
258 string will be interpreted relative to the node's base directory.
266 ``introducer.furl = (FURL string, mandatory)``
268 This FURL tells the client how to connect to the introducer. Each
269 Tahoe-LAFS grid is defined by an introducer. The introducer's FURL is
270 created by the introducer node and written into its base directory when
271 it starts, whereupon it should be published to everyone who wishes to
272 attach a client to that grid
274 ``helper.furl = (FURL string, optional)``
276 If provided, the node will attempt to connect to and use the given helper
277 for uploads. See `<helper.rst>`_ for details.
279 ``key_generator.furl = (FURL string, optional)``
281 If provided, the node will attempt to connect to and use the given
282 key-generator service, using RSA keys from the external process rather
283 than generating its own.
285 ``stats_gatherer.furl = (FURL string, optional)``
287 If provided, the node will connect to the given stats gatherer and
288 provide it with operational statistics.
290 ``shares.needed = (int, optional) aka "k", default 3``
292 ``shares.total = (int, optional) aka "N", N >= k, default 10``
294 ``shares.happy = (int, optional) 1 <= happy <= N, default 7``
296 These three values set the default encoding parameters. Each time a new
297 file is uploaded, erasure-coding is used to break the ciphertext into
298 separate shares. There will be ``N`` (i.e. ``shares.total``) shares
299 created, and the file will be recoverable if any ``k``
300 (i.e. ``shares.needed``) shares are retrieved. The default values are
301 3-of-10 (i.e. ``shares.needed = 3``, ``shares.total = 10``). Setting
302 ``k`` to 1 is equivalent to simple replication (uploading ``N`` copies of
305 These values control the tradeoff between storage overhead and
306 reliability. To a first approximation, a 1MB file will use (1MB *
307 ``N``/``k``) of backend storage space (the actual value will be a bit
308 more, because of other forms of overhead). Up to ``N``-``k`` shares can
309 be lost before the file becomes unrecoverable. So large ``N``/``k``
310 ratios are more reliable, and small ``N``/``k`` ratios use less disk
311 space. ``N`` cannot be larger than 256, because of the 8-bit
312 erasure-coding algorithm that Tahoe-LAFS uses. ``k`` can not be greater
313 than ``N``. See `<performance.rst>`_ for more details.
315 ``shares.happy`` allows you control over how well to "spread out" the
316 shares of an immutable file. For a successful upload, shares are
317 guaranteed to be initially placed on at least ``shares.happy`` distinct
318 servers, the correct functioning of any ``k`` of which is sufficient to
319 guarantee the availability of the uploaded file. This value should not be
320 larger than the number of servers on your grid.
322 A value of ``shares.happy`` <= ``k`` is allowed, but does not provide any
323 redundancy if some servers fail or lose shares.
325 (Mutable files use a different share placement algorithm that does not
326 currently consider this parameter.)
328 ``mutable.format = sdmf or mdmf``
330 This value tells Tahoe-LAFS what the default mutable file format should
331 be. If ``mutable.format=sdmf``, then newly created mutable files will be
332 in the old SDMF format. This is desirable for clients that operate on
333 grids where some peers run older versions of Tahoe-LAFS, as these older
334 versions cannot read the new MDMF mutable file format. If
335 ``mutable.format`` is ``mdmf``, then newly created mutable files will use
336 the new MDMF format, which supports efficient in-place modification and
337 streaming downloads. You can overwrite this value using a special
338 mutable-type parameter in the webapi. If you do not specify a value here,
339 Tahoe-LAFS will use SDMF for all newly-created mutable files.
341 Note that this parameter only applies to mutable files. Mutable
342 directories, which are stored as mutable files, are not controlled by
343 this parameter and will always use SDMF. We may revisit this decision
344 in future versions of Tahoe-LAFS.
346 Frontend Configuration
347 ======================
349 The Tahoe client process can run a variety of frontend file-access protocols.
350 You will use these to create and retrieve files from the virtual filesystem.
351 Configuration details for each are documented in the following
352 protocol-specific guides:
356 Tahoe runs a webserver by default on port 3456. This interface provides a
357 human-oriented "WUI", with pages to create, modify, and browse
358 directories and files, as well as a number of pages to check on the
359 status of your Tahoe node. It also provides a machine-oriented "WAPI",
360 with a REST-ful HTTP interface that can be used by other programs
361 (including the CLI tools). Please see `<frontends/webapi.rst>`_ for full
362 details, and the ``web.port`` and ``web.static`` config variables above.
363 The `<frontends/download-status.rst>`_ document also describes a few WUI
368 The main "bin/tahoe" executable includes subcommands for manipulating the
369 filesystem, uploading/downloading files, and creating/running Tahoe
370 nodes. See `<frontends/CLI.rst>`_ for details.
374 Tahoe can also run both FTP and SFTP servers, and map a username/password
375 pair to a top-level Tahoe directory. See `<frontends/FTP-and-SFTP.rst>`_
376 for instructions on configuring these services, and the ``[ftpd]`` and
377 ``[sftpd]`` sections of ``tahoe.cfg``.
381 As of Tahoe-LAFS v1.9.0, a node running on Linux can be configured to
382 automatically upload files that are created or changed in a specified
383 local directory. See `<frontends/drop_upload.rst>`_ for details.
387 Storage Server Configuration
388 ============================
392 ``enabled = (boolean, optional)``
394 If this is ``True``, the node will run a storage server, offering space
395 to other clients. If it is ``False``, the node will not run a storage
396 server, meaning that no shares will be stored on this node. Use ``False``
397 for clients who do not wish to provide storage service. The default value
400 ``readonly = (boolean, optional)``
402 If ``True``, the node will run a storage server but will not accept any
403 shares, making it effectively read-only. Use this for storage servers
404 that are being decommissioned: the ``storage/`` directory could be
405 mounted read-only, while shares are moved to other servers. Note that
406 this currently only affects immutable shares. Mutable shares (used for
407 directories) will be written and modified anyway. See ticket `#390
408 <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/390>`_ for the current
409 status of this bug. The default value is ``False``.
411 ``reserved_space = (str, optional)``
413 If provided, this value defines how much disk space is reserved: the
414 storage server will not accept any share that causes the amount of free
415 disk space to drop below this value. (The free space is measured by a
416 call to statvfs(2) on Unix, or GetDiskFreeSpaceEx on Windows, and is the
417 space available to the user account under which the storage server runs.)
419 This string contains a number, with an optional case-insensitive scale
420 suffix like "K" or "M" or "G", and an optional "B" or "iB" suffix. So
421 "100MB", "100M", "100000000B", "100000000", and "100000kb" all mean the
422 same thing. Likewise, "1MiB", "1024KiB", and "1048576B" all mean the same
425 "``tahoe create-node``" generates a tahoe.cfg with
426 "``reserved_space=1G``", but you may wish to raise, lower, or remove the
427 reservation to suit your needs.
433 ``expire.override_lease_duration =``
435 ``expire.cutoff_date =``
437 ``expire.immutable =``
441 These settings control garbage collection, in which the server will
442 delete shares that no longer have an up-to-date lease on them. Please see
443 `<garbage-collection.rst>`_ for full details.
449 A "helper" is a regular client node that also offers the "upload helper"
454 ``enabled = (boolean, optional)``
456 If ``True``, the node will run a helper (see `<helper.rst>`_ for
457 details). The helper's contact FURL will be placed in
458 ``private/helper.furl``, from which it can be copied to any clients that
459 wish to use it. Clearly nodes should not both run a helper and attempt to
460 use one: do not create ``helper.furl`` and also define
461 ``[helper]enabled`` in the same node. The default is ``False``.
464 Running An Introducer
465 =====================
467 The introducer node uses a different ``.tac`` file (named
468 "``introducer.tac``"), and pays attention to the ``[node]`` section, but not
471 The Introducer node maintains some different state than regular client nodes.
473 ``BASEDIR/introducer.furl``
475 This is generated the first time the introducer node is started, and used
476 again on subsequent runs, to give the introduction service a persistent
477 long-term identity. This file should be published and copied into new
478 client nodes before they are started for the first time.
481 Other Files in BASEDIR
482 ======================
484 Some configuration is not kept in ``tahoe.cfg``, for the following reasons:
486 * it is generated by the node at startup, e.g. encryption keys. The node
487 never writes to ``tahoe.cfg``.
488 * it is generated by user action, e.g. the "``tahoe create-alias``" command.
490 In addition, non-configuration persistent state is kept in the node's base
491 directory, next to the configuration knobs.
493 This section describes these other files.
497 This contains an SSL private-key certificate. The node generates this the
498 first time it is started, and re-uses it on subsequent runs. This
499 certificate allows the node to have a cryptographically-strong identifier
500 (the Foolscap "TubID"), and to establish secure connections to other nodes.
504 Nodes that host StorageServers will create this directory to hold shares of
505 files on behalf of other clients. There will be a directory underneath it
506 for each StorageIndex for which this node is holding shares. There is also
507 an "incoming" directory where partially-completed shares are held while
508 they are being received.
512 This file defines the client, by constructing the actual Client instance
513 each time the node is started. It is used by the "``twistd``" daemonization
514 program (in the ``-y`` mode), which is run internally by the "``tahoe
515 start``" command. This file is created by the "``tahoe create-node``" or
516 "``tahoe create-client``" commands.
518 ``tahoe-introducer.tac``
520 This file is used to construct an introducer, and is created by the
521 "``tahoe create-introducer``" command.
523 ``tahoe-key-generator.tac``
525 This file is used to construct a key generator, and is created by the
526 "``tahoe create-key-gernerator``" command.
528 ``tahoe-stats-gatherer.tac``
530 This file is used to construct a statistics gatherer, and is created by the
531 "``tahoe create-stats-gatherer``" command.
533 ``private/control.furl``
535 This file contains a FURL that provides access to a control port on the
536 client node, from which files can be uploaded and downloaded. This file is
537 created with permissions that prevent anyone else from reading it (on
538 operating systems that support such a concept), to insure that only the
539 owner of the client node can use this feature. This port is intended for
540 debugging and testing use.
542 ``private/logport.furl``
544 This file contains a FURL that provides access to a 'log port' on the
545 client node, from which operational logs can be retrieved. Do not grant
546 logport access to strangers, because occasionally secret information may be
549 ``private/helper.furl``
551 If the node is running a helper (for use by other clients), its contact
552 FURL will be placed here. See `<helper.rst>`_ for more details.
554 ``private/root_dir.cap`` (optional)
556 The command-line tools will read a directory cap out of this file and use
557 it, if you don't specify a '--dir-cap' option or if you specify
560 ``private/convergence`` (automatically generated)
562 An added secret for encrypting immutable files. Everyone who has this same
563 string in their ``private/convergence`` file encrypts their immutable files
564 in the same way when uploading them. This causes identical files to
565 "converge" -- to share the same storage space since they have identical
566 ciphertext -- which conserves space and optimizes upload time, but it also
567 exposes file contents to the possibility of a brute-force attack by people
568 who know that string. In this attack, if the attacker can guess most of the
569 contents of a file, then they can use brute-force to learn the remaining
572 So the set of people who know your ``private/convergence`` string is the
573 set of people who converge their storage space with you when you and they
574 upload identical immutable files, and it is also the set of people who
575 could mount such an attack.
577 The content of the ``private/convergence`` file is a base-32 encoded
578 string. If the file doesn't exist, then when the Tahoe-LAFS client starts
579 up it will generate a random 256-bit string and write the base-32 encoding
580 of this string into the file. If you want to converge your immutable files
581 with as many people as possible, put the empty string (so that
582 ``private/convergence`` is a zero-length file).
590 Each Tahoe-LAFS node creates a directory to hold the log messages produced
591 as the node runs. These logfiles are created and rotated by the
592 "``twistd``" daemonization program, so ``logs/twistd.log`` will contain the
593 most recent messages, ``logs/twistd.log.1`` will contain the previous ones,
594 ``logs/twistd.log.2`` will be older still, and so on. ``twistd`` rotates
595 logfiles after they grow beyond 1MB in size. If the space consumed by
596 logfiles becomes troublesome, they should be pruned: a cron job to delete
597 all files that were created more than a month ago in this ``logs/``
598 directory should be sufficient.
602 this is written by all nodes after startup, and contains a base32-encoded
603 (i.e. human-readable) NodeID that identifies this specific node. This
604 NodeID is the same string that gets displayed on the web page (in the
605 "which peers am I connected to" list), and the shortened form (the first
606 few characters) is recorded in various log messages.
610 Gateway nodes may find it necessary to prohibit access to certain files. The
611 web-API has a facility to block access to filecaps by their storage index,
612 returning a 403 "Forbidden" error instead of the original file. For more
613 details, see the "Access Blacklist" section of `<frontends/webapi.rst>`_.
619 The following is a sample ``tahoe.cfg`` file, containing values for some of
620 the keys described in the previous section. Note that this is not a
621 recommended configuration (most of these are not the default values), merely
627 nickname = Bob's Tahoe-LAFS Node
629 tub.location = 123.45.67.89:8098,44.55.66.77:8098
631 log_gatherer.furl = pb://soklj4y7eok5c3xkmjeqpw@192.168.69.247:44801/eqpwqtzm
632 timeout.keepalive = 240
633 timeout.disconnect = 1800
635 ssh.authorized_keys_file = ~/.ssh/authorized_keys
639 introducer.furl = pb://ok45ssoklj4y7eok5c3xkmj@tahoe.example:44801/ii3uumo
640 helper.furl = pb://ggti5ssoklj4y7eok5c3xkmj@helper.tahoe.example:7054/kk8lhr
646 sizelimit = 10000000000
653 Old Configuration Files
654 =======================
656 Tahoe-LAFS releases before v1.3.0 had no ``tahoe.cfg`` file, and used
657 distinct files for each item. This is no longer supported and if you have
658 configuration in the old format you must manually convert it to the new
659 format for Tahoe-LAFS to detect it. See `<historical/configuration.rst>`_.