> 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 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. > You cannot sanely rewrite a slapd.conf file from machine-generated code > and > 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 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. > Only a moron would have chosen any other design path than the one we > took. 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. > 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. 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 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. 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 fact. 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 o! pposing point of view…
