From: Howard Chu
Sent: Tuesday, May 13, 2014 3:56 PM
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.
I see, you're going to go with the "your opinion differs from mine; therefore,
you are clearly not qualified to have an opinion" argument?
As a systems administrator who has been managing large-scale distributed systems since the
mid-90s, I think I do actually have the qualifications to have an opinion on configuration
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.
Really? It's amazing then how other enterprise scale software packages such as Apache
httpd managed to survive using flat text file configuration models without inventing
secure remote administration protocols for deploying that configuration.
Again, you're mixing up two things – how configuration is processed, and how
configuration is delivered. You are tightly coupling two things that do not need to be
coupled, basically decreeing by fiat that only that configuration which arrives over the
LDAP protocol may be dynamically placed into effect. If someone already has a secure way
of delivering flat text file configuration updates, too bad, they don't get to be
dynamically applied. Not because it's impossible to reload a configuration file and
apply the changes, but because you don't want to do it.
stupid, when we already have highly evolved protocol, data model,
security mechanisms in place. Keep in mind that none of
puppet/chef/cfengine/what-have-you existed or were in common use in that
Perhaps, but in the late 90s, before this design discussion that I didn't participate
in even took place, I already had secure mechanisms for delivering configuration files to
large distributed networks of systems.
You cannot sanely rewrite a slapd.conf file from machine-generated
expect it to resemble the original input.
I have no expectation that you will rewrite my slapd.conf. My expectation is that *I* will
rewrite my slapd.conf, and then slapd will reread it and apply the change configuration.
Nor can you sanely reload an entire slapd.conf file without doing a
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.
I don't think I ever claimed it wouldn't involve some additional code, some
additional work, to allow dynamic reconfiguration from rereading a flat text
configuration; I simply claimed it is possible. And "redundant" or not, parsing
a configuration file into a configuration structure is hardly intractable, nor is running
through the existing in-place configuration and comparing it to the new configuration just
loaded in determining the differences.
Only a moron would have chosen any other design path than the one we
All those morons that would really really really like the ability to have slapd
dynamically reload its configuration from a changed flat text file, please raise your
hands? Based on the mailing list archives, there seem to be quite a few of us. And I guess
now we have degenerated to the "if you wouldn't have done it the way I did,
you're a moron" argument.
other path would have been tons of redundant code, redundant processing,
still caused complaints from clueless ungrateful users because it transformed
their sloppily constructed config files into something else.
Assuming the implementation of what I would actually want, not the implementation you are
currently imagining I would want, that is blatantly false, as nothing would ever touch the
configuration file other than the user or their agent. The whole point is I don't want
something *else* touching my configuration files, I want my *configuration management
system* generating them.
You're entirely mistaken. LDAP administrators have to know how
anyway. LDAP administrators have to know about ldapsearch/add/modify
slapadd/slapcat anyway. LDAP administrators have to know how to read
anyway. This is, in fact, shortening the learning curve for brand new admins.
By that argument, apache administrators need to know how http works, so it would only make
sense to manage an apache server configuration via HTTP PUT. And bind administrators
clearly do need to know the details of the DNS protocol, so it only makes sense to manage
named configuration via secure dns updates. Anybody running samba should surely know the
details of the CIFS protocol, so obviously samba configuration should be managed via
mounting a share. Claiming that the configuration of an application needs to be managed
the same way that the data within the application is managed is fallacious.
You're just too stuck in your flatland ways to recognize that
And you have absolutely no consideration for people already administrating complicated
large-scale systems with many pieces, and the fact that deploying configuration this way
especially just for openldap doesn't necessarily fit in to the overall picture.
I've got nothing against your cn=config method, and will absolutely agree for some
deployment scenarios it is the better option. On the other hand, you blindly and
consistently insist that it is the only option that will ever make sense, despite numerous
people pointing out scenarios where a flat text file configuration works better for them.
So why did the deprecation of the flat text configuration file get pushed off from 2.5 to
a later release, other than many many people still wanting and needing it? Perhaps the
fact that a large number of people disagree with you is less an indication that there are
a lot of incompetent unqualified luddite morons and more an indication that there actually
is a reasonable and rational opposing point of view…