[Sorry Howard for sending it to you personally. It was meant for the list. I sent a copy to the list as well. I hope you don't mind if I send this reply to the list. I've included every word, so not to take something out of context.]
On Jan 30, 2014, at 6:17 PM, Howard Chu wrote:
Personally, I think it's spot on. It IS hard to configure an LDAP server, and even harder to understand how it works (the object based part). Took me three months first time, and I'm not an idiot.
The object based part is *LDAP*, so that complaint is not specific to OpenLDAP.
Indeed.
But setting up something like Active Directory is something my aunt can/could do. It probably won't scale to thousands (or maybe not even hundreds :) of users, but it can be done with reasonable ease.
The part about RedHat seems fairly accurate to me, it *is* true that they have their own commercial LDAP server to sell, and they have no great interest in OpenLDAP working well on their platforms.
Even today, I need to consult either my own book or the howto (or seriously skim through the man pages) to setup a new server.
And I still need to read the docs when configuring an Apache HTTP server. That's why we have manpages, there's nothing wrong about that.
Same here. Not my point (see the part at the bottom)...
And even worse if when you want to optimize the backend... There's a lot of magic there....
The LMDB backend has no tuning/optimization. That's one of the reasons it exists today.
Yeah, but isn't it quite slow with lmdb? I haven't tested that in years, so I don't know. One wouldn't run it in production though?
And with the new config backend!? I haven't even had the time or energy to go that far yet!
I think you (and everyone else) are blowing this way out of proportion. Compare the example from here
I know how it works and I don't really have that much problem with it, it's just so much more difficult to setup (initially) and then maintain than a simple text file.
It's way better, but it IS also more complicated (than just fire up an editor, modify the part you want and then issue a service restart - can't be much simpler than that)...
http://www.openldap.org/doc/admin24/slapdconf2.html#Configuration%20Example
to the slapd.conf example
http://www.openldap.org/doc/admin24/slapdconfig.html#Configuration%20File%20...
They aren't that different, and anyone familiar with slapd.conf and LDIF files should have no trouble mapping concepts from one to the other.
And if you aren't familiar with slapd.conf *and* LDIF then you don't know enough to be an LDAP administrator in the first place, you need to do more homework. That's just life.
I couldn't agree more! I've taken over more than my fair share of badly setup and maintained OpenLDAP servers to get really pissed at all the ones not having a clue what they're doing.
It's not just making a config file/backend to allow the server to start, it's more planning on how the database should look like (where to put what and what object classes to use and allow), setting up access control etc, etc. The actually planing of the database (the content) is the most important part, and it require quite a lot of reading and testing before it's understood properly to be able to be used to any extent.
But then there's the integration to the rest of the system (pam login and what not), Kerberos, SASL, etc, etc...
My point wasn't to argue about the validity of how the OpenLDAP server and it's config file/backend work etc. I fully agree and have no problems with it.
My point was that the website isn't WRONG - it IS hard! Maybe it SHOULD be hard? The whole concept of an LDAP server is a difficult subject, and shouldn't be taken lightly.
Unfortunately, it seems that way to many beginners that have been installing a distribution at home is starting to work as a Linux tech/admin thinking that just because the've run it at their workstation at home for a couple of months makes them good enough to work in a professional environment.
I see that in a lot of OpenSource project I'm part of. Complete noobs want to use something complicated that require quite a lot of homework. And then comes complaining when things go south! Or even worse, they bad mouth the project or the technology!
(Open)LDAP is one of those many things that require a lot more from the admin than say ... installing a mail server locally...
On Debian GNU/Linux that's practically automatic. Just answer a couple of questions, and it works...
It's sad that the website in question (and from what one could take from this - that people 'out there') actually thinks that this should be easy. But it's not (technically) wrong... -- There are no dumb questions, unless a customer is asking them. - Unknown
Turbo Fredriksson wrote:
[Sorry Howard for sending it to you personally. It was meant for the list. I sent a copy to the list as well. I hope you don't mind if I send this reply to the list. I've included every word, so not to take something out of context.]
No problem, after I saw your reply on the list I figured out that was your original intent.
And even worse if when you want to optimize the backend... There's a lot of magic there....
The LMDB backend has no tuning/optimization. That's one of the reasons it exists today.
Yeah, but isn't it quite slow with lmdb? I haven't tested that in years, so I don't know. One wouldn't run it in production though?
You are (unfortunately) confusing the very new back-mdb with the very old, long obsolete, years-ago-deleted, back-ldbm. OpenLDAP back-mdb is quite simply the fastest LDAP engine in the world, by a huge margin over all other directory software in existence.
And with the new config backend!? I haven't even had the time or energy to go that far yet!
I think you (and everyone else) are blowing this way out of proportion. Compare the example from here
I know how it works and I don't really have that much problem with it, it's just so much more difficult to setup (initially) and then maintain than a simple text file.
It's way better, but it IS also more complicated (than just fire up an editor, modify the part you want and then issue a service restart - can't be much simpler than that)...
I don't even fire up an editor, I just issue an ldapmodify - no service restart needed either, no interruption of service to clients. There's nothing smoother and more transparent than that.
And if you aren't familiar with slapd.conf *and* LDIF then you don't know enough to be an LDAP administrator in the first place, you need to do more homework. That's just life.
I couldn't agree more! I've taken over more than my fair share of badly setup and maintained OpenLDAP servers to get really pissed at all the ones not having a clue what they're doing.
It's not just making a config file/backend to allow the server to start, it's more planning on how the database should look like (where to put what and what object classes to use and allow), setting up access control etc, etc. The actually planing of the database (the content) is the most important part, and it require quite a lot of reading and testing before it's understood properly to be able to be used to any extent.
But then there's the integration to the rest of the system (pam login and what not), Kerberos, SASL, etc, etc...
My point wasn't to argue about the validity of how the OpenLDAP server and it's config file/backend work etc. I fully agree and have no problems with it.
My point was that the website isn't WRONG - it IS hard! Maybe it SHOULD be hard? The whole concept of an LDAP server is a difficult subject, and shouldn't be taken lightly.
Perhaps. Vendors like RedHat make it worse than necessary though, forcing the use of Mozilla NSS which is still not ready for primetime, despite having existed for 20+ years. People made enough mistakes configuring TLS support when all you needed was to drop a few PEM files into place. With RedHat requiring the use of MozNSS they make the setup even more opaque and crash-prone. That's not OpenLDAP's fault, that's all RedHat.
Unfortunately, it seems that way to many beginners that have been installing a distribution at home is starting to work as a Linux tech/admin thinking that just because the've run it at their workstation at home for a couple of months makes them good enough to work in a professional environment.
I see that in a lot of OpenSource project I'm part of. Complete noobs want to use something complicated that require quite a lot of homework. And then comes complaining when things go south! Or even worse, they bad mouth the project or the technology!
(Open)LDAP is one of those many things that require a lot more from the admin than say ... installing a mail server locally...
On Debian GNU/Linux that's practically automatic. Just answer a couple of questions, and it works...
It's sad that the website in question (and from what one could take from this - that people 'out there') actually thinks that this should be easy. But it's not (technically) wrong...
On Jan 30, 2014, at 7:35 PM, Howard Chu wrote:
You are (unfortunately) confusing the very new back-mdb with the very old
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).
I don't even fire up an editor, I just issue an ldapmodify - no service restart needed either, no interruption of service to clients. There's nothing smoother and more transparent than that.
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...
That's not OpenLDAP's fault, that's all RedHat.
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
--On Thursday, January 30, 2014 8:02 PM +0100 Turbo Fredriksson turbo@bayour.com wrote:
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...
Having used both methods for years, I disagree. It is a learning curve to understand the cn=config backend, but once you do, it is far superior to the old flat file, and to me, much easier to use. The main thing at this point that is lacking is getting the admin and quick start guides updated to reference cn=config instead of slapd.conf. I've gotten some progress on that going in the OpenLDAP 2.5 code branch. It is my goal to have both pieces fully "cn=config"'d for 2.5. Also being able to make modifications on the fly to my configuration is a major plus. It has allowed me to script pretty much everything our clients need to do on the ldap side of things.
You may want to read over the various bits I've written for Zimbra.
Our cn=config defaults: https://github.com/Zimbra-Community/zimbra-sources/tree/master/main/ZimbraServer/conf/ldap/config
Script to configure MMR: https://github.com/Zimbra-Community/zimbra-sources/blob/master/main/ZimbraServer/src/libexec/zmldapenable-mmr
Script to initialize our ldap server: https://github.com/Zimbra-Community/zimbra-sources/blob/master/main/ZimbraServer/src/libexec/zmldapinit
MDB monitoring script: https://github.com/Zimbra-Community/zimbra-sources/blob/master/main/ZimbraServer/src/libexec/zmldapmonitordb
Script to promote a replica to a MMR member: https://github.com/Zimbra-Community/zimbra-sources/blob/master/main/ZimbraServer/src/libexec/zmldappromote-replica-mmr
etc
--Quanah
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
From: Quanah Gibson-Mount Sent: Thursday, January 30, 2014 1:09 PM
Having used both methods for years, I disagree. It is a learning curve to understand the cn=config backend, but once you do, it is far superior to the old flat file, and to me, much easier to use.
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?
--On Friday, January 31, 2014 5:20 PM -0800 "Paul B. Henson" henson@acm.org wrote:
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?
Our servers do a nightly backup of cn=config via slapcat -n 0, and those are kept for a month. Since this is for clients, there's no revision control involved, but it would be trivial for someone to check in the resulting LDIF file into their favorite RCS system.
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
From: Quanah Gibson-Mount Sent: Friday, January 31, 2014 6:03 PM
Our servers do a nightly backup of cn=config via slapcat -n 0, and those are kept for a month. Since this is for clients, there's no revision control involved, but it would be trivial for someone to check in the resulting LDIF file into their favorite RCS system.
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?
On Thu, 6 Feb 2014, Paul B. Henson wrote:
Our servers do a nightly backup of cn=config via slapcat -n 0, and those are kept for a month. Since this is for clients, there's no revision control involved, but it would be trivial for someone to check in the resulting LDIF file into their favorite RCS system.
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?
Off the top of my head, I'm not really seeing this. With slapd.conf:
(human on workstation) $RCS checkout repo/production.slapd.conf $EDITOR !$ $RCS checkin repo/production.slapd.conf
(magical config overlord/human on server) $RCS checkout repo/production.slapd.conf cp repo/production.slapd.conf /server/production.slapd.conf pkill slapd slapd
or slapd.d:
(human on workstation) $RCS checkout repo/production.slapd.ldif $EDITOR !$ $RCS checkin repo/production.slapd.ldif
(magical config overlord/human on server) $RCS checkout repo/production.slapd.ldif ldifdiff /server/production.slapd.ldif repo/production.slapd.ldif > /tmp/diff.ldif ldapmodify [...] -f /tmp/diff.ldif slapcat -n0 -l /server/production.slapd.ldif
These both end up with the same state, and it's the same number of commands! You can checkout and revert to the latest head/trunk/etc. or any arbitrary rev with either config format. Monitoring in-core vs. on-disk vs. expected-in-production committed config is possible in both cases and actually easier/more comprehensive with cn=config. If "magical config overlord" is a cron job then "automatically be corrected" happens with both of these workflows. How are your hands tied in this case?
Aaron Richton richton@nbcs.rutgers.edu wrote
On Thu, 6 Feb 2014, Paul B. Henson wrote:
Our servers do a nightly backup of cn=config via slapcat -n 0, and those are kept for a month. Since this is for clients, there's no revision control involved, but it would be trivial for someone to check in the resulting LDIF file into their favorite RCS system.
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?
Off the top of my head, I'm not really seeing this. With slapd.conf:
(human on workstation) $RCS checkout repo/production.slapd.conf $EDITOR !$ $RCS checkin repo/production.slapd.conf
(magical config overlord/human on server) $RCS checkout repo/production.slapd.conf cp repo/production.slapd.conf /server/production.slapd.conf pkill slapd slapd
or slapd.d:
(human on workstation) $RCS checkout repo/production.slapd.ldif $EDITOR !$ $RCS checkin repo/production.slapd.ldif
(magical config overlord/human on server) $RCS checkout repo/production.slapd.ldif ldifdiff /server/production.slapd.ldif repo/production.slapd.ldif > /tmp/diff.ldif ldapmodify [...] -f /tmp/diff.ldif slapcat -n0 -l /server/production.slapd.ldif
These both end up with the same state, and it's the same number of commands! You can checkout and revert to the latest head/trunk/etc. or any arbitrary rev with either config format. Monitoring in-core vs. on-disk vs. expected-in-production committed config is possible in both cases and actually easier/more comprehensive with cn=config. If "magical config overlord" is a cron job then "automatically be corrected" happens with both of these workflows. How are your hands tied in this case?
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 02/07/2014 01:00 PM, Aaron Richton wrote:
(human on workstation) $RCS checkout repo/production.slapd.conf $EDITOR !$ $RCS checkin repo/production.slapd.conf
(magical config overlord/human on server) $RCS checkout repo/production.slapd.conf cp repo/production.slapd.conf /server/production.slapd.conf pkill slapd slapd
these last two are far usually done with a service restart, or, when the service support the online changes, with a service reload or a kill -HUP.
or slapd.d:
(human on workstation) $RCS checkout repo/production.slapd.ldif $EDITOR !$ $RCS checkin repo/production.slapd.ldif
(magical config overlord/human on server) $RCS checkout repo/production.slapd.ldif ldifdiff /server/production.slapd.ldif repo/production.slapd.ldif > /tmp/diff.ldif ldapmodify [...] -f /tmp/diff.ldif slapcat -n0 -l /server/production.slapd.ldif
These both end up with the same state, and it's the same number of commands!
As noted before is usually shorter, I can put comment in the file about the change I done, and reverting it is done by using the previous file, and having coherent data and doing modification does not depends in using specialized software over different files.
Not to mention that slapd.conf is still far more readable that any slapd.d ldif...
Regards Simone
On Fri, Feb 07, 2014 at 02:25:45PM +0100, Simone Piccardi wrote:
(SNIP)
these last two are far usually done with a service restart, or, when the service support the online changes, with a service reload or a kill -HUP.
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)
Christopher Wood wrote:
On Fri, Feb 07, 2014 at 02:25:45PM +0100, Simone Piccardi wrote:
these last two are far usually done with a service restart, or, when the service support the online changes, with a service reload or a kill -HUP.
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.
If you have strong HA requirements you have to run with decent load-balancers in front of your LDAP servers anyway. So restarting replicas one after another is not really a big deal.
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.
Well, it seems there's a choice of whether to use back-config or config file.
Ciao, Michael.
--On Friday, February 07, 2014 2:25 PM +0100 Simone Piccardi piccardi@truelite.it wrote:
Not to mention that slapd.conf is still far more readable that any slapd.d ldif...
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
On 07/02/2014 18:36, Quanah Gibson-Mount wrote:
--On Friday, February 07, 2014 2:25 PM +0100 Simone Piccardi piccardi@truelite.it wrote:
Not to mention that slapd.conf is still far more readable that any slapd.d ldif...
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.
I never got any problem with it having always used a it in a correct order with well commented directives. But if ordering is needed not having it enforced in the file configuration syntax is a design defect of slapd, not a shortcoming of using a text file for configuration.
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.
Using apache, postfix, bind, and so on I usually know quite well what is happening, just having a text configuration file. And I can use a generic text editor to modify it, and I don't need to feed the configuration to the program using some dedicated tool or talking the specific protocol they are serving.
I agree that the current slapd.conf has lot problems and is prone to abuse, and if you tell me that rewriting it in a saner way or simply mantaining it is too much a burden for developers, I will not raise any further objection.
But this does not change the fact that slapd.conf is far more readable than a cn=config ldif file, were the use of LDIF syntax force the use of that ugly curly brace index prefix to order things, and make visible irrelevant (for the sake of configuration) informations like entryCSN, createTimestamp, and the like.
Perhaps I'm just getting old, but I still prefer the traditional Unix way to configure services, by the simple use of human (almost) readable text configuration files.
Regards Simone
Simone Piccardi wrote:
On 07/02/2014 18:36, Quanah Gibson-Mount wrote:
--On Friday, February 07, 2014 2:25 PM +0100 Simone Piccardi
piccardi@truelite.it wrote:
Not to mention that slapd.conf is still far more readable that any slapd.d ldif...
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.
I never got any problem with it having always used a it in a correct order with well commented directives. But if ordering is needed not having it enforced in the file configuration syntax is a design defect of slapd, not a shortcoming of using a text file for configuration.
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.
Using apache, postfix, bind, and so on I usually know quite well what is happening, just having a text configuration file. And I can use a generic text editor to modify it, and I don't need to feed the configuration to the program using some dedicated tool or talking the specific protocol they are serving.
I agree that the current slapd.conf has lot problems and is prone to abuse, and if you tell me that rewriting it in a saner way or simply mantaining it is too much a burden for developers, I will not raise any further objection.
But this does not change the fact that slapd.conf is far more readable than a cn=config ldif file, were the use of LDIF syntax force the use of that ugly curly brace index prefix to order things,
you are right, but is is easy to reformat things
and make visible irrelevant (for the sake of configuration) informations like entryCSN, createTimestamp, and the like.
Perhaps I'm just getting old, but I still prefer the traditional Unix way to configure services, by the simple use of human (almost) readable text configuration files.
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}
Regards Simone
harry.jede@arcor.de wrote:
#!/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.
Nice formatting, but just a note - the ordering prefixes are there to allow you to insert new ACLs in the precise spot where they belong. So in fact, human or machine, they are necessary. We wouldn't throw things in there for no reason.
Otherwise, to insert one rule in front of existing rules, you would need to delete and reinsert all of the rules.
Howard Chu wrote:
harry.jede@arcor.de wrote:
#!/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.
Nice formatting, but just a note - the ordering prefixes are there to allow you to insert new ACLs in the precise spot where they belong. So in fact, human or machine, they are necessary. We wouldn't throw things in there for no reason.
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.
Otherwise, to insert one rule in front of existing rules, you would need to delete and reinsert all of the rules.
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.
Quanah Gibson-Mount wrote:
--On Friday, February 07, 2014 2:25 PM +0100 Simone Piccardi piccardi@truelite.it wrote:
Not to mention that slapd.conf is still far more readable that any slapd.d ldif...
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.
It's not fair to argue with idiots messing up their slapd.conf file.
My slapd.conf files are readable, in correct order and with lots of comments and this is indeed much more readable than back-config LDIF files.
Ciao, Michael.
Paul B. Henson wrote:
From: Quanah Gibson-Mount Sent: Friday, January 31, 2014 6:03 PM
Our servers do a nightly backup of cn=config via slapcat -n 0, and those are kept for a month. Since this is for clients, there's no revision control involved, but it would be trivial for someone to check in the resulting LDIF file into their favorite RCS system.
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?
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.
Hi,
On Fri, 31 Jan 2014, Paul B. Henson wrote:
From: Quanah Gibson-Mount Sent: Thursday, January 30, 2014 1:09 PM
Having used both methods for years, I disagree. It is a learning curve to understand the cn=config backend, but once you do, it is far superior to the old flat file, and to me, much easier to use.
My main issue with the cn=config method is how to integrate it into our revision control and approval system.
all of the below:
- apply the changes using ldif files and put those changes into your approval system
- run nightly slapcat of cn=config an archive those
- put an ldif auditlog on cn=config and user personal users only to modify cn=config so you have a clean audit trail.
- ...
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?
I fail to see any issues in the above ...
Greetings Christian
Paul B. Henson wrote:
From: Quanah Gibson-Mount Sent: Thursday, January 30, 2014 1:09 PM
Having used both methods for years, I disagree. It is a learning curve to understand the cn=config backend, but once you do, it is far superior to the old flat file, and to me, much easier to use.
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?
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.
From: Michael Ströder Sent: Saturday, February 01, 2014 2:45 AM
As Howard confirmed on this mailing list static configuration will still
be
available in OpenLDAP 2.5.x.
Really? I didn't see that; my last understanding was that it was deprecated in 2.4 and was going to be removed in 2.5. Sweet, that means I can push off dealing with the conversion for much longer :).
On 02/06/2014 03:28 PM, Paul B. Henson wrote:
From: Michael Ströder Sent: Saturday, February 01, 2014 2:45 AM
As Howard confirmed on this mailing list static configuration will still
be
available in OpenLDAP 2.5.x.
Really? I didn't see that; my last understanding was that it was deprecated in 2.4 and was going to be removed in 2.5. Sweet, that means I can push off dealing with the conversion for much longer :).
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. ;-)
Hi,
On Thu, 6 Feb 2014, Andy Dorman wrote:
On 02/06/2014 03:28 PM, Paul B. Henson wrote:
From: Michael Ströder Sent: Saturday, February 01, 2014 2:45 AM
As Howard confirmed on this mailing list static configuration will still
be
available in OpenLDAP 2.5.x.
Really? I didn't see that; my last understanding was that it was deprecated in 2.4 and was going to be removed in 2.5. Sweet, that means I can push off dealing with the conversion for much longer :).
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. ;-)
as has been said before several times. There is no reason to lose your ability to put your configs into version control when you move to cn=config.
- You can check the output from slapcat -n0 into your vcs.
- You can revert to an older configuration from your version control by using slapadd -n0.
- You can use ldapdiff between old and new versions and generate deltas that you could apply with ldapmodify.
- etc ...
Greetings Christian
Quoting Christian Kratzer ck-lists@cksoft.de:
as has been said before several times. There is no reason to lose your ability to put your configs into version control when you move to cn=config.
- You can check the output from slapcat -n0 into your vcs.
"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
Mike Jackson wrote:
Quoting Christian Kratzer ck-lists@cksoft.de:
as has been said before several times. There is no reason to lose your ability to put your configs into version control when you move to cn=config.
- You can check the output from slapcat -n0 into your vcs.
"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.
We've discussed that here many times: IMO it's a big difference to export a running configuration in your VCS just for the records or to control the configuration in VCS before rollout.
For me doing the VCS actions *before* rolling out the configuration to all the slapd instances gives much more control especially if you have to roll *back* something. And think of staging. And slapd-config does not handle deletion => rollback can be very hard.
Also orchestrated rollout of changes might spread across other systems as well. E.g. when I'm deploying schema changes in slapd I have to change the web-based admin UI as well etc.
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).
Nonsense. If HA is important you must have decent load-balancers in front of your servers and know how to operate them.
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.
Ah, and you are the one and only *real* expert.
Strange enough my customers are running mission-critical OpenLDAP deployments with static configuration - since years.
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.
Complete nonsense.
Ciao, Michael.
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.
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…
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.
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 opposing point of view…
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.
From: Howard Chu Sent: Tuesday, May 13, 2014 6:35 PM
You're not a developer and clearly unable to write code that behaves as you suggest.
[...]
Your opinion is worthless noise.
[...]
Your examples are irrelevant and not applicable.
[...]
But hey moron, that didn't work with threaded programs.
[...]
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
[...]
You're clearly not qualified to do the work yourself.
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...
Paul B. Henson wrote:
From: Howard Chu Sent: Tuesday, May 13, 2014 6:35 PM
You're not a developer and clearly unable to write code that behaves as you suggest.
[...]
Your opinion is worthless noise.
[...]
Your examples are irrelevant and not applicable.
[...]
But hey moron, that didn't work with threaded programs.
[...]
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
[...]
You're clearly not qualified to do the work yourself.
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.
A technical debate can only productively occur between parties that both understand the issues at hand. You clearly don't, and had no business joining the debate.
If you had done your homework (it's not hard, everything is on www.openldap.org), read up on everything that had been considered and tried before, and understood anything about writing code, you might have had something useful to contribute. The fact (not opinion) is you didn't, and you don't. Irresponsible posts like yours deserve flames, not respect.
From: Howard Chu Sent: Wednesday, May 14, 2014 1:20 PM
A technical debate can only productively occur between parties that both understand the issues at hand. You clearly don't, and had no business joining the debate.
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.
Paul B. Henson wrote:
From: Howard Chu Sent: Wednesday, May 14, 2014 1:20 PM
A technical debate can only productively occur between parties that both understand the issues at hand. You clearly don't, and had no business joining the debate.
Nice way to short-circuit a debate. "You don't understand the issues, you lose."
It would save a lot of time.
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.
If it's not the best design, then it's not worth doing. You're still acting as if nobody ever considered what you're suggesting, which is just plain ignorant. You still have nothing worthwhile to contribute to this topic.
Just for you:
https://www.facebook.com/georgehtakei/photos/a.223098324386295.105971.205344...
You haven't done enough homework to justify having an alternative viewpoint.
From: Howard Chu Sent: Wednesday, May 14, 2014 4:43 PM
If it's not the best design, then it's not worth doing.
So you're changing your position from "it's impossible to do" to "it's not worth doing"?
You're still acting as if nobody ever considered what you're suggesting, which is just plain ignorant.
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.
You still have nothing worthwhile to contribute to this topic.
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…
https://www.facebook.com/georgehtakei/photos/a.223098324386295.105 971.205344452828349/908340742528713/?type=1
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.
You haven't done enough homework to justify having an alternative viewpoint.
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.
Paul B. Henson wrote:
From: Howard Chu Sent: Wednesday, May 14, 2014 4:43 PM
If it's not the best design, then it's not worth doing.
So you're changing your position from "it's impossible to do" to "it's not worth doing"?
Not at all. My position is still that we tried multiple alternatives and ruled them out. That's experience, not opinion. You have no experience.
You're still acting as if nobody ever considered what you're suggesting, which is just plain ignorant.
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.
No. That's experience too.
I apologize, Dr. Chu, could you please repost the syllabus and study guide
There's no excuse for ignorance when the links have already been posted and everything is published on the www.openldap.org website.
From: Howard Chu Sent: Wednesday, May 14, 2014 6:41 PM
Not at all. My position is still that we tried multiple alternatives and
ruled
them out.
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.
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.
No. That's experience too.
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.
There's no excuse for ignorance when the links have already been posted
and
everything is published on the www.openldap.org website.
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...
Paul B. Henson wrote:
There's no excuse for ignorance when the links have already been posted
and
everything is published on the www.openldap.org website.
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.
Standard netiquette is that you search for topics before posting. The standard welcome message for these lists already tell you to search the archives before asking a question that has already been asked and answered.
There's no point in people writing email replies to you if you're incapable of reading. If you're unwilling to read information that people provide you in links, you're just wasting everyone's time.
Howard Chu hyc@symas.com schrieb am 15.05.2014 um 05:14 in Nachricht
Paul B. Henson wrote:
There's no excuse for ignorance when the links have already been posted
and
everything is published on the www.openldap.org website.
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.
Standard netiquette is that you search for topics before posting. The standard welcome message for these lists already tell you to search the archives before asking a question that has already been asked and answered.
There's no point in people writing email replies to you if you're incapable of reading. If you're unwilling to read information that people provide you in links, you're just wasting everyone's time.
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).
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Ulrich Windl wrote:
Howard Chu hyc@symas.com schrieb am 15.05.2014 um 05:14 in Nachricht
There's no point in people writing email replies to you if you're incapable of reading. If you're unwilling to read information that people provide you in links, you're just wasting everyone's time.
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).
You will note that I always specify where something is documented. In this case:
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.
Which you can plainly see in the archive http://www.openldap.org/lists/openldap-technical/201405/msg00105.html
From: Howard Chu Sent: Wednesday, May 14, 2014 8:15 PM
There's no point in people writing email replies to you if you're
incapable of
reading. If you're unwilling to read information that people provide you
in
links, you're just wasting everyone's time.
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.
Paul B. Henson wrote:
From: Howard Chu
No. That's experience too.
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.
There's a difference between expressing a desire, and insisting upon it. The desire has been expressed, hooray, move on now.
In an open source project, the only people with the right to insist on how code should work are the people who are willing and able to make it so. You continue to insist, but you don't have the capability to implement.
From: Howard Chu Sent: Wednesday, May 14, 2014 10:25 PM
There's a difference between expressing a desire, and insisting upon it.
Yup. Can't speak for anybody else, but I'm pretty sure I've never insisted on or demanded anything from you.
The desire has been expressed, hooray, move on now.
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.
In an open source project, the only people with the right to insist on how code should work are the people who are willing and able to make it so.
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?
You continue to insist, but you don't have the capability to implement.
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.
Quoting "Paul B. Henson" henson@acm.org:
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.
Herein lies the problem: your sense of entitlement - your sense of entitlement to receive an answer simply because you asked someone a question. And the reason that you want that answer is so you can use it for the next step in whatever scheme your small little mind is trying to concoct.
I've been going the rounds with my youngest daughter to ensure that she actually gets past this same thing as just one of the things she needs to do in order to leave her childhood selfishness behind, reach emotional maturity and become an adult.
You, personally, can not win an argument with Howard. He's far more intelligent than you, his grasp on technology light years ahead of your own and his ability to funnel an argument down to a conclusion puts yours to shame. Still, you continue to walk around the orchard where there is clearly no fruit available - wandering around looking for fruit to appear just because you want some.
Additionally, there's a matter at hand called evolution. One either adapts to a changing environment or one becomes extinct. That the Netscape code already had dynamic configuration more than 15 years ago as a result of having DISA as one of their main customers should demonstrate to you that it's actually a feature that was needed by organizations with a very large userbase. Those requirements are even moreso valid today than they were back in 1996 when the world was hoping to escape from the grasp of Nexor and the like - that monstrosity we, we who knew and operated things, knew as X.500.
Finally, if you don't like the way the project is going then do a git clone and stab yourself repeatedly in the eye with your own fork. Darwinism in action, and all that.
The summary here is that far greater minds than yours have already considered the problems at hand and taken appropriate action to solve them. A long time ago. And the fact that you mistake ruthless pragmatism for simple arrogance leaves you out of that club. Sorry. Case dismissed.
-mike
From: Mike Jackson Sent: Thursday, May 15, 2014 10:44 PM
Herein lies the problem: your sense of entitlement - your sense of entitlement to receive an answer simply because you asked someone a question.
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?
And the reason that you want that answer is so you can use it for the next step in whatever scheme your small little mind is trying to concoct.
I believe you overestimate the deviousness of my "small little" mind.
You, personally, can not win an argument with Howard. He's far more intelligent than you, his grasp on technology light years ahead of your own and his ability to funnel an argument down to a conclusion puts yours to shame.
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?
Still, you continue to walk around the orchard where there is clearly no fruit available - wandering around looking for fruit to appear just because you want some.
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?
I've been going the rounds with my youngest daughter to ensure that she actually gets past this same thing as just one of the things she needs to do in order to leave her childhood selfishness behind, reach emotional maturity and become an adult.
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.
Netscape code already had dynamic configuration more than 15 years ago as a result of having DISA as one of their main customers should demonstrate to you that it's actually a feature that was needed by organizations with a very large userbase. Those requirements are even
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).
Finally, if you don't like the way the project is going then do a git clone and stab yourself repeatedly in the eye with your own fork. Darwinism in action, and all that.
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!"
The summary here is that far greater minds than yours have already considered the problems at hand and taken appropriate action to solve them.
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.
And the fact that you mistake ruthless pragmatism for simple arrogance leaves you out of that club.
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.
On Thu, May 15, 2014 at 10:48 AM, Paul B. Henson henson@acm.org wrote:
https://www.facebook.com/georgehtakei/photos/a.223098324386295.105 971.205344452828349/908340742528713/?type=1
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
I raise your happy cat, to 10 interesting facts about bunnies :)
http://www.clickreadshare.com/10-facts-never-knew-bunny-rabbits/
Quoting "Paul B. Henson" henson@acm.org:
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.
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
From: Mike Jackson Sent: Tuesday, May 13, 2014 10:59 PM
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.
The ego is strong with this one.
On 15 May 2014, at 6:21 am, "Paul B. Henson" henson@acm.org wrote:
From: Mike Jackson Sent: Tuesday, May 13, 2014 10:59 PM
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.
The ego is strong with this one.
Lol. And the award goes to??
I think it would be impossible to decide..
Mike Jackson wrote:
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.
Well, judging from your postings my impression of your analytical skills are pretty precise.
Ciao, Michael.
On Wed, May 14, 2014 at 11:57:22PM +0200, Michael Ströder wrote:
Well, judging from your postings my impression of your analytical skills are pretty precise.
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@stroeder.com | wc -l 2
$ git log | grep mj@netauth.com | wc -l 0 $ git log | grep Jackson | wc -l 0
Be sure not to underestimate with whom you are speaking 8-/.
On 05/13/2014 12:55 PM, Howard Chu wrote:
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.
Having been exposed to OpenLDAP for the first time two and a half years ago, I can attest that this was true, at least for me. Not that it wasn't a frustrating journey.
For me, lack of _context_ surrounding for example, configuration options, was more difficult than learning LDIF, client tools or server configuration, though.
Hugs & Kisses,
Stephan
On 13/05/2014 11:01, Mike Jackson wrote:
In any case, dynamic configuration IS an enterprise-grade/carrier-grade feature as opposed to static configuration.
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
Well, I can say that I operate OpenLDAP at an "enterprise" level and the configuration do not change very often here. The dynamic configuration is something that could be useful but definetly is not required for me.
I also think the term "enterprise-grade" is misleading. There is a lot of junk software out there which call themselves "enterprise solution" but in fact are just garbage. I can give a list of LDAP servers which have dynamic configuration but can't scale, can't keep data sync between the servers, fail frequently and etc.
At the end of the day the most important thing for me and business people is stability/performance and if one can't configure OpenLDAP with all man pages and documentation that it have, maybe it's in the wrong role.
Em 13-05-2014 16:47, Simone Piccardi escreveu:
On 13/05/2014 11:01, Mike Jackson wrote:
In any case, dynamic configuration IS an enterprise-grade/carrier-grade feature as opposed to static configuration.
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
Esta mensagem é somente para uso do destinatário informado e pode conter informações privilegiadas, proprietárias, ou privadas. Se você recebeu esta mensagem por engano, por favor notifique o remetente imediatamente e apague a original. Qualquer uso deste email é proibido. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
Simone Piccardi wrote:
On 13/05/2014 11:01, Mike Jackson wrote:
In any case, dynamic configuration IS an enterprise-grade/carrier-grade feature as opposed to static configuration.
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.
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...
On 14/05/2014 00:58, Howard Chu wrote:
Most people didn't "need" electricity when they still had oil lamps...
If I'm going in a cave almost everytime I still need an oil lamp. Bringing there electricity can be far more costly.
Yes for a solution for arbitrarily large networks cn=config could be more scalable and cheaper. But that's not true for a small server for a small organization that doesn't need the extra complexity.
I don't want to understate the pros of cn=config, I just state my opinion about the cons. If you tell me the maintaining slapd.conf is too costly in terms of developers energies I've nothing to say. But I don't agree that cn=config is always better.
Simone
Yes for a solution for arbitrarily large networks cn=config could be more scalable and cheaper. But that's not true for a small server for a small organization that doesn't need the extra complexity.
I don't want to understate the pros of cn=config, I just state my opinion about the cons. If you tell me the maintaining slapd.conf is too costly in terms of developers energies I've nothing to say. But I don't agree that cn=config is always better.
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.,
Quoting "Brett @Google" brett.maxfield@gmail.com:
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?
Since the cn=config is simply the conversion of one LDIF file into a hierarchical directory structure of LDIF files, there isn't any conversion needed for slapd to be able to use it or write to it for that matter - slapadd already exists. Only thing that is needed is some filesystem directory traversal logic in order to write out the LDIF hierarchy.
But can we reliably create the slap.d config file with deployment scripts directly, as it also seems to just be text.
I have built a fully automated installation system directly using cn=config. I have a file called config.ldif which contains a lot of %%MACROS%% and a tiny perl script that replaces those macros with actual values depending on the details of the particular installation. So, there isn't any of this silliness of creating slapd.conf, converting it into cn=config, and then continuing - that's an unnecessary step.
After I generate the real config.ldif from the template config.ldif, I simply load it with slapadd to build my cn=config hierarchy.
slapadd \ -n0 \ -v \ -F ${CONF_DIR} \ -l ldifs/config.ldif
Repeat the process to load the DIT skeleton into n2 with slapadd, slapindex n2 (needed if the DIT skeleton is huge like mine), fire up the server and do the rest of the work.
My cn=config is replicated across servers so that access control, tuning, and indices, for example, only need to be added to one server over the wire. And they only need to be dumped from one server, over the wire. That is a workable management interface.
My entire installation system: TLS certs, replication, DIT skeleton, service admin users, access control, tuning, indexing, everything - it takes less than 2 minutes and is 100% hands free.
-mike
Mike Jackson wrote:
I have built a fully automated installation system directly using cn=config. I have a file called config.ldif which contains a lot of %%MACROS%% and a tiny perl script that replaces those macros with actual values depending on the details of the particular installation. So, there isn't any of this silliness of creating slapd.conf, converting it into cn=config, and then continuing - that's an unnecessary step.
After I generate the real config.ldif from the template config.ldif, I simply load it with slapadd to build my cn=config hierarchy.
slapadd \ -n0 \ -v \ -F ${CONF_DIR} \ -l ldifs/config.ldif
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.
Quoting Michael Ströder michael@stroeder.com:
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.
Please read my post more carefully and understand it before commenting.
Slapd has never been started at this point so there's nothing to stop. It doesn't have any configuration at all. I don't muck with the LDIF, I generate it. If you take a little time to study the cn=config entries, you'll see that it's not exactly rocket science to write or generate your own. The only real concern is that the attribute names or something change over time and I have to adapt my template, in other words it's not declared as a public interface but it really should be. You can even keep it in git (my template is certainly in git).
-mike
Mike Jackson wrote:
Quoting Michael Ströder michael@stroeder.com:
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.
Please read my post more carefully and understand it before commenting.
Slapd has never been started at this point so there's nothing to stop. It doesn't have any configuration at all. I don't muck with the LDIF, I generate it. If you take a little time to study the cn=config entries, you'll see that it's not exactly rocket science to write or generate your own.
Be assured that I did study cn=config schema in depth.
The only real concern is that the attribute names or something change over time and I have to adapt my template, in other words it's not declared as a public interface but it really should be. You can even keep it in git (my template is certainly in git).
*You* clearly don't understand what the discussion is all about. And you're arguing with contradictions.
Ciao, Michael.
Quoting Michael Ströder michael@stroeder.com:
*You* clearly don't understand what the discussion is all about. And you're arguing with contradictions.
Either you are wilfully dense, or your grasp of the english language hasn't quite reached full maturity. In any case, I was reverse-engineering the management protocols of commercial LDAP servers with ethereal so I could build automated installations and command-line management tools to said management interfaces already 15 years ago. And you still don't have a grasp of this concept today. What have you been doing with your time if your knowledge still hasn't advanced after 15 years?
-mike
On Thu, May 15, 2014 at 01:28:16AM +0300, Mike Jackson wrote:
I was reverse-engineering the management protocols of commercial LDAP servers with ethereal so I could build automated installations and command-line management tools to said management interfaces already 15 years ago.
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.
Mike Jackson wrote:
Quoting Michael Ströder michael@stroeder.com:
*You* clearly don't understand what the discussion is all about. And you're arguing with contradictions.
Either you are wilfully dense, or your grasp of the english language hasn't quite reached full maturity.
Wir können ja auch auf Deutsch schreiben. Dann habe ich den Vorteil der Muttersprache.
In any case, I was reverse-engineering the management protocols of commercial LDAP servers with ethereal so I could build automated installations and command-line management tools to said management interfaces already 15 years ago.
Do you really think you're the only one? And where's the public proof that you really did all that?
BTW: I think I recall who you were, back then at ODD 2006.
Ciao, Michael.
From: Michael Ströder Sent: Thursday, May 15, 2014 1:02 AM
Wir können ja auch auf Deutsch schreiben. Dann habe ich den Vorteil der Muttersprache.
Was auf der Erde haben die Menschen tun, bevor Google übersetzen?
Ciao, Michael.
So your native language is German, you're posting on a primarily English-based mailing list, and then your signature includes an Italian colloquialism ;)?
Paul B. Henson wrote:
From: Michael Ströder Wir können ja auch auf Deutsch schreiben. Dann habe ich den Vorteil der Muttersprache.
Was auf der Erde haben die Menschen tun, bevor Google übersetzen?
They hired better translators. ;-)
So your native language is German, you're posting on a primarily English-based mailing list, and then your signature includes an Italian colloquialism ;)?
That's globalization - I guess. ;-)
Ciao, Michael.
--On May 15, 2014 at 12:58:30 AM +0300 Mike Jackson mj@netauth.com wrote:
Please read my post more carefully and understand it before commenting.
Slapd has never been started at this point so there's nothing to stop. It doesn't have any configuration at all. I don't muck with the LDIF, I generate it. If you take a little time to study the cn=config entries, you'll see that it's not exactly rocket science to write or generate your own. The only real concern is that the attribute names or something change over time and I have to adapt my template, in other words it's not declared as a public interface but it really should be. You can even keep it in git (my template is certainly in git).
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
Quoting Quanah Gibson-Mount quanah@zimbra.com:
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.
It'll work after that as well: you'll still be able to create n0 from zero with slapadd in the same way that you can already create n2 from zero with slapadd.
--On May 15, 2014 at 8:32:07 AM +0300 Mike Jackson mj@netauth.com wrote:
Quoting Quanah Gibson-Mount quanah@zimbra.com:
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.
It'll work after that as well: you'll still be able to create n0 from zero with slapadd in the same way that you can already create n2 from zero with slapadd.
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
Mike Jackson wrote:
Quoting Michael Ströder michael@stroeder.com:
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.
Please read my post more carefully and understand it before commenting.
Slapd has never been started at this point so there's nothing to stop. It doesn't have any configuration at all. I don't muck with the LDIF, I generate it. If you take a little time to study the cn=config entries, you'll see that it's not exactly rocket science to write or generate your own. The only real concern is that the attribute names or something change over time and I have to adapt my template, in
We've never changed the names of any config attributes. The only thing that has changed over time is adding new definitions.
other words it's not declared as a public interface but it really should be. You can even keep it in git (my template is certainly in git).
The schema is published in the cn=schema,cn=config entry. That's as much a public interface as there'll ever be in an LDAP directory.
Quoting Howard Chu hyc@symas.com:
We've never changed the names of any config attributes. The only thing that has changed over time is adding new definitions.
So, it's not even a concern at all.
The schema is published in the cn=schema,cn=config entry. That's as much a public interface as there'll ever be in an LDAP directory.
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
Mike Jackson wrote:
Quoting Howard Chu hyc@symas.com:
We've never changed the names of any config attributes. The only thing that has changed over time is adding new definitions.
So, it's not even a concern at all.
The schema is published in the cn=schema,cn=config entry. That's as much a public interface as there'll ever be in an LDAP directory.
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.
It's not mentioned because it ought to be blindingly obvious. We provide a sample config.ldif in the Admin Guide. Only an idiot would create a format that can never be created directly, and can only be used through conversion of some other format.
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.
Doc patches are always welcome.
--On May 15, 2014 at 7:03:50 AM -0700 Howard Chu hyc@symas.com wrote:
Mike Jackson wrote:
Quoting Howard Chu hyc@symas.com:
We've never changed the names of any config attributes. The only thing that has changed over time is adding new definitions.
So, it's not even a concern at all.
The schema is published in the cn=schema,cn=config entry. That's as much a public interface as there'll ever be in an LDAP directory.
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.
It's not mentioned because it ought to be blindingly obvious. We provide a sample config.ldif in the Admin Guide. Only an idiot would create a format that can never be created directly, and can only be used through conversion of some other format.
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.
Doc patches are always welcome.
Already done a few weeks ago. As is of course, public record.. ;)
- Log ----------------------------------------------------------------- commit f48242de0051380d3ec4d9bb72976f277a9ddeac Author: Quanah Gibson-Mount quanah@openldap.org Date: Fri Apr 25 15:03:50 2014 -0500
Convert quickstart guide to cn=config
--Quanah
Quoting Quanah Gibson-Mount quanah@zimbra.com:
Convert quickstart guide to cn=config
OK, then no need for me to spend time on it.
-mike
Quoting Howard Chu hyc@symas.com:
It's not mentioned because it ought to be blindingly obvious. We provide a sample config.ldif in the Admin Guide. Only an idiot would create a format that can never be created directly, and can only be used through conversion of some other format.
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.
Doc patches are always welcome.
OK, I will prepare one. I already did a git clone.
-mike
Mike Jackson mj@netauth.com schrieb am 15.05.2014 um 18:20 in Nachricht
20140515192013.Horde.4mvYB8UtnuC1xnvdJjmKKA9@mail.netauth.com:
Quoting Howard Chu hyc@symas.com:
It's not mentioned because it ought to be blindingly obvious. We provide a sample config.ldif in the Admin Guide. Only an idiot would create a format that can never be created directly, and can only be used through conversion of some other format.
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.
No, it's just that new people will use the system. See MS-Windows.
Doc patches are always welcome.
OK, I will prepare one. I already did a git clone.
-mike
Michael Ströder wrote:
Mike Jackson wrote:
I have built a fully automated installation system directly using cn=config. I have a file called config.ldif which contains a lot of %%MACROS%% and a tiny perl script that replaces those macros with actual values depending on the details of the particular installation. So, there isn't any of this silliness of creating slapd.conf, converting it into cn=config, and then continuing - that's an unnecessary step.
After I generate the real config.ldif from the template config.ldif, I simply load it with slapadd to build my cn=config hierarchy.
slapadd \ -n0 \ -v \ -F ${CONF_DIR} \ -l ldifs/config.ldif
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.
Perfectly fine for bootstrapping the initial config though.
Also when mucking directly with the LDIF you loose slapd's capability of input validation.
You can muck with input to slapadd all you want. It will still get basic validation.
Howard Chu wrote:
Michael Ströder wrote:
Mike Jackson wrote:
I have built a fully automated installation system directly using cn=config. I have a file called config.ldif which contains a lot of %%MACROS%% and a tiny perl script that replaces those macros with actual values depending on the details of the particular installation. So, there isn't any of this silliness of creating slapd.conf, converting it into cn=config, and then continuing - that's an unnecessary step.
After I generate the real config.ldif from the template config.ldif, I simply load it with slapadd to build my cn=config hierarchy.
slapadd \ -n0 \ -v \ -F ${CONF_DIR} \ -l ldifs/config.ldif
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.
Perfectly fine for bootstrapping the initial config though.
But the main argument for cn=config in this discussion is *modifying* the configuration of a running server without taking it down. So Mike's arguing with boot-strapping with slapadd is clearly a contradiction.
IMO this is one of the main problems of OpenLDAP admins with cn=config, besides lack of comments, missing support for deletion etc.: Many of the instructions on the mailing list how to use back-config are not really consequent. And sorry that I have to repeat my statement, this is a bit consequence of the design. And i might be worth to rethink some aspects of it.
In the past you've argued that one should point out issues more clearly. But people will only put effort into it if there is some willingness shown by you to really consider suggestions.
Also when mucking directly with the LDIF you loose slapd's capability of input validation.
You can muck with input to slapadd all you want. It will still get basic validation.
Regarding validation it's still in some cases a big difference whether an entry is added with slapadd or via LDAP.
Ciao, Michael.
Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
Mike Jackson wrote:
I have built a fully automated installation system directly using cn=config. I have a file called config.ldif which contains a lot of %%MACROS%% and a tiny perl script that replaces those macros with actual values depending on the details of the particular installation. So, there isn't any of this silliness of creating slapd.conf, converting it into cn=config, and then continuing - that's an unnecessary step.
After I generate the real config.ldif from the template config.ldif, I simply load it with slapadd to build my cn=config hierarchy.
slapadd \ -n0 \ -v \ -F ${CONF_DIR} \ -l ldifs/config.ldif
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.
Perfectly fine for bootstrapping the initial config though.
But the main argument for cn=config in this discussion is *modifying* the configuration of a running server without taking it down. So Mike's arguing with boot-strapping with slapadd is clearly a contradiction.
IMO this is one of the main problems of OpenLDAP admins with cn=config, besides lack of comments, missing support for deletion etc.: Many of the instructions on the mailing list how to use back-config are not really consequent. And sorry that I have to repeat my statement, this is a bit consequence of the design. And i might be worth to rethink some aspects of it.
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 wrote:
Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
Mike Jackson wrote:
I have built a fully automated installation system directly using cn=config. I have a file called config.ldif which contains a lot of %%MACROS%% and a tiny perl script that replaces those macros with actual values depending on the details of the particular installation. So, there isn't any of this silliness of creating slapd.conf, converting it into cn=config, and then continuing - that's an unnecessary step.
After I generate the real config.ldif from the template config.ldif, I simply load it with slapadd to build my cn=config hierarchy.
slapadd \ -n0 \ -v \ -F ${CONF_DIR} \ -l ldifs/config.ldif
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.
Perfectly fine for bootstrapping the initial config though.
But the main argument for cn=config in this discussion is *modifying* the configuration of a running server without taking it down. So Mike's arguing with boot-strapping with slapadd is clearly a contradiction.
IMO this is one of the main problems of OpenLDAP admins with cn=config, besides lack of comments, missing support for deletion etc.: Many of the instructions on the mailing list how to use back-config are not really consequent. And sorry that I have to repeat my statement, this is a bit consequence of the design. And i might be worth to rethink some aspects of it.
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.
I understand that pretty well. Really no need to explain that.
You seem to be arguing that cn=config is only useful for dynamic modification,
Nope.
My impression of this thread was that dynamic modification is used as the strongest argument *for* cn=config. And therefore IMO pointing to using slapadd as a configuration tool is a contradiction.
which implies that you use some other format for your seed configs, which is, frankly, stupid.
At LDAPcon we already agreed that we slightly disagree. ;-) But you confirmed that slapd.conf will not be hunked out of 2.5. So I'm perfectly fine with that.
Ciao, Michael.
Brett @Google wrote:
But can we reliably create the slap.d config file with deployment scripts directly, as it also seems to just be text.
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.
From: Howard Chu Sent: Tuesday, May 13, 2014 3:59 PM
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.
Ah, yes, the "I'm going to redefine terminology so your argument is no longer valid" approach.
I never said I had to or planned to physically login to a server to make a change. I simply said that reloading a flat text configuration file and applying any configuration changes in it is a valid and reasonable approach. Perhaps in a scenario where the person managing the LDAP server configuration does not have any operating system privileges, your feature would be invaluable. But in an environment where the person managing the operating system configuration itself is also managing the LDAP server configuration, it is meaningless. What next, you're going to offer the feature for slapd to proxy changes to the operating system configuration files via the LDAP interface? You just don't seem to understand or accept that deployment scenarios other than the one you envision exist, are useful, or should be supported, and that the ability to manage openldap via existing infrastructure that is already managing other systems and applications is a valuable feature.
Most people didn't "need" electricity when they still had oil lamps...
Many people still drive a manual transmission vehicle even after the widespread availability of the automatic transmission. See, I can spew irrelevant platitudes too…
You can reply to this if you like, but I'm done with the debate, as clearly 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.
Paul B. Henson wrote:
You can reply to this if you like, but I'm done with the debate, as clearly
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
From: Howard Chu Sent: Tuesday, May 13, 2014 10:41 PM
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.
I'm sorry, I must not be remembering the message in which I demanded you do anything. Could you possibly send a link to the list archives pointing it out?
As I recall, I simply said that dynamic reconfiguration could be done via rereading the flat text configuration file, and that the developers chose not to do so then and choose not to do so now. Both of which are factually true. Perhaps the basis for your venomous and unnecessary personal attacks is what you read into my message that wasn't actually there?
I've been trying to get a message I posted to the developers list regarding a trivial extension of the password policy module to support microsecond granularity for authentication failures approved and delivered for two weeks with no luck. Why on earth would I spend the amount of time and effort it would take to implement flat text config file based dynamic reconfiguration when I can't even get engagement on what will likely be a five line diff? On top of which, you've already made it clear that you would not accept an implementation of dynamic reconfiguration from flat text configuration files even if it existed and functioned perfectly, so it would be an exercise in utter futility, even more so than this discussion.
"Paul B. Henson" henson@acm.org schrieb am 14.05.2014 um 22:18 in Nachricht
0ce601cf6fb1$b6199c60$224cd520$@acm.org:
From: Howard Chu Sent: Tuesday, May 13, 2014 10:41 PM
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.
I'm sorry, I must not be remembering the message in which I demanded you do anything. Could you possibly send a link to the list archives pointing it out?
As I recall, I simply said that dynamic reconfiguration could be done via rereading the flat text configuration file, and that the developers chose not to do so then and choose not to do so now. Both of which are factually true. Perhaps the basis for your venomous and unnecessary personal attacks is what you read into my message that wasn't actually there?
Well if you want to sync your configuration with LDAP means, the LDAP representation (as well as DIT metadata) makes sense.
I've been trying to get a message I posted to the developers list regarding a trivial extension of the password policy module to support microsecond granularity for authentication failures approved and delivered for two weeks with no luck. Why on earth would I spend the amount of time and effort it would take to implement flat text config file based dynamic reconfiguration when I can't even get engagement on what will likely be a five line diff? On
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.
top of which, you've already made it clear that you would not accept an implementation of dynamic reconfiguration from flat text configuration files even if it existed and functioned perfectly, so it would be an exercise in utter futility, even more so than this discussion.
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
From: Ulrich Windl Sent: Wednesday, May 14, 2014 11:13 PM
Well if you want to sync your configuration with LDAP means, the LDAP representation (as well as DIT metadata) makes sense.
Yes, if you eat LDAP for breakfast, lunch, and dinner, dream about LDAP, and don't really work with anything else, then the LDAP-based configuration is probably great for you. If you manage dozens of other services for which you already have a well developed and flexible framework for managing configuration files, perhaps not so much.
with no luck. Why on earth would I spend the amount of time and effort
it
would take to implement flat text config file based dynamic reconfiguration when I can't even get engagement on what will likely be a five line
diff? On
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.
I'm not quite sure what you're addressing with this remark? Implementing flat text config file reconfiguration? The five line diff for increasing the granularity of the authentication failure attribute for the password policy module? Something else?
At that point one might argue that implementinc two mechanisms for the same thing is one too much, maybe.
Possibly. But assuming the "convert slapd.conf into LDIF" functionality isn't going away, then flat text config file reconfiguration would really be only a layer on top of that and the existing LDIF dynamic reconfiguration implementation.
"Paul B. Henson" henson@acm.org schrieb am 01.02.2014 um 02:20 in Nachricht
070e01cf1eeb$ded56ab0$9c804010$@acm.org:
From: Quanah Gibson-Mount Sent: Thursday, January 30, 2014 1:09 PM
Having used both methods for years, I disagree. It is a learning curve to understand the cn=config backend, but once you do, it is far superior to the old flat file, and to me, much easier to use.
My main issue with the cn=config method is how to integrate it into our revision control and approval system.
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)...
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.
Well maybe you'd need another tool, like LDIF-diff-to-ldapmodify ;-)
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?
I'm experimenting with importing LDAP database backups into Git with structured LDIFs as described above. Anybody else?
Regards, Ulrich
--On Thursday, January 30, 2014 10:35 AM -0800 Howard Chu hyc@symas.com wrote:
Yeah, but isn't it quite slow with lmdb? I haven't tested that in years, so I don't know. One wouldn't run it in production though?
You are (unfortunately) confusing the very new back-mdb with the very old, long obsolete, years-ago-deleted, back-ldbm. OpenLDAP back-mdb is quite simply the fastest LDAP engine in the world, by a huge margin over all other directory software in existence.
See also:
http://mishikal.wordpress.com/2013/05/16/openldap-a-comparison-of-back-mdb-and-back-hdb-performance/
http://wiki.zimbra.com/wiki/OpenLDAP_MDB_vs_HDB_performance
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Turbo Fredriksson wrote:
But setting up something like Active Directory is something my aunt can/could do.
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.
On Jan 31, 2014, at 3:06 PM, Michael Ströder wrote:
Yeah, if she manages to setup AD the next thing is to teach her how to fix or work around replication problems.
Not the point. The argument was that OpenLDAP "is difficult to install and setup". NOT administrate!
And my opinion (and many, many others!) have been that it is. And that there's something huge lacking in the OpenLDAP documentation. But every time this is brought up, all the maintainers get very hostile.
I started '99/2k with OpenLDAP, and I had huge problems understanding and reading the documentation at the time. Most regarding the whole concept of LDAP.
Luckily, I've adapted (through years of testing) to this, so now it's reasonably easy. But when installing the new auth VM a few weeks ago, I had forgot that there's a problem with OpenSSL/GnuTLS (the interaction between them) so I couldn't get SSL/TLS work. It took hours of googling the very weird and non-discriptive errors to figure out the problem. And that of course struck a memory cord on how to solve it... -- You know, boys, a nuclear reactor is a lot like a woman. You just have to read the manual and press the right buttons - Homer Simpson
Turbo Fredriksson wrote:
On Jan 31, 2014, at 3:06 PM, Michael Ströder wrote:
Yeah, if she manages to setup AD the next thing is to teach her how to fix or work around replication problems.
Not the point. The argument was that OpenLDAP "is difficult to install and setup". NOT administrate!
Nonsense! There is no difference between installation and administration. It's a major fault to artificially distinguish that!
And my opinion (and many, many others!) have been that it is. And that there's something huge lacking in the OpenLDAP documentation. But every time this is brought up, all the maintainers get very hostile.
I started '99/2k with OpenLDAP, and I had huge problems understanding and reading the documentation at the time. Most regarding the whole concept of LDAP.
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.
Luckily, I've adapted (through years of testing) to this, so now it's reasonably easy. But when installing the new auth VM a few weeks ago, I had forgot that there's a problem with OpenSSL/GnuTLS (the interaction between them) so I couldn't get SSL/TLS work. It took hours of googling the very weird and non-discriptive errors to figure out the problem. And that of course struck a memory cord on how to solve it...
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.
Michael Strödermichael@stroeder.com schrieb am 31.01.2014 um 16:24 in
Nachricht 52EBC029.9000903@stroeder.com:
Turbo Fredriksson wrote:
On Jan 31, 2014, at 3:06 PM, Michael Ströder wrote:
Yeah, if she manages to setup AD the next thing is to teach her how to fix
or
work around replication problems.
Not the point. The argument was that OpenLDAP "is difficult to install and setup". NOT administrate!
Nonsense! There is no difference between installation and administration. It's a major fault to artificially distinguish that!
I disagree: Once the infrastructure is set up, the basic directory structure is set up, and the clients are configured, it's much easier to add/remove/modify entries than to do the initial setup.
And my opinion (and many, many others!) have been that it is. And that
there's
something huge lacking in the OpenLDAP documentation. But every time this
is
brought up, all the maintainers get very hostile.
I started '99/2k with OpenLDAP, and I had huge problems understanding and reading the documentation at the time. Most regarding the whole concept of
LDAP.
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.
Personally I could not decide whether the implementation is ease of use or ease of implementation.
Anyone not able to read man pages and admin guides should not touch server configurations at all.
Just as anyone not able to write man pages should not write software.
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.
Luckily, I've adapted (through years of testing) to this, so now it's
reasonably
easy. But when installing the new auth VM a few weeks ago, I had forgot
that
there's a problem with OpenSSL/GnuTLS (the interaction between them) so I couldn't get SSL/TLS work. It took hours of googling the very weird and non-discriptive errors to figure out the problem. And that of course struck
a
memory cord on how to solve it...
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:
And my opinion (and many, many others!) have been that it is. And that there's something huge lacking in the OpenLDAP documentation. But every time this is brought up, all the maintainers get very hostile.
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.
openldap-technical@openldap.org
-
Aaron Richton -
Andy Dorman -
Brett ＠Google -
Brett Maxfield
-
Christian Kratzer -
Christopher Wood -
harry.jede＠arcor.de -
Howard Chu -
Matheus Eduardo Bonifacio Morais -
Michael Ströder -
Mike Jackson -
Paul B. Henson -
Quanah Gibson-Mount -
Simone Piccardi -
Stephan Fabel -
Turbo Fredriksson -
Ulrich Windl