On Jan 30, 2014, at 7:35 PM, Howard Chu wrote: Ah, ok. Fair enough, but that must need optimization to work properly (?). I'm currently in the process of migrating all the authentication services from my iron (which is also my ZFS On Linux storage - my idea was to ONLY have storage on the iron) to a virtual machine. So I installed the latest version (2.4.39 or something like that - can't check now). I saw the recommendation to use the new mdb backend (I'm using hdb on the ldap server on the iron). But a few days later, I noticed that the LDAP server on the VM was down, and I couldn't restart it. Some debugging later, I noticed that the log db had grown out of control (also using mdb). I didn't have time to investigate exactly why, so I just deleted the whole log db (don't really need it). Yeah, but you probably do that all day. I don't change my server that often, so every time I first need to retrieve the object in question, look at it, then generate a change ldif that I can send to the LDAP server. In my phpQLAdmin tool (which I haven't worked on in quite some time) I added support for the new slapd config backend 'years' ago, so I HAVE used it, I just remember that it's a lot more complicated (if you don't do it all day) than editing a flat file. I'm all for removing the flat config file, I also think that the new way is better. But it IS more complicated, no matter how you see it. TO complicated, no, but still MORE complicated... Technically you're of course right, but that doesn't really matter in practice. That's not how 'the noob' sees it. People (especially people not experienced enough to file a proper bug/issue report - which is quite difficult!) have a (really bad) habit of looking at the wrong thing when something doesn't work. How many haven't heard the report: "It doesn't work." (period, full stop! :). Usually followed with "Fix it now!" :D I'm in no way immune to that, but I like to think that when I have a problem, I'm good at trying to figure out WHY something goes wrong and 'blame' the correct part/software... But most people don't. And that's the ones bitching most loudly about OpenLDAP being complex. It IS complex, but it's supposed to be - it's the most advanced and fastest LDAP server out there, with the longest list of features... -- Life sucks and then you die

My main issue with the cn=config method is how to integrate it into our revision control and approval system. Currently, with the flat file, the authoritative configuration is stored in a revision control system. When there are any changes to be made, they are made in a development branch, tested, then reviewed and approved to be merged into the production branch, at which point they are pushed out to the system. I'm not really sure how to do that with the dynamic cn=config method. For example, currently our revision control system could tell us exactly what configuration was in place seven weeks ago. How would you do that with cn=config? I suppose you could have a change log document in revision control, but unlike the actual configuration file in revision control, there's no way to say whether or not the changes made dynamically via cn=config are exactly matched to the changelog. Unless perhaps the ldif executing the change is maintained in revision control?

Hmm, so the revision control system would transition from being the authoritative source of what the configuration is (ie, in our current system, if somehow the running configuration deviated from the version in revision control, it would automatically be corrected back) to simply becoming a record of whatever changes happen to have been made on the running configuration?

Aaron Richton <richton(a)nbcs.rutgers.edu&gt; wrote I'm checking in the VCS and from there the automated configuration (puppet, ansible etc.) does the rest of it. Automatically diffing config DBs and apply the changes is far more complicated than diffing text files. Especially the latter gives you far better text logs of which changes were done. Ciao, Michael.

On Fri, Feb 07, 2014 at 02:25:45PM +0100, Simone Piccardi wrote: (SNIP) Therein lies the issue with the text config file for some of us - we are not able to interrupt the ldap service which supports critical customer-facing services. Or, more specifically, we are not able to interrupt ldap service without floods of really grumpy master tickets. The cn=config layout really helps here. For my part I had ldap bootstrapped via puppet into a full cn=config supplier/consumer multimaster setup, but I never got as far as a type/provider to configure ACLs or anything. (SNIP)

--On Friday, February 07, 2014 2:25 PM +0100 Simone Piccardi <piccardi(a)truelite.it&gt; wrote: Definitely not. slapd.conf allows people to put things in all sorts of random order that slapd "fixes" when it reads in the slapd.conf file. cn=config enforces correct ordering, so with cn=config you can tell exactly what is happening, where it can be a muddled mess with slapd.conf. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

