docs/configuration.rst

   1 =============================
   2 Configuring a Tahoe-LAFS node
   3 =============================
   4
   5 1.  `Overall Node Configuration`_
   6 2.  `Client Configuration`_
   7 3.  `Storage Server Configuration`_
   8 4.  `Frontend Configuration`_
   9 5.  `Running A Helper`_
  10 6.  `Running An Introducer`_
  11 7.  `Other Files in BASEDIR`_
  12 8.  `Other files`_
  13 9.  `Backwards Compatibility Files`_
  14 10. `Example`_
  15
  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.
  19
  20 The node also writes state to its base directory, so it will create files on
  21 its own.
  22
  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
  25 base directory.
  26
  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.
  35
  36 The item descriptions below use the following types:
  37
  38 ``boolean``
  39
  40     one of (True, yes, on, 1, False, off, no, 0), case-insensitive
  41
  42 ``strports string``
  43
  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>`_.
  48
  49 ``FURL string``
  50
  51     a Foolscap endpoint identifier, like
  52     ``pb://soklj4y7eok5c3xkmjeqpw@192.168.69.247:44801/eqpwqtzm``
  53
  54
  55 Overall Node Configuration
  56 ==========================
  57
  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.
  62
  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.
  67
  68 ``[node]``
  69
  70 ``nickname = (UTF-8 string, optional)``
  71
  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.
  75
  76 ``web.port = (strports string, optional)``
  77
  78     This controls where the node's webserver should listen, providing
  79     filesystem access and node status as defined in
  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.
  86
  87     If this is not provided, the node will not run a web server.
  88
  89 ``web.static = (string, optional)``
  90
  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.
  96
  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`` .
 101
 102 ``tub.port = (integer, optional)``
 103
 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.
 109
 110 ``tub.location = (string, optional)``
 111
 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.
 118
 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).
 125
 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.
 132
 133     The value is a comma-separated string of host:port location hints, like
 134     this::
 135
 136       123.45.67.89:8098,tahoe.example.com:8098,127.0.0.1:8098
 137
 138     A few examples:
 139
 140     * Emulate default behavior, assuming your host has IP address
 141       123.45.67.89 and the kernel-allocated port number was 8098::
 142
 143         tub.port = 8098
 144         tub.location = 123.45.67.89:8098,127.0.0.1:8098
 145
 146     * Use a DNS name so you can change the IP address more easily::
 147
 148         tub.port = 8098
 149         tub.location = tahoe.example.com:8098
 150
 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
 153       8098::
 154
 155         tub.port = 8098
 156         tub.location = external-firewall.example.com:7912
 157
 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"::
 164
 165         tub.port = 8098
 166         tub.location = unreachable.example.org:0
 167
 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::
 174
 175         HiddenServiceDir /var/lib/tor/hidden_services/tahoe
 176         HiddenServicePort 29212 127.0.0.1:8098
 177
 178       once Tor is restarted, the ``.onion`` hostname will be in
 179       ``/var/lib/tor/hidden_services/tahoe/hostname``. Then set up your
 180       ``tahoe.cfg`` like::
 181
 182         tub.port = 8098
 183         tub.location = ualhejtq2p7ohfbb.onion:29212
 184
 185     Most users will not need to set ``tub.location``.
 186
 187 ``log_gatherer.furl = (FURL, optional)``
 188
 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.
 199
 200     .. _`#1423`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1423
 201
 202 ``timeout.keepalive = (integer in seconds, optional)``
 203
 204 ``timeout.disconnect = (integer in seconds, optional)``
 205
 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
 214     minutes).
 215
 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.
 225
 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
 232     accident.
 233
 234     .. _`#521`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/521
 235
 236 ``ssh.port = (strports string, optional)``
 237
 238 ``ssh.authorized_keys_file = (filename, optional)``
 239
 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
 243     your account, use::
 244
 245       [tub]
 246       ssh.port = 8022
 247       ssh.authorized_keys_file = ~/.ssh/authorized_keys
 248
 249 ``tempdir = (string, optional)``
 250
 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.
 255
 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.
 260
 261
 262 Client Configuration
 263 ====================
 264
 265 ``[client]``
 266
 267 ``introducer.furl = (FURL string, mandatory)``
 268
 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
 274
 275 ``helper.furl = (FURL string, optional)``
 276
 277     If provided, the node will attempt to connect to and use the given helper
 278     for uploads. See `<helper.rst>`_ for details.
 279
 280 ``key_generator.furl = (FURL string, optional)``
 281
 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.
 285
 286 ``stats_gatherer.furl = (FURL string, optional)``
 287
 288     If provided, the node will connect to the given stats gatherer and
 289     provide it with operational statistics.
 290
 291 ``shares.needed = (int, optional) aka "k", default 3``
 292
 293 ``shares.total = (int, optional) aka "N", N >= k, default 10``
 294
 295 ``shares.happy = (int, optional) 1 <= happy <= N, default 7``
 296
 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 shares. There will be ``N`` (i.e. ``shares.total``) shares
 300     created, and the file will be recoverable if any ``k``
 301     (i.e. ``shares.needed``) shares 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
 304     the file).
 305
 306     These values control the tradeoff between storage overhead and
 307     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 large ``N``/``k``
 311     ratios are more reliable, and small ``N``/``k`` ratios use less disk
 312     space. ``N`` cannot be larger than 256, because of the 8-bit
 313     erasure-coding algorithm that Tahoe-LAFS uses. ``k`` can not be greater
 314     than ``N``. See `<performance.rst>`_ for more details.
 315
 316     ``shares.happy`` allows you control over how well to "spread out" the
 317     shares of an immutable file. For a successful upload, shares are
 318     guaranteed to be initially placed on at least ``shares.happy`` distinct
 319     servers, the correct functioning of any ``k`` of which is sufficient to
 320     guarantee the availability of the uploaded file. This value should not be
 321     larger than the number of servers on your grid.
 322
 323     A value of ``shares.happy`` <= ``k`` is allowed, but does not provide any
 324     redundancy if some servers fail or lose shares.
 325
 326     (Mutable files use a different share placement algorithm that does not
 327     currently consider this parameter.)
 328
 329 ``mutable.format = sdmf or mdmf``
 330
 331     This value tells Tahoe-LAFS what the default mutable file format should
 332     be. If ``mutable.format=sdmf``, then newly created mutable files will be
 333     in the old SDMF format. This is desirable for clients that operate on
 334     grids where some peers run older versions of Tahoe-LAFS, as these older
 335     versions cannot read the new MDMF mutable file format. If
 336     ``mutable.format`` is ``mdmf``, then newly created mutable files will use
 337     the new MDMF format, which supports efficient in-place modification and
 338     streaming downloads. You can overwrite this value using a special
 339     mutable-type parameter in the webapi. If you do not specify a value here,
 340     Tahoe-LAFS will use SDMF for all newly-created mutable files.
 341
 342     Note that this parameter only applies to mutable files. Mutable
 343     directories, which are stored as mutable files, are not controlled by
 344     this parameter and will always use SDMF. We may revisit this decision
 345     in future versions of Tahoe-LAFS.
 346
 347 Frontend Configuration
 348 ======================
 349
 350 The Tahoe client process can run a variety of frontend file-access protocols.
 351 You will use these to create and retrieve files from the virtual filesystem.
 352 Configuration details for each are documented in the following
 353 protocol-specific guides:
 354
 355 HTTP
 356
 357     Tahoe runs a webserver by default on port 3456. This interface provides a
 358     human-oriented "WUI", with pages to create, modify, and browse
 359     directories and files, as well as a number of pages to check on the
 360     status of your Tahoe node. It also provides a machine-oriented "WAPI",
 361     with a REST-ful HTTP interface that can be used by other programs
 362     (including the CLI tools). Please see `<frontends/webapi.rst>`_ for full
 363     details, and the ``web.port`` and ``web.static`` config variables above.
 364     The `<frontends/download-status.rst>`_ document also describes a few WUI
 365     status pages.
 366
 367 CLI
 368
 369     The main "bin/tahoe" executable includes subcommands for manipulating the
 370     filesystem, uploading/downloading files, and creating/running Tahoe
 371     nodes. See `<frontends/CLI.rst>`_ for details.
 372
 373 FTP, SFTP
 374
 375     Tahoe can also run both FTP and SFTP servers, and map a username/password
 376     pair to a top-level Tahoe directory. See `<frontends/FTP-and-SFTP.rst>`_
 377     for instructions on configuring these services, and the ``[ftpd]`` and
 378     ``[sftpd]`` sections of ``tahoe.cfg``.
 379
 380 Drop-Upload
 381
 382     As of Tahoe-LAFS v1.9.0, a node running on Linux can be configured to
 383     automatically upload files that are created or changed in a specified
 384     local directory. See `<frontends/drop_upload.rst>`_ for details.
 385
 386
 387
 388 Storage Server Configuration
 389 ============================
 390
 391 ``[storage]``
 392
 393 ``enabled = (boolean, optional)``
 394
 395     If this is ``True``, the node will run a storage server, offering space
 396     to other clients. If it is ``False``, the node will not run a storage
 397     server, meaning that no shares will be stored on this node. Use ``False``
 398     for clients who do not wish to provide storage service. The default value
 399     is ``True``.
 400
 401 ``readonly = (boolean, optional)``
 402
 403     If ``True``, the node will run a storage server but will not accept any
 404     shares, making it effectively read-only. Use this for storage servers
 405     that are being decommissioned: the ``storage/`` directory could be
 406     mounted read-only, while shares are moved to other servers. Note that
 407     this currently only affects immutable shares. Mutable shares (used for
 408     directories) will be written and modified anyway. See ticket `#390
 409     <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/390>`_ for the current
 410     status of this bug. The default value is ``False``.
 411
 412 ``reserved_space = (str, optional)``
 413
 414     If provided, this value defines how much disk space is reserved: the
 415     storage server will not accept any share that causes the amount of free
 416     disk space to drop below this value. (The free space is measured by a
 417     call to statvfs(2) on Unix, or GetDiskFreeSpaceEx on Windows, and is the
 418     space available to the user account under which the storage server runs.)
 419
 420     This string contains a number, with an optional case-insensitive scale
 421     suffix like "K" or "M" or "G", and an optional "B" or "iB" suffix. So
 422     "100MB", "100M", "100000000B", "100000000", and "100000kb" all mean the
 423     same thing. Likewise, "1MiB", "1024KiB", and "1048576B" all mean the same
 424     thing.
 425
 426     "``tahoe create-node``" generates a tahoe.cfg with
 427     "``reserved_space=1G``", but you may wish to raise, lower, or remove the
 428     reservation to suit your needs.
 429
 430 ``expire.enabled =``
 431
 432 ``expire.mode =``
 433
 434 ``expire.override_lease_duration =``
 435
 436 ``expire.cutoff_date =``
 437
 438 ``expire.immutable =``
 439
 440 ``expire.mutable =``
 441
 442     These settings control garbage collection, in which the server will
 443     delete shares that no longer have an up-to-date lease on them. Please see
 444     `<garbage-collection.rst>`_ for full details.
 445
 446
 447 Running A Helper
 448 ================
 449
 450 A "helper" is a regular client node that also offers the "upload helper"
 451 service.
 452
 453 ``[helper]``
 454
 455 ``enabled = (boolean, optional)``
 456
 457     If ``True``, the node will run a helper (see `<helper.rst>`_ for
 458     details).  The helper's contact FURL will be placed in
 459     ``private/helper.furl``, from which it can be copied to any clients that
 460     wish to use it. Clearly nodes should not both run a helper and attempt to
 461     use one: do not create ``helper.furl`` and also define
 462     ``[helper]enabled`` in the same node.  The default is ``False``.
 463
 464
 465 Running An Introducer
 466 =====================
 467
 468 The introducer node uses a different ``.tac`` file (named
 469 "``introducer.tac``"), and pays attention to the ``[node]`` section, but not
 470 the others.
 471
 472 The Introducer node maintains some different state than regular client nodes.
 473
 474 ``BASEDIR/introducer.furl``
 475
 476   This is generated the first time the introducer node is started, and used
 477   again on subsequent runs, to give the introduction service a persistent
 478   long-term identity. This file should be published and copied into new
 479   client nodes before they are started for the first time.
 480
 481
 482 Other Files in BASEDIR
 483 ======================
 484
 485 Some configuration is not kept in ``tahoe.cfg``, for the following reasons:
 486
 487 * it is generated by the node at startup, e.g. encryption keys. The node
 488   never writes to ``tahoe.cfg``.
 489 * it is generated by user action, e.g. the "``tahoe create-alias``" command.
 490
 491 In addition, non-configuration persistent state is kept in the node's base
 492 directory, next to the configuration knobs.
 493
 494 This section describes these other files.
 495
 496 ``private/node.pem``
 497
 498   This contains an SSL private-key certificate. The node generates this the
 499   first time it is started, and re-uses it on subsequent runs. This
 500   certificate allows the node to have a cryptographically-strong identifier
 501   (the Foolscap "TubID"), and to establish secure connections to other nodes.
 502
 503 ``storage/``
 504
 505   Nodes that host StorageServers will create this directory to hold shares of
 506   files on behalf of other clients. There will be a directory underneath it
 507   for each StorageIndex for which this node is holding shares. There is also
 508   an "incoming" directory where partially-completed shares are held while
 509   they are being received.
 510
 511 ``tahoe-client.tac``
 512
 513   This file defines the client, by constructing the actual Client instance
 514   each time the node is started. It is used by the "``twistd``" daemonization
 515   program (in the ``-y`` mode), which is run internally by the "``tahoe
 516   start``" command. This file is created by the "``tahoe create-node``" or
 517   "``tahoe create-client``" commands.
 518
 519 ``tahoe-introducer.tac``
 520
 521   This file is used to construct an introducer, and is created by the
 522   "``tahoe create-introducer``" command.
 523
 524 ``tahoe-key-generator.tac``
 525
 526   This file is used to construct a key generator, and is created by the
 527   "``tahoe create-key-gernerator``" command.
 528
 529 ``tahoe-stats-gatherer.tac``
 530
 531   This file is used to construct a statistics gatherer, and is created by the
 532   "``tahoe create-stats-gatherer``" command.
 533
 534 ``private/control.furl``
 535
 536   This file contains a FURL that provides access to a control port on the
 537   client node, from which files can be uploaded and downloaded. This file is
 538   created with permissions that prevent anyone else from reading it (on
 539   operating systems that support such a concept), to insure that only the
 540   owner of the client node can use this feature. This port is intended for
 541   debugging and testing use.
 542
 543 ``private/logport.furl``
 544
 545   This file contains a FURL that provides access to a 'log port' on the
 546   client node, from which operational logs can be retrieved. Do not grant
 547   logport access to strangers, because occasionally secret information may be
 548   placed in the logs.
 549
 550 ``private/helper.furl``
 551
 552   If the node is running a helper (for use by other clients), its contact
 553   FURL will be placed here. See `<helper.rst>`_ for more details.
 554
 555 ``private/root_dir.cap`` (optional)
 556
 557   The command-line tools will read a directory cap out of this file and use
 558   it, if you don't specify a '--dir-cap' option or if you specify
 559   '--dir-cap=root'.
 560
 561 ``private/convergence`` (automatically generated)
 562
 563   An added secret for encrypting immutable files. Everyone who has this same
 564   string in their ``private/convergence`` file encrypts their immutable files
 565   in the same way when uploading them. This causes identical files to
 566   "converge" -- to share the same storage space since they have identical
 567   ciphertext -- which conserves space and optimizes upload time, but it also
 568   exposes file contents to the possibility of a brute-force attack by people
 569   who know that string. In this attack, if the attacker can guess most of the
 570   contents of a file, then they can use brute-force to learn the remaining
 571   contents.
 572
 573   So the set of people who know your ``private/convergence`` string is the
 574   set of people who converge their storage space with you when you and they
 575   upload identical immutable files, and it is also the set of people who
 576   could mount such an attack.
 577
 578   The content of the ``private/convergence`` file is a base-32 encoded
 579   string.  If the file doesn't exist, then when the Tahoe-LAFS client starts
 580   up it will generate a random 256-bit string and write the base-32 encoding
 581   of this string into the file. If you want to converge your immutable files
 582   with as many people as possible, put the empty string (so that
 583   ``private/convergence`` is a zero-length file).
 584
 585
 586 Other files
 587 ===========
 588
 589 ``logs/``
 590
 591   Each Tahoe-LAFS node creates a directory to hold the log messages produced
 592   as the node runs. These logfiles are created and rotated by the
 593   "``twistd``" daemonization program, so ``logs/twistd.log`` will contain the
 594   most recent messages, ``logs/twistd.log.1`` will contain the previous ones,
 595   ``logs/twistd.log.2`` will be older still, and so on. ``twistd`` rotates
 596   logfiles after they grow beyond 1MB in size. If the space consumed by
 597   logfiles becomes troublesome, they should be pruned: a cron job to delete
 598   all files that were created more than a month ago in this ``logs/``
 599   directory should be sufficient.
 600
 601 ``my_nodeid``
 602
 603   this is written by all nodes after startup, and contains a base32-encoded
 604   (i.e. human-readable) NodeID that identifies this specific node. This
 605   NodeID is the same string that gets displayed on the web page (in the
 606   "which peers am I connected to" list), and the shortened form (the first
 607   few characters) is recorded in various log messages.
 608
 609 ``access.blacklist``
 610
 611   Gateway nodes may find it necessary to prohibit access to certain files. The
 612   web-API has a facility to block access to filecaps by their storage index,
 613   returning a 403 "Forbidden" error instead of the original file. For more
 614   details, see the "Access Blacklist" section of `<frontends/webapi.rst>`_.
 615
 616
 617 Example
 618 =======
 619
 620 The following is a sample ``tahoe.cfg`` file, containing values for some of
 621 the keys described in the previous section. Note that this is not a
 622 recommended configuration (most of these are not the default values), merely
 623 a legal one.
 624
 625 ::
 626
 627   [node]
 628   nickname = Bob's Tahoe-LAFS Node
 629   tub.port = 34912
 630   tub.location = 123.45.67.89:8098,44.55.66.77:8098
 631   web.port = 3456
 632   log_gatherer.furl = pb://soklj4y7eok5c3xkmjeqpw@192.168.69.247:44801/eqpwqtzm
 633   timeout.keepalive = 240
 634   timeout.disconnect = 1800
 635   ssh.port = 8022
 636   ssh.authorized_keys_file = ~/.ssh/authorized_keys
 637
 638
 639   [client]
 640   introducer.furl = pb://ok45ssoklj4y7eok5c3xkmj@tahoe.example:44801/ii3uumo
 641   helper.furl = pb://ggti5ssoklj4y7eok5c3xkmj@helper.tahoe.example:7054/kk8lhr
 642
 643
 644   [storage]
 645   enabled = True
 646   readonly = True
 647   sizelimit = 10000000000
 648
 649
 650   [helper]
 651   enabled = True
 652
 653
 654 Old Configuration Files
 655 =======================
 656
 657 Tahoe-LAFS releases before v1.3.0 had no ``tahoe.cfg`` file, and used
 658 distinct files for each item. This is no longer supported and if you have
 659 configuration in the old format you must manually convert it to the new
 660 format for Tahoe-LAFS to detect it. See `<historical/configuration.rst>`_.