[6098] in Release_7.7_team
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