Hi

 

Basically what Jon and Turbo and Dan have said.  I have been on and off  this mailing list for nearly 10 years and my first choice for ldap server has always been openldap, but to be honest gone are the days when I want to read code to find out what its doing. Take that to read the unit tests as well.

 

I have also found the list to be rather abrasive to people who’s first job is not ldap who come here to ask questions.

 

Alex

 

 

 

 

From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Dan Pritts
Sent: Friday, 31 January 2014 9:20 AM
To: Borresen, John - 0442 - MITLL
Cc: Howard Chu; openldap-technical@openldap.org
Subject: Re: FW: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

 

I'm with John & Turbo, and I guess with the article author.  Openldap is hard to configure.  It is also, in my limited experience, pretty solid, once you get it working the way you want. 

Part of the problem is definitely just groking LDAP itself.   And I haven't ever tried to configure any of the competition, except I guess AD, so I can't compare to the others directly. 

I have so far always been able to bend openldap to my will, usually with help from the people on this mailing list.  But I've been at this *nix stuff for more than 20 years, and it has never been easy. 

Someone compared configuring openldap to configuring apache.  Apache is hardly the model of easy-to-configure software.  However, the documentation is much better and the examples are much, much more usable. 

The openldap Administrator's guide and man pages are incomplete and occasionally incorrect/outdated.  For example, yesterday I found bad syntax in the "map" examples at the bottom of the slapo-rwm man page (i do intend to report a bug on that one). 

Error messages are pretty bad.  For example, an unreadable private key file causes this error in the syslog:  "main: TLS init def ctx failed: -1".   Of course, this and the associated startup failure is a big improvement, version 2.4.23 failed the initialization silently, and just logged "TLS Negotiation failed" when you tried to connect.  

Another example - slaptest gives the following when I test a config file that has the old, bad rwm syntax:

[root@cnsutil0 openldap]# ../../sbin/slaptest -f test
slaptest: config.c:198: config_check_vals: Assertion `c->argc == 2' failed.
Aborted

The administrator's guide talks about stacking overlays, but doesn't mention that gee, sometimes that doesn't work real well (ITS 5941, rwm + translucent = crash).   That issue is from 2010, with no apparent solution.  


Just so we are clear --- I would not have posted these complaints (at least, not without solutions) if it weren't for this thread.  My intent is not to bitch about the quality of the software or the documentation.  I am getting much more than I am paying for, and I notably have not raised my hand to rewrite the documentation or fix any bugs in the code.  However, to deny these things is to put one's head in the sand.

regards
danno

Borresen, John - 0442 - MITLL wrote:

Sorry, I didn't read the original mailing list...I too wanted to send to the board and not you individually.  My apologies.
 
-----Original Message-----
From: Borresen, John - 0442 - MITLL 
Sent: Thursday, January 30, 2014 1:16 PM
To: 'Turbo Fredriksson'; Howard Chu
Subject: RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?
 
I have experience with OpenLDAP, 389-Directory-Server, OpenDJ, OpenDS, RedHat's Directory Studio.  I am not an LDAP expert by any means (as can be seen by my help posts -- that was supposed to be funny).  While I get aggravated by the difficulty in installing OpenLDAP, the miniscule documentation, and the differing, and often conflicting, documents found via a google search I always recommend OpenLDAP over the other products.  The OpenLDAP Admin Guide, for a product that has been out for a very long time, as far as a how-to-guide, is lacking a lot and seems incomplete -- many areas are simply blank.  The bouncing back and forth between the slapd.conf (old) and the slapd.d (new) methodologies is very aggravating and not helpful (to me).
 
I understand that there is not just one way to install OpenLDAP...the options are pretty mind-boggling -- and can't all be put in an Admin Guide, the manual as more than a dictionary could be so much more.  With this test environment I've been building over that 2 or 3 months, it's been broken down and restarted, from scratch, at least once a month.  The original environment (the current production) took me about a year to get up and running.
 
We use the Apache Directory Studio as a front-end GUI to view the dbase, mostly.  Most modifications are via the CLI tools.  
 
Don't get me wrong, even for my "bashing" of OpenLDAP above, it is the first one that I would recommend.  I look at the bright side...each time the slate has to be cleaned and restarted the more I learn.
 
Dave Borresen
 
 
-----Original Message-----
From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Turbo Fredriksson
Sent: Thursday, January 30, 2014 11:53 AM
To: Howard Chu
Subject: Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?
 
On Jan 30, 2014, at 5:35 PM, Howard Chu wrote:
 
I saw some of this on twitter before, ignored it since none of the parties involved have any clue what they're talking about.
 
 
Personally, I think it's spot on. It IS hard to configure an LDAP server, and even harder to understand how it works (the object based part). Took me three months first time, and I'm not an idiot.
 
Even today, I need to consult either my own book or the howto (or seriously skim through the man pages) to setup a new server.
 
And even worse if when you want to optimize the backend... There's a lot of magic there....
 
And with the new config backend!? I haven't even had the time or energy to go that far yet!
--
I love deadlines. I love the whooshing noise they make as they go by.
- Douglas Adams
 
 
 

 

--
Dan Pritts
ICPSR Computing & Network Services
University of Michigan