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