[rhelv6-list] LDAP without the cruft

[William Hopkins]

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
upfront. 

NSLCD was designed client-server for a variety of reasons and I assume with
good intentions. It still isn't a good idea. And at the end of the day, I am
less interested in convincing the current linux community to follow good
practices than I am in finding out how to configure my environment in
accordance with my own principles. So I was asking for technical assistance on
how to avoid NSLCD, not reasons why you think NSLCD is a good idea. 

-- 
William
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/rhelv6-list/attachments/20130719/2919c0a6/attachment.sig>