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 ``ssh.port = (strports string, optional)``
 225
 226 ``ssh.authorized_keys_file = (filename, optional)``
 227
 228     This enables an SSH-based interactive Python shell, which can be used to
 229     inspect the internal state of the node, for debugging. To cause the node
 230     to accept SSH connections on port 8022 from the same keys as the rest of
 231     your account, use::
 232
 233       [tub]
 234       ssh.port = 8022
 235       ssh.authorized_keys_file = ~/.ssh/authorized_keys
 236
 237 ``tempdir = (string, optional)``
 238
 239     This specifies a temporary directory for the webapi server to use, for
 240     holding large files while they are being uploaded. If a webapi client
 241     attempts to upload a 10GB file, this tempdir will need to have at least
 242     10GB available for the upload to complete.
 243
 244     The default value is the ``tmp`` directory in the node's base directory
 245     (i.e. ``BASEDIR/tmp``), but it can be placed elsewhere. This directory is
 246     used for files that usually (on a Unix system) go into ``/tmp``. The string
 247     will be interpreted relative to the node's base directory.
 248
 249 Client Configuration
 250 ====================
 251
 252 ``[client]``
 253
 254 ``introducer.furl = (FURL string, mandatory)``
 255
 256     This FURL tells the client how to connect to the introducer. Each Tahoe-LAFS
 257     grid is defined by an introducer. The introducer's FURL is created by the
 258     introducer node and written into its base directory when it starts,
 259     whereupon it should be published to everyone who wishes to attach a
 260     client to that grid
 261
 262 ``helper.furl = (FURL string, optional)``
 263
 264     If provided, the node will attempt to connect to and use the given helper
 265     for uploads. See `<helper.rst>`_ for details.
 266
 267 ``key_generator.furl = (FURL string, optional)``
 268
 269     If provided, the node will attempt to connect to and use the given
 270     key-generator service, using RSA keys from the external process rather
 271     than generating its own.
 272
 273 ``stats_gatherer.furl = (FURL string, optional)``
 274
 275     If provided, the node will connect to the given stats gatherer and
 276     provide it with operational statistics.
 277
 278 ``shares.needed = (int, optional) aka "k", default 3``
 279
 280 ``shares.total = (int, optional) aka "N", N >= k, default 10``
 281
 282 ``shares.happy = (int, optional) 1 <= happy <= N, default 7``
 283
 284     These three values set the default encoding parameters. Each time a new
 285     file is uploaded, erasure-coding is used to break the ciphertext into
 286     separate pieces. There will be ``N`` (i.e. ``shares.total``) pieces created,
 287     and the file will be recoverable if any ``k`` (i.e. ``shares.needed``)
 288     pieces are retrieved. The default values are 3-of-10 (i.e.
 289     ``shares.needed = 3``, ``shares.total = 10``). Setting ``k`` to 1 is
 290     equivalent to simple replication (uploading ``N`` copies of the file).
 291
 292     These values control the tradeoff between storage overhead, performance,
 293     and reliability. To a first approximation, a 1MB file will use (1MB * ``N``/``k``)
 294     of backend storage space (the actual value will be a bit more, because of
 295     other forms of overhead). Up to ``N``-``k`` shares can be lost before the file
 296     becomes unrecoverable, so assuming there are at least ``N`` servers, up to
 297     ``N``-``k`` servers can be offline without losing the file. So large ``N``/``k``
 298     ratios are more reliable, and small ``N``/``k`` ratios use less disk space.
 299     Clearly, ``k`` must never be smaller than ``N``.
 300
 301     Large values of ``N`` will slow down upload operations slightly, since more
 302     servers must be involved, and will slightly increase storage overhead due
 303     to the hash trees that are created. Large values of ``k`` will cause
 304     downloads to be marginally slower, because more servers must be involved.
 305     ``N`` cannot be larger than 256, because of the 8-bit erasure-coding
 306     algorithm that Tahoe-LAFS uses.
 307
 308     ``shares.happy`` allows you control over the distribution of your immutable
 309     file. For a successful upload, shares are guaranteed to be initially
 310     placed on at least ``shares.happy`` distinct servers, the correct
 311     functioning of any ``k`` of which is sufficient to guarantee the availability
 312     of the uploaded file. This value should not be larger than the number of
 313     servers on your grid.
 314
 315     A value of ``shares.happy`` <= ``k`` is allowed, but does not provide any
 316     redundancy if some servers fail or lose shares.
 317
 318     (Mutable files use a different share placement algorithm that does not
 319     currently consider this parameter.)
 320
 321
 322 Storage Server Configuration
 323 ============================
 324
 325 ``[storage]``
 326
 327 ``enabled = (boolean, optional)``
 328
 329     If this is ``True``, the node will run a storage server, offering space to
 330     other clients. If it is ``False``, the node will not run a storage server,
 331     meaning that no shares will be stored on this node. Use ``False`` for
 332     clients who do not wish to provide storage service. The default value is
 333     ``True``.
 334
 335 ``readonly = (boolean, optional)``
 336
 337     If ``True``, the node will run a storage server but will not accept any
 338     shares, making it effectively read-only. Use this for storage servers
 339     that are being decommissioned: the ``storage/`` directory could be mounted
 340     read-only, while shares are moved to other servers. Note that this
 341     currently only affects immutable shares. Mutable shares (used for
 342     directories) will be written and modified anyway. See ticket `#390
 343     <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/390>`_ for the current
 344     status of this bug. The default value is ``False``.
 345
 346 ``reserved_space = (str, optional)``
 347
 348     If provided, this value defines how much disk space is reserved: the
 349     storage server will not accept any share that causes the amount of free
 350     disk space to drop below this value. (The free space is measured by a
 351     call to statvfs(2) on Unix, or GetDiskFreeSpaceEx on Windows, and is the
 352     space available to the user account under which the storage server runs.)
 353
 354     This string contains a number, with an optional case-insensitive scale
 355     suffix like "K" or "M" or "G", and an optional "B" or "iB" suffix. So
 356     "100MB", "100M", "100000000B", "100000000", and "100000kb" all mean the
 357     same thing. Likewise, "1MiB", "1024KiB", and "1048576B" all mean the same
 358     thing.
 359
 360 ``expire.enabled =``
 361
 362 ``expire.mode =``
 363
 364 ``expire.override_lease_duration =``
 365
 366 ``expire.cutoff_date =``
 367
 368 ``expire.immutable =``
 369
 370 ``expire.mutable =``
 371
 372     These settings control garbage collection, in which the server will
 373     delete shares that no longer have an up-to-date lease on them. Please see
 374     `<garbage-collection.rst>`_ for full details.
 375
 376
 377 Running A Helper
 378 ================
 379
 380 A "helper" is a regular client node that also offers the "upload helper"
 381 service.
 382
 383 ``[helper]``
 384
 385 ``enabled = (boolean, optional)``
 386
 387     If ``True``, the node will run a helper (see `<helper.rst>`_ for details).
 388     The helper's contact FURL will be placed in ``private/helper.furl``, from
 389     which it can be copied to any clients that wish to use it. Clearly nodes
 390     should not both run a helper and attempt to use one: do not create
 391     ``helper.furl`` and also define ``[helper]enabled`` in the same node.
 392     The default is ``False``.
 393
 394
 395 Running An Introducer
 396 =====================
 397
 398 The introducer node uses a different ``.tac`` file (named "``introducer.tac``"),
 399 and pays attention to the ``[node]`` section, but not the others.
 400
 401 The Introducer node maintains some different state than regular client nodes.
 402
 403 ``BASEDIR/introducer.furl`` : This is generated the first time the introducer
 404 node is started, and used again on subsequent runs, to give the introduction
 405 service a persistent long-term identity. This file should be published and
 406 copied into new client nodes before they are started for the first time.
 407
 408
 409 Other Files in BASEDIR
 410 ======================
 411
 412 Some configuration is not kept in ``tahoe.cfg``, for the following reasons:
 413
 414 * it is generated by the node at startup, e.g. encryption keys. The node
 415   never writes to ``tahoe.cfg``.
 416 * it is generated by user action, e.g. the "``tahoe create-alias``" command.
 417
 418 In addition, non-configuration persistent state is kept in the node's base
 419 directory, next to the configuration knobs.
 420
 421 This section describes these other files.
 422
 423 ``private/node.pem``
 424   This contains an SSL private-key certificate. The node
 425   generates this the first time it is started, and re-uses it on subsequent
 426   runs. This certificate allows the node to have a cryptographically-strong
 427   identifier (the Foolscap "TubID"), and to establish secure connections to
 428   other nodes.
 429
 430 ``storage/``
 431   Nodes that host StorageServers will create this directory to hold shares
 432   of files on behalf of other clients. There will be a directory underneath
 433   it for each StorageIndex for which this node is holding shares. There is
 434   also an "incoming" directory where partially-completed shares are held
 435   while they are being received.
 436
 437 ``client.tac``
 438   this file defines the client, by constructing the actual Client instance
 439   each time the node is started. It is used by the "``twistd``" daemonization
 440   program (in the ``-y`` mode), which is run internally by the "``tahoe start``"
 441   command. This file is created by the "``tahoe create-node``" or
 442   "``tahoe create-client``" commands.
 443
 444 ``private/control.furl``
 445   this file contains a FURL that provides access to a control port on the
 446   client node, from which files can be uploaded and downloaded. This file is
 447   created with permissions that prevent anyone else from reading it (on
 448   operating systems that support such a concept), to insure that only the
 449   owner of the client node can use this feature. This port is intended for
 450   debugging and testing use.
 451
 452 ``private/logport.furl``
 453   this file contains a FURL that provides access to a 'log port' on the
 454   client node, from which operational logs can be retrieved. Do not grant
 455   logport access to strangers, because occasionally secret information may be
 456   placed in the logs.
 457
 458 ``private/helper.furl``
 459   if the node is running a helper (for use by other clients), its contact
 460   FURL will be placed here. See `<helper.rst>`_ for more details.
 461
 462 ``private/root_dir.cap`` (optional)
 463   The command-line tools will read a directory cap out of this file and use
 464   it, if you don't specify a '--dir-cap' option or if you specify
 465   '--dir-cap=root'.
 466
 467 ``private/convergence`` (automatically generated)
 468   An added secret for encrypting immutable files. Everyone who has this same
 469   string in their ``private/convergence`` file encrypts their immutable files
 470   in the same way when uploading them. This causes identical files to
 471   "converge" -- to share the same storage space since they have identical
 472   ciphertext -- which conserves space and optimizes upload time, but it also
 473   exposes file contents to the possibility of a brute-force attack by people
 474   who know that string. In this attack, if the attacker can guess most of the
 475   contents of a file, then they can use brute-force to learn the remaining
 476   contents.
 477
 478   So the set of people who know your ``private/convergence`` string is the set
 479   of people who converge their storage space with you when you and they upload
 480   identical immutable files, and it is also the set of people who could mount
 481   such an attack.
 482
 483   The content of the ``private/convergence`` file is a base-32 encoded string.
 484   If the file doesn't exist, then when the Tahoe-LAFS client starts up it will
 485   generate a random 256-bit string and write the base-32 encoding of this
 486   string into the file. If you want to converge your immutable files with as
 487   many people as possible, put the empty string (so that ``private/convergence``
 488   is a zero-length file).
 489
 490 Other files
 491 ===========
 492
 493 ``logs/``
 494   Each Tahoe-LAFS node creates a directory to hold the log messages produced as
 495   the node runs. These logfiles are created and rotated by the "``twistd``"
 496   daemonization program, so ``logs/twistd.log`` will contain the most recent
 497   messages, ``logs/twistd.log.1`` will contain the previous ones,
 498   ``logs/twistd.log.2`` will be older still, and so on. ``twistd`` rotates
 499   logfiles after they grow beyond 1MB in size. If the space consumed by logfiles
 500   becomes troublesome, they should be pruned: a cron job to delete all files
 501   that were created more than a month ago in this ``logs/`` directory should be
 502   sufficient.
 503
 504 ``my_nodeid``
 505   this is written by all nodes after startup, and contains a base32-encoded
 506   (i.e. human-readable) NodeID that identifies this specific node. This
 507   NodeID is the same string that gets displayed on the web page (in the
 508   "which peers am I connected to" list), and the shortened form (the first
 509   few characters) is recorded in various log messages.
 510
 511 Backwards Compatibility Files
 512 =============================
 513
 514 Tahoe-LAFS releases before v1.3.0 had no ``tahoe.cfg`` file, and used distinct
 515 files for each item listed below. For each configuration knob, if the distinct
 516 file exists, it will take precedence over the corresponding item in ``tahoe.cfg``.
 517
 518 ===============================  ===================================  =================
 519 Config setting                   File                                 Comment
 520 ===============================  ===================================  =================
 521 ``[node]nickname``               ``BASEDIR/nickname``
 522 ``[node]web.port``               ``BASEDIR/webport``
 523 ``[node]tub.port``               ``BASEDIR/client.port``              (for Clients, not Introducers)
 524 ``[node]tub.port``               ``BASEDIR/introducer.port``          (for Introducers, not Clients) (note that, unlike other keys, ``tahoe.cfg`` overrides this file)
 525 ``[node]tub.location``           ``BASEDIR/advertised_ip_addresses``
 526 ``[node]log_gatherer.furl``      ``BASEDIR/log_gatherer.furl``        (one per line)
 527 ``[node]timeout.keepalive``      ``BASEDIR/keepalive_timeout``
 528 ``[node]timeout.disconnect``     ``BASEDIR/disconnect_timeout``
 529 ``[client]introducer.furl``      ``BASEDIR/introducer.furl``
 530 ``[client]helper.furl``          ``BASEDIR/helper.furl``
 531 ``[client]key_generator.furl``   ``BASEDIR/key_generator.furl``
 532 ``[client]stats_gatherer.furl``  ``BASEDIR/stats_gatherer.furl``
 533 ``[storage]enabled``             ``BASEDIR/no_storage``               (``False`` if ``no_storage`` exists)
 534 ``[storage]readonly``            ``BASEDIR/readonly_storage``         (``True`` if ``readonly_storage`` exists)
 535 ``[storage]sizelimit``           ``BASEDIR/sizelimit``
 536 ``[storage]debug_discard``       ``BASEDIR/debug_discard_storage``
 537 ``[helper]enabled``              ``BASEDIR/run_helper``               (``True`` if ``run_helper`` exists)
 538 ===============================  ===================================  =================
 539
 540 Note: the functionality of ``[node]ssh.port`` and ``[node]ssh.authorized_keys_file``
 541 were previously combined, controlled by the presence of a
 542 ``BASEDIR/authorized_keys.SSHPORT`` file, in which the suffix of the filename
 543 indicated which port the ssh server should listen on, and the contents of the
 544 file provided the ssh public keys to accept. Support for these files has been
 545 removed completely. To ``ssh`` into your Tahoe-LAFS node, add ``[node]ssh.port``
 546 and ``[node].ssh_authorized_keys_file`` statements to your ``tahoe.cfg``.
 547
 548 Likewise, the functionality of ``[node]tub.location`` is a variant of the
 549 now-unsupported ``BASEDIR/advertised_ip_addresses`` . The old file was additive
 550 (the addresses specified in ``advertised_ip_addresses`` were used in addition to
 551 any that were automatically discovered), whereas the new ``tahoe.cfg`` directive
 552 is not (``tub.location`` is used verbatim).
 553
 554
 555 Example
 556 =======
 557
 558 The following is a sample ``tahoe.cfg`` file, containing values for all keys
 559 described above. Note that this is not a recommended configuration (most of
 560 these are not the default values), merely a legal one.
 561
 562 ::
 563
 564   [node]
 565   nickname = Bob's Tahoe-LAFS Node
 566   tub.port = 34912
 567   tub.location = 123.45.67.89:8098,44.55.66.77:8098
 568   web.port = 3456
 569   log_gatherer.furl = pb://soklj4y7eok5c3xkmjeqpw@192.168.69.247:44801/eqpwqtzm
 570   timeout.keepalive = 240
 571   timeout.disconnect = 1800
 572   ssh.port = 8022
 573   ssh.authorized_keys_file = ~/.ssh/authorized_keys
 574
 575   [client]
 576   introducer.furl = pb://ok45ssoklj4y7eok5c3xkmj@tahoe.example:44801/ii3uumo
 577   helper.furl = pb://ggti5ssoklj4y7eok5c3xkmj@helper.tahoe.example:7054/kk8lhr
 578
 579   [storage]
 580   enabled = True
 581   readonly_storage = True
 582   sizelimit = 10000000000
 583
 584   [helper]
 585   run_helper = True