1
This is a proposal for handing accounts and quotas in Tahoe. Nothing is final
2
yet.. we are still evaluating the options.
5
= Account Management: Introducer-based =
7
A Tahoe grid can be configured in several different modes. The simplest mode
8
(which is also the default) is completely permissive: all storage servers
9
will accept shares from all clients, and no attempt is made to keep track of
10
who is storing what. Access to the grid is mostly equivalent to having access
11
to the Introducer (or convincing one of the existing members to give you a
12
list of all their storage server FURLs).
14
This mode, while a good starting point, does not accomodate any sort of
15
auditing or quota management. Even in a small friendnet, operators might like
16
to know how much of their storage space is being consumed by Alice, so they
17
might be able to ask her to cut back when overall disk usage is getting to
18
high. In a larger commercial deployment, a service provider needs to be able
19
to get accurate usage numbers so they can bill the user appropriately. In
20
addition, the operator may want the ability to delete all of Bob's shares
21
(i.e. cancel any outstanding leases) when he terminates his account.
23
There are several lease-management/garbage-collection/deletion strategies
24
possible for a Tahoe grid, but the most efficient ones require knowledge of
25
lease ownership, so that renewals and expiration can take place on a
26
per-account basis rather than a (more numerous) per-share basis.
30
To accomplish this, "Accounts" can be established in a Tahoe grid. There is
31
nominally one account per human user of the grid, but of course a user might
32
use multiple accounts, or an account might be shared between multiple users.
33
The Account is the smallest unit of quota and lease management.
35
Accounts are created by an "Account Manager". In a commercial network there
36
will be just one (centralized) account manager, and all storage nodes will be
37
configured to require a valid account before providing storage services. In a
38
friendnet, each peer can run their own account manager, and servers will
39
accept accounts from any of the managers (this mode is permissive but allows
40
quota-tracking of non-malicious users).
42
The account manager is free to manage the accounts as it pleases. Large
43
systems will probably use a database to correlate things like username,
44
storage consumed, billing status, etc.
48
The Account Manager ("AM") replaces the normal Introducer node: grids which
49
use an Account Manager will not run an Introducer, and the participating
50
nodes will not be configured with an "introducer.furl".
52
Instead, each client will be configured with a different "account.furl",
53
which gives that client access to a specific account. These account FURLs
54
point to an object inside the Account Manager which exists solely for the
55
benefit of that one account. When the client needs access to storage servers,
56
it will use this account object to acquire personalized introductions to a
57
per-account "Personal Storage Server" facet, one per storage server node. For
58
example, Alice would wind up with PSS[1A] on server 1, and PSS[2A] on server
59
2. Bob would get PSS[1B] and PSS[2B].
61
These PSS facets provide the same remote methods as the old generic SS facet,
62
except that every time they create a lease object, the account information of
63
the holder is recorded in that lease. The client stores a list of these PSS
64
facet FURLs in persistent storage, and uses them in the "get_permuted_peers"
65
function that all uploads and downloads use to figure out who to talk to when
66
looking for shares or shareholders.
68
Each Storage Server has a private facet that it gives to the Account Manager.
69
This facet allows the AM to create PSS facets for a specific account. In
70
particular, the AM tells the SS "please create account number 42, and tell me
71
the PSS FURL that I should give to the client". The SS creates an object
72
which remembers the account number, creates a FURL for it, and returns the
75
If there is a single central account manager, then account numbers can be
76
small integers. (if there are multiple ones, they need to be large random
77
strings to ensure uniqueness). To avoid requiring large (accounts*servers)
78
lookup tables, a given account should use the same identifer for all the
79
servers it talks to. When this can be done, the PSS and Account FURLs are
80
generated as MAC'ed copies of the account number.
82
More specifically, the PSS FURL is a MAC'ed copy of the account number: each
83
SS has a private secret "S", and it creates a string "%d-%s" % (accountnum,
84
b2a(hash(S+accountnum))) to use as the swissnum part of the FURL. The SS uses
85
tub.registerNameLookupHandler to add a function that tries to validate
86
inbound FURLs against this scheme: if successful, it creates a new PSS object
87
with the account number stashed inside. This allows the server to minimize
88
their per-user storage requirements but still insure that PSS FURLs are
91
Account FURLs are created by the Account Manager in a similar fashion, using
92
a MAC of the account number. The Account Manager can use the same account
93
number to index other information in a database, like account status, billing
96
The mechanism by which Account FURLs are minted is left up to the account
97
manager, but the simple AM that the 'tahoe create-account-manager' command
98
makes has a "new-account" FURL which accepts a username and creates an
99
account for them. The 'tahoe create-account' command is a CLI frontend to
100
this facility. In a friendnet, you could publish this FURL to your friends,
101
allowing everyone to make their own account. In a commercial grid, this
102
facility would be reserved use by the same code which handles billing.
105
== Creating the Account Manager ==
107
The 'tahoe create-account-manager' command is used to create a simple account
108
manager node. When started, this node will write several FURLs to its
109
private/ directory, some of which should be provided to other services.
111
* new-account.furl : this FURL allows the holder to create new accounts
112
* manage-accounts.furl : this FURL allows the holder to list and modify
113
all existing accounts
114
* serverdesk.furl : this FURL is used by storage servers to make themselves
115
available to all account holders
118
== Configuring the Storage Servers ==
120
To use an account manager, each storage server node should be given access to
121
the AM's serverdesk (by simply copying "serverdesk.furl" into the storage
122
server's base directory). In addition, it should *not* be given an
123
introducer.furl . The serverdesk FURL tells the SS that it should allow the
124
AM to create PSS facets for each account, and the lack of an introducer FURL
125
tells the SS to not make its generic SS facet available to anyone. The
126
combination means that clients must acquire PSS facets instead of using the
129
== Configuring Clients ==
131
Each client should be configured to use a specific account by copying their
132
account FURL into their basedir, in a file named "account.furl". In addition,
133
these client nodes should *not* have an "introducer.furl". This combination
134
tells the client to ask the AM for ...
added
removed
docs/proposed/old-accounts-introducer.txt
