[6101] in Release_7.7_team
Re: Reworking liblocker
daemon@ATHENA.MIT.EDU (Evan Broder)
Wed Dec 3 16:12:43 2008
Message-ID: <4936F61D.2020909@mit.edu>
Date: Wed, 03 Dec 2008 16:11:57 -0500
From: Evan Broder <broder@MIT.EDU>
MIME-Version: 1.0
To: Bill Cattey <wdc@mit.edu>
CC: Greg Price <price@mit.edu>, release-team@mit.edu, athena10@mit.edu
In-Reply-To: <1228334979.14797.23.camel@localhost.localdomain>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Flag: NO
X-Spam-Score: 0.00
I'm going to side-step replying to this for now. Instead I'll say that I
think that all of us had our assumptions wrong. We've been arguing about
this a lot on zephyr, and I think we've come up with a solution that
works better for everyone. Here's what I think it is...
First, punt liblocker.
Second, make pyLockerFS maintain what is essentially a per-user
attachtab, as I described earlier. Also, implement support for the
symlink and unlink calls. symlink basically implements support for
attach -e at the filesystem and per-user level. unlink will remove
whatever is located at a path, but doesn't prevent it from reappearing,
so any stat operation or whatever could cause the path to exist again
courtesy of Hesiod.
Whenever any of the liblocker utilities previously would have enumerated
the attached lockers from the attachtab, instead just look at `ls /mit`
to get the list of "attached" lockers.
`attach locker` just does `stat /mit/locker`.
`attach -e` does an `ln -s`
All forms of attach still aklog and sub to zephyr classes when appropriate
`add locker` works as it always has
`add -r locker` works regardless of if the locker is attached or not.
Note that the necessary athdir calls will probably cause the locker to
become attached if it's not already.
`detach locker` does `rm /mit/locker`
It also does whatever unlogging and unsubbing it would otherwise do.
Additionally, it checks your PATH and prints a warning of /mit/locker is
in your PATH, saying that you should run add -r
What do people think of that?
- Evan
Bill Cattey wrote:
> Insasmuch as the Athena 10 as we've been distributing it contains the
> Athena 9 detach man page, the functions of detach are documented, and
> missing.
>
> Additionally, the detach script that we distribute for the non-athena,
> stand-alone OpenAFS removes the /mit symbolic link created by the attach
> script we provide.
>
> Other things that the Athena 10 detach man page says that it does:
>
> * unsubscribe you from the zephyr filsys notification that attach
> subscribed you to.
>
> * offers you the option to detach all filesystems.
>
> * offers you the option to clean up the attachtab.
>
> I think going forward, that debathena is the outlier here and needs to
> offer some of the functionality of detach as deployed everywhere else.
> At the very least it is a bug that there is a man page that says detach
> does all these things, when in fact, it does not.
>
> Speaking as the guy who was Dan Winship's manager when he initially
> wrote detach (and the man page), I would say: The semantics you like
> are really closer in spirit to how the Sun automounter approached remote
> filesystems, not the way Athena did. I'd advocate for a way to offer
> the semantics of detach that give you the ability to disable access to
> the filesystem. That is what detach is for. If you don't like those
> semantics, you don't have to use the detach command, but I think its
> incorrect to argue that the detach concept should change simply because
> debathena broke with the Athena canon.
>
> At minimum we should:
>
> * Fix add -r to remove the path element even if the locker is not
> attached.
> * Prepare a new man page for detach that describes what it actually
> does.
>
> To go beyond the minimum, in my opinion, we should proceed with
> semantics that broder has outlined.
>
>
> -Bill
>
>
> On Wed, 2008-12-03 at 14:15 -0500, Greg Price wrote:
>
>> On Wed, Dec 03, 2008 at 02:09:54PM -0500, Bill Cattey wrote:
>>
>>> You want to maintain the debathena semantic compatibility that the
>>> detach command does nothing?
>>>
>> Yes, that's exactly the point. It's a consequence of the
>> always-working /mit namespace, which is an explicit, constantly
>> helpful design feature of Debathena.
>>
>> Use add -r to remove things from your PATH, because it actually alters
>> your PATH. I guess I'm not aware of much else detach is useful for.
>>
>> Greg
>>
>
>
