[928] in athena10
Re: nss: hesiod -> ldap for groups?
daemon@ATHENA.MIT.EDU (Evan Broder)
Fri Jan 23 00:53:31 2009
Message-ID: <49795B15.9010601@mit.edu>
Date: Fri, 23 Jan 2009 00:52:21 -0500
From: Evan Broder <broder@MIT.EDU>
MIME-Version: 1.0
To: Jonathan Reed <jdreed@mit.edu>
CC: debathena@mit.edu
In-Reply-To: <D57EA9D1-12B9-4D98-8F0D-139011E66354@mit.edu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
It, uh, turns out that we actually lose here, at least against
ldap.mit.edu as it stands now.
Groups in LDAP don't have a GID field.
- Evan
Jonathan Reed wrote:
> Assuming LDAP is guaranteed to be a stable source of (AFS) group
> information, this sounds like a good idea. I think LDAP gets a moira
> incremental, right, so it would also eliminate a DCM delay when
> updating group information. However, is LDAP as replicated as Hesiod
> (which has both the local cacheing nameserver and 3 Hesiod servers)?
>
> -Jon
>
> On Jan 22, 2009, at 8:15 PM, Evan Broder wrote:
>
>> Do we want to switch to using LDAP instead of Hesiod for group
>> information on Athena 10? This would solve the problem where people fall
>> off of groups when they're on too many, and also get rid of this weird
>> usage of NFS groups - i.e. why should I have to make something an NFS
>> group instead of an AFS groups to be able to use it in a Unix ACL?
>>
>> Does anyone have opinions on this?
>>
>> - Evan
>
