Thanks to Jan Harkes and to M. Satyanarayanan for their comments
on my paper.  I'm very glad it has pleased some of the people
who've done most of the work on this project.

On Tue, May 09, 2000 at 03:29:41PM -0400, Jan Harkes wrote:
> Adrian has been going through the Coda user and administrators manual
> over the past 2 weeks and converted it to DocBook while he was at it.
> We'll put the new version online and into CVS soon. Manual pages are
> still quite outdated.

I shall be very happy to read this closely when it's done and to
make suggestions and even supply patches/new text/additions...

I wrote;
> I'd like to see an option to kclog which allows you to specify
> a token lifetime shorter or longer than the default, being
> anything from a few minutes to a few months.  This involves changes
> to kauth2 as well as to kclog.

And Jan wrote:
> My guess is that a user would always try to get a token for as long as
> possible, so maybe just changing kauth2 to have per user token lifetime
> policies. My other idea is in the direction of a clog-daemon, which
> Venus can query for the user's `secret' when a token expires.

This is, of course, technically rather nicer.  I myself am much more
likely to choose shorter values when possible than some users.
So would it not be possible to have, say (1) a default and (2) a
maximum length for each user, which could be configured in the way
you suggest, and still allow some flexibility at clog time in the
way I suggest?  Of course, this is still more work than my original
suggestion, which I deliberately made easy to implement.

I wrote:
> I'd like to see something like AFS's ptserver, volserver, and buserver;
> that is, some way of handling users and groups, volume status, and
> backup configuration remotely.  I realise that pdbtool is a relatively
> new piece of Coda, but I don't think it goes far enough.

And Jan wrote:
> We've experimented with LDAP for this, and although it looks promising
> we did have several problems.

Given the advantages and disadvantages of LDAP, which you point out
very clearly, I'd like to suggest something else.  Since all
of these services are very similar, requiring a small data base
which is kept up-to-date on all data servers, it seems to me a generic
solution should be possible.  It could be built on top of rpc2
and lwp and rvm like the rest of coda, and incorporate a solution
to the SCM question as well: I'd like to see a quorum system that
can be configured automatically by common tools, and one that
takes into account coda tokens and groups in deciding what a given
user can and can not do.  Indeed, as I understand it, you might
even be able to continue using the updateclnt/updatesrv processes
to disseminate the information, though again, that might be something
whose design may need to change if you're going to allow Coda
to expand to deal with large scale operations.  Similarly, AFS sites
with 30 or 40 thousand users have found that it's worth replacing
Transarc's ubik with something that doesn't transfer whole databases
acress.

Perhaps something like this might be a fruitful project that
Coda and Arla workers could collaborate on?

I also mentioned in the paper a suggestion that Coda might be able
to use something like AFS's PAG.  The PAG mechanism has the
advantage that it's implemented in public domain software, and
is reasonably well understood.  It means that, for example, I
can associate a token (an AFS token, in this case) with a web server
and its clients; I can replace the token for all processes in this
PAG, so I can control it; and someone who breaks into my web server/
Coda (or AFS) client can't easily get the token just by doing
'su www'.  It has nice effects by avoiding, for example, the problem
of associating a Coda token with root, which automatically allows
any process running as root to have that access.

This latter question is part of a general series of related problems
that I have: is Coda too oriented towards machines which have only
one user?  Or towards situations in which there is in effect only
one user per machine?  Thus the problem of the dangerous options
in cfs is related, the problem of getting things into the cache
(why can't hoard work unless I give at least L access to
System:AnyUser?), indeed the problem that anyone can clear someone
else's hoard list, etc.  For example, suppose I set up a cell with
real users, and one of these (a student) puts his thesis and a
few GB of personal files into the local hoard list; this will affect
everyone's performance on the machine, which we are assuming is one
shared by many users.

Thanks very much for listening, and for all the useful work!

     -- Owen
     LeBlanc_at_mcc.ac.uk