Simone Piccardi wrote: you are right, but is is easy to reformat things same to me ;-) but ldif may also looks nice # ldapsearch -LLLY external -H ldapi:/// -b 'cn=config' '(olcaccess=*)' olcaccess 2>/dev/null|fmt_olcAccess dn: olcDatabase={-1}frontend,cn=config olcAccess: to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break olcAccess: to dn.exact="" by * read olcAccess: to dn.base="cn=Subschema" by * read dn: olcDatabase={0}config,cn=config olcAccess: to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break dn: olcDatabase={1}hdb,cn=config olcAccess: to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=kronprinz,dc=xx" write by * none olcAccess: to dn.base="" by * read olcAccess: to * by self write by dn="cn=admin,dc=kronprinz,dc=xx" write by * read # cat $(which fmt_olcAccess) #!/bin/sed -rf # Author: Harry Jede # produce human readable but still machine parseable # olcAccess lines and removes the ordering numbers in {} # because humans don't need them, really. # the hole script s/^(olcAccess: )\{[[:digit:]]+\}(.*$)/\1\2/ $!{H;d} ${H;g;s/\n //g;s/[[:space:]]+by /\n by /g} -- Harry Jede

Howard Chu wrote: I know this. The reason why you have created the ordering prefixes is that without them the ordering is *not* always the same during multiple searches. Dacor. For documenting, comparing, testing or creating access to new databases I found that this is my favorite approach. And during some support sessions by customers I found that one of the common failures during access design, is that customers failed to order the "to clause" of access rules. In such cases I retrieve the access rules, reorder them with an editor, and upload all at once wih ldapmodify. And yes, slapd adds the ordering prefixes in line order of the ldif file. Magic and cool. If I need to modify or add single rules, i still use the script to retrieve, but without the olcacces line. Now I can create ldifs for ldapmodify with ordering prefix. The "by clauses" are one at a line. That's better for my eys. # cat $(which fmt_olcAccess2) #!/bin/sed -rf # Author: Harry Jede # produce human readable but still machine parseable # olcAccess lines # the hole script $!{H;d} ${H;g;s/\n //g;s/[[:space:]]+by /\n by /g} the output is now with prefixes. -- Harry Jede

Paul B. Henson wrote: Especially I'm not keen on allowing a CRON job with a clear-text credential in a config file to commit into the VCS. Also you don't have meaningful commit messages when doing so. Ciao, Michael.

Paul B. Henson wrote: I'm also working with a configuration pulled from revision control system and pushed to the systems with automated orchestration system. As Howard confirmed on this mailing list static configuration will still be available in OpenLDAP 2.5.x. Ciao, Michael.

On 02/06/2014 03:28 PM, Paul B. Henson wrote: Just FWIW, we also have the configs for our different OpenLDAP databases on various servers under git version control. This provides us with a critical, time-stamped audit trail and documentation for all changes along with a fast, reliable method for reverting to earlier configs should it become necessary. We would very much hate to lose that audit-trail & documentation and control. ;-) -- Andy Dorman Ironic Design, Inc. AnteSpam.com, ComeHome.net CONFIDENTIALITY NOTICE: This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any erroneous transmission. If you receive this message in error, please immediately destroy it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, or copy any part of this message if you are not the intended recipient.

Quoting Christian Kratzer <ck-lists(a)cksoft.de&gt;: "You" in my message referring to the OP, not you Christian. Or you can ldapsearch it from a backup script running on a cron job. Or you can cd into the config directory and do a git init. 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). I have built multilevel LDAP clusters where there were over 15000 simultaneous persistent connections from mobile network elements checking RBAC against management actions and believe me, static configuration would have been a showstopper if I needed to restart LDAP services just to expand my capacity (adding new replicas, etc). 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 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. -mike

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

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

