(Illustration by Gaich Muramatsu)
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.ukReceived on 2000-05-10 11:39:54