54f974d44c
This is a change I've wanted to make for many years, because when we get to HTTP-based servers, we won't have tubids for them. What held me back was that there's code all over the place that uses the serverid for various purposes, so I wasn't sure it was safe. I did a big push a few years ago to use IServer instances instead of serverids in most places (in #1363), and to split out the values that actually depend upon tubid into separate accessors (like get_lease_seed and get_foolscap_write_enabler_seed), which I think took care of all the important uses. There are a number of places that use get_serverid() as dictionary key to track shares (Checker results, mutable servermap). I believe these are happy to use pubkeys instead of tubids: the only thing they do with get_serverid() is to compare it to other values obtained from get_serverid(). A few places in the WUI used serverid to compute display values: these were fixed. The main trouble was the Helper: it returns a HelperUploadResults (a Copyable) with a share->server mapping that's keyed by whatever the Helper's get_serverid() returns. If the uploader and the helper are on different sides of this change, the Helper could return values that the uploader won't recognize. This is cosmetic: that mapping is only used to display the upload results on the "Recent and Active Operations" page. I've added code to StorageFarmBroker.get_stub_server() to fall back to tubids when looking up a server, so this should still work correctly when the uploader is new and the Helper is old. If the Helper is new and the uploader is old, the upload results will show unusual server ids. refs ticket:1363
Tahoe-LAFS
Tahoe-LAFS is a Free and Open decentralized cloud storage system. It distributes your data across multiple servers. Even if some of the servers fail or are taken over by an attacker, the entire file store continues to function correctly, preserving your privacy and security.
For full documentation, please see http://tahoe-lafs.readthedocs.io/en/latest/ .
INSTALLING
Pre-packaged versions are available for several operating systems:
- Debian and Ubuntu users can
apt-get install tahoe-lafs - NixOS, NetBSD (pkgsrc), ArchLinux, Slackware, and Gentoo have packages available, see OSPackages for details
- Mac and Windows installers are in development.
If you don't use an OS package, you'll need Python 2.7 and pip. You may also need a C compiler, and the development headers for python, libffi, and OpenSSL. On a Debian-like system, use apt-get install build-essential python-dev libffi-dev libssl-dev python-virtualenv. On Windows, see docs/windows.rst.
Then, to install the most recent release, just run:
pip install tahoe-lafs
To install from source (either so you can hack on it, or just to run pre-release code), you should create a virtualenv and install into that:
git clone https://github.com/tahoe-lafs/tahoe-lafs.gitcd tahoe-lafsvirtualenv venvvenv/bin/pip install --editable .venv/bin/tahoe --version
To run the unit test suite:
tox
For more detailed instructions, read docs/INSTALL.rst .
Once tahoe --version works, see docs/running.rst to learn how to set up your first Tahoe-LAFS node.
LICENCE
Copyright 2006-2016 The Tahoe-LAFS Software Foundation
You may use this package under the GNU General Public License, version 2 or, at your option, any later version. You may use this package under the Transitive Grace Period Public Licence, version 1.0, or at your option, any later version. (You may choose to use this package under the terms of either licence, at your option.) See the file COPYING.GPL for the terms of the GNU General Public License, version 2. See the file COPYING.TGPPL for the terms of the Transitive Grace Period Public Licence, version 1.0.
See TGPPL.PDF for why the TGPPL exists, graphically illustrated on three slides.