[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

Paul B. Henson wrote:

From: Mike Jackson
Sent: Tuesday, May 13, 2014 2:02 AM

In any case, dynamic configuration IS an
enterprise-grade/carrier-grade feature as opposed to static
configuration. It enables you to perform critical adjustments to your
service without interrupting your service (more or less depending on
the implementation).


You seem to be confusing the concept of "dynamic configuration", the
ability

to change the configuration of a running service without having to stop said
service or disrupt providing the service, with the concept of where the
configuration is stored, in a flat text file or in a database.


There is absolutely no reason why openldap could not support dynamic

configuration when the configuration is stored in a flat text file. There are
numerous examples of services which store their configuration in a flat text
file, and are capable of rereading that file and dynamically changing the
running configuration based on the changes found.


Yes, the current implementation of openldap only supports dynamic

configuration when the configuration is stored in an LDAP database, but that
is not an inherent limitation of storing configuration in a flat text file,
but simply the preference of the openldap developers. If they chose to do so,
they could absolutely implement a similar dynamic configuration for flat text
file configuration. The merits of flat text versus LDAP database configuration
have been debated to no end, and I don't intend to reopen that discussion, but
rather simply to point out it was a choice and not a restriction.
It was the only sane choice, and as you are not a developer and were not participating in the design discussions back in 2002-2003 you're not in any position to comment or critique on it. And judging from your commentary, you're not qualified to offer an opinion.
It's all well and fine for you to say "sure they could have kept the flat text file" but we would have had to invent a remote administration protocol and all of its required security mechanisms. Reinventing those wheels would have been stupid, when we already have highly evolved protocol, data model, and security mechanisms in place. Keep in mind that none of puppet/chef/cfengine/what-have-you existed or were in common use in that timeframe.
You cannot sanely rewrite a slapd.conf file from machine-generated code and expect it to resemble the original input. Since sysadmins tended to be sloppy and put config directives where they didn't belong, it was guaranteed that any dynamically modified file would still be reorganized relative to the input. Nor can you sanely reload an entire slapd.conf file without doing a bunch of redundant parsing, to skip over the parts that didn't change. It's a lot of work simply to find the parts that didn't change, unless you invent a network protocol that lets you send deltas. But oh wait, we already have a protocol with that - we can use the LDAPModify operation.
Only a moron would have chosen any other design path than the one we took. Any other path would have been tons of redundant code, redundant processing, and still caused complaints from clueless ungrateful users because it transformed their sloppily constructed config files into something else. 


If you don't see why dynamic configuration is a good idea, then you
probably shouldn't be using LDAP for anything too important, anyway.


I guess if we're going to play at being haughty, perhaps people that
cannot

differentiate between where the configuration is stored and how it is
processed shouldn't be using LDAP for anything too important, anywayâ



I personally believe that support for static configuration should be
removed already because having two different configuration systems in
place serves to confuse a lot of people, especially learners.


That statement is true; but if you had to pick which configuration system

confused more people, especially learners, it wouldn't be the flat text file
implementationâ
You're entirely mistaken. LDAP administrators have to know how LDIF works anyway. LDAP administrators have to know about ldapsearch/add/modify slapadd/slapcat anyway. LDAP administrators have to know how to read schema anyway. This is, in fact, shortening the learning curve for brand new admins. You're just too stuck in your flatland ways to recognize that fact. 

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/