command-line: make it work with the private vdrive #120

New Issue

zooko · 2007-08-23T18:21:12Z

zooko commented

2007-08-23 18:21:12 +00:00

Currently the command-line can't access your private vdrive.

Make the command-line client parse the secret private vdrive uri out of $basedir/start.html and use it.

While you are at it, make it get the port number out of $basedir/webport and use "localhost" as the default host, thus giving the -u option a good default.

Currently the command-line can't access your private vdrive. Make the command-line client parse the secret private vdrive uri out of $basedir/start.html and use it. While you are at it, make it get the port number out of $basedir/webport and use "localhost" as the default host, thus giving the -u option a good default.

zooko added the

labels 2007-08-23 18:21:12 +00:00

zooko added this to the 0.6.0 milestone 2007-08-23 18:21:12 +00:00

zooko self-assigned this 2007-08-23 18:21:12 +00:00

warner commented

2007-08-23 19:13:33 +00:00

actually, I'd suggest adding a utility function which reads the my_vdrive.uri
and webport out of $basedir, and computes the private vdrive base url from
that. Then use that function in all the CLI tools. (scraping HTML is icky).

Alternatively, we could have the node write a my_vdrive.url (URL, not URI)
with this information, to make that utility function easier. It could also
write my_node.url for the welcome page (this is derivable from the contents
of 'webport', but it seems like it might be more reliable to have the node do
this for us).

Let's talk about default node basedirs, since that has bearing here: I'd like
to propose the following CLI tool options:

--basedir : the base directory of the local tahoe node to use.
Defaults to ~/.tahoe . If $BASEDIR/webport exists, the tool will use
it to compute a node-url to use. If $BASEDIR/my_vdrive.uri exists, the
tool will use it to compute a URL to use for --vdrive=private
-u/--node-url : the base URL of the node,
http://localhost:$webport . This has no default value. If this is provided,
--basedir is ignored.

If we also add --basedir=~/.tahoe to the create-client and start/stop/restart
commands, and if we added a hypothetical --introducer=FURL option to
create-client (which would contact an introducer and fetch the vdrive furl
and write both into the newly-created client directory), then the usage
pattern for a tahoe user would be:

% tahoe create-client --introducer=pb://blah/allmydata.org/testnetstuff
% tahoe start
% tahoe ls               # lists global root
% tahoe ls -d private    # lists private root

(mind you I'm not tied to the spelling of these options, just the concept)

actually, I'd suggest adding a utility function which reads the my_vdrive.uri and webport out of $basedir, and computes the private vdrive base url from that. Then use that function in all the CLI tools. (scraping HTML is icky). Alternatively, we could have the node write a my_vdrive.url (URL, not URI) with this information, to make that utility function easier. It could also write my_node.url for the welcome page (this is derivable from the contents of 'webport', but it seems like it might be more reliable to have the node do this for us). Let's talk about default node basedirs, since that has bearing here: I'd like to propose the following CLI tool options: * `--basedir` : the base directory of the local tahoe node to use. Defaults to ~/.tahoe . If $BASEDIR/webport exists, the tool will use it to compute a node-url to use. If $BASEDIR/my_vdrive.uri exists, the tool will use it to compute a URL to use for --vdrive=private * `-u`/`--node-url` : the base URL of the node, <http://localhost:$webport> . This has no default value. If this is provided, --basedir is ignored. If we also add --basedir=~/.tahoe to the create-client and start/stop/restart commands, and if we added a hypothetical --introducer=FURL option to create-client (which would contact an introducer and fetch the vdrive furl and write both into the newly-created client directory), then the usage pattern for a tahoe user would be: ``` % tahoe create-client --introducer=pb://blah/allmydata.org/testnetstuff % tahoe start % tahoe ls # lists global root % tahoe ls -d private # lists private root ``` (mind you I'm not tied to the spelling of these options, just the concept)

zooko commented

2007-08-23 19:54:52 +00:00

Oh, I think this might interact closely or identically with ticket #105.

zooko changed title from ~~command-line: deal with new security regime from #98~~ to command-line: make it work with the private vdrive

2007-08-23 19:54:52 +00:00

zooko modified the milestone from 0.6.0 to 0.7.0

2007-09-19 22:55:31 +00:00

zooko commented

2007-10-01 18:30:46 +00:00

As per discussion with Peter:

Also, we want it to be convenient to use the allmydata-tahoe command-line tool even when the node isn't installed on the local machine. So the mapping from petname to directory uri should be managed by the command-line tool instead of by the node.

For example:

tahoe store-uri private URI:DIR:pb$^^t7p44biq3u6i5r5zjpb6cdqxid7v7vpx@192.168.69.247$58845,127.0.0.1$58845/vdrive:w57ncp9cmzyb6kwrjaebq7d8co

would store a mapping from the string "private" to that URI in the user's ~/.tahoe directory (even if there is no node installed on that machine.