[...] [...] [...] [...] [...] You aren't by any chance the long-lost separated at birth twin of Theo de Raadt? You seem to share the great skill of turning what should be a technical debate into a circus of baseless insults, groundless accusations, and ad hominem attacks. On the other hand, both of you are brilliant in your own ways, so I guess what god takes with one hand he gives with the other. I already told you I was not going to continue this argument, it's like trying to talk the sun into not casting shadows...

Nice way to short-circuit a debate. "You don't understand the issues, you lose." Actually, I do understand the issue; you are right, everyone who disagrees with you or expresses an alternative viewpoint is wrong. Perhaps reloading flat text configuration files wasn't the best design then, perhaps it isn't the best design now, but it's certainly *possible*, which is all that I'm saying. I'm not saying I'm going to do it, I'm not demanding that you do it, I am simply saying it can be done. Hell, you already have a function that converts a slapd.conf into ldif format. Given two slapd.conf files, convert them both into ldif, run an ldifdiff on them to generate the ldif modifying the first into the second, and feed that into the existing ldif-based dynamic reconfiguration code. It can be done. You choose not to do it.

So you're changing your position from "it's impossible to do" to "it's not worth doing"? And you're still acting as if nobody has ever posted to the mailing list in favor of keeping the plaintext configuration, and of having the feature of dynamic reconfiguration from the plaintext configuration, which is just plain egocentric. So you say. Yet clearly you still feel compelled to continue to attempt to refute any argument I raise; it seems that if I were only generating noise it would be far simpler to ignore it and let it fade into the background… Ah, yes, the grumpy cat meme. Posting pictures of grumpy cats never fails to help solidify the soundness and accuracy of one's arguments. I counter your grumpy cat position with a happy cat rebuttal: http://breakappz.com/wp-content/uploads/2014/02/happycat.jpg No snappy slogan, but happy cats need no caption to make their point. I apologize, Dr. Chu, could you please repost the syllabus and study guide that might lead one to a full and complete understanding of everything you've ever said, done, or looked at in your lifespan? Perhaps if they ever achieve cloning a human being along with all of their knowledge and memories, you might actually have someone you consider worthy of corresponding with without childish tantrums and and taunting? Sheesh.

ruled Yes, 10 odd years ago you looked at reloading a flat text configuration file and decided not to do it. And since not a single thing could have possibly changed in that 10 years, there's absolutely no reason to ever consider it again. After all, since signals and multithreaded programs were a bad combination 10 years ago, there's no way that signals and multithreaded programs could possibly work today, right? Just like 10 years ago there were no other options other than signals, such as UNIX sockets, to control a program externally. A decision made is a decision finalized, and pity the fool who might want to reconsider it, even if only as an abstract hypothetical. in of plain Yes, you have plenty of experience at telling people who express the desire, need, or requirement for plaintext configuration that they don't really desire, need, or require plaintext configuration, that they are morons, have no basis for an opinion, have nothing to contribute to the discussion, clearly have no development skills, and perhaps should have never been born in the first place. and May I see a show of hands as to who has reviewed the entirety of the www.openldap.org website, including all of the mailing list threads, presentations, topics linked to, and FAQs? Didn't raise your hand? Please unsubscribe from the list immediately and stop pestering Howard with your uninformed and ignorant postings. You already have the framework for dynamic reconfiguration. If the guts are LDIF, more power to them. But there's nothing magic about feeding that framework LDIF. Given the ability to turn a plaintext slapd.conf into LDIF (which exists), the ability to take two LDIF files and generate a third LDIF file that turns the first into the second (which exists), it seems it's really not that much glue required to hook all that together and feed your dynamic reconfiguration framework the LDIF it wants based on the changes between two flat text configuration files. Disregarding the fact that you don't want to do it, disregarding the fact you don't want it done, and maybe even staying on track with the technical discussion and not diverging onto a tangent about how my great great great grandfather was too incompetent to shoe a horse, why exactly is it that such a design is infeasible, impracticable, and impossible to implement? Obviously you couldn't do this 10 years ago before you had the existing LDIF based reconfiguration framework, so saying you couldn't do this 10 years ago is not really a valid justification as to why it could not be done now...

