[6095] in Release_7.7_team
Re: Reworking liblocker
daemon@ATHENA.MIT.EDU (Evan Broder)
Wed Dec 3 14:11:47 2008
Message-ID: <4936D9C5.4080701@mit.edu>
Date: Wed, 03 Dec 2008 14:11:01 -0500
From: Evan Broder <broder@MIT.EDU>
MIME-Version: 1.0
To: Greg Price <price@mit.edu>
CC: release-team@mit.edu, athena10@mit.edu
In-Reply-To: <20081203183815.GX10836@vinegar-pot.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Flag: NO
X-Spam-Score: 0.00
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, or aklogging when necessary. There are some semantics
there that, while we can't provide them through the filesystem, we
shouldn't destroy for people who expect them.
> We do need some form of attach -e, for people maintaining replicated
> lockers. I don't think this needs to be any more complicated than
> making PyHesiodFS accept the symlink() call and accept unlink() on
> symlinks. That plan allows people to make fudges on the semantics (*)
> but only very consciously. It's also of minimal complexity.
>
Like Jon said, it requires root privileges. I like the idea of being
able to mount arbitrary paths to arbitrary names regardless of whether
I'm root or not. That's useful for people who are trying to do things on
a variety of platforms, but maybe aren't SIPB-affiliated and therefore
don't have root access to a machine of every architecture ever.
- Evan
