[tahoe-dev] tahoe connection error

[Brian Warner]

Jody Harris wrote:
> 
> I had changed the WUI URL. I was unaware that the CLI needed to be
> told about that change.
> 
> Can a tahoe CLI point to a different server all together?

Yup. Here's how it works: if you can figure out a good way (and place)
to explain this in the docs, we'd love a patch..

 * by default, all tahoe CLI commands look in ~/.tahoe/node.url and use
   the contents as a webapi URL. All CLI commands (currently) operate
   through the webapi exclusively, so node.url completely controls which
   tahoe "gateway" node they use.
 * CLI commands also use other files in ~/.tahoe, in particular:
   * ~/.tahoe/private/aliases is used by most commands to store aliases
   * ~/.tahoe/private/backupdb.sqlite is used by the "tahoe backup" command
 * CLI commands can be told to use something other than ~/.tahoe, by
   passing a --node-directory= or -d argument to the CLI command, for
   example "tahoe ls -d ~/.tahoe2 what:" instead of "tahoe ls what:". In
   this case, it will use ~/.tahoe2/node.url
 * alternatively, CLI commands can be told to use a specific webapi URL
   with the --node-url= or -u argument. For example, "tahoe ls -u
   http://localhost:8765". If you use --node-url=, the CLI command will
   keep using everything else in ~/.tahoe , just not the node.url file.

 * A tahoe "gateway" node is one which is listening on a webapi port, as
   a result of having a [node]web.port= configured in its tahoe.cfg .
   These nodes will write the URL of their webapi port into
   BASEDIR/node.url each time the node is started.

 * The default behavior of "tahoe create-client" is to create it in
   ~/.tahoe , and the default "tahoe start" command looks for a node in
   ~/.tahoe and starts whatever it finds.


All of the defaults line up, so that you get the right behavior by just
doing:

 tahoe create-client -i INTRODUCER.furl
 tahoe start
 tahoe create-alias foo
 tahoe ls foo:

all of which use ~/.tahoe/ .

If you want to run multiple nodes, or for any reason you don't want to
run your node in ~/.tahoe, then you have two basic choices. The first is
to pick a different directory (call it $BASEDIR), create+run the tahoe
node there, and tell all of your CLI commands to look in it.

The second is to run the tahoe node in $BASEDIR as before, but create a
stub ~/.tahoe that contains just enough information to tell the CLI
commands how to find the right webapi node:

 tahoe create-client -i INTRODUCER.furl -C /var/lib/foo
 tahoe start /var/lib/foo

 mkdir ~/.tahoe
 mkdir ~/.tahoe/private
 chmod go-rwx ~/.tahoe/private
 cp /var/lib/foo/node.url ~/.tahoe
 tahoe create-alias foo
 tahoe ls foo:

In this case, ~/.tahoe will have only a very few files: node.url,
private/aliases, and private/backupdb.sqlite . The rest of the usual
tahoe files (like tahoe.cfg, storage/shares, logs/, private/node.pem,
etc) will be present in the real node's $BASEDIR, but not in ~/.tahoe .
Also note that this second approach allows you to run a webapi node on
one machine and run your CLI commands on a separate machine. This is not
particularly recommended (if node.url is HTTP instead of HTTPS, you'll
be exposing your secret filecaps to eavesdroppers), but there are
situations in which it is useful.

Personally, I have dozens of nodes defined in various places on my
computer, but I only tend to run one of them at a time. I've got one
each for the testgrid, volunteergrid, allmydata prodgrid, and a personal
grid. And then I have a self-contained testgrid with 5 nodes in which
only one runs a webapi port. All of them are configured to listen on
127.0.0.1:3456, and I have a single ~/.tahoe/node.url which points to
http://127.0.0.1:3456 . I have a separate alias stored for each one.
Then, to access things on the volunteergrid, I do something like:

 tahoe start ~/nodes/volunteergrid
 tahoe ls volunteergrid:

and to switch to the prodgrid:

 tahoe stop ~/nodes/volunteergrid
 tahoe start ~/nodes/prodgrid
 tahoe ls prod:

All of these are going through the same ~/.tahoe/node.url, but that's
just to let me avoid a lot of long --node-directory arguments.

Also, note that we have some tickets (#706, #772, #188) about how the
--node-directory argument could be easier to use. In particular, having
it come after the CLI command (i.e. "tahoe ls -d /var/lib/tahoe foo:"
instead of "tahoe -d /var/lib/tahoe ls foo:") makes it harder to build a
simple alias or shell script that gives access to a particular node.
It'd be nice if I could do:

 alias tahoe-prodgrid="tahoe -d /var/lib/tahoe-prod"
 alias tahoe-volunteergrid="tahoe -d /var/lib/tahoe-volunteer"
 tahoe-prodgrid ls foo:
 tahoe-volunteergrid ls bar:

but with the '-d DIR' after the 'ls' (or mkdir, or cp, or whatever),
that becomes a small shell script that shuffles around the argument
lists instead of a simple alias. The thought is to make a global -d
option which is available for all the CLI commands that want to use it,
and can be ignored by the ones (like "tahoe debug dump-cap") which do
not.


hope that helps,
 -Brian