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.