William Hopkins | 19 Jul 16:59 2013

Re: LDAP without the cruft

On 07/19/13 at 04:16am, Collins, Kevin [Contractor Acquisition Program] wrote:
> On 18/07/13 11:44, William Hopkins wrote:
> > I see it is clearly now necessary, but that doesn't make it not cruft. There is
> > a decided direction in Linux engineering going towards more system daemons and
> > more layers of abstraction (D-BUS, GConf, Dconf, gsettings, consolekit,
> > network-manager, policykit, udisks, upower, etc. etc. etc.) I understand for
> > many of them they gain popularity because they make desktop maintenance easier,
> > but I resist their encroachment in the server world; philosophically they don't
> > line up with the UNIX/Linux mindset. Luckily, in the Linux world we are still
> > allowed to choose. Anyway, that's my little rant on that subject, thanks for
> > your help.
> Just as an FYI, the new model with nslcd makes for a much more resilient
> model when your LDAP server(s) have issues. In the prior model, if one LDAP
> server has an issue there is the potential for MANY processes to be directly
> impacted by timeouts. With the new model, only the nslcd process has to face
> the timeout... 
> If you have ever had to deal with those problems you will definitely
> appreciate nslcd :)

Please don't top post to mailing lists. I know modern clients make that
difficult, but still. 

I am aware of the issues when LDAP goes down; these are best addressed by 1) a
proper configuration with LDAP as a secondary auth source with the appropriate
timeouts and pam options and 2) a robust LDAP architecture, load balanced or
clustered with delegations per-site. These are all described in detail in most
LDAP software configuration manuals. LDAP servers, like any other service you
are responsible for configuring and providing, require good engineering
(Continue reading)