I am trying to package tahoe for pkgsrc, the native packaging system on
NetBSD and Dragonfly, also portable to Darwin, Linux, Solaris, OpenBSD,
FreeBSD, IRIX, AIX, and a few others.
I don't understand how setup.py decides if a particular python package
is already present or needs to be downloaded
5:43 setuptools-0.6c11-py2.6.egg-info
drwxr-xr-x 2 root wheel512 Jul 20 19:58
zope.interface-3.6.1-py2.6.egg-info
I now think there are two kinds of egg-aware packages: 1st-class ones
that take --single-version-externally-managed, and older ones that just
install an egg file, and that pkgsrc&
I can see how Tahoe uses the POLA in cryptographic design, but it seems
one should also approach host operation in the same way. In
contemplating setting this up, I'm inclined to
Have an introducer on a particularly reliable machine (really, one I
have to fix quickly anyway).
Run the intr
while packaging tahoe:
zfec seems to depend on darcsver and setuptools_darc. Downloading code
during package builds is not allowed, so I either have to package those
or patch them out. It seems they really are required for a good build
of zfec, and thus I should package them, but I wanted to as
Greg Troxel writes:
> while packaging tahoe:
>
> zfec seems to depend on darcsver and setuptools_darc. Downloading code
> during package builds is not allowed, so I either have to package those
> or patch them out. It seems they really are required for a good build
> o
Marc Tooley writes:
> On Friday 23 July 2010, Greg Troxel wrote:
>> Still, does it make sense to add darcsver to pkgsrc? I have already
>> made the package control files.
>
> Are you using darcs-2.4.4? darcs-2.0.2 or even darcs-2.2.0 both have a
> problem on NetBSD
Thanks for the packaging help.
The real issue was that pkgsrc distutils packages were not making egg
files like they should, due to disabling them in 2.5 and 2.6 to match
2.4, in order to avoid variant packing lists. I fixed this, so
distutils packages have egg files in 2.5+. Presumably no one
"Zooko O'Whielacronx" writes:
> On Sat, Jul 24, 2010 at 8:10 AM, Greg Troxel wrote:
>>
>> I've made packages for most of tahoe's prereqs. I have two more to
>> go and then should be able to commit the tahoe-lafs package.
>
> Hooray!
OK,
I was very surprised to see requests to
http://chart.apis.google.com/chart
From the web UI. It seems that while one can argue that sending the
hash of a serverid is not tha big a deal, it still reveals the IP
address of a tahoe client to google.
By default, I think the web UI should not gene
Francois Deppierraz writes:
> Hi Nathan,
>
> On 07/27/2010 07:02 PM, Nathan Eisenberg wrote:
>
>> I wasn’t sure, so I thought I’d bring it up – does Tahoe support IPv6
>> yet? If not, where is it on the roadmap?
>
> Not yet. There's a feature request filled in trac #867 and it has been
> previou
playing with test grid, I have several suggestions:
1) local web page should indicate IP address for servers that are not
connected.
2) if a node has had a share placement refused, that should be
indicated. a count of 'servers accepting shares' should be given too;
8/22 is one thing,
Kyle Markley writes:
> I'm not sure whether I'm misunderstanding something, or whether I've found
> a bug.
>
> I've been playing with my home grid a lot recently. When I first set up
> this grid I was using encoding parameters 2/3/4 but I changed this to 2/4/4
> after the first couple days. Wh
The testgrid seems not really ok. I realize it's volunteer/test, so I
don't mean to complain, but it's an interesting set of error
cases/marginal cases. Things that would be nice:
some way to test if servers actually will take and return shares.
some status of how this has gone (perhaps ju
In using my packaged version of tahoe, I tried to build it on a machine
with very few packages installed. It seems that the darcsver or the
non-standard version of setuptools included in zfec depends on py-expat:
File
"/usr/ANONCVS/pkgsrc/converters/py-zfec/work/zfec-1.4.7/setuptools-0.6c15de
http://tahoe-lafs.org/source/tahoe-lafs/snapshots/tahoe-lafs-ticket798-1.8.0β.tar.bz2
perhaps gnus is behind the times, but it would be nice to avoid greek
letters and make this work in ascii...
pgpF2m40XKZQ8.pgp
Description: PGP signature
___
taho
"Zooko O'Whielacronx" writes:
> On Tue, Aug 3, 2010 at 12:10 PM, Greg Troxel wrote:
>>
>> http://tahoe-lafs.org/source/tahoe-lafs/snapshots/tahoe-lafs-ticket798-1.8.0β.tar.bz2
>>
>> perhaps gnus is behind the times, but it would be nice to avoid gr
I tested
http://tahoe-lafs.org/source/tahoe-lafs/snapshots/tahoe-lafs-ticket798-1.8.0β.tar.bz2
on netbsd-5 with python 2.6 as a client. It seemed to basically work fine.
Two things I've been running into, not sure if they are problems or me
being confused:
--repair seems to write a new
"Zooko O'Whielacronx" writes:
> On Tue, Aug 3, 2010 at 12:53 PM, Greg Troxel wrote:
>>
>>>> http://tahoe-lafs.org/source/tahoe-lafs/snapshots/tahoe-lafs-ticket798-1.8.0β.tar.bz2
> …
>>> http://tahoe-lafs.org/source/tahoe-lafs/snapshots/tahoe-laf
"tahoe-lafs" writes:
> #1168: make setup.py more easily patchable by OS packagers
> ---+
> Reporter: davidsarah | Owner: somebody
> Type: defect | Status: new
Currently there is an option to "python setup.py install" named
"--single-version-externally-managed" which gives the behavior of just
not checking dependencies at all.
Is that sufficient to satisfy the needs of the NetBSD and Ubuntu
packagers (Greg, Paul), or do you want something more
I am not really understanding all the build machinery, which is because
I haven't spent enough time, so sorry if I am seeming dense.
pkgsrc does use --single-version-externally-managed on python
distributions which are eggs, and the install command looks like:
(cd
/n0/gdt/NetBSD-current/pkgsrc/
It would be nice if there were a way to
have a local node measure server performance and indicate it in the
status page. Pehaps: has it refused an upload, query RTT, download
speed, etc.
Do some kind of operation to store and retrieve single shares to
particular servers. This would n
"tahoe-lafs" writes:
> Okay this does appear to be happening in at least one of the slow v1.8.0c2
> downloads attached to this ticket. I looked at
> attachment:1.8.0c2-r4698-run-106-down-0.html and every request-block in it
> (for three different shares) went to the same server -- nszizgf5 -
I did a 'tahoe --check --raw' on my main directory in the pubgrid, and
got an odd report: the object is 'unhealthy', even though all 10 shares
are present, plus two leftover shares of a previous version. I would
call that healthy with some stale bits in need of garbage collection,
but maybe I don
David-Sarah Hopwood writes:
> Greg Troxel wrote:
>> I did a 'tahoe --check --raw' on my main directory in the pubgrid, and
>> got an odd report: the object is 'unhealthy', even though all 10 shares
>> are present, plus two leftover shares of a previo
I have an object that when I --check it find
"count-good-share-hosts": 6,
"count-wrong-shares": 2,
"count-shares-good": 8,
"count-corrupt-shares": 0,
"list-corrupt-shares": [],
"recoverable": true
},
"storage-index": "[redacted]",
"summary": "Unhealthy: some versions are un
We have a half-baked idea of how to solve the JavaScript dependencies
problem by making the visualizer code be a Secure Decentralized Cloud
App. :-) Commit Brian's patches to Tahoe-LAFS which cause it to emit
its download status report in JSON, but don't commit any of the actual
JS visua
"Zooko O'Whielacronx" writes:
> On Fri, Sep 3, 2010 at 6:34 AM, Greg Troxel wrote:
>>
>> That is half-baked, because it only works on the pubgrid :-)
>
> I have a vague notion that someone could run an "installer" which
> installs the JS app
"Zooko O'Whielacronx" writes:
> On Fri, Sep 3, 2010 at 10:03 AM,
> wrote:
>>
>> My first impression on reading about the project is, "redundancy and
>> crypto in the same tool? I wonder if they couldn't be separated".
>
> Actually I've been wondering the same thing recently. The encryption
>
So, I've been wondering if we should build some sort of plug-in
mechanism into Tahoe to make it easier to ship non-core features without
adding to the dependency load of the core system.
My $0.02, unix-centric: dependencies that are provided by packages that
already exist in os/etc. packagi
I built 1.8.0c3 on netbsd-5/i386 (via an updated pkgsrc entry not yet
committed) and it seems to work. 'tahoe check --raw' feels faster than
the previous beta and 1.7.1.
tahoe manifest seems to work reasonably quickly.
"tahoe deep-check --verify --repair" gave me an 'uncoordinated write'
error.
Brian Warner writes:
> On 9/7/10 6:29 PM, Greg Troxel wrote:
>>
>> I built 1.8.0c3 on netbsd-5/i386 (via an updated pkgsrc entry not yet
>> committed) and it seems to work. 'tahoe check --raw' feels faster than
>> the previous beta and 1.7.1.
>>
If audio of the talk could be available somehow, perhaps as a tahoe-lafs
podcast channel, that would be great.
pgpfU7FRLLD44.pgp
Description: PGP signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listin
ANNOUNCING Tahoe, the Least-Authority File System, v1.8.0c4
Works on on netbsd-5, i386, python 2.6.5. (where works means no
regressions; I have a bunch of things to file tickets on about repair
behavior in unstable grids)
I had run a previous version of ticket798 and had to change the
tahoe-c
slush writes:
> Hello Kevan,
>
> on volunteergrid are currently 14 servers online where 8 of them are
>>1.7.0. I'm using the last beta version on my all boxes.
Do people mean the same thing by "volunteergrid" and "pubgrid", and
specifically the one with introducer:
introducer.furl =
pb://tin5
1. We don't actually have a binary egg of pycryptopp-0.5.20 for
py2.6/linux/amd64 hosted yet, see:
http://tahoe-lafs.org/source/tahoe-lafs/deps/tahoe-lafs-dep-eggs/?C=M;O=D
. As soon as either Josh's or Brian's buildslaves are respectively
connected to the Internet or empowered with flap
"Zooko O'Whielacronx" writes:
> pycryptopp-0.5.19 had some bugs in the included copy of the Crypto++
> source code, which bugs were also present in Crypto++ v5.6.0 and are
> fixed in Crypto++ v5.6.1.
ok, don't wnat to deal with those, and upgrading is fine.
> Therefore Tahoe-LAFS will refuse t
"Zooko O'Whielacronx" writes:
> On Thu, Sep 23, 2010 at 7:10 AM, Greg Troxel wrote:
>>
>> buglet: storage status page should have nickname and page generation time.
>>
>> buglet: default config file for storage should say "reserved_space =
>&g
"Zooko O'Whielacronx" writes:
> On Thu, Sep 23, 2010 at 4:37 PM, Greg Troxel wrote:
>>
>> Sure, that's fine - but I missed the announcement here that the version
>> needed for tahoe had increased.
>
> I didn't mention it on the list! I gues
David-Sarah Hopwood writes:
> Greg Troxel wrote:
>> "Zooko O'Whielacronx" writes:
>>
>>> On Thu, Sep 23, 2010 at 4:37 PM, Greg Troxel wrote:
>>>> Sure, that's fine - but I missed the announcement here that the version
>>>>
"Zooko O'Whielacronx" writes:
> On Thu, Sep 23, 2010 at 4:37 PM, Greg Troxel wrote:
>> ERROR:
>> /usr/ANONCVS/pkgsrc/security/py-cryptopp/work/.destdir/usr/pkg/cryptopp/extraversion.h
> ...
>> Where is it supposed to be? Surely not
>
> U
"Zooko O'Whielacronx" writes:
> On the bright side, writing this letter has shown me a solution! Set M
> = the number of servers on your grid (while keeping K/M the same as
> it was before). So if you have 100 servers on your grid, set K=30,
> H=70, M=100 instead of K=3, H=7, M=10! Then there is
[dropping list on purpose]
Last time I checked there were two servers on the Test Grid that had
latencies > 1 second for every request. They were the ones named
"sunpal" and "linuxpal". Yep, I see that they are still connected:
http://pubgrid.tahoe-lafs.org/
Those are mine. it seems odd
"Zooko O'Whielacronx" writes:
> Last time I checked there were two servers on the Test Grid that had
> latencies > 1 second for every request. They were the ones named
> "sunpal" and "linuxpal". Yep, I see that they are still connected:
> http://pubgrid.tahoe-lafs.org/
Those are mine. I have
remind me not to join lists with bogus reply-to headers!
pgpxBNJsJDSWq.pgp
Description: PGP signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
"Zooko O'Whielacronx" writes:
> Last time I checked there were two servers on the Test Grid that had
> latencies > 1 second for every request. They were the ones named
> "sunpal" and "linuxpal". Yep, I see that they are still connected:
> http://pubgrid.tahoe-lafs.org/
I have updated sunpal7 (6
http://tahoe-lafs.org/trac/tahoe-lafs/wiki/OSPackages
I spiffed up the pkgsrc entry (which is now at 1.8.0)
I was unable to find this page from the front page.
pgpTg6PZwzkcs.pgp
Description: PGP signature
___
tahoe-dev mailing list
tahoe-dev@tahoe
There is a feature which is intended to fix this:
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/530# use setuptools's
--multi-version mode
-build = darcsver --count-all-patches develop --prefix=support
make_executable build
+build = darcsver --count-all-patches develop --multi-version
Okay, since you said this I haven't noticed any problems with sunpal7
(except that it is currently off-line), but your other system linuxpal
continues to take 8 minutes to answer most (or all?)
queries!
tahoes 1804 0.0 1.9 56400 39336 ttyp1 Sl Wed04PM 9:12.66
/usr/pkg/bin/pyt
It seems that what's needed is a weakened introducer capability, like a RO
dircap.
Then nodes would allow reads but not puts of shares.
pgp7nNalXvqra.pgp
Description: PGP signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.
"Zooko O'Whielacronx" writes:
> To see how quickly a server responded to some requests, go to the
> welcome page of a gateway (e.g. http://pubgrid.tahoe-lafs.org/ ) and
> click on "Recent Uploads and Downloads", e.g.
> http://pubgrid.tahoe-lafs.org/status/ . Then choose a recent
> operations and
Greg: would you be so kind as to open an issue ticket for this? Your
suggestions about how to improve the UI sounded spot on.
Sure, and I filed into the easy bits and the hard bit separately:
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1221
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1
"Zooko O'Whielacronx" writes:
> On Fri, Sep 24, 2010 at 5:38 PM, Greg Troxel wrote:
>>
>> There's a semi-related reliability issue, which is that a grid of N
>> servers which are each available most of the time should allow a user to
>> store, che
Rahul Golwalkar writes:
> As a part of our curriculum we are supposed to contribute towards an
> open source project. So, can anyone suggest a Network Security project
> available in Tahoe-LAFS which requires attention.
> I have read most of the material related to Tahoe-LAFS available
Ravi Pinjala writes:
> Just now in the IRC channel, it came up that the docs living in
> version control aren't especially discoverable. Zooko suggested
> converting them to .rst format and generating HTML pages from that,
> and I volunteered to do the conversion. Does anybody have any
> objecti
OS is a mix of distributions of GNU/Linux (which is really one OS) and
leaves out NetBSD, FreeBSD, OpenBSD, OpenSolaris, not to mention AIX and
HP-UX.
I realize OS version is then a huge bit of work, but I would also say
it's not that important. You might just have "unreleased / current
stable r
I know how to make a trac query to show tickets reported by me, but I
don't know how to put a query on the wiki page that will do that for
everyone, just like the 'tickets assigned to me'.
pgp9b9AkQNGkj.pgp
Description: PGP signature
___
tahoe-dev mai
David-Sarah Hopwood writes:
> Greg Troxel wrote:
>> I know how to make a trac query to show tickets reported by me, but I
>> don't know how to put a query on the wiki page that will do that for
>> everyone, just like the 'tickets assigned to me'.
&g
It's interesting that this paper (from the abstract) appears to fail to
decompose availability and confidentiality issues, as tahoe-lafs does
via encrypting the file content. I haven't read it, but it seems
relevant to tahoe peeps.
arXiv:1003.0488 (*cross-listing*)
Date: Tue, 2 Mar 2010 01:13:4
Wow, i will have to digest all that.
As a packaging ranter, I'll say that depending on 10 py-foo packages is
not a big hassle as long as:
most of those don't update constantly, and when they do the changes
are minor (API/ABI compat, not a lot of churn in installed file
organization)
We
I'm trying to build Tahoe on my Mac OSX laptop. I followed the instructions
on the quickstart page, but when I run:
pkgsrc works on osx. www.pkgsrc.org, read the instrucitons, and then
filesystems/tahoe-lafs. this is likely to be hard, but then you can
build lots of other stuff easily.
pg
Shu Lin writes:
> I have been running my own introducer and two server nodes. But these two
> nodes can't see each other running although they are both running and
> connected to the introducer. Also, the directories created on these two
> nodes are totally separated. Is there any configuration
All (or nearly all) of the pubgrid machines are on public IPs and have the
appropriate ports open, so your node(s) can connect to them even if yours
are behind NAT or have their ports blocked.
That's not my experience. I'd say 75% are public.
pgpshk5BgHh39.pgp
Description: PGP signature
sreenivasulu velpula writes:
> If i configure multiple clients in a single host machine, will there
> be a gate way for each client separately or else one gateway for all clients
> in that single host ?
One gateway per node. See tahoe.cfg in each node's directory. in
particular web.port
I think it makes sense to take down the pubgrid public gateway. I
realize it lets people sort of play with things before they install a
client, but as you point out it's a use that has really broken security
properties and that makes it feel more harmful than helpful.
pgpC4VoCoehmm.pgp
Descript
http://tahoe-lafs.org/source/tahoe-lafs/tarballs/allmydata-tahoe-1.8.0-r4803.tar.bz2
I only had a few minutes to try this, but I adjusted (locally) the
pkgsrc files to refer to the new version:
Index: Makefile
-VERSION= 1.8.0
+VERSION= 1.8.0-r4803
and had 2 problems:
1) The bu
Kyle Markley writes:
> I have also recently used the Tahoe-LAFS pubgrid to transfer (encrypted
> .zip) files to a mortgage broker in preparation for buying a house. The
> broker's e-mail system disallowed large incoming file attachments, but I
> needed to send him scanned documents. I put the
http://tahoe-lafs.org/source/tahoe-lafs/tarballs/allmydata-tahoe-1.8.0-r4803.tar.bz2
I have now built and run this, and it works fine (NetBSD-5, i386). I
was able to deep-check/repair/add-lease on my set of 13 dirs/files in
pubgrid. So it seems basically ok, modulo my prior two comments.
> Yes, it's very similar, but this was more convenient for me. The only
> other difference is that I don't have to remember to delete the files
> later; they'll expire naturally.
The default config seems not to turn on expiration, but I have opened a ticket
about that.
_
I think you have a good point about symlinks. Probably you should file
a ticket so this doesn't get lost. It isn't immediately obvious how
they should work, especially because tahoe does not have a concept of
"..". I think it can't grow one, because .. is a huge change to chained
capabilities s
Kyle Markley writes:
> On Wed, 10 Nov 2010 07:53:46 -0500, Greg Troxel wrote:
>> I think you have a good point about symlinks. Probably you should
>> file
>> a ticket so this doesn't get lost. It isn't immediately obvious how
>> they should work, esp
I think the real question is how failures are correlated and what the
recovery expectations are.
If you look at a company with staff, and consider disks independent,
then many faliures are just a disk. If the motherboard fails, you'd
have a spare and move the disks. But there is also a fire/flo
[request to adopt a platform]
So obviously I've adopted pkgsrc. Anyone on a pkgsrc system can just
install tahoe-lafs and all dependenicies very easily. Thus I am not
super inclined to put up binaries. If there's anyone using pkgsrc for
tahoe and having trouble, please ask for help.
Could
Brian Warner writes:
> In a sense, by desiring this, you're putting more emphasis on the
> unreliability of the server hardware (CPU) itself. (I guess that my
> inclination, one tahoe node per disk, shows that I'm putting more
> emphasis on the unreliability of the disks, and assuming that the C
"Paul Grunwald" writes:
> Greg, do you think this would work:
> http://www.netbsd.org/docs/pkgsrc/platforms.html#interix
>
> I'm installing SUA under Windows 7 Ultimate 64-bit right now just for grins.
>
> http://www.suacommunity.com/SUA.aspx
>
> I really don't want to play the whole Debian und
Bostonian writes:
> I am experiencing an issue with unplugging one node from my private
> grid. Here is my testbed:
>
> 1) 5 storage nodes
> 2) N=5, K=3
> 3) two clients running on my laptops
>
> It has been working fine for normal operations. Then, I thought it
> should continue to work even if
As I've mentioned before, I am contemplating a friendnet for backup.
I've collected some of my thoughts, and told zooko via identi.ca. He
suggested posting here rather than saying I was confused, so I'll
inflict it on the rest of you:
http://www.lexort.com/blog/tahoe-lafs.html
If anyone is do
Raoul Duke writes:
> regarding installation woes, i'd like to throw out a gordian knot
> style solution: make a vm that has it all set up, and give that out.
That's not a solution -- that's a workaround.
Seriously, while VMs are trendy and also have their users, tahoe-lafs is
a *filesystem* an
For your use case tahoe is not yet baked enough.
It's also possible tahoe is not the right tool for your problem.
Also check out coda:
http://www.coda.cs.cmu.edu/
tahoe doesn't currently have servers do resyncing automatically. That's
done by clients running repair.
You might want to decouple
I have updated pkgsrc to 1.8.1. Besides dealing with the 700/400
permissions, I had to add the following patch to avoid installing the
non-namespaced "buildtest" code (thanks to Zooko and David-Sarah for
helping me with this privately, although I may have misattributed
exactly which of them got t
"Zooko O'Whielacronx" writes:
> I intend to apply that patch to upstream once I have a test for it.
Soundsgood.
> Then, if we can also figure out how to fix the permissions there will
> be no patches needed for pkgsrc! Right? Cool.
True; that is the only patch now. Permissions isn't strictly
Shu Lin writes:
Certainly coda may not do what you want; I just thought you should know
about it.
> For fixing the firewall, I don't quite understand you suggestion. Even
> through, I fixed my setup by opening a port in my firewall last time as you
> suggest if you remember. But, I don't think
Ravi Pinjala writes:
> As far as description languages for data allocation go, Ceph has
> already solved this problem - check out the "CRUSH" algorithm.
> Basically, it's a description language for data placement that
> controls replication and data placement, and I think it also lets
> clients
Brian Warner writes:
> We've also been considering changing our main client-to-server protocol
> away from TCP-based Foolscap and over to something else, which might
> make it easier to use UDP-based STUN-like protocols.
There is bulk data, and thus we need TCP-friendly congestion control.
So m
Brian Warner writes:
> Oh, using socks as a *listening* proxy, instead of a connecting proxy?
> Interesting, I'd completely forgotten about that feature.
My hidden agenda is tor hidden service support :-)
pgpSTNaisDrSv.pgp
Description: PGP signature
___
Brian Warner writes:
> I suspect that UPnP is a bigger win, because a significant percentage of
> home firewall/routers at least claim to support it, whereas the only
> SOCKS proxies that I've encountered have been ones that I've installed
> myself.
Until now I had been blissfully unaware of UP
"Ted Rolle Jr." writes:
> `python setup.py build' issued these messages:
>
> Download error: [Errno 111] Connection refused -- Some packages may not be
> found!
> Reading http://www.divmod.org/
> Download error: [Errno 111] Connection refused -- Some packages may not be
> found!
> Reading http:/
I'll have to digest your note later, but a quick thought: There's a
grand ultimate vision, and there are incrementally useful steps. It
would be nice if we could both do something limited that was immediately
useful, and also have that work be on the path to the eventual right
answer.
As a concr
Brian Warner writes:
> On 12/20/10 7:53 AM, Greg Troxel wrote:
>>
>> As a concrete situation, it would be nice to target a friendnet grid
>> where we aren't particularly worried about malicious attempts to
>> cheat, but we do want to be able to observe how much
My real point was not that openpgp should be mandatory, but that
whatever tahoe does should be compatible, and avoid reinventing the
trust management wheel
Your comment made me realize more crisply that the real property I want
From pgp is to be able to manage keys via pgp and then easily insert
"James A. Donald" writes:
> On 2010-12-21 11:56 PM, Greg Troxel wrote:
>>
>> My real point was not that openpgp should be mandatory, but that
>> whatever tahoe does should be compatible, and avoid reinventing the
>> trust management wheel
>
> Tru
"Zooko O'Whielacronx" writes:
> Just so y'all know, the Test Grid (which is linked to from the front
> page of http://tahoe-lafs.org ) is full. I just tried to upload a 1.8
> MB PDF to it, and got this error message:
I am seeing this also.
> I wouldn't expect the Test Grid to become un-full an
"Zooko O'Whielacronx" writes:
> On Wed, Dec 22, 2010 at 6:34 AM, Greg Troxel wrote:
>>
>> I don't debate your point, but will observe that if you are right it
>> needs to be reinvented as a first-class project/protocol/etc. rather than
>> someth
I think it makes sense to have
$ tahoe create-node --demo
that will do that, and leave the default case suitable for use. I would
try 1/2/5 as parameters for the demo case and fix the instructions to
demand two servers.
Alternatively, the instructions might point at the pubgrid for servers
ins
Michael Coppola writes:
> I currently have a Tahoe-LAFS network that only has one server. This
> one server is both a storage node and the introducer. The
> shares.needed, shares.total, and shares.happy values are all set to 1.
> I plan to add more storage nodes to this network in the near fu
If the server status page had information about which servers had
refused to take shares (and the smallest size that was refused)
recently, that would help people figure things out. Right now the only
way to tell that servers are full is to get upload errors and then try
to piece things together
Brian Warner writes:
> On 1/4/11 9:36 AM, Greg Troxel wrote:
>>
>> [show full servers on status page]
>
> Oh, that's an awesome idea. I'll add that to the accounting
> server-status page that I'm building for #666 now.
Thanks. If that makes it into 1.8.
quick comment (without reading the whole foolscap/twisted discussion as
thorougly as I should):
it is totally fair to expect the OS/packaging system to have versions
of foolscap and twisted that work *with each other*
it is not reasonable to demand versions of dependencies that haven't
b
Brian Warner writes:
> What matters most is the filecap, dircap, or "rootcap" under which you
> stored your data. You must retain access to that string.
Nit: you really need the introducer furl. But all the storage servers
should have it, so that's less scary than your rootcap.
pgpHMBIdcC9z
Shawn Willden writes:
> On Sun, Jan 9, 2011 at 7:19 AM, Josh Wilcox wrote:
>
>> I was surprised because I assumed each share would be sent to a different
>> server, but this error message seems to be saying that tahoe was only
>> looking for 7 distinct servers.
>>
>
> The default is to use 10
1 - 100 of 401 matches
Mail list logo
