[6106] in Release_7.7_team
Re: Reworking liblocker
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Wed Dec 3 17:58:43 2008
From: Ken Raeburn <raeburn@MIT.EDU>
To: Evan Broder <broder@mit.edu>
In-Reply-To: <4936FFF7.2020305@mit.edu>
Message-Id: <B0FFD4AC-5517-46FC-8AD3-BD37518C5904@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 17:57:57 -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 16:53, Evan Broder wrote:
>> Does the automounter support filesystem names of the form
>> 'foo@raeburn.org' like attach does?
>
> I'm going to start by taking a moment to boggle at that. That's
> awesome
> - I had no idea Hesiod did that.
:-)
I don't know if anyone other than me has really used it in the cross-
domain attach case (and my only interesting case, that emacs volume,
was eaten up in a server crash), but it's there.
People could theoretically attach real volumes from other sites using
hesiod:
% attach gendalia@iastate.edu
gendalia@iastate.edu: You are not allowed to attach a locker on /home/
gendalia
% attach -n -m /mit/gendalia gendalia@iastate.edu
attach: /afs/iastate.edu/users/13/16/gendalia attached to /mit/
gendalia for filesystem gendalia@iastate.edu
%
... and then I can browse Tracy's home directory via a short path. Or
attach gnuplot@iastate.edu, etc.
If you wanted to get all fancy with the use of Hesiod etc, you could
probably even arrange for someone to be able to log in to a machine as
user@domain, map the locker name in hesiod, translate the "home"
Kerberos realm name, etc. But that would probably take a lot of
hacking, and would be silly.
> I think I'm in favor of forcing lockername to mount at /mit/lockername
> always, but I could possibly be swayed.
It's probably reasonable, but it is a functional change that should be
considered carefully.
I hope no one has created locker names with "/" in them.
> Are there justifications for keeping the ability to mount lockername
> at
> not-/mit/lockername other than that being the way it's always been
> done.
Well, if there are such lockers set up with scripts, they may have the
current mount point hard-coded in scripts. I don't know if debathena
does the automounting trick or a "real attach", but if it's the
latter, there could even be compiled binaries for *_deb40 with the
current pathnames hard-coded. If you want to use cross-domain
attaches, I wouldn't be surprised if binaries in volumes at other
sites have their normal paths hard-coded.
There seem to be only five volume names with colons in them (like
aeneas:ftp and achilles:mit), unless the moira client is lying to me;
they generally don't mount under /mit but instead use /hostname/
volumename. A few *srvd* names map to mount points of /srvd. The
filesystem athena-sun4-os-80 mounts on /os; filesystems x11r{2,3,4,5}
mount on /mit/x11. Many of these, at least, will probably not be
important in Athena 10; while x11r* might be interesting for
historical reference, the exact pathnames probably won't be
important. Access to the aeneas file systems is occasionally useful,
but doing it via /mit/aeneas:ftp/foo probably won't kill anyone.
I got those through the moira client and hesiod and knowing some of
our history, but I don't have the ability to check the database for
other cases.
Anything of type MUL (like athena-sun4sys) probably won't be handled
well by an automounter. I don't know if effectively desupporting that
type is likely to be a real problem.
Ken
