1 .. -*- coding: utf-8-with-signature -*-
3 =============================
4 Configuring a Tahoe-LAFS node
5 =============================
8 2. `Overall Node Configuration`_
9 3. `Client Configuration`_
10 4. `Storage Server Configuration`_
11 5. `Frontend Configuration`_
12 6. `Running A Helper`_
13 7. `Running An Introducer`_
14 8. `Other Files in BASEDIR`_
18 A Tahoe-LAFS node is configured by writing to files in its base directory.
19 These files are read by the node when it starts, so each time you change
20 them, you need to restart the node.
22 The node also writes state to its base directory, so it will create files on
25 This document contains a complete list of the config files that are examined
26 by the client node, as well as the state files that you'll observe in its
29 The main file is named "``tahoe.cfg``", and is an ".INI"-style configuration
30 file (parsed by the Python stdlib 'ConfigParser' module: "``[name]``" section
31 markers, lines with "``key.subkey: value``", rfc822-style
32 continuations). There are also other files containing information that does
33 not easily fit into this format. The "``tahoe create-node``" or "``tahoe
34 create-client``" command will create an initial ``tahoe.cfg`` file for
35 you. After creation, the node will never modify the ``tahoe.cfg`` file: all
36 persistent state is put in other files.
38 The item descriptions below use the following types:
42 one of (True, yes, on, 1, False, off, no, 0), case-insensitive
46 a Twisted listening-port specification string, like "``tcp:80``" or
47 "``tcp:3456:interface=127.0.0.1``". For a full description of the format,
48 see `the Twisted strports documentation`_. Please note, if interface= is
49 not specified, Tahoe-LAFS will attempt to bind the port specified on all
54 a Foolscap endpoint identifier, like
55 ``pb://soklj4y7eok5c3xkmjeqpw@192.168.69.247:44801/eqpwqtzm``
57 .. _the Twisted strports documentation: https://twistedmatrix.com/documents/current/api/twisted.application.strports.html
63 A node can be a client/server, an introducer, a statistics gatherer, or a
66 Client/server nodes provide one or more of the following services:
75 A client/server that provides storage service (i.e. storing shares for
76 clients) is called a "storage server". If it provides any of the other
77 services, it is a "storage client" (a node can be both a storage server and a
78 storage client). A client/server node that provides web-API service is called
82 Overall Node Configuration
83 ==========================
85 This section controls the network behavior of the node overall: which ports
86 and IP addresses are used, when connections are timed out, etc. This
87 configuration applies to all node types and is independent of the services
88 that the node is offering.
90 If your node is behind a firewall or NAT device and you want other clients to
91 connect to it, you'll need to open a port in the firewall or NAT, and specify
92 that port number in the tub.port option. If behind a NAT, you *may* need to
93 set the ``tub.location`` option described below.
97 ``nickname = (UTF-8 string, optional)``
99 This value will be displayed in management tools as this node's
100 "nickname". If not provided, the nickname will be set to "<unspecified>".
101 This string shall be a UTF-8 encoded Unicode string.
103 ``web.port = (strports string, optional)``
105 This controls where the node's web server should listen, providing node
106 status and, if the node is a client/server, providing web-API service as
107 defined in webapi.rst_.
109 This file contains a Twisted "strports" specification such as "``3456``"
110 or "``tcp:3456:interface=127.0.0.1``". The "``tahoe create-node``" or
111 "``tahoe create-client``" commands set the ``web.port`` to
112 "``tcp:3456:interface=127.0.0.1``" by default; this is overridable by the
113 ``--webport`` option. You can make it use SSL by writing
114 "``ssl:3456:privateKey=mykey.pem:certKey=cert.pem``" instead.
116 If this is not provided, the node will not run a web server.
118 ``web.static = (string, optional)``
120 This controls where the ``/static`` portion of the URL space is
121 served. The value is a directory name (``~username`` is allowed, and
122 non-absolute names are interpreted relative to the node's basedir), which
123 can contain HTML and other files. This can be used to serve a
124 Javascript-based frontend to the Tahoe-LAFS node, or other services.
126 The default value is "``public_html``", which will serve
127 ``BASEDIR/public_html`` . With the default settings,
128 ``http://127.0.0.1:3456/static/foo.html`` will serve the contents of
129 ``BASEDIR/public_html/foo.html`` .
131 ``tub.port = (integer, optional)``
133 This controls which port the node uses to accept Foolscap connections
134 from other nodes. If not provided, the node will ask the kernel for any
135 available port. The port will be written to a separate file (named
136 ``client.port`` or ``introducer.port``), so that subsequent runs will
137 re-use the same port.
139 ``tub.location = (string, optional)``
141 In addition to running as a client, each Tahoe-LAFS node also runs as a
142 server, listening for connections from other Tahoe-LAFS clients. The node
143 announces its location by publishing a "FURL" (a string with some
144 connection hints) to the Introducer. The string it publishes can be found
145 in ``BASEDIR/private/storage.furl`` . The ``tub.location`` configuration
146 controls what location is published in this announcement.
148 If you don't provide ``tub.location``, the node will try to figure out a
149 useful one by itself, by using tools like "``ifconfig``" to determine the
150 set of IP addresses on which it can be reached from nodes both near and
151 far. It will also include the TCP port number on which it is listening
152 (either the one specified by ``tub.port``, or whichever port was assigned
153 by the kernel when ``tub.port`` is left unspecified).
155 You might want to override this value if your node lives behind a
156 firewall that is doing inbound port forwarding, or if you are using other
157 proxies such that the local IP address or port number is not the same one
158 that remote clients should use to connect. You might also want to control
159 this when using a Tor proxy to avoid revealing your actual IP address
160 through the Introducer announcement.
162 If ``tub.location`` is specified, by default it entirely replaces the
163 automatically determined set of IP addresses. To include the automatically
164 determined addresses as well as the specified ones, include the uppercase
165 string "``AUTO``" in the list.
167 The value is a comma-separated string of host:port location hints, like
170 123.45.67.89:8098,tahoe.example.com:8098,127.0.0.1:8098
174 * Emulate default behavior, assuming your host has IP address
175 123.45.67.89 and the kernel-allocated port number was 8098::
178 tub.location = 123.45.67.89:8098,127.0.0.1:8098
180 * Use a DNS name so you can change the IP address more easily::
183 tub.location = tahoe.example.com:8098
185 * Use a DNS name but also include the default set of addresses::
188 tub.location = tahoe.example.com:8098,AUTO
190 * Run a node behind a firewall (which has an external IP address) that
191 has been configured to forward port 7912 to our internal node's port
195 tub.location = external-firewall.example.com:7912
197 * Run a node behind a Tor proxy (perhaps via ``torsocks``), in
198 client-only mode (i.e. we can make outbound connections, but other
199 nodes will not be able to connect to us). The literal
200 '``unreachable.example.org``' will not resolve, but will serve as a
201 reminder to human observers that this node cannot be reached. "Don't
202 call us.. we'll call you"::
205 tub.location = unreachable.example.org:0
207 * Run a node behind a Tor proxy, and make the server available as a Tor
208 "hidden service". (This assumes that other clients are running their
209 node with ``torsocks``, such that they are prepared to connect to a
210 ``.onion`` address.) The hidden service must first be configured in
211 Tor, by giving it a local port number and then obtaining a ``.onion``
212 name, using something in the ``torrc`` file like::
214 HiddenServiceDir /var/lib/tor/hidden_services/tahoe
215 HiddenServicePort 29212 127.0.0.1:8098
217 once Tor is restarted, the ``.onion`` hostname will be in
218 ``/var/lib/tor/hidden_services/tahoe/hostname``. Then set up your
222 tub.location = ualhejtq2p7ohfbb.onion:29212
224 Most users will not need to set ``tub.location``.
226 ``log_gatherer.furl = (FURL, optional)``
228 If provided, this contains a single FURL string that is used to contact a
229 "log gatherer", which will be granted access to the logport. This can be
230 used to gather operational logs in a single place. Note that in previous
231 releases of Tahoe-LAFS, if an old-style ``BASEDIR/log_gatherer.furl``
232 file existed it would also be used in addition to this value, allowing
233 multiple log gatherers to be used at once. As of Tahoe-LAFS v1.9.0, an
234 old-style file is ignored and a warning will be emitted if one is
235 detected. This means that as of Tahoe-LAFS v1.9.0 you can have at most
236 one log gatherer per node. See ticket `#1423`_ about lifting this
237 restriction and letting you have multiple log gatherers.
239 .. _`#1423`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1423
241 ``timeout.keepalive = (integer in seconds, optional)``
243 ``timeout.disconnect = (integer in seconds, optional)``
245 If ``timeout.keepalive`` is provided, it is treated as an integral number
246 of seconds, and sets the Foolscap "keepalive timer" to that value. For
247 each connection to another node, if nothing has been heard for a while,
248 we will attempt to provoke the other end into saying something. The
249 duration of silence that passes before sending the PING will be between
250 KT and 2*KT. This is mainly intended to keep NAT boxes from expiring idle
251 TCP sessions, but also gives TCP's long-duration keepalive/disconnect
252 timers some traffic to work with. The default value is 240 (i.e. 4
255 If timeout.disconnect is provided, this is treated as an integral number
256 of seconds, and sets the Foolscap "disconnect timer" to that value. For
257 each connection to another node, if nothing has been heard for a while,
258 we will drop the connection. The duration of silence that passes before
259 dropping the connection will be between DT-2*KT and 2*DT+2*KT (please see
260 ticket `#521`_ for more details). If we are sending a large amount of
261 data to the other end (which takes more than DT-2*KT to deliver), we
262 might incorrectly drop the connection. The default behavior (when this
263 value is not provided) is to disable the disconnect timer.
265 See ticket `#521`_ for a discussion of how to pick these timeout values.
266 Using 30 minutes means we'll disconnect after 22 to 68 minutes of
267 inactivity. Receiving data will reset this timeout, however if we have
268 more than 22min of data in the outbound queue (such as 800kB in two
269 pipelined segments of 10 shares each) and the far end has no need to
270 contact us, our ping might be delayed, so we may disconnect them by
273 .. _`#521`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/521
275 ``ssh.port = (strports string, optional)``
277 ``ssh.authorized_keys_file = (filename, optional)``
279 This enables an SSH-based interactive Python shell, which can be used to
280 inspect the internal state of the node, for debugging. To cause the node
281 to accept SSH connections on port 8022 from the same keys as the rest of
286 ssh.authorized_keys_file = ~/.ssh/authorized_keys
288 ``tempdir = (string, optional)``
290 This specifies a temporary directory for the web-API server to use, for
291 holding large files while they are being uploaded. If a web-API client
292 attempts to upload a 10GB file, this tempdir will need to have at least
293 10GB available for the upload to complete.
295 The default value is the ``tmp`` directory in the node's base directory
296 (i.e. ``BASEDIR/tmp``), but it can be placed elsewhere. This directory is
297 used for files that usually (on a Unix system) go into ``/tmp``. The
298 string will be interpreted relative to the node's base directory.
300 .. _webapi.rst: frontends/webapi.rst
308 ``introducer.furl = (FURL string, mandatory)``
310 This FURL tells the client how to connect to the introducer. Each
311 Tahoe-LAFS grid is defined by an introducer. The introducer's FURL is
312 created by the introducer node and written into its private base
313 directory when it starts, whereupon it should be published to everyone
314 who wishes to attach a client to that grid
316 ``helper.furl = (FURL string, optional)``
318 If provided, the node will attempt to connect to and use the given helper
319 for uploads. See helper.rst_ for details.
321 ``key_generator.furl = (FURL string, optional)``
323 If provided, the node will attempt to connect to and use the given
324 key-generator service, using RSA keys from the external process rather
325 than generating its own.
327 ``stats_gatherer.furl = (FURL string, optional)``
329 If provided, the node will connect to the given stats gatherer and
330 provide it with operational statistics.
332 ``shares.needed = (int, optional) aka "k", default 3``
334 ``shares.total = (int, optional) aka "N", N >= k, default 10``
336 ``shares.happy = (int, optional) 1 <= happy <= N, default 7``
338 These three values set the default encoding parameters. Each time a new
339 file is uploaded, erasure-coding is used to break the ciphertext into
340 separate shares. There will be ``N`` (i.e. ``shares.total``) shares
341 created, and the file will be recoverable if any ``k``
342 (i.e. ``shares.needed``) shares are retrieved. The default values are
343 3-of-10 (i.e. ``shares.needed = 3``, ``shares.total = 10``). Setting
344 ``k`` to 1 is equivalent to simple replication (uploading ``N`` copies of
347 These values control the tradeoff between storage overhead and
348 reliability. To a first approximation, a 1MB file will use (1MB *
349 ``N``/``k``) of backend storage space (the actual value will be a bit
350 more, because of other forms of overhead). Up to ``N``-``k`` shares can
351 be lost before the file becomes unrecoverable. So large ``N``/``k``
352 ratios are more reliable, and small ``N``/``k`` ratios use less disk
353 space. ``N`` cannot be larger than 256, because of the 8-bit
354 erasure-coding algorithm that Tahoe-LAFS uses. ``k`` can not be greater
355 than ``N``. See performance.rst_ for more details.
357 ``shares.happy`` allows you control over how well to "spread out" the
358 shares of an immutable file. For a successful upload, shares are
359 guaranteed to be initially placed on at least ``shares.happy`` distinct
360 servers, the correct functioning of any ``k`` of which is sufficient to
361 guarantee the availability of the uploaded file. This value should not be
362 larger than the number of servers on your grid.
364 A value of ``shares.happy`` <= ``k`` is allowed, but this is not
365 guaranteed to provide any redundancy if some servers fail or lose shares.
366 It may still provide redundancy in practice if ``N`` is greater than
367 the number of connected servers, because in that case there will typically
368 be more than one share on at least some storage nodes. However, since a
369 successful upload only guarantees that at least ``shares.happy`` shares
370 have been stored, the worst case is still that there is no redundancy.
372 (Mutable files use a different share placement algorithm that does not
373 currently consider this parameter.)
375 ``mutable.format = sdmf or mdmf``
377 This value tells Tahoe-LAFS what the default mutable file format should
378 be. If ``mutable.format=sdmf``, then newly created mutable files will be
379 in the old SDMF format. This is desirable for clients that operate on
380 grids where some peers run older versions of Tahoe-LAFS, as these older
381 versions cannot read the new MDMF mutable file format. If
382 ``mutable.format`` is ``mdmf``, then newly created mutable files will use
383 the new MDMF format, which supports efficient in-place modification and
384 streaming downloads. You can overwrite this value using a special
385 mutable-type parameter in the webapi. If you do not specify a value here,
386 Tahoe-LAFS will use SDMF for all newly-created mutable files.
388 Note that this parameter applies only to files, not to directories.
389 Mutable directories, which are stored in mutable files, are not
390 controlled by this parameter and will always use SDMF. We may revisit
391 this decision in future versions of Tahoe-LAFS.
393 See mutable.rst_ for details about mutable file formats.
395 .. _helper.rst: helper.rst
396 .. _performance.rst: performance.rst
397 .. _mutable.rst: specifications/mutable.rst
399 ``peers.preferred = (string, optional)``
401 This is an optional comma-separated list of Node IDs of servers that will
402 be tried first when selecting storage servers for reading or writing.
404 Servers should be identified here by their Node ID as it appears in the web
405 ui, underneath the server's nickname. For storage servers running tahoe
406 versions >=1.10 (if the introducer is also running tahoe >=1.10) this will
407 be a "Node Key" (which is prefixed with 'v0-'). For older nodes, it will be
408 a TubID instead. When a preferred server (and/or the introducer) is
409 upgraded to 1.10 or later, clients must adjust their configs accordingly.
411 Every node selected for upload, whether preferred or not, will still
412 receive the same number of shares (one, if there are ``N`` or more servers
413 accepting uploads). Preferred nodes are simply moved to the front of the
414 server selection lists computed for each file.
416 This is useful if a subset of your nodes have different availability or
417 connectivity characteristics than the rest of the grid. For instance, if
418 there are more than ``N`` servers on the grid, and ``K`` or more of them
419 are at a single physical location, it would make sense for clients at that
420 location to prefer their local servers so that they can maintain access to
421 all of their uploads without using the internet.
424 Frontend Configuration
425 ======================
427 The Tahoe client process can run a variety of frontend file-access protocols.
428 You will use these to create and retrieve files from the virtual filesystem.
429 Configuration details for each are documented in the following
430 protocol-specific guides:
434 Tahoe runs a webserver by default on port 3456. This interface provides a
435 human-oriented "WUI", with pages to create, modify, and browse
436 directories and files, as well as a number of pages to check on the
437 status of your Tahoe node. It also provides a machine-oriented "WAPI",
438 with a REST-ful HTTP interface that can be used by other programs
439 (including the CLI tools). Please see webapi.rst_ for full details, and
440 the ``web.port`` and ``web.static`` config variables above. The
441 `download-status.rst`_ document also describes a few WUI status pages.
445 The main "bin/tahoe" executable includes subcommands for manipulating the
446 filesystem, uploading/downloading files, and creating/running Tahoe
447 nodes. See CLI.rst_ for details.
451 Tahoe can also run both SFTP and FTP servers, and map a username/password
452 pair to a top-level Tahoe directory. See FTP-and-SFTP.rst_ for
453 instructions on configuring these services, and the ``[sftpd]`` and
454 ``[ftpd]`` sections of ``tahoe.cfg``.
458 As of Tahoe-LAFS v1.9.0, a node running on Linux can be configured to
459 automatically upload files that are created or changed in a specified
460 local directory. See drop-upload.rst_ for details.
462 .. _download-status.rst: frontends/download-status.rst
463 .. _CLI.rst: frontends/CLI.rst
464 .. _FTP-and-SFTP.rst: frontends/FTP-and-SFTP.rst
465 .. _drop-upload.rst: frontends/drop-upload.rst
468 Storage Server Configuration
469 ============================
473 ``enabled = (boolean, optional)``
475 If this is ``True``, the node will run a storage server, offering space
476 to other clients. If it is ``False``, the node will not run a storage
477 server, meaning that no shares will be stored on this node. Use ``False``
478 for clients who do not wish to provide storage service. The default value
481 ``readonly = (boolean, optional)``
483 If ``True``, the node will run a storage server but will not accept any
484 shares, making it effectively read-only. Use this for storage servers
485 that are being decommissioned: the ``storage/`` directory could be
486 mounted read-only, while shares are moved to other servers. Note that
487 this currently only affects immutable shares. Mutable shares (used for
488 directories) will be written and modified anyway. See ticket `#390`_ for
489 the current status of this bug. The default value is ``False``.
491 ``reserved_space = (str, optional)``
493 If provided, this value defines how much disk space is reserved: the
494 storage server will not accept any share that causes the amount of free
495 disk space to drop below this value. (The free space is measured by a
496 call to ``statvfs(2)`` on Unix, or ``GetDiskFreeSpaceEx`` on Windows, and
497 is the space available to the user account under which the storage server
500 This string contains a number, with an optional case-insensitive scale
501 suffix, optionally followed by "B" or "iB". The supported scale suffixes
502 are "K", "M", "G", "T", "P" and "E", and a following "i" indicates to use
503 powers of 1024 rather than 1000. So "100MB", "100 M", "100000000B",
504 "100000000", and "100000kb" all mean the same thing. Likewise, "1MiB",
505 "1024KiB", "1024 Ki", and "1048576 B" all mean the same thing.
507 "``tahoe create-node``" generates a tahoe.cfg with
508 "``reserved_space=1G``", but you may wish to raise, lower, or remove the
509 reservation to suit your needs.
515 ``expire.override_lease_duration =``
517 ``expire.cutoff_date =``
519 ``expire.immutable =``
523 These settings control garbage collection, in which the server will
524 delete shares that no longer have an up-to-date lease on them. Please see
525 garbage-collection.rst_ for full details.
527 .. _#390: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/390
528 .. _garbage-collection.rst: garbage-collection.rst
534 A "helper" is a regular client node that also offers the "upload helper"
539 ``enabled = (boolean, optional)``
541 If ``True``, the node will run a helper (see helper.rst_ for details).
542 The helper's contact FURL will be placed in ``private/helper.furl``, from
543 which it can be copied to any clients that wish to use it. Clearly nodes
544 should not both run a helper and attempt to use one: do not create
545 ``helper.furl`` and also define ``[helper]enabled`` in the same node.
546 The default is ``False``.
549 Running An Introducer
550 =====================
552 The introducer node uses a different ``.tac`` file (named
553 "``introducer.tac``"), and pays attention to the ``[node]`` section, but not
556 The Introducer node maintains some different state than regular client nodes.
558 ``BASEDIR/private/introducer.furl``
560 This is generated the first time the introducer node is started, and used
561 again on subsequent runs, to give the introduction service a persistent
562 long-term identity. This file should be published and copied into new
563 client nodes before they are started for the first time.
566 Other Files in BASEDIR
567 ======================
569 Some configuration is not kept in ``tahoe.cfg``, for the following reasons:
571 * it is generated by the node at startup, e.g. encryption keys. The node
572 never writes to ``tahoe.cfg``.
573 * it is generated by user action, e.g. the "``tahoe create-alias``" command.
575 In addition, non-configuration persistent state is kept in the node's base
576 directory, next to the configuration knobs.
578 This section describes these other files.
582 This contains an SSL private-key certificate. The node generates this the
583 first time it is started, and re-uses it on subsequent runs. This
584 certificate allows the node to have a cryptographically-strong identifier
585 (the Foolscap "TubID"), and to establish secure connections to other nodes.
589 Nodes that host StorageServers will create this directory to hold shares of
590 files on behalf of other clients. There will be a directory underneath it
591 for each StorageIndex for which this node is holding shares. There is also
592 an "incoming" directory where partially-completed shares are held while
593 they are being received.
597 This file defines the client, by constructing the actual Client instance
598 each time the node is started. It is used by the "``twistd``" daemonization
599 program (in the ``-y`` mode), which is run internally by the "``tahoe
600 start``" command. This file is created by the "``tahoe create-node``" or
601 "``tahoe create-client``" commands.
603 ``tahoe-introducer.tac``
605 This file is used to construct an introducer, and is created by the
606 "``tahoe create-introducer``" command.
608 ``tahoe-key-generator.tac``
610 This file is used to construct a key generator, and is created by the
611 "``tahoe create-key-gernerator``" command.
613 ``tahoe-stats-gatherer.tac``
615 This file is used to construct a statistics gatherer, and is created by the
616 "``tahoe create-stats-gatherer``" command.
618 ``private/control.furl``
620 This file contains a FURL that provides access to a control port on the
621 client node, from which files can be uploaded and downloaded. This file is
622 created with permissions that prevent anyone else from reading it (on
623 operating systems that support such a concept), to insure that only the
624 owner of the client node can use this feature. This port is intended for
625 debugging and testing use.
627 ``private/logport.furl``
629 This file contains a FURL that provides access to a 'log port' on the
630 client node, from which operational logs can be retrieved. Do not grant
631 logport access to strangers, because occasionally secret information may be
634 ``private/helper.furl``
636 If the node is running a helper (for use by other clients), its contact
637 FURL will be placed here. See helper.rst_ for more details.
639 ``private/root_dir.cap`` (optional)
641 The command-line tools will read a directory cap out of this file and use
642 it, if you don't specify a '--dir-cap' option or if you specify
645 ``private/convergence`` (automatically generated)
647 An added secret for encrypting immutable files. Everyone who has this same
648 string in their ``private/convergence`` file encrypts their immutable files
649 in the same way when uploading them. This causes identical files to
650 "converge" -- to share the same storage space since they have identical
651 ciphertext -- which conserves space and optimizes upload time, but it also
652 exposes file contents to the possibility of a brute-force attack by people
653 who know that string. In this attack, if the attacker can guess most of the
654 contents of a file, then they can use brute-force to learn the remaining
657 So the set of people who know your ``private/convergence`` string is the
658 set of people who converge their storage space with you when you and they
659 upload identical immutable files, and it is also the set of people who
660 could mount such an attack.
662 The content of the ``private/convergence`` file is a base-32 encoded
663 string. If the file doesn't exist, then when the Tahoe-LAFS client starts
664 up it will generate a random 256-bit string and write the base-32 encoding
665 of this string into the file. If you want to converge your immutable files
666 with as many people as possible, put the empty string (so that
667 ``private/convergence`` is a zero-length file).
675 Each Tahoe-LAFS node creates a directory to hold the log messages produced
676 as the node runs. These logfiles are created and rotated by the
677 "``twistd``" daemonization program, so ``logs/twistd.log`` will contain the
678 most recent messages, ``logs/twistd.log.1`` will contain the previous ones,
679 ``logs/twistd.log.2`` will be older still, and so on. ``twistd`` rotates
680 logfiles after they grow beyond 1MB in size. If the space consumed by
681 logfiles becomes troublesome, they should be pruned: a cron job to delete
682 all files that were created more than a month ago in this ``logs/``
683 directory should be sufficient.
687 this is written by all nodes after startup, and contains a base32-encoded
688 (i.e. human-readable) NodeID that identifies this specific node. This
689 NodeID is the same string that gets displayed on the web page (in the
690 "which peers am I connected to" list), and the shortened form (the first
691 few characters) is recorded in various log messages.
695 Gateway nodes may find it necessary to prohibit access to certain
696 files. The web-API has a facility to block access to filecaps by their
697 storage index, returning a 403 "Forbidden" error instead of the original
698 file. For more details, see the "Access Blacklist" section of
705 The following is a sample ``tahoe.cfg`` file, containing values for some of
706 the keys described in the previous section. Note that this is not a
707 recommended configuration (most of these are not the default values), merely
713 nickname = Bob's Tahoe-LAFS Node
715 tub.location = 123.45.67.89:8098,44.55.66.77:8098
717 log_gatherer.furl = pb://soklj4y7eok5c3xkmjeqpw@192.168.69.247:44801/eqpwqtzm
718 timeout.keepalive = 240
719 timeout.disconnect = 1800
721 ssh.authorized_keys_file = ~/.ssh/authorized_keys
724 introducer.furl = pb://ok45ssoklj4y7eok5c3xkmj@tahoe.example:44801/ii3uumo
725 helper.furl = pb://ggti5ssoklj4y7eok5c3xkmj@helper.tahoe.example:7054/kk8lhr
730 reserved_space = 10000000000
736 Old Configuration Files
737 =======================
739 Tahoe-LAFS releases before v1.3.0 had no ``tahoe.cfg`` file, and used
740 distinct files for each item. This is no longer supported and if you have
741 configuration in the old format you must manually convert it to the new
742 format for Tahoe-LAFS to detect it. See `historical/configuration.rst`_.
744 .. _historical/configuration.rst: historical/configuration.rst