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

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

Paul B. Henson wrote:

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?
No, I'm going with the "where were you with your bright ideas when we needed help designing and implementing this?" argument. You're not a developer and clearly unable to write code that behaves as you suggest. Nor are you anywhere volunteering to sponsor such work.
Meanwhile, you have no concept of the programming constraints that led to the decisions we made, nor sufficient background to appreciate their significance. 

Your opinion is worthless noise.


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 management.



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, 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.


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.

Your examples are irrelevant and not applicable.
I've been writing server code since the 1980s. Yes, it was common practice back in the day to allow manual rewriting of config files and sending a server a SIGHUP to tell it to reread its config. But hey moron, that didn't work with threaded programs. Signal handling wreaked havoc with the threading implementations of the day. If you were a developer you might be aware of this fact. But you're not, and you have no valid basis for any opinion of how the code should have been implemented. 


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.


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.
How kind of you to volunteer someone else to go to all the trouble of donating the additional work required to implement a non-viable mechanism. That's not how open source development works. If you want a feature, you either write it or you sponsor its development. You're clearly not qualified to do the work yourself. In this particular case, it's pointless anyway because the feature you're requesting, to make slapd behave like every other historical Unix daemon, is a non-starter. 

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