Brian writes:
> Date: Mon, 16 Sep 1996 18:51:46 -0400 (EDT)
> From: "Brian W. Spolarich" <[EMAIL PROTECTED]>
> Reply-To: "Brian W. Spolarich" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: AFS administration "wrapper"
>
>
> I've heard mention of a tool that will enable cell admins to securely
> delegate cell administration privileges to sets of users. For example, I
> might have group volumes that have read-only replicas, and I want the
> users who manage those volumes to be able to "vos release" them on demand
> without having them be in system:administrators.
>
> I've grabbed EMT (Environment Maintenance Tool) from
> andrew2.andrew.cmu.edu, which looks like it might be the thing, but it
> looks pretty andrew-specific. It wants depot, the ADM server, and other
> stuff which I don't necessarily need.
>
> Have I found what I'm looking for? If not, does anyone know where I
> might find such a tool?
You probably actually want ADM not EMT. So far as I recall,
EMT uses ADM to do vos releases. ADM is essentially a secure
scheme interpreter that you program with your policy, in scheme,
ADM provides as scheme primitives, the various AFS RPC's, so your
policy code can then invoke the appropriate function as needed.
The last I recall, it didn't quite look like the ADM people had
caught up with the latest AFS 3.x release. That was a long
time ago however (pre AFS 3.3a), so hopefully it's no longer true.
Another potential tool is "sysctl", from IBM. Michael Fagan
<[EMAIL PROTECTED]> is probaby the person to ask about this,
as I think he was involved with the development of this.
I remember he was very friendly, but I understand he's since
left IBM.
Since you mention "vos release", there could be some special problems
here. A lot depends on whether ADM tries to invoke the logic
in libvolser, or what. I don't know what ADM does specifically today,
but I know that I have had a lot of problems implementing a "vos release"
mechanism in long-living server code, for the home directory server
code ("hdserver") which we use at the University of Michigan to manage
the creation of and changes to individual home directories.
These problems include:
(1) UV_MoveVolume catches interrupts. It never restores
the interrupt handler. Once UV_MoveVolume is
invoked, an interrupt will invoke a routine
that will do a long jmp into UV_MoveVolume's
context, with obviously bad results if
UV_MoveVolume returned in the meantime.
Come to think of it, the results are probably
bad before as well.
(2) UV_MoveVolume calls "exit" on certain errors,
instead of returning to the application.
(3) All the routines print all errors to stderr.
There are no provisions to capture the
error to log or return to a user. There
is a single global, "verbose", which
enables further copious trace output,
which also can't be logged or captured as well.
Things get very messy indeed if you arrange
to run multiple "vos releases" in parallel.
(4) UV_SyncVldb. If you don't specify "force",
it can prompt on stdout & wait forever.
Bad move in a server.
(5) "cstruct" global. This is a ubik connection to VL.
You need to arrange to periodically reauthenticate
tickets on this connection, if you want your
server to run "forever". The 'cstruct' global
is a dependency that extends way down, even
into such surprising functions such as "Lp_GetRwIndex"
which don't necessarily look like they would care.
(6) No provisions to interlock filesystem & rw volume
access during critical part of "vos release".
In a threaded server environment, it is very important to
avoid writing to a file on a volume that is being "vos
release"d by the same Unix process. In ADM, that is left
up to the scheme programmer to avoid. You might, for
instance, have a separate ADM server that just does "vos
release"s. In hdserver, it was important to do both with
the best throughput, so I ended up modifying the "vos release"
code to have a lock on the volume during the critical part
of the process in which a write to the filesystem was bad.
(7) the UV code creates and destroys many RX connections
to file servers during its work. I found problems in the AFS
3.3a version of rx that caused it to self-destruct
occasionally when used this way by hdserver. I see
some fixes in later versions of RX that address at least
some of the problems. I don't know if they fix all
of the problems. I dug into the 3.3a code and fixed
enough to make hdserver stable for us.
Essentially, all of these problems stem from libvolser mainly being
used by transarc for the "vos" command, which only does one vos
operation, and doesn't hang around long afterwards.
Here are the alternatives:
(I) invoke the program "vos release" on each volume you release.
This is the approach that is easy to do with "sysctl".
Advantages:
can always use the latest transarc stuff unmodified.
easy to run lots in parallel.
hard to deadlock
doesn't require source
possible to do a "vos release" in more than one cell
(granted, this seems of limited value...)
Disadvantages:
means playing shell games with output & process waits.
means you have to manage pags & tokens too.
no fine grain rw vol/filesystem lock available.
potentially not a good performer if you plan to do
*very* freqent updates to a smallish volume
from a largish server image using an underpowered
server (if it has to fork to exec vos...)
(II) use the library as is:
This is the approach ADM took in 1993 (and probably does today).
Advantages:
fairly easy to keep up with latest transarc source
should perform best w/ limited resources.
should be stable if you test rigorously first
(including load & error conditions
exceeding service expectations.)
possible to refresh tickets (but watch out
for cstruct!)
ADM source is readily available.
Disadvantages:
may break if transarc makes more unsuitable
changes to the library
is generally likely be fragile.
easy to deadlock
no fine grain rw vol/filesystem lock.
probably unwise to do more than one vos operation
in parallel.
difficult to capture verbose or error output.
"vos move" is almost certainly just plain bad.
various undocumented "bad" things (such as
not passing force to "vos synvvldb", etc.)
can't do a "vos release" in more than one cell
at the same time (since cstruct is shared!)
(III) fix the library to do it right
This is what hdserver does.
Advantages:
fine grain rw vol/filesystem lock possible.
potentially, a good performer (as long
as you don't do anything too silly,
like 26 "vos release"s at once.)
easy to capture output & errors as needed, and to
manage refreshing tickets.
possible to do a "vos release" in more than one cell
(granted, this seems of limited value...)
Disadvantages:
requires source
requires real programming expertise (but if you
have a source license, you are welcome
to a copy of my changes...)
hard to update to latest transarc version.
-Marcus Watts
UM ITD PD&D Umich Systems Group
