[OpenAFS-devel] openafs cell and contrib area?

[Jeffrey Hutzelman]

On 2 Nov 2000, Derek Atkins wrote:

> Also, I believe there are at least some plans to resurrect the
> grand.central.org AFS Cell, though there are still some technical
> issues in terms of distributing the cell.

All true.  The first dbserver for the grand.central.org cell is sitting in
my machine room, waiting for me to add more memory to it and install a
fileserver.  I have the memory (thanks, Derrick!), so there should be a
cell Real Soon Now(tm).

I expect the grand.central.org cell will contain copies of the releases of
major AFS implementations, documentation, and so on.  It certainly seems
likely that there will be a contributed area of some sort.  At the very
least, there is a need for someplace to collect contributed/third-party
tools and such.


ObOpenAFS:  As Derek points out, there are some problems involved with
setting up a widely-distributed cell like grand.central.org or openafs.org
Mostly these are related to limitations in AFS's authentication model (all
servers share one key) and in the authorization model used by the
bosserver, volserver, and vlserver. 

The model I envision is one where the Kerberos and pts databases are
maintained by a trusted set of individuals (presumably, members of the
system:administrators group), but fileservers can be run by anyone. 
Clearly the database services need to run on machines that are trusted by
the cell's administrators.  However, it is desirable that the operators of
database servers not be forced to trust _each other_. 

This requires that each server machine have its own key, so that no server
operator knows the service key used by another server.  This problem looks
hard, because all the clients "know" that every server uses the
afs@cell.name key.  However, I think that rxkad3 can enable that to change
in new clients, and a workaround for old clients, while ugly, would not be
impossible.

The authorization problem is considerably more interesting, I think.  At
present, the bosserver, volserver, and vlserver each recognize a fixed set
of privileged users, identified by the contents of /usr/afs/etc/UserList.
In order to allow independent server operators to exist within one cell,
the volserver and vlserver must have more flexible authorization models.
As a first cut, I propose something like the following:


- Every server has a defined set of administrators.  Presumably these
  are represented by pts groups, with the vlserver storing the pts ID
  of the administrator group for each server.

- Every volume has an administrator known to the vldb.  This is different
  from the concept of volume ownership -- volumes may be owned by users,
  but a volume administrator is unlikely to be a user.  This information
  _may_ also have to be stored in the volume header, but I don't think so.

- The following operations are permitted to server/volume admins:

  + An admin may create a volume on any server he controls.  Volume names
    are presumably subject to restrictions defined by the cell admins.
    A newly created volume has the same administrator as the server on
    which it was created (_not_ the individual who created it)

  + An admin may move a volume he controls to a server he controls.
    He need not be an administrator of the volume's old site.

  + An admin may remove any volume he controls, regardless of location.

  + An admin may rename any volume he controls, subject to the same
    volume namespace restrictions as for creation.

  + An admin may add an RO site for a volume he controls to a server he
    controls.

  ??? how to add RO sites when volume and server admin are not the same?

  + An admin may remove any RO site for a volume he controls.

  + An admin may remove any RO site on a server he controls.
  
  + An admin may perform a release of any volume he controls.

  + An admin may change the administrator of any volume or server he
    controls.

  ??? Can server admins release volumes?  When?


Cell admins can presumably do any of the usual operations, without
regard to who the volume and server administrators are.  They also
have the ability to set volume namespace policy in some fashion.
Unfortunately, that is a complicated issue...

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA