[tahoe-dev] git-annex & tahoe
hey people, after my unsuccesful or mostly unsuccesful excursions of the sort of - connect owncloud to tahoe via sftp - connect owncloud to tahoe via ftp - connect my mac to tahoe using macfuse & sshfs (too slow!) - compile csync on my mac to use it with tahoe via sftp my last attempt to get more comfortable interactions to tahoe, is via git-annex. After joeyh helped me figured out some quirks on the installation of git-annex assistant on the mac, i finally got it running but still having problems with the tahoe hooks. is anyone using this combination and can answer some questions? thanks, t.___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: [tahoe-dev] [tahoe-lafs-trac-stream] [tahoe-lafs] #1707: iputil cannot get local IP addresses on newer Dragonfly BSD (sys.platform == "dragonfly2")
We could also add a regex for BSD. Any system that has BSD in it is type
'bsd'.
Randall Mason
clashthebu...@gmail.com
On Thu, Jun 13, 2013 at 10:41 AM, tahoe-lafs wrote:
> #1707: iputil cannot get local IP addresses on newer Dragonfly BSD
> (sys.platform
> == "dragonfly2")
> +--
> Reporter: phma| Owner: davidsarah
> Type: defect | Status: assigned
> Priority: normal | Milestone: soon
> Component: code|Version: 1.9.1
>Resolution: | Keywords: iputil dragonfly bsd
> Launchpad Bug: |
> +--
>
> Comment (by zooko):
>
> Here's a list of all tickets about "iputil":
>
> https://tahoe-lafs.org/trac/tahoe-
> lafs/query?status=!closed&keywords=~iputil
>
> Hm, we need to open a new ticket for Daira's suggestion from #1918, to try
> invoking {{{ifconfig}}} (and then maybe {{{route.exe}}}?) regardless of
> platform.
>
> --
> Ticket URL:
> tahoe-lafs
> secure decentralized storage
> ___
> tahoe-lafs-trac-stream mailing list
> tahoe-lafs-trac-str...@tahoe-lafs.org
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-lafs-trac-stream
>
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: [tahoe-dev] git-annex & tahoe
til writes: > hey people, > > after my unsuccesful or mostly unsuccesful excursions of the sort of > > - connect owncloud to tahoe via sftp > - connect owncloud to tahoe via ftp > - connect my mac to tahoe using macfuse & sshfs (too slow!) > - compile csync on my mac to use it with tahoe via sftp [digression: Do you really mean macfuse? That's no longer being maintained: https://code.google.com/p/macfuse/ I have seen http://osxfuse.github.io/ http://fuse4x.github.io/ (competing fork, now merged into osxfuse, yay) and maybe this is the same thing too: http://sourceforge.net/projects/fuse-for-macosx/ ] Can you explain what you mean by "slow"? Are operations with sshfs/sftp/tahoe slower than using the tahoe CLI? (I have found tahoe to be slow enough that I'd only want to use it for backups.) pgpDta_CRWXYx.pgp Description: PGP signature ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: [tahoe-dev] Suggestion for command: tahoe df
On Sat, Jun 08, 2013 at 09:52:38PM -0400, Pierre Abbat wrote: > I'd like to see a tahoe df command. It should find out how much free space is > at each storage server, sort them, clip the biggest shares.happy ones to the > shares.happy'th, add them up, and divide by the expansion factor. When run > verbosely, it could tell how much free space is available at each server. > What do you think? Dear Pierre: I like the idea, in principle! Although I wonder if the algorithm for computing "estimated free space" should take more information into account in order to provide more informative results. The algorithm sketched out above seems like it under-estimates the effective available space by ignoring some servers... But, now that I think about it, it would be really cool to see those results (either the summarized number or the verbose output)! I hope someone does it! The next step is for someone (I nominate Pierre) to open a ticket on the trac: https://tahoe-lafs.org . Please include a link to this discussion in the archives (https://tahoe-lafs.org/pipermail/tahoe-dev/2013-June/008357.html ), and then please reply to this thread and post a link to the trac ticket. :-) Regards, Zooko ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: [tahoe-dev] git-annex & tahoe
I use tahoe-lafs + git-annex, it works, its sorta slow though, and im still using a fairly ancient version of git-annex on that particular setup. On Thu, Jun 13, 2013 at 12:31 PM, Greg Troxel wrote: > > til writes: > > > hey people, > > > > after my unsuccesful or mostly unsuccesful excursions of the sort of > > > > - connect owncloud to tahoe via sftp > > - connect owncloud to tahoe via ftp > > - connect my mac to tahoe using macfuse & sshfs (too slow!) > > - compile csync on my mac to use it with tahoe via sftp > > [digression: > Do you really mean macfuse? That's no longer being maintained: > https://code.google.com/p/macfuse/ > I have seen > http://osxfuse.github.io/ > http://fuse4x.github.io/ (competing fork, now merged into osxfuse, yay) > and maybe this is the same thing too: > http://sourceforge.net/projects/fuse-for-macosx/ > ] > > > Can you explain what you mean by "slow"? Are operations with > sshfs/sftp/tahoe slower than using the tahoe CLI? > (I have found tahoe to be slow enough that I'd only want to use it for > backups.) > > > > > ___ > tahoe-dev mailing list > tahoe-dev@tahoe-lafs.org > https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev > > -- http://www.sgenomics.org/~jtang/ ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: [tahoe-dev] Suggestion for command: tahoe df
On Thursday, June 13, 2013 17:39:15 zooko wrote: > The next step is for someone (I nominate Pierre) to open a ticket on the > trac: https://tahoe-lafs.org . Please include a link to this discussion in > the archives > (https://tahoe-lafs.org/pipermail/tahoe-dev/2013-June/008357.html ), and > then please reply to this thread and post a link to the trac ticket. :-) https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2002 Pierre -- gau do li'i co'e kei do ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: [tahoe-dev] Suggestion for command: tahoe df
Pierre Abbat writes: [df] Excellent wording. your machine seems to be listed in SSBL and IPREPDNS_0: Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on fnord.ir.bbn.com X-Spam-Flag: YES X-Spam-Level: * X-Spam-Status: Yes, score=1.1 required=1.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, RCVD_IN_IPREPDNS_0,RCVD_IN_SSBL autolearn=no version=3.3.2 X-Spam-Report: * 2.0 RCVD_IN_IPREPDNS_0 RBL: Sender listed at * http://www.chaosreigns.com/iprep/, 0% ham * [75.180.132.120 listed in iprep.chaosreigns.com] * -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no * trust * [75.180.132.120 listed in list.dnswl.org] * -2.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.] * 2.0 RCVD_IN_SSBL RCVD_IN_SSBL pgpg_y4U3S0so.pgp Description: PGP signature ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: [tahoe-dev] py-zfec on github now includes darcs history
On Sun, Jun 9, 2013 at 3:33 PM, Richard Kiss wrote: > I realized I should just rebase on the darcs history import I produced, so > the github repo at > > https://github.com/richardkiss/py-zfec > > is now rebased with the darcs history. > > In darcs, the top level included misc and zfec. I moved everything in zfec > to the top level so it would be a little more standard, and so the > README.rst file would display. This might break build scripts, but if so, > they should be easy to fix (substitute zfec/zfec => zfec). Feel free to use > this as a github base (ie. if you do a clone and push, I'll delete my > version). > > -- > http://richardkiss.com/ > I don't know which tool you used to port darcs-to-git, and you may already be aware of this, but if you're not, you should know that there is a discrepancy in the way that darcs records patches, and git records commits. Git does not record commits of empty trees. A git blob is a sha1 indexed object that includes (among other things) the data in a file. A git tree is an object with a reference to a blob, or to another tree. An important caveat is that there must be at least one blob referred to by a tree (even if the reference is indirect via multiple trees), for that tree to exist. In git file contents are mapped into blobs, and directory contents are mapped into trees. Unfortunately, this means that there is not a map from an empty directory into a git object, because an empty directory contains no files-or-directories, and git-trees are required to refer to at least one blob. In darcs on the other hand an empty directory can be added as its own patch. The result of this discrepancy between data models is that porting tools must make a decision about how to report darcs patches that correspond to the addition of a single directory. I don't know if this is an issue in the zfec code base, but it's something that "porters" ought to be aware of. -- -- ظ ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: [tahoe-dev] Tahoe prefered peer selection
Dear Leif, Thanks for the reply! I still have one question. Iv'e installed the current code you commited, since i don't have so many servers i am using the public test grid of tahoe to test it, that means i have to go to localhost:3456 to get the server ids to be setup, however, when i start the tahoe client node at my local computer the web ui directly showed an exception : Client instance has no attribute '_node_key'. I've read about the node key link you provided, and that means a node id is encrypted by this key, but does this error suggests i should set it up somewhere in the cfg file? Thanks for your help! I really appreciate it! Best, Yu On Thu, Jun 13, 2013 at 2:24 AM, Leif Ryge wrote: > On Wed, Jun 12, 2013 at 10:09:01PM -0400, Yu Xiang wrote: > > Dear leif, > > i am recently trying to set chunks to be sent to prefered servers in > > tahoe-lafs, and i came across your code in > > https://github.com/tahoe-lafs/tahoe-lafs/pull/39, which is really what i > > need. However, there are something that i don't fully understand in the > > code, hopefully you can help me with this, since it's really urgent and > > i've tried many methods and spent plenty of time on this before i met > this > > perfectly matched code. I really need this help. > > > > First it seems that i have to type in preferred peers in tahoe.cfg file, > > but in which format? from the code it should be peers.prefered , > pstrip()? > > but in this case i am not able to compile the code successfully for now, > i > > did the changes in the files in your commit, are there anything else i > need > > to change? > > > > Thanks in advance! Your help will be highly appreciated since i really > need > > this! > > > > Best, > > Yu > > Thanks for asking! You've caused me to discover a problem with the > preferred peers code and/or documentation. > > I've been using a comma-seperated list of node IDs (you can find the > nodeid in the my_nodeid file in the storage node's directory). But, it > appears that the method I'm using to obtain it - the storage_client > object's get_longname method - now (as of 1.10) returns the new node > key instead! This is displayed in the web ui in the same place as the > nodeid was, but is prefixed with v0- which I *think* should not go in > the preferred peers list. > > So, I *think* the current code should work if you list whatever you see > in the web ui under a node's nickname, except if it starts with v0- you > should remove that part. But I'm going to do some more testing now, and > will push updated docs (and possibly code) in the near future. > > Btw, would you mind CC'ing the tahoe-dev list? I'm not sure if anyone > else is using this code, but I'd like to keep information about it there > just in case. > > ~leif > > ps: you can read about the new node keys here: > https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/nodekeys.rst > ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: [tahoe-dev] Tahoe prefered peer selection
Dear Leif, Also I would like you to check if this is the correct format of preferred peers setting in tahoe.cfg. Since i think this is what i got from the code, but i am not sure about it. should the string to the left of the equal sign be "peers.preferred p"? [client] introducer.furl = pb:// hckqqn4vq5ggzuukfztpuu4wykwef...@publictestgrid.dnsd.info:50213/introducer peers.preferred p = 7ncac2wflv5hmmkcqnlcmnturdlojuxz, 9ncac2wflv5hmmkcqnlcmnturdlojuwy [storage] enabled = true Thanks for your kindly help! Best, Yu On Thu, Jun 13, 2013 at 2:24 AM, Leif Ryge wrote: > On Wed, Jun 12, 2013 at 10:09:01PM -0400, Yu Xiang wrote: > > Dear leif, > > i am recently trying to set chunks to be sent to prefered servers in > > tahoe-lafs, and i came across your code in > > https://github.com/tahoe-lafs/tahoe-lafs/pull/39, which is really what i > > need. However, there are something that i don't fully understand in the > > code, hopefully you can help me with this, since it's really urgent and > > i've tried many methods and spent plenty of time on this before i met > this > > perfectly matched code. I really need this help. > > > > First it seems that i have to type in preferred peers in tahoe.cfg file, > > but in which format? from the code it should be peers.prefered , > pstrip()? > > but in this case i am not able to compile the code successfully for now, > i > > did the changes in the files in your commit, are there anything else i > need > > to change? > > > > Thanks in advance! Your help will be highly appreciated since i really > need > > this! > > > > Best, > > Yu > > Thanks for asking! You've caused me to discover a problem with the > preferred peers code and/or documentation. > > I've been using a comma-seperated list of node IDs (you can find the > nodeid in the my_nodeid file in the storage node's directory). But, it > appears that the method I'm using to obtain it - the storage_client > object's get_longname method - now (as of 1.10) returns the new node > key instead! This is displayed in the web ui in the same place as the > nodeid was, but is prefixed with v0- which I *think* should not go in > the preferred peers list. > > So, I *think* the current code should work if you list whatever you see > in the web ui under a node's nickname, except if it starts with v0- you > should remove that part. But I'm going to do some more testing now, and > will push updated docs (and possibly code) in the near future. > > Btw, would you mind CC'ing the tahoe-dev list? I'm not sure if anyone > else is using this code, but I'd like to keep information about it there > just in case. > > ~leif > > ps: you can read about the new node keys here: > https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/nodekeys.rst > ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
[tahoe-dev] Android client
Has anyone used the Android client recently? https://play.google.com/store/apps/details?id=org.allmydata.tahoelafs&hl=en If yes, then what should go in the WAPI field and the rootcap? cheers, Sameer ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
