> Quite honestly, if I could set priorities at Transarc, I
> would say this:
> 1) more than the 1K to 2K entries in a single pt group. how
> about 64K as a limit that actually worked? 64K would last for
> a while and guarantee that we'd have something to talk about
> in the future...
> 2) pt groups within pt groups.
> 3) define a difference between people with tokens and ip addresses
> in the pt server by providing system:whatever special names.
Paul, I definitely agree that having large groups (1) and groups
within groups (2) would make AFS even more powerful and flexible.
In fact, we've developed, implemented and are running AFS "groups within
groups" in production. It's been running fine now for over 6 months
in the umich.edu cell. We've found it very useful for delegating
control and administration. We've also used it effectively to logically
create groups with more than 1,000 members.
We have one protection group now (university:members) that has over
17,000 members in it. This protection group's membership is updated
based on extracts from the University personnel database. Currently
the procedures for timely updates aren't at a production level, but
that's not an AFS issue. Given a potential for 100,000 members we've
used the first two letters of a person's uniqname (KA entry) to create
a two-level hash:
university:members has as its members
university:members.<first letter> which has as its members
university:members.<first letter>.<second letter>
which has as its members all university members
with uniqnames starting <first letter><second letter>
Another example is itd:staff, which has as its members:
% pts mem itd:staff
Members of itd:staff (id: -1343) are:
itd.central:staff
itd.its:staff
itd.ns:staff
itd.uis:staff
itd.rs:staff
itd.ra:staff
itd.css:staff
The sub-groups are in turn administered by the corresponding units
(which can in turn further delegate to department levels by creating
protection groups administered by the departments and making those
groups members of the unit group). This allows us to permit files
to the entire division (itd:staff) or University (university:members)
just by placing the appropriate pt group on the ACL.
Since we offer services to non-University people, we really try to
discourage the use of the system:authuser pt group since it doesn't
really mean that the person is a member of the university (and therefore
should have access to software licensed only to members of the university).
With groups within groups, you could instead come up with a
engin:site_licensed_people
group and simply add the appropriate "pts add" command to your "new user"
script. Perhaps something similar could be done for IP addresses when
you create new subnets or machines (engin:site_licensed_machines).
The modifications to support groups within groups requires the addition
of code to the ptserver and the addition of one command to pts. Old
versions of pts work fine with the new ptserver and can even display
and add groups to groups, but they need the additional command to find
what groups a group is a member of.
If others are interested in the code, I have no problem making it available
subject to normal Transarc source code restrictions.
Bill Doster
ITD Umich Systems Group
University of Michigan, Ann Arbor
