[933] in athena10
Re: nss: hesiod -> ldap for groups?
daemon@ATHENA.MIT.EDU (John Hawkinson)
Fri Jan 23 08:47:50 2009
Date: Fri, 23 Jan 2009 08:46:51 -0500
From: John Hawkinson <jhawk@MIT.EDU>
To: Evan Broder <broder@MIT.EDU>
Cc: athena10@MIT.EDU
Message-ID: <20090123134651.GC29687@multics.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <49799A6B.4000801@mit.edu>
Technical specifics somewhat aside, are you really comfortable
adding a dependancy for athena logins on yet another set of
servers?
What's the reliability of the LDAP.MIT.EDU servers and service? What's
NIST's expected level of support in the event of a failure? How close
are they running to capacity, and how much of a big deal is that? How
redundant are they?
--jhawk
Evan Broder <broder@MIT.EDU> wrote on Fri, 23 Jan 2009
at 05:22:35 -0500 in <49799A6B.4000801@mit.edu>:
> Message-ID: <49799A6B.4000801@mit.edu>
> Date: Fri, 23 Jan 2009 05:22:35 -0500
> From: Evan Broder <broder@MIT.EDU>
> To: Evan Broder <broder@mit.edu>
> CC: Jonathan Reed <jdreed@mit.edu>, athena10@mit.edu
> Subject: Re: nss: hesiod -> ldap for groups?
> In-Reply-To: <49795B15.9010601@mit.edu>
> X-Enigmail-Version: 0.95.7
> X-Spam-Score: -5
>
> Hmm...that being said, I just spent a couple of hours source diving into
> Hesiod and Moira, I'm not convinced that it's actually feasible for us
> to fix nss_hesiod to deal with more than 255 bytes worth of groups; my
> instinct is that we can cause more change to ldap.mit.edu than we can to
> the combination of Moira, Debian/Ubuntu's Hesiod, and Debian/Ubuntu's
> libc (where nss_hesiod lives).
>
> I think we should pursue updating ldap.mit.edu to give us the
> information we want, but I'm not sure what the political playing field
> looks like there. IS&T people: is it likely that we can get ldap.mit.edu
> fixed up for this? Or should we suck it up and deal with and continue to
> try to fix Hesiod groups?
>
> To answer your earlier questions, Jon, LDAP appears to get a DCM, not an
> incremental, and it looks like there are two servers that receive that
> DCM, although I haven't figured out the topology that connects them to
> ldap.mit.edu. And both servers are in the same room, so less resilience
> than Hesiod, but *shrug*
>
> - Evan
>
> Evan Broder wrote:
> > 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
> >>>