<53743120.9040700(a)symas.com&gt;: But there's also no point in writing replies like "it's documented" (as if the writer has found it) without giving the proof (i.e.: URI). Finding such a response in a mailing list archive is just as useless IMHO. (You may supress the flame that usually follows such replies).

incapable of in So far I've seen a lot of links and explanations as to why you could not/would not do it 10 years ago; an answer as to why it couldn't be fairly readily bolted on on top of the existing LDIF dynamic reconfiguration today (other than you don't want to), not so much. Asking one question and continuously getting an answer to a different one is a bit of a waste of time too.

Yup. Can't speak for anybody else, but I'm pretty sure I've never insisted on or demanded anything from you. That's true; but in case you missed it, this discussion for some time now has been less about whether or not someone wants something, and more about whether or not it could be done. At least twice if not three times now I've suggested a hypothetical implementation that should allow dynamic reconfiguration from flat text configuration files without that much complexity. And while you keep sending me links and telling me about discussions that are 10 years old, I don't believe you have even once addressed that specific question about implementing something today, not about not implementing something 10 years ago. I'm not insisting that you do it, I'm not demanding that you do it, I'm not even asking you to do it, I'm just looking for a nonbiased technical response as to whether or not it could be done. Good thing I haven't been insisting then. I notice you didn't respond to my previous inquiry requesting mailing list archive links to those messages where I allegedly insisted or demanded for something from you? As it turns out, no matter how many times you say something that isn't true, it doesn't become true. I will grant that I've been *asking* you for an answer to a question for far longer than any rational person should waste time doing so, but stopping that is entirely in your own hands - either actually answer the question rather than deflecting, or just stop responding with tangential topics.

Hmm, I'm not sure how continuing to engage in a discussion in which two people are involved demonstrates a sense of entitlement? I don't believe I have sent a single post on this thread that was not in response to someone else's post. Am I mistaken? Perhaps you could point one out? If no one replied to me, I'd stop posting. Clearly, as people continue to reply, they are interested in continuing the discussion. I'm not demanding an answer, I'm simply saying that if you're going to take the trouble to keep replying to the conversation, why not answer the actual question rather than continuously going off on tangents and insulting people? I believe you overestimate the deviousness of my "small little" mind. Well, I definitely concede his superiority in the department of spewing insults, making irrelevant demeaning comments, and most certainly in posting pictures of grumpy cats with snappy slogans. But personally, I find a technical argument much more compelling when it is not interwoven with baseless accusations and judgments, and turns of phrase that would be much more suitable in a kindergarten playground confrontation. Do you enjoy making conclusions about others peoples abilities and skill sets with no evidence to back them up? When combined with your obvious pleasure in telling boastful stories of your own abilities and accomplishments, it makes one wonder if they might be signs of some type of self-confidence disorder. Perhaps you should see someone about that? Actually, it's more like flipping the channels on late-night TV and accidentally tuning in the Jerry Springer show. It's a guilty pleasure to be sure, but watching people make train wrecks of themselves in wild agitation is such schadenfreude. Yelling, screaming, insulting; if we happened to be speaking in person, would you be the guy that starts throwing chairs around? If you're going to use this thread as a learning experience for your daughter, be sure to include the parts where it is rude to be vain and boastful, that all human beings deserve to be treated with some level of common courtesy and not insulted for no cause, and maybe not to judge people you don't actually know? God willing, perhaps she will grow up to be kinder and less egotistical than you've shown yourself to be. I'm going to have to agree with Michael on your reading comprehension skills, as my input in this thread clearly demonstrates I agreed that dynamic configuration is important and an excellent feature. Perhaps if you go and reread it a couple more times, you will understand that all I ever said was that it would be possible to have a flat text configuration file interface to dynamic configuration. It seems you continue to make the mistake upon which I first called you out, confusing the feature (dynamic configuration) with the implementation (LDIF over an LDAP interface). Does your daughter tell her friends on the playground that they should go stab themselves in the eye with a fork? Cause you know, saying things like that is a sign of a lack of emotional maturity. Would you show this thread to your daughter and take pride in it, and tell her "Hey, look at me! I told some guy I don't even know to stab himself in the eye with a fork! That showed him!" I get the feeling there are many many far greater minds than yours. But please do continue to respond, as sometimes after the chair throwing there is the shirt ripping off of and chest beating. I've got no issue with pragmatism, but while ruthless might indeed describe this thread, pragmatism does not – when considering the rude insults, baseless judgments, and name-calling that seem to have outweighed any technical merit, I think it would be more appropriate to pair ruthless with bully.

Quoting "Paul B. Henson" <henson(a)acm.org&gt;: Apache httpd was not responsible for providing core services and management interfaces inside of telecom networks (it was even so unsuitable as a middleware platform that java was used instead). LDAP, on the other hand was, and is a core component of every telecom network in existence. Things like, oh I don't know, being able to dynamically crank up the logging level without disconnecting your clients in order to respond to and investigate alarms... Those are sort of important and stuff, you know, for a network to which 50 million phones are connected. Back in 2002-2003, as a core architect I personally made the decision regarding which LDAP server software to use for a mobile network management system that still has a very large market share. If you use a mobile phone, chances are high that you are supported still today by the system I designed and implemented. I wrote a scathing report about the capabilities of OpenLDAP at the time, and I even shared it with Howard IIRC. I'm pretty sure I also discussed it with him in person in Tuebingen over dinner. OpenLDAP was not my choice, even though I did attend the developers conference and bring along a friend to boot. Needless to say, the situation is completely reversed today and given the current capabilities of OpenLDAP, I wouldn't recommend anything else. Howard and crew have done one hell of a job positioning OpenLDAP so that it can be used inside the telecom arena. Little IT shops where you want LDAP to authenticate 10 users and you are never going to contribute anything except for complaints, you're simply not important in the grand scheme of things. So before you all go blowing smoke out of your asses, Stroeder, that includes you, too, it might be wise not to underestimate with whom you are speaking. -mike

On 15 May 2014, at 6:21 am, "Paul B. Henson" <henson(a)acm.org&gt; wrote: Lol. And the award goes to?? I think it would be impossible to decide..

On Wed, May 14, 2014 at 11:57:22PM +0200, Michael Ströder wrote: Hey now, you do realize that back in 2002-2003, as a *core architect*, Mike *personally* made the decision regarding which LDAP server software to use for a mobile network management system that *still* has a *very large* market share? *And* he had dinner with Howard in Tuebingen? And that not only did he attend the developers conference but he *brought* a *friend* to *boot*? And that while *you've* never contributed *anything* but *complaints*, *he's* ... oh, wait: $ git log | grep michael(a)stroeder.com | wc -l 2 $ git log | grep mj(a)netauth.com | wc -l 0 $ git log | grep Jackson | wc -l 0 Be sure not to underestimate with whom you are speaking 8-/.

On 13/05/2014 11:01, Mike Jackson wrote: I don't need anything of this. I just need a simple LDAP server for a small business, where the complexity of dynamic configuration is just a cost with no benefit. And anyway a lot of services (bind, apache, posfix just to name a few) implemented dynamic configuration by the means of a kill -HUP. Simone

Simone Piccardi wrote: That's not really dynamic configuration. Anything that requires you to physically login to a server to issue a change is not scalable. With cn=config you can delegate configuration privileges across an arbitrarily large network, without requiring any host/OS privileges. Most people didn't "need" electricity when they still had oil lamps... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

There is not much difference between a slapd.conf and an .ldif of the cn=config information, just a different text format. But the benefits come from synergy of using ldap as the internal config structure should not be overlooked, there are strongly typed data storage, fast lookups, and reams of boilerplate code being thrown away. But presently we still need a binary (executable) to turn that cn=config text format into something slapd can boot up and use. Given the text -> cn=config code is present already, is there really that much work to leaving it there? But can we reliably create the slap.d config file with deployment scripts directly, as it also seems to just be text. Other than being nicer to read, is there really anything wrong with the (already) text format of cn=config on the disk ? There are some gotchas with the conf file, in any case. Config options mean different things in different places etc.,

Mike Jackson wrote: When using slapadd to fully load cn=config you have to stop your slapd during that. So this is definitely *not* how cn=config is supposed to be operated. Also when mucking directly with the LDIF you loose slapd's capability of input validation. Ciao, Michael.

Mike Jackson wrote: Be assured that I did study cn=config schema in depth. *You* clearly don't understand what the discussion is all about. And you're arguing with contradictions. Ciao, Michael.

On Thu, May 15, 2014 at 01:28:16AM +0300, Mike Jackson wrote: So, when might we expect your memoirs to be published? It seems you have done so many interesting things in your life. You didn't perchance happen to walk barefoot ten miles through the snow to get to the computer with ethereal on it? That would certainly add a dash of spice to the story, which is always helpful when one hopes to make the bestsellers list.

Was auf der Erde haben die Menschen tun, bevor Google übersetzen? So your native language is German, you're posting on a primarily English-based mailing list, and then your signature includes an Italian colloquialism ;)?

--On May 15, 2014 at 12:58:30 AM +0300 Mike Jackson <mj(a)netauth.com&gt; wrote: That'll work up until the point cn=config is migrated to a binary backend such as back-mdb, and there are no flat text files to access at all. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

--On May 15, 2014 at 8:32:07 AM +0300 Mike Jackson <mj(a)netauth.com&gt; wrote: Yeah, sorry, I misread what you were saying. I thought you were saying you were hand-editing the cn=config LDIF entries, which wouldn't be portable if cn=config goes to a binary format. Since your not, never mind. ;) --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

Quoting Howard Chu <hyc(a)symas.com&gt;: So, it's not even a concern at all. Well, I did consider it as a "public interface". What I meant was that it didn't seem to be the officially sanctioned way to do things - it's not mentioned in any of the documentation that you can bootstrap your initial config in this way, although the attributes and such are documented in the admin guide. Now that we are clear on this, would you mind if I rewrote the Quick-Start Guide to remove slapd.conf references and provide a clear example how to bootstrap config with an LDIF? I'd be happy to do it. -mike

--On May 15, 2014 at 7:03:50 AM -0700 Howard Chu <hyc(a)symas.com&gt; wrote: Already done a few weeks ago. As is of course, public record.. ;) - Log ----------------------------------------------------------------- commit f48242de0051380d3ec4d9bb72976f277a9ddeac Author: Quanah Gibson-Mount <quanah(a)openldap.org&gt; Date: Fri Apr 25 15:03:50 2014 -0500 Convert quickstart guide to cn=config --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

