On Fri, May 27, 2011 at 12:06 PM, Matthias Birkner <[email protected]> wrote: > At $ork we have been "granted the opportunity" to consolidate our 20-odd, > globally dispersed, NIS domains into a central LDAP database. If anyone has > success stories, war stories, or good references they'd be willing to share, > I'd > appreciate any pointers I can get.
In a comparatively small deployment I've had great success: one location in the US and one in Singapore sharing the same database. Lessons: The OpenLDAP guys are right when they say you "probably don't need a multi-master environment"; unless your connection to the master is likely to fail and you have services (like RADIUS) that need write acces in order to function. Most of the time replication "just works"; it's been a long time since I needed to reload the database on a consumer because of replication problems. (Since OpenLDAP 2.4 I think.) pam_ldap works well, nss_ldap has some interesting behavior; like overly-hungry group searches. As a result I don't use nss_ldap unless it is absolutely required, like on my samba servers. /Most/ applications use referrals and server lists properly, the biggest exception seems to be the ldap tools suite (ldapsearch, ldapmodify, etc.) and, very likely, ldap libraries for perl/php/ruby etc. Extending OpenLDAP is very easy, we have created a custom schema for all sorts of attributes that aren't in the supplied schemas. That said, it is far better to plan ahead because removing an attribute from a schema is risky business. Managing your OpenLDAP data is another story. Although it is perfectly possible to manage the data using various existing tools, like luma, none of them deal with validating your data. We have had to build an internal ruby-rails application to be a front-end to LDAP that *does* handle validation, dependent attributes, etc. Although LDAP is a lightweight service I sometimes see timeouts connecting to it. As far as I can tell these are not related to load or record locking and despite my efforts to load-balance my ldap servers they still occur occasionally. However, this hasn't been a real issue because the application (usually samba) fails-over to the next server in it's list. (So I recommend running several LDAP consumers for general read access.) -- Perfection is just a word I use occasionally with mustard. --Atom Powers-- _______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
