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 _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