Quoting Howard Chu <hyc(a)symas.com&gt;: I agree, but it does serve to reinforce rule number 1 of system engineering: design a better system and they'll design a better idiot. OK, I will prepare one. I already did a git clone. -mike

Michael Ströder wrote: Perfectly fine for bootstrapping the initial config though. You can muck with input to slapadd all you want. It will still get basic validation. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

Michael Ströder wrote: In this post I believe you're the one who has missed the point. The point is the cn=config format serves both needs - you can create a slapd configuration in pure LDIF, and you can dynamically modify it. You seem to be arguing that cn=config is only useful for dynamic modification, which implies that you use some other format for your seed configs, which is, frankly, stupid. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

Brett @Google wrote: That's *not* the official way of doing it. The general recommendation on this mailing list has always been not to touch the LDIF files in slapd.d/ directly. Especially input validation cannot be performed in this case. Ciao, Michael.

Paul B. Henson wrote: you will never accept an alternative viewpoint and banging my head against a concrete wall is not my favorite hobby. While I have great respect for your skills and knowledge, and great appreciation for your work with openldap, I think your opinion on this particular topic is a bit too artificially ingrained. You really think what you're suggesting wasn't suggested already, 12 years ago? You really think we didn't already *try* it and see that it didn't work? This is why advice and opinions from people like you is utterly worthless. If you didn't participate in the work leading up to the current implementation, and didn't walk through the code and previous designs, and don't understand the coding implications of a particular approach, then you've got nothing valid to contribute to the topic. If you didn't read the debates from the openldap-devel mailing list back when this was first covered, you've got no business rehashing the conversation now. If you didn't actually spend any of your own time writing code to test an approach, failing, and trying another approach, you've got no right to demand any particular implementation from anyone else. http://www.openldap.org/conf/odd-wien-2003/proceedings.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