(As as aside, that directory URI string is big and ugly. I think that it is important for usability (therefore important for adoption) to make them smaller and prettier. See #102.)

Subsequently, this command line would use the stored URI:

tahoe ls -d private

as would this

tahoe put -d private myfile.txt

As per discussion with Peter: Also, we want it to be convenient to use the allmydata-tahoe command-line tool even when the node isn't installed on the local machine. So the mapping from petname to directory uri should be managed by the command-line tool instead of by the node. For example: ``` tahoe store-uri private URI:DIR:pb$^^t7p44biq3u6i5r5zjpb6cdqxid7v7vpx@192.168.69.247$58845,127.0.0.1$58845/vdrive:w57ncp9cmzyb6kwrjaebq7d8co ``` would store a mapping from the string "private" to that URI in the user's ~/.tahoe directory (even if there is no node installed on that machine. (As as aside, that directory URI string is big and ugly. I think that it is important for usability (therefore important for adoption) to make them smaller and prettier. See #102.) Subsequently, this command line would use the stored URI: ``` tahoe ls -d private ``` as would this ``` tahoe put -d private myfile.txt ```

zooko commented

2007-10-01 18:34:27 +00:00

Yay, Brian!

zooko added

0.6.0

and removed

0.5.0

labels 2007-10-01 18:34:27 +00:00

zooko modified the milestone from 0.7.0 to 0.6.1

2007-10-01 18:34:27 +00:00

zooko removed their assignment 2007-10-01 18:34:27 +00:00

warner was assigned by zooko

2007-10-01 18:34:27 +00:00

zooko commented

2007-10-01 18:49:03 +00:00

I promoted this ticket from milestone 0.7 to 0.6.1 because my favorite customer, Peter, wants it. (Also because Brian wants to implement it!)

warner commented

2007-10-11 09:36:47 +00:00

ok, I've finished pushing my changes. The new code uses --node-directory, --node-url, and --root-uri . If you don't specify anything, --node-directory defaults to ~/.tahoe and reads everything else from there. --root-uri can be 'private', 'public', or a real dirnode URI, and it defaults to 'private'. Both 'private' and 'public' cause the CLI commands to look in the node-directory for URIs.

Also, all create/start/stop/restart commands (except create-introducer) default to using ~/.tahoe too. Finally, I changed create-client to accept a --webport argument, to populate NODEDIR/webport, and it defaults to localhost:8011 (feel free to change it to a different default port, that was just the first value that popped into my head). So the following sequence of commands Just Works:

allmydata-tahoe create-client
cp introducer.furl vdrive.furl ~/.tahoe/
allmydata-tahoe start
allmydata-tahoe ls   # lists your (empty) private vdrive
allmydata-tahoe put FILE newfile
allmydata-tahoe ls   # lists 'newfile'
allmydata-tahoe ls -r public  # lists the global public vdrive

The 'cp *.furl' step is a drag, but we're stuck with it until we build the Invitation/Introduction protocol, at which point we can either use 'allmydata-tahoe accept-invitation FURL', or 'allmydata-tahoe create-client --invitation=FURL'.

I think we can close this out now, but I'm going to leave it open for another day to solicit comments.

ok, I've finished pushing my changes. The new code uses --node-directory, --node-url, and --root-uri . If you don't specify anything, --node-directory defaults to ~/.tahoe and reads everything else from there. --root-uri can be 'private', 'public', or a real dirnode URI, and it defaults to 'private'. Both 'private' and 'public' cause the CLI commands to look in the node-directory for URIs. Also, all create/start/stop/restart commands (except create-introducer) default to using ~/.tahoe too. Finally, I changed create-client to accept a --webport argument, to populate NODEDIR/webport, and it defaults to localhost:8011 (feel free to change it to a different default port, that was just the first value that popped into my head). So the following sequence of commands Just Works: ``` allmydata-tahoe create-client cp introducer.furl vdrive.furl ~/.tahoe/ allmydata-tahoe start allmydata-tahoe ls # lists your (empty) private vdrive allmydata-tahoe put FILE newfile allmydata-tahoe ls # lists 'newfile' allmydata-tahoe ls -r public # lists the global public vdrive ``` The 'cp *.furl' step is a drag, but we're stuck with it until we build the Invitation/Introduction protocol, at which point we can either use 'allmydata-tahoe accept-invitation FURL', or 'allmydata-tahoe create-client --invitation=FURL'. I *think* we can close this out now, but I'm going to leave it open for another day to solicit comments.

warner commented

2007-10-11 22:41:50 +00:00

I watched Peter use this successfully, and he seems happy. Time to close the ticket.

warner added the

fixed

label 2007-10-11 22:41:50 +00:00

warner closed this issue

2007-10-11 22:41:50 +00:00

Sign in to join this conversation.