1 =============================
2 Configuring a Tahoe-LAFS node
3 =============================
6 2. `Overall Node Configuration`_
7 3. `Client Configuration`_
8 4. `Storage Server Configuration`_
9 5. `Frontend Configuration`_
10 6. `Running A Helper`_
11 7. `Running An Introducer`_
12 8. `Other Files in BASEDIR`_
16 A Tahoe-LAFS node is configured by writing to files in its base directory.
17 These files are read by the node when it starts, so each time you change
18 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 <https://twistedmatrix.com/documents/current/api/twisted.application.strports.html>`_.
48 Please note, if interface= is not specified, Tahoe-LAFS will attempt to
49 bind the port specified on all interfaces.
53 a Foolscap endpoint identifier, like
54 ``pb://soklj4y7eok5c3xkmjeqpw@192.168.69.247:44801/eqpwqtzm``
60 A node can be a client/server, an introducer, a statistics gatherer, or a
63 Client/server nodes provide one or more of the following services:
72 A client/server that provides storage service (i.e. storing shares for
73 clients) is called a "storage server". If it provides any of the other
74 services, it is a "storage client" (a node can be both a storage server and a
75 storage client). A client/server node that provides web-API service is called
79 Overall Node Configuration
80 ==========================
82 This section controls the network behavior of the node overall: which ports
83 and IP addresses are used, when connections are timed out, etc. This
84 configuration applies to all node types and is independent of the services
85 that the node is offering.
87 If your node is behind a firewall or NAT device and you want other clients to
88 connect to it, you'll need to open a port in the firewall or NAT, and specify
89 that port number in the tub.port option. If behind a NAT, you *may* need to
90 set the ``tub.location`` option described below.
94 ``nickname = (UTF-8 string, optional)``
96 This value will be displayed in management tools as this node's
97 "nickname". If not provided, the nickname will be set to "<unspecified>".
98 This string shall be a UTF-8 encoded Unicode string.
100 ``web.port = (strports string, optional)``
102 This controls where the node's web server should listen, providing node
103 status and, if the node is a client/server, providing web-API service as
104 defined in `webapi.rst <frontends/webapi.rst>_`.
106 This file contains a Twisted "strports" specification such as "``3456``"
107 or "``tcp:3456:interface=127.0.0.1``". The "``tahoe create-node``" or
108 "``tahoe create-client``" commands set the ``web.port`` to
109 "``tcp:3456:interface=127.0.0.1``" by default; this is overridable by the
110 ``--webport`` option. You can make it use SSL by writing
111 "``ssl:3456:privateKey=mykey.pem:certKey=cert.pem``" instead.
113 If this is not provided, the node will not run a web server.
115 ``web.static = (string, optional)``
117 This controls where the ``/static`` portion of the URL space is
118 served. The value is a directory name (``~username`` is allowed, and
119 non-absolute names are interpreted relative to the node's basedir), which
120 can contain HTML and other files. This can be used to serve a
121 Javascript-based frontend to the Tahoe-LAFS node, or other services.
123 The default value is "``public_html``", which will serve
124 ``BASEDIR/public_html`` . With the default settings,
125 ``http://127.0.0.1:3456/static/foo.html`` will serve the contents of
126 ``BASEDIR/public_html/foo.html`` .
128 ``tub.port = (integer, optional)``
130 This controls which port the node uses to accept Foolscap connections
131 from other nodes. If not provided, the node will ask the kernel for any
132 available port. The port will be written to a separate file (named
133 ``client.port`` or ``introducer.port``), so that subsequent runs will
134 re-use the same port.
136 ``tub.location = (string, optional)``
138 In addition to running as a client, each Tahoe-LAFS node also runs as a
139 server, listening for connections from other Tahoe-LAFS clients. The node
140 announces its location by publishing a "FURL" (a string with some
141 connection hints) to the Introducer. The string it publishes can be found
142 in ``BASEDIR/private/storage.furl`` . The ``tub.location`` configuration
143 controls what location is published in this announcement.
145 If you don't provide ``tub.location``, the node will try to figure out a
146 useful one by itself, by using tools like "``ifconfig``" to determine the
147 set of IP addresses on which it can be reached from nodes both near and
148 far. It will also include the TCP port number on which it is listening
149 (either the one specified by ``tub.port``, or whichever port was assigned
150 by the kernel when ``tub.port`` is left unspecified).
152 You might want to override this value if your node lives behind a
153 firewall that is doing inbound port forwarding, or if you are using other
154 proxies such that the local IP address or port number is not the same one
155 that remote clients should use to connect. You might also want to control
156 this when using a Tor proxy to avoid revealing your actual IP address
157 through the Introducer announcement.
159 The value is a comma-separated string of host:port location hints, like
162 123.45.67.89:8098,tahoe.example.com:8098,127.0.0.1:8098
166 * Emulate default behavior, assuming your host has IP address
167 123.45.67.89 and the kernel-allocated port number was 8098::
170 tub.location = 123.45.67.89:8098,127.0.0.1:8098
172 * Use a DNS name so you can change the IP address more easily::
175 tub.location = tahoe.example.com:8098
177 * Run a node behind a firewall (which has an external IP address) that
178 has been configured to forward port 7912 to our internal node's port
182 tub.location = external-firewall.example.com:7912
184 * Run a node behind a Tor proxy (perhaps via ``torsocks``), in
185 client-only mode (i.e. we can make outbound connections, but other
186 nodes will not be able to connect to us). The literal
187 '``unreachable.example.org``' will not resolve, but will serve as a
188 reminder to human observers that this node cannot be reached. "Don't
189 call us.. we'll call you"::
192 tub.location = unreachable.example.org:0
194 * Run a node behind a Tor proxy, and make the server available as a Tor
195 "hidden service". (This assumes that other clients are running their
196 node with ``torsocks``, such that they are prepared to connect to a
197 ``.onion`` address.) The hidden service must first be configured in
198 Tor, by giving it a local port number and then obtaining a ``.onion``
199 name, using something in the ``torrc`` file like::
201 HiddenServiceDir /var/lib/tor/hidden_services/tahoe
202 HiddenServicePort 29212 127.0.0.1:8098
204 once Tor is restarted, the ``.onion`` hostname will be in
205 ``/var/lib/tor/hidden_services/tahoe/hostname``. Then set up your
209 tub.location = ualhejtq2p7ohfbb.onion:29212
211 Most users will not need to set ``tub.location``.
213 ``log_gatherer.furl = (FURL, optional)``
215 If provided, this contains a single FURL string that is used to contact a
216 "log gatherer", which will be granted access to the logport. This can be
217 used to gather operational logs in a single place. Note that in previous
218 releases of Tahoe-LAFS, if an old-style ``BASEDIR/log_gatherer.furl``
219 file existed it would also be used in addition to this value, allowing
220 multiple log gatherers to be used at once. As of Tahoe-LAFS v1.9.0, an
221 old-style file is ignored and a warning will be emitted if one is
222 detected. This means that as of Tahoe-LAFS v1.9.0 you can have at most
223 one log gatherer per node. See ticket `#1423`_ about lifting this
224 restriction and letting you have multiple log gatherers.
226 .. _`#1423`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1423
228 ``timeout.keepalive = (integer in seconds, optional)``
230 ``timeout.disconnect = (integer in seconds, optional)``
232 If ``timeout.keepalive`` is provided, it is treated as an integral number
233 of seconds, and sets the Foolscap "keepalive timer" to that value. For
234 each connection to another node, if nothing has been heard for a while,
235 we will attempt to provoke the other end into saying something. The
236 duration of silence that passes before sending the PING will be between
237 KT and 2*KT. This is mainly intended to keep NAT boxes from expiring idle
238 TCP sessions, but also gives TCP's long-duration keepalive/disconnect
239 timers some traffic to work with. The default value is 240 (i.e. 4
242 If timeout.disconnect is provided, this is treated as an integral number
243 of seconds, and sets the Foolscap "disconnect timer" to that value. For
244 each connection to another node, if nothing has been heard for a while,
245 we will drop the connection. The duration of silence that passes before
246 dropping the connection will be between DT-2*KT and 2*DT+2*KT (please see
247 ticket `#521`_ for more details). If we are sending a large amount of
248 data to the other end (which takes more than DT-2*KT to deliver), we
249 might incorrectly drop the connection. The default behavior (when this
250 value is not provided) is to disable the disconnect timer.
252 See ticket `#521`_ for a discussion of how to pick these timeout values.
253 Using 30 minutes means we'll disconnect after 22 to 68 minutes of
254 inactivity. Receiving data will reset this timeout, however if we have
255 more than 22min of data in the outbound queue (such as 800kB in two
256 pipelined segments of 10 shares each) and the far end has no need to
257 contact us, our ping might be delayed, so we may disconnect them by
260 .. _`#521`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/521
262 ``ssh.port = (strports string, optional)``
264 ``ssh.authorized_keys_file = (filename, optional)``
266 This enables an SSH-based interactive Python shell, which can be used to
267 inspect the internal state of the node, for debugging. To cause the node
268 to accept SSH connections on port 8022 from the same keys as the rest of
273 ssh.authorized_keys_file = ~/.ssh/authorized_keys
275 ``tempdir = (string, optional)``
277 This specifies a temporary directory for the web-API server to use, for
278 holding large files while they are being uploaded. If a web-API client
279 attempts to upload a 10GB file, this tempdir will need to have at least
280 10GB available for the upload to complete.
282 The default value is the ``tmp`` directory in the node's base directory
283 (i.e. ``BASEDIR/tmp``), but it can be placed elsewhere. This directory is
284 used for files that usually (on a Unix system) go into ``/tmp``. The
285 string will be interpreted relative to the node's base directory.
293 ``introducer.furl = (FURL string, mandatory)``
295 This FURL tells the client how to connect to the introducer. Each
296 Tahoe-LAFS grid is defined by an introducer. The introducer's FURL is
297 created by the introducer node and written into its base directory when
298 it starts, whereupon it should be published to everyone who wishes to
299 attach a client to that grid
301 ``helper.furl = (FURL string, optional)``
303 If provided, the node will attempt to connect to and use the given helper
304 for uploads. See `<helper.rst>`_ for details.
306 ``key_generator.furl = (FURL string, optional)``
308 If provided, the node will attempt to connect to and use the given
309 key-generator service, using RSA keys from the external process rather
310 than generating its own.
312 ``stats_gatherer.furl = (FURL string, optional)``
314 If provided, the node will connect to the given stats gatherer and
315 provide it with operational statistics.
317 ``shares.needed = (int, optional) aka "k", default 3``
319 ``shares.total = (int, optional) aka "N", N >= k, default 10``
321 ``shares.happy = (int, optional) 1 <= happy <= N, default 7``
323 These three values set the default encoding parameters. Each time a new
324 file is uploaded, erasure-coding is used to break the ciphertext into
325 separate shares. There will be ``N`` (i.e. ``shares.total``) shares
326 created, and the file will be recoverable if any ``k``
327 (i.e. ``shares.needed``) shares are retrieved. The default values are
328 3-of-10 (i.e. ``shares.needed = 3``, ``shares.total = 10``). Setting
329 ``k`` to 1 is equivalent to simple replication (uploading ``N`` copies of
332 These values control the tradeoff between storage overhead and
333 reliability. To a first approximation, a 1MB file will use (1MB *
334 ``N``/``k``) of backend storage space (the actual value will be a bit
335 more, because of other forms of overhead). Up to ``N``-``k`` shares can
336 be lost before the file becomes unrecoverable. So large ``N``/``k``
337 ratios are more reliable, and small ``N``/``k`` ratios use less disk
338 space. ``N`` cannot be larger than 256, because of the 8-bit
339 erasure-coding algorithm that Tahoe-LAFS uses. ``k`` can not be greater
340 than ``N``. See `<performance.rst>`_ for more details.
342 ``shares.happy`` allows you control over how well to "spread out" the
343 shares of an immutable file. For a successful upload, shares are
344 guaranteed to be initially placed on at least ``shares.happy`` distinct
345 servers, the correct functioning of any ``k`` of which is sufficient to
346 guarantee the availability of the uploaded file. This value should not be
347 larger than the number of servers on your grid.
349 A value of ``shares.happy`` <= ``k`` is allowed, but does not provide any
350 redundancy if some servers fail or lose shares.
352 (Mutable files use a different share placement algorithm that does not
353 currently consider this parameter.)
355 ``mutable.format = sdmf or mdmf``
357 This value tells Tahoe-LAFS what the default mutable file format should
358 be. If ``mutable.format=sdmf``, then newly created mutable files will be
359 in the old SDMF format. This is desirable for clients that operate on
360 grids where some peers run older versions of Tahoe-LAFS, as these older
361 versions cannot read the new MDMF mutable file format. If
362 ``mutable.format`` is ``mdmf``, then newly created mutable files will use
363 the new MDMF format, which supports efficient in-place modification and
364 streaming downloads. You can overwrite this value using a special
365 mutable-type parameter in the webapi. If you do not specify a value here,
366 Tahoe-LAFS will use SDMF for all newly-created mutable files.
368 Note that this parameter applies only to files, not to directories.
369 Mutable directories, which are stored in mutable files, are not
370 controlled by this parameter and will always use SDMF. We may revisit
371 this decision in future versions of Tahoe-LAFS.
373 See `<frontends/specifications/mutable.rst>`_ for details about mutable
376 Frontend Configuration
377 ======================
379 The Tahoe client process can run a variety of frontend file-access protocols.
380 You will use these to create and retrieve files from the virtual filesystem.
381 Configuration details for each are documented in the following
382 protocol-specific guides:
386 Tahoe runs a webserver by default on port 3456. This interface provides a
387 human-oriented "WUI", with pages to create, modify, and browse
388 directories and files, as well as a number of pages to check on the
389 status of your Tahoe node. It also provides a machine-oriented "WAPI",
390 with a REST-ful HTTP interface that can be used by other programs
391 (including the CLI tools). Please see `<frontends/webapi.rst>`_ for full
392 details, and the ``web.port`` and ``web.static`` config variables above.
393 The `<frontends/download-status.rst>`_ document also describes a few WUI
398 The main "bin/tahoe" executable includes subcommands for manipulating the
399 filesystem, uploading/downloading files, and creating/running Tahoe
400 nodes. See `<frontends/CLI.rst>`_ for details.
404 Tahoe can also run both SFTP and FTP servers, and map a username/password
405 pair to a top-level Tahoe directory. See `<frontends/FTP-and-SFTP.rst>`_
406 for instructions on configuring these services, and the ``[sftpd]`` and
407 ``[ftpd]`` sections of ``tahoe.cfg``.
411 As of Tahoe-LAFS v1.9.0, a node running on Linux can be configured to
412 automatically upload files that are created or changed in a specified
413 local directory. See `<frontends/drop-upload.rst>`_ for details.
417 Storage Server Configuration
418 ============================
422 ``enabled = (boolean, optional)``
424 If this is ``True``, the node will run a storage server, offering space
425 to other clients. If it is ``False``, the node will not run a storage
426 server, meaning that no shares will be stored on this node. Use ``False``
427 for clients who do not wish to provide storage service. The default value
430 ``readonly = (boolean, optional)``
432 If ``True``, the node will run a storage server but will not accept any
433 shares, making it effectively read-only. Use this for storage servers
434 that are being decommissioned: the ``storage/`` directory could be
435 mounted read-only, while shares are moved to other servers. Note that
436 this currently only affects immutable shares. Mutable shares (used for
437 directories) will be written and modified anyway. See ticket `#390
438 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/390>`_ for the current
439 status of this bug. The default value is ``False``.
441 ``reserved_space = (str, optional)``
443 If provided, this value defines how much disk space is reserved: the
444 storage server will not accept any share that causes the amount of free
445 disk space to drop below this value. (The free space is measured by a
446 call to ``statvfs(2)`` on Unix, or ``GetDiskFreeSpaceEx`` on Windows, and
447 is the space available to the user account under which the storage server
450 This string contains a number, with an optional case-insensitive scale
451 suffix like "K" or "M" or "G", and an optional "B" or "iB" suffix. So
452 "100MB", "100M", "100000000B", "100000000", and "100000kb" all mean the
453 same thing. Likewise, "1MiB", "1024KiB", and "1048576B" all mean the same
456 "``tahoe create-node``" generates a tahoe.cfg with
457 "``reserved_space=1G``", but you may wish to raise, lower, or remove the
458 reservation to suit your needs.
464 ``expire.override_lease_duration =``
466 ``expire.cutoff_date =``
468 ``expire.immutable =``
472 These settings control garbage collection, in which the server will
473 delete shares that no longer have an up-to-date lease on them. Please see
474 `<garbage-collection.rst>`_ for full details.
480 A "helper" is a regular client node that also offers the "upload helper"
485 ``enabled = (boolean, optional)``
487 If ``True``, the node will run a helper (see `<helper.rst>`_ for
488 details). The helper's contact FURL will be placed in
489 ``private/helper.furl``, from which it can be copied to any clients that
490 wish to use it. Clearly nodes should not both run a helper and attempt to
491 use one: do not create ``helper.furl`` and also define
492 ``[helper]enabled`` in the same node. The default is ``False``.
495 Running An Introducer
496 =====================
498 The introducer node uses a different ``.tac`` file (named
499 "``introducer.tac``"), and pays attention to the ``[node]`` section, but not
502 The Introducer node maintains some different state than regular client nodes.
504 ``BASEDIR/introducer.furl``
506 This is generated the first time the introducer node is started, and used
507 again on subsequent runs, to give the introduction service a persistent
508 long-term identity. This file should be published and copied into new
509 client nodes before they are started for the first time.
512 Other Files in BASEDIR
513 ======================
515 Some configuration is not kept in ``tahoe.cfg``, for the following reasons:
517 * it is generated by the node at startup, e.g. encryption keys. The node
518 never writes to ``tahoe.cfg``.
519 * it is generated by user action, e.g. the "``tahoe create-alias``" command.
521 In addition, non-configuration persistent state is kept in the node's base
522 directory, next to the configuration knobs.
524 This section describes these other files.
528 This contains an SSL private-key certificate. The node generates this the
529 first time it is started, and re-uses it on subsequent runs. This
530 certificate allows the node to have a cryptographically-strong identifier
531 (the Foolscap "TubID"), and to establish secure connections to other nodes.
535 Nodes that host StorageServers will create this directory to hold shares of
536 files on behalf of other clients. There will be a directory underneath it
537 for each StorageIndex for which this node is holding shares. There is also
538 an "incoming" directory where partially-completed shares are held while
539 they are being received.
543 This file defines the client, by constructing the actual Client instance
544 each time the node is started. It is used by the "``twistd``" daemonization
545 program (in the ``-y`` mode), which is run internally by the "``tahoe
546 start``" command. This file is created by the "``tahoe create-node``" or
547 "``tahoe create-client``" commands.
549 ``tahoe-introducer.tac``
551 This file is used to construct an introducer, and is created by the
552 "``tahoe create-introducer``" command.
554 ``tahoe-key-generator.tac``
556 This file is used to construct a key generator, and is created by the
557 "``tahoe create-key-gernerator``" command.
559 ``tahoe-stats-gatherer.tac``
561 This file is used to construct a statistics gatherer, and is created by the
562 "``tahoe create-stats-gatherer``" command.
564 ``private/control.furl``
566 This file contains a FURL that provides access to a control port on the
567 client node, from which files can be uploaded and downloaded. This file is
568 created with permissions that prevent anyone else from reading it (on
569 operating systems that support such a concept), to insure that only the
570 owner of the client node can use this feature. This port is intended for
571 debugging and testing use.
573 ``private/logport.furl``
575 This file contains a FURL that provides access to a 'log port' on the
576 client node, from which operational logs can be retrieved. Do not grant
577 logport access to strangers, because occasionally secret information may be
580 ``private/helper.furl``
582 If the node is running a helper (for use by other clients), its contact
583 FURL will be placed here. See `<helper.rst>`_ for more details.
585 ``private/root_dir.cap`` (optional)
587 The command-line tools will read a directory cap out of this file and use
588 it, if you don't specify a '--dir-cap' option or if you specify
591 ``private/convergence`` (automatically generated)
593 An added secret for encrypting immutable files. Everyone who has this same
594 string in their ``private/convergence`` file encrypts their immutable files
595 in the same way when uploading them. This causes identical files to
596 "converge" -- to share the same storage space since they have identical
597 ciphertext -- which conserves space and optimizes upload time, but it also
598 exposes file contents to the possibility of a brute-force attack by people
599 who know that string. In this attack, if the attacker can guess most of the
600 contents of a file, then they can use brute-force to learn the remaining
603 So the set of people who know your ``private/convergence`` string is the
604 set of people who converge their storage space with you when you and they
605 upload identical immutable files, and it is also the set of people who
606 could mount such an attack.
608 The content of the ``private/convergence`` file is a base-32 encoded
609 string. If the file doesn't exist, then when the Tahoe-LAFS client starts
610 up it will generate a random 256-bit string and write the base-32 encoding
611 of this string into the file. If you want to converge your immutable files
612 with as many people as possible, put the empty string (so that
613 ``private/convergence`` is a zero-length file).
621 Each Tahoe-LAFS node creates a directory to hold the log messages produced
622 as the node runs. These logfiles are created and rotated by the
623 "``twistd``" daemonization program, so ``logs/twistd.log`` will contain the
624 most recent messages, ``logs/twistd.log.1`` will contain the previous ones,
625 ``logs/twistd.log.2`` will be older still, and so on. ``twistd`` rotates
626 logfiles after they grow beyond 1MB in size. If the space consumed by
627 logfiles becomes troublesome, they should be pruned: a cron job to delete
628 all files that were created more than a month ago in this ``logs/``
629 directory should be sufficient.
633 this is written by all nodes after startup, and contains a base32-encoded
634 (i.e. human-readable) NodeID that identifies this specific node. This
635 NodeID is the same string that gets displayed on the web page (in the
636 "which peers am I connected to" list), and the shortened form (the first
637 few characters) is recorded in various log messages.
641 Gateway nodes may find it necessary to prohibit access to certain
642 files. The web-API has a facility to block access to filecaps by their
643 storage index, returning a 403 "Forbidden" error instead of the original
644 file. For more details, see the "Access Blacklist" section of
645 `<frontends/webapi.rst>`_.
651 The following is a sample ``tahoe.cfg`` file, containing values for some of
652 the keys described in the previous section. Note that this is not a
653 recommended configuration (most of these are not the default values), merely
659 nickname = Bob's Tahoe-LAFS Node
661 tub.location = 123.45.67.89:8098,44.55.66.77:8098
663 log_gatherer.furl = pb://soklj4y7eok5c3xkmjeqpw@192.168.69.247:44801/eqpwqtzm
664 timeout.keepalive = 240
665 timeout.disconnect = 1800
667 ssh.authorized_keys_file = ~/.ssh/authorized_keys
670 introducer.furl = pb://ok45ssoklj4y7eok5c3xkmj@tahoe.example:44801/ii3uumo
671 helper.furl = pb://ggti5ssoklj4y7eok5c3xkmj@helper.tahoe.example:7054/kk8lhr
676 reserved_space = 10000000000
682 Old Configuration Files
683 =======================
685 Tahoe-LAFS releases before v1.3.0 had no ``tahoe.cfg`` file, and used
686 distinct files for each item. This is no longer supported and if you have
687 configuration in the old format you must manually convert it to the new
688 format for Tahoe-LAFS to detect it. See `<historical/configuration.rst>`_.