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