[6103] in Release_7.7_team
Re: Reworking liblocker
daemon@ATHENA.MIT.EDU (Greg Price)
Wed Dec 3 16:25:55 2008
Date: Wed, 3 Dec 2008 16:24:18 -0500
From: Greg Price <price@MIT.EDU>
To: Evan Broder <broder@mit.edu>
Cc: Bill Cattey <wdc@mit.edu>, release-team@mit.edu, athena10@mit.edu
Message-ID: <20081203212418.GC10836@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4936F61D.2020909@mit.edu>
X-Spam-Flag: NO
X-Spam-Score: 0.00
This looks good.
I'm a little puzzled only about one aspect of the plan:
> All forms of attach still aklog and sub to zephyr classes when appropriate
Does this mean that I aklog and sub every time I stat /mit/price/?
Also, I'm not sure how you propose to let the automounter aklog
on my behalf. Maybe you don't really mean that `attach locker`
just does `stat /mit/locker`, but rather that it also aklogs and subs.
Greg
On Wed, Dec 03, 2008 at 04:11:57PM -0500, Evan Broder wrote:
> 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
> >>
> >
> >
