As of this afternoon, I have EFS automating the /afs namespace as far as
create/destroy project, which is pretty huge. The test suite completely
sets up and tears down all the AFS volumes necessary for EFS, and I'm at the
point now where I have to make some critical decisions before I go any
further.
The next thing to tackle is release creation, and this the first place in
the namespace where we need to grant access to someone other than efsops.
That means the next challenge is tackling the pts database.
EFS is all about scaling a single, logical "domain" globally. In that
context, this means a lot of different things, but in the case of NFS, it
means you need a globally managed uid/gid namespace. In the case of AFS,
this means the pts database needs to be in sync across all the cells.
Since we have no real users for this code, I'm not going to agonize over
trying to make the pts management configurable 10 different ways. For the
first pass, I'm going to do the same thing I did in the MS AFS/VMS
implementation: take total control of the pts database. We can then turn
off subsets of the functionality based on how sites that adopt EFS manage
their existing pts infrastructure. If that ever happens....
The EFS database will have a few tables for managing the contents of the pts
database, and users of an AFS/EFS environment will not be able to use the
pts command directly. The ownership of ALL objects in the pts database will
be system:administrators, and the ONLY way to alter the contents will be via
EFS. Each pts command will map trivially to an EFS CLI command as well:
pts $command $arguments => efs $command pts $arguments
Eventually, I'll write a very simple wrapper script that can be deployed for
users that does the CLI translation. Without such a wrapper, normal users
attempting to change the pts database will get EACCESS.
Each command will, after validation, update the EFS database first, and then
make the necessary change to the actual pts database in each cell in
parallel via the EFS::RPC mechanism. Things will get out of sync, of
course, so I'll write something like:
efs syncpts cell $name
to sanity check the contents of the EFS pts database against any given AFS
pts database. In fact, I plan to write a new subset of the test suite to
make sure all this is bullet proof. It's easy to create arbitrary problems
that can then be audited, and I will almost certainly write something to
audit the VLDB as well.
The immediate goal is pts management, then I'll be able to extend the
authorization model in EFS to support AFS pts groups as well as plain old
UNIX groups. Once that's done then it's on to the meat of EFS: managing
releases.
That'll be fun....
_______________________________________________
EFS-dev mailing list
[email protected]
http://mailman.openefs.org/mailman/listinfo/efs-dev
