William Hopkins | 19 Jul 16:59 2013
Picon

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)


Gmane