[tahoe-dev] Logging howto / sftp with hashed passwords

Wolfgang Strobl news4 at mystrobl.de
Fri Mar 23 06:38:19 UTC 2012

Zitat von Zooko Wilcox-O'Hearn <zooko at zooko.com>:

> 2012/3/22 Wolfgang Strobl <news4 at mystrobl.de>:
>> Didn't anybody ever try to install according to the instructions in https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/quickstart.rst on a bare machine?
> Yes, lots of people do that. That works to install tahoe-lafs and make
> the "bin/tahoe" script work. It also installs foolscap, since
> tahoe-lafs depends on foolscap, but it does not create a
> "bin/flogtool" script (akin to the "bin/tahoe" script), because we
> hadn't previously considered flogtool to be part of what tahoe-lafs is
> providing.

Thanks, Zooko, for explaining that, in hindsight it seems obvious. Please forget the sarcasm in the paragraph above, it wasn't ment as it may sound, its just the frustration of a newcomer to a complex tool who got stuck, after all went so well up to now. :-)

> However, your story illustrates that perhaps we should! Since, after
> all, it is necessary to get logging information and our docs instruct
> you to use it.


> I'm not sure of the best way to do so. The cheapest way out is to add
> a line of doc to logging.rst saying "Just because tahoe-lafs uses
> foolscap and automatically resolves its dependency on foolscap doesn't
> mean that building tahoe-lafs automatically makes a working 'flogtool'
> script for you. To get a working 'flogtool', you'll have to install
> foolscap manually.".

I'd add that adding site-packages from support the python path is ok and suffictient for runnig flogtool. (what about the other scripts in support/bin, btw.?)

As a new user of some complex piece of software, I'm not going to add random parts of its distribution to the path, when something doesn't work, without understanding beforehand what I'm doing there, but try to follow the instructions by the letter.

> An interesting possibility would be to extend the "tahoe" script to do
> all of the flogtool functionality.

Yes, that sounds plausible. If memory serves me right, there is a ticket somewhere which discussed something similar. I looked into the "tahoe" script before asking my question, but as it seems, that script does a lot more than just adding something to the python path, so I gave up there.

> This would no doubt go under the
> "tahoe debug" sub-command, along with sundry other utilities, and...
> oh! There's already a feature of "tahoe debug" that can help with
> this. Run "./bin/tahoe debug --help" and read about the "arbitrary
> 'runner' command". If I understand it correctly, this means that the
> following command should run flogtool from any tahoe-lafs directory:
> ./bin/tahoe @./support/bin/flogtool

I'll try that and report back.

> Oh, but that will work only if flogtool was written into ./support by
> the build process, which will happen only if foolscap was not already
> present on your system when you built.

It wasn't.

> I'm still kind of intrigued about the notion of the "bin/tahoe"
> command acquiring all of the functionality of flogtool, because it
> makes me wonder if tahoe-specific extensions of flogtool would then
> arise. Like, would it be useful to have a command that gatherers logs
> from all of your storage servers (those which have opted in by
> publishing a logport.furl) and aggregated their logs? Interesting...
> I've opened #1693 to track this issue.

I'll perhaps add a few thoughts to if, after learning a bit more about the matter.

Thanks again for your help!



More information about the tahoe-dev mailing list