[6098] in Release_7.7_team

home help back first fref pref prev next nref lref last post

Re: Reworking liblocker

daemon@ATHENA.MIT.EDU (Ken Raeburn)
Wed Dec 3 15:38:46 2008

From: Ken Raeburn <raeburn@MIT.EDU>
To: Evan Broder <broder@mit.edu>
In-Reply-To: <4936D9C5.4080701@mit.edu>
Message-Id: <BBF43488-C5EB-4689-B6F3-C4B2AF2B5E96@mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Wed, 3 Dec 2008 15:37:59 -0500
Cc: Greg Price <price@mit.edu>, release-team@mit.edu, athena10@mit.edu
X-Spam-Flag: NO
X-Spam-Score: 0.00

On Dec 3, 2008, at 14:11, Evan Broder wrote:
> Greg Price wrote:
>> The reason liblocker hasn't been updated already is that it doesn't
>> really have a role in this world.  Why don't we just let it die?
> Because there are features of liblocker that we don't and can't
> replicate in pyHesiodFS alone. Things like subbing to -c filsrv if you
> attach a locker,

I've heard that we're theoretically working on phasing out krb4.   
Certainly the next MIT Kerberos release isn't going to have it (and  
the current Mac OS X version already doesn't have it).  So unless  
someone's working on updating us to krb5 zephyr, zephyr's got a  
limited lifespan and we should be finding other ways to get  
notifications out if, indeed, we need to do that at all.  As for  
specific plans in phasing out krb4 or doing anything about Zephyr,  
I'll just say that I'm not really in much of a position to have heard  
about MIT's plans, so the fact that I've heard next to nothing  
recently may mean little.


Is it known that all the file system entries in Hesiod that mount  
under /mit attach at /mit/<lockername> and not elsewhere?  I know it  
didn't used to be the case, but the one example I know of (emacsdev)  
seems to have been fixed, probably long ago.

Does the automounter support filesystem names of the form 'foo@raeburn.org 
' like attach does?

Some file systems like aeneas:ftp don't attach under /mit, so the /mit  
automounter wouldn't be sufficient to cover those cases.

There's also the issue of "attach -m", which currently (Athena 9) does  
not require any special privileges to specify an alternate path under / 
mit, and possibly mess with other users' environments via $PATH if / 
mit isn't made per-user.

% attach emacs@raeburn.org
attach: /afs/raeburn.org/project/emacs attached to /mit/kr-emacs for  
filesystem emacs@raeburn.org
% detach emacs@raeburn.org
detach: emacs@raeburn.org detached
% attach -m /mit/foobar emacs@raeburn.org
attach: /afs/raeburn.org/project/emacs attached to /mit/foobar for  
filesystem emacs@raeburn.org
%

Ken

home help back first fref pref prev next nref lref last post