<0ce601cf6fb1$b6199c60$224cd520$(a)acm.org&gt;: Well if you want to sync your configuration with LDAP means, the LDAP representation (as well as DIT metadata) makes sense. If you see the server as an island, modifications are trivial, but if the server is part of an infrastructure, any change may break other parts of the infrastructure. At that point one might argue that implementinc two mechanisms for the same thing is one too much, maybe. I'm not an OpenLDAP developer... Regards, Ulrich

<070e01cf1eeb$ded56ab0$9c804010$(a)acm.org&gt;: Why not check-in the config directory? It shouldn't change that often. You could check in the "slapcat" also, but ordering of entries may be somewhat, well, chaotic. Personally I wrote a program that postprocesses the slapcat LDIF output to write the entries in a structured directory (similar to slapd.d) while avoiding line breaks in the LDIF. I wonder whether it would make sense to sort the attribute namess of an entry (I already have one file per entry)... Well maybe you'd need another tool, like LDIF-diff-to-ldapmodify ;-) I'm experimenting with importing LDAP database backups into Git with structured LDIFs as described above. Anybody else? Regards, Ulrich

Turbo Fredriksson wrote: Yeah, if she manages to setup AD the next thing is to teach her how to fix or work around replication problems. (Note: It's nearly impossible to repair a broken AD domain without migrating it and/or re-joining all systems.) Ciao, Michael.

Turbo Fredriksson wrote: Nonsense! There is no difference between installation and administration. It's a major fault to artificially distinguish that! I've started with OpenLDAP 1.0 in 1998 (well actually I've started with Umich 3.3. just before). But it's unfair to argue with docs from that time. Many things improved since then. And yes, I'm still reading OpenLDAP docs. Especially when designing ACLs. Fine-grained ACLs are hard in every software component. Anyone not able to read man pages and admin guides should not touch server configurations at all. No wonder that so many systems are hacked when so-called "IT pros" (web enthusiasts etc.) set up systems without learning about what they are doing. In this particular case your problems arised from deficiencies of the GnuTLS code layer. Simply don't use GnuTLS or try to improve this code part. Ciao, Michael.

Turbo Fredriksson wrote: Let me be clear about this - there is nothing hostile in this message: The Project is run by volunteers. If you want something to improve, then contribute your time to making it happen. There is no chain of command where any person gives orders and someone else carries them out. Areas get worked on when interested people step up and work on them. The areas of code that I've worked on were the areas that interested me personally. Areas that don't interest me get ignored. (Some things, like asserts and other annoying crashes, may get my attention even though the code doesn't interest me, but these are somewhat rare.) The topic of documentation does raise some ire these days, particularly because we see companies like Zytrax slurping up our Admin Guide and regurgitating it with a large dose of their own misunderstanding and misinformation. If you actually want to help make things better for the Project and the community, then do so - submit documentation patches back to us. Don't splinter off and write your own fantasy novel of how you think things work. Write patches to the Guide to expand on the areas you think need to be explained better. Fragmenting the knowledge base only increases confusion, it doesn't make things better. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/