Hello,
Having migrated from slapd.conf, I would like to ask some questions regarding cases/scenarios where someone - unintentionally - breaks the configuration.
So, let's assume that, due to some misspelling or use of wrong values (esp. when using a graphical LDAP Browser - like JXplorer - to maintain the configuration DIT), we have added/modified a setting that would break the installation without warning.
*Question 1*: Are there cases where: 1/ LDAP Server will stop immediately? (It is stated that "Beware: You can configure cn=config to an unusable state.", ref. with example: http://www.zytrax.com/books/ldap/ch6/slapd-config.html) 2/ LDAP Server will continue to operate but, if stopped, when restarted it will not be able to restart?
If the answer to Q1.2 above is yes: *Question 2*: How can we test at any given point the current configuration to make sure it will be OK if/when restarted (AFAIK, slaptest only tests slapd.conf and not slapd.d configuration)?
*Question 3* (especially critical if the answer to Q1.1 or Q1.2 above is yes): If the server is stopped, how can we change manually the config settings (e.g. by editing slapd.d/ files) to attempt to correct it?
(In one such test I did, I changed - directly in "cn=config.ldif" file - olcLogLevel as follows: Initial state:
olcLogLevel: Config olcLogLevel: Sync
New state (removed one attribute value and changed the other):
olcLogLevel: -1
and when I tried to start I got:
ldif_read_file: checksum error on "/usr/local/openldap/etc/openldap/slapd.d/cn=config.ldif"
so I had to re-edit the file and change the values as they were initially, which allowed the server to start.
So (to *repeat Question 3*), how can we "re-engineer" cn=config settings when off-line? It is always desirable to be able to do some "low-level engineering" to the configuration (under administrator's or system engineer's responsibility) in case something goes wrong. This is also important in cases of "cloning" the server where we want a copy of the config but we need to change a few settings in the new context. We need to avoid things like "checksum error"!
Finally, there might be cases where - after having migrated and worked for a period using cn=config - business/technical needs require the use of overlay(s) or other modules like SLAPI, which would not be supported by cn=config and someone would need to move to slapd.conf configuration (at least temporarily). If such a need arises, *Question 4*: Is there a tool/method to "migrate" to slapd.conf from a slapd.d configuration?
Thanks in advance, Nick
Nick Milas wrote:
Hello,
Having migrated from slapd.conf, I would like to ask some questions regarding cases/scenarios where someone - unintentionally - breaks the configuration.
So, let's assume that, due to some misspelling or use of wrong values (esp. when using a graphical LDAP Browser - like JXplorer - to maintain the configuration DIT), we have added/modified a setting that would break the installation without warning.
*Question 1*: Are there cases where: 1/ LDAP Server will stop immediately? (It is stated that "Beware: You can configure cn=config to an unusable state.", ref. with example: http://www.zytrax.com/books/ldap/ch6/slapd-config.html)
Not intentionally. Some errors could lead to an assert() failing, which would cause slapd to stop.
Zytrax.com is not a reliable source of OpenLDAP documentation. Most of what they advise is misguided or flat wrong.
2/ LDAP Server will continue to operate but, if stopped, when restarted it will not be able to restart?
This has been known to happen a few times in the past due to bugs in the config code. In general, no.
If the answer to Q1.2 above is yes: *Question 2*: How can we test at any given point the current configuration to make sure it will be OK if/when restarted (AFAIK, slaptest only tests slapd.conf and not slapd.d configuration)?
Where do you get this "knowledge"? From Zytrax? slaptest tests "the server configuration" - it doesn't matter whether it is in slapd.conf or slapd.d.
*Question 3* (especially critical if the answer to Q1.1 or Q1.2 above is yes): If the server is stopped, how can we change manually the config settings (e.g. by editing slapd.d/ files) to attempt to correct it?
Manually editing slapd.d files is the surest way of causing a problem that prevents slapd from restarting.
(In one such test I did, I changed - directly in "cn=config.ldif" file - olcLogLevel as follows: Initial state:
olcLogLevel: Config olcLogLevel: SyncNew state (removed one attribute value and changed the other):
olcLogLevel: -1and when I tried to start I got:
ldif_read_file: checksum error on "/usr/local/openldap/etc/openldap/slapd.d/cn=config.ldif"so I had to re-edit the file and change the values as they were initially, which allowed the server to start.
So (to *repeat Question 3*), how can we "re-engineer" cn=config settings when off-line? It is always desirable to be able to do some "low-level engineering" to the configuration (under administrator's or system engineer's responsibility) in case something goes wrong. This is also important in cases of "cloning" the server where we want a copy of the config but we need to change a few settings in the new context. We need to avoid things like "checksum error"!
It is always desirable to not make a mistake that blows your foot off (or ankle or leg, for that matter).
In this case, that means ensuring that any changes you want to make are checked for syntax and other such constraints, so that you're not stuck with a non-working config.
Obvious approach: slapcat -n0 -F old/slapd.d > config.ldif edit config.ldif slapadd -n0 -F new/slapd.d -l config.ldif test using new/slapd.d deploy...
Finally, there might be cases where - after having migrated and worked for a period using cn=config - business/technical needs require the use of overlay(s) or other modules like SLAPI, which would not be supported by cn=config and someone would need to move to slapd.conf configuration (at least temporarily). If such a need arises, *Question 4*: Is there a tool/method to "migrate" to slapd.conf from a slapd.d configuration?
Ask your buddies at Zytrax, they seem to think so.
As far as the OpenLDAP Project is concerned, conversion from slapd.conf to slapd.d is a one-way trip. Migrate everything else forward.
Howard Chu writes:
Zytrax.com is not a reliable source of OpenLDAP documentation. Most of what they advise is misguided or flat wrong.
Yet Google(OpenLDAP cn=config)'s two first hits are at Zytrax. It's not surprising people keep using that stuff.
Maybe the OpenLDAP site could be improved to help that. Google has some guidelines for that at http://www.google.com/webmasters/.
On Thu, Oct 20, 2011 at 10:00 PM, Hallvard B Furuseth < h.b.furuseth@usit.uio.no> wrote:
Howard Chu writes:
Zytrax.com is not a reliable source of OpenLDAP documentation. Most of
what
they advise is misguided or flat wrong.
Yet Google(OpenLDAP cn=config)'s two first hits are at Zytrax. It's not surprising people keep using that stuff.
Maybe the OpenLDAP site could be improved to help that. Google has some guidelines for that at http://www.google.com/webmasters/
I think the popularity of Zytrax guide on google indicates that there is a need for some simple guide or howto of how to get some sort of trivial ldap server running, in the first instance.
Zytrax might fail with regard to accuracy in specific details as it seems to be infrequently updated (last August 2010, before that July 2009), but taken asis it gets people going such that they can at least get a server running, then they can then start to learn by actively using openldap. The zytrax guide itself is open source, so the other alternative is to help improve it's accuracy ?
Such a openldap guide might least serve a purpose, more for newbies as supposed to the old salts, in that it could reduce chatter regards to getting a server compiled/running/loaded etc., in the first place, but call me an optimist.
Cheers Brett
On Thu, October 20, 2011 16:20, Brett @Google wrote:
I think the popularity of Zytrax guide on google indicates that there is a need for some simple guide or howto of how to get some sort of trivial ldap server running, in the first instance.
Zytrax might fail with regard to accuracy in specific details as it seems to be infrequently updated (last August 2010, before that July 2009), but taken asis it gets people going such that they can at least get a server running, then they can then start to learn by actively using openldap. The zytrax guide itself is open source, so the other alternative is to help improve it's accuracy ?
Such a openldap guide might least serve a purpose, more for newbies as supposed to the old salts, in that it could reduce chatter regards to getting a server compiled/running/loaded etc., in the first place, but call me an optimist.
Cheers Brett
+1 billion to that!
Brett @Google writes:
I think the popularity of Zytrax guide on google indicates that there is a need for some simple guide or howto of how to get some sort of trivial ldap server running, in the first instance.
True enough, but also OpenLDAP website doesn't look like a shining example of modern web design. Not that I know much of how to improve that.
Zytrax might fail with regard to accuracy in specific details as it seems to be infrequently updated (last August 2010, before that July 2009), but taken asis it gets people going such that they can at least get a server running, then they can then start to learn by actively using openldap. The zytrax guide itself is open source, so the other alternative is to help improve it's accuracy ?
Yesno. HOWTOs, certainly. Not that I've looked much at the site myself. Mostly I've seen others talk about it.
OTOH, much of it seems more or less copied from manpages, the Admin Guide etc. Seems a losing game to proofreed and try to maintain a separate copy of those, in a permanent state of catch-up.
----- Original Message -----
Brett @Google writes:
I think the popularity of Zytrax guide on google indicates that there is a need for some simple guide or howto of how to get some sort of trivial ldap server running, in the first instance.
True enough, but also OpenLDAP website doesn't look like a shining example of modern web design. Not that I know much of how to improve that.
Zytrax might fail with regard to accuracy in specific details as it seems to be infrequently updated (last August 2010, before that July 2009), but taken asis it gets people going such that they can at least get a server running, then they can then start to learn by actively using openldap. The zytrax guide itself is open source, so the other alternative is to help improve it's accuracy ?
Yesno. HOWTOs, certainly. Not that I've looked much at the site myself. Mostly I've seen others talk about it.
OTOH, much of it seems more or less copied from manpages, the Admin Guide etc. Seems a losing game to proofreed and try to maintain a separate copy of those, in a permanent state of catch-up.
We do have our wiki and that's the only place for this stuff but as a project the policy has always been to be neutral. So what distro would you pick for installs, setup etc. as they all bundle their own out of date versions.
Do we skip that bit and just talk about config or what?
I'm happy to write stuff if we want to work on a small table of contents.
What about adopting the Zytrax stuff, updating it and get them to do a 301 redirect to our wiki?
I see they are a company offering support using out dated knowledge :-)
On Fri, Oct 21, 2011 at 2:42 AM, Gavin Henry ghenry@openldap.org wrote:
Do we skip that bit and just talk about config or what?
I'd be inclined to document a source build, from the current release, at least then people would end up with a newer version and dependencies were provided (bdb etc.,) as part. Describing using binary packages is going to be a morass of distribution specific details and caviats, package names & versions etc., a source build instruction (with explicit links to third party libraries) is going to date more slowly and be simpler to read.
Then maybe show a script to generate some random test data (such as Make LDIF from OpenDS https://www.opends.org/wiki/page/MakeLdif), and how to load it into an ldap instance and get it running etc., or documetn how to load some canned test data.
And then a basic example of how to run ldapsearch, ldapmodify and a list of GUI tools such as Apache Directory Studio, etc.,
Running through a source build is not that hard if documented, distribution binaries / libraries are usually very outdated / broken.
What about adopting the Zytrax stuff, updating it and get them to do a 301
redirect to our wiki?
I'm sure you could ask. But it might not be actively supported anymore, so maybe noone to ask .. ?
Cheers Brett
Hallvard B Furuseth wrote:
Brett @Google writes:
I think the popularity of Zytrax guide on google indicates that there is a need for some simple guide or howto of how to get some sort of trivial ldap server running, in the first instance.
True enough, but also OpenLDAP website doesn't look like a shining example of modern web design.
From my experience a shiny modern web design is bad for the Google page rank.
Ciao, Michael.
Brett @Google wrote:
On Thu, Oct 20, 2011 at 10:00 PM, Hallvard B Furuseth <h.b.furuseth@usit.uio.no mailto:h.b.furuseth@usit.uio.no> wrote:
Howard Chu writes: > Zytrax.com is not a reliable source of OpenLDAP documentation. Most of what > they advise is misguided or flat wrong. Yet Google(OpenLDAP cn=config)'s two first hits are at Zytrax. It's not surprising people keep using that stuff. Maybe the OpenLDAP site could be improved to help that. Google has some guidelines for that at <http://www.google.com/webmasters/>I think the popularity of Zytrax guide on google indicates that there is a need for some simple guide or howto of how to get some sort of trivial ldap server running, in the first instance.
Zytrax might fail with regard to accuracy in specific details as it seems to be infrequently updated (last August 2010, before that July 2009), but taken asis it gets people going such that they can at least get a server running, then they can then start to learn by actively using openldap. The zytrax guide itself is open source, so the other alternative is to help improve it's accuracy ?
Wow, talk about putting the cart before the horse. Last time I checked, the OpenLDAP documentation was also open source. If anyone sincerely wants to improve the docs and make things easier for new users to get off the ground, while getting their edits vetted by people who actually understand how the code works, the obvious (to me anyway) thing to do is to submit updates in the ITS.
The Zytrax guys are clearly just out to make a buck, lifting the OpenLDAP Admin Guide content and putting a thin layer of "personal experience" around it. They're not contributing back to the OpenLDAP community; they're not participating in the community at all, and the info they're distributing is (as noted) already outdated.
Such a openldap guide might least serve a purpose, more for newbies as supposed to the old salts, in that it could reduce chatter regards to getting a server compiled/running/loaded etc., in the first place, but call me an optimist.
If you really believe that helping a 3rd party keep their obsolete plagiarism of the OpenLDAP Project's work up to date is a good idea, "optimist" is not the word I'd use for you.
Cheers Brett
-- *The only thing that interferes with my learning is my education.*
Albert Einstein*
On Fri, Oct 21, 2011 at 3:35 AM, Howard Chu hyc@symas.com wrote:
Brett @Google wrote:
Zytrax might fail with regard to accuracy in specific details as it seems to be infrequently updated (last August 2010, before that July 2009), but taken asis it gets people going such that they can at least get a server running, then they can then start to learn by actively using openldap. The zytrax guide itself is open source, so the other alternative is to help improve it's accuracy ?
Wow, talk about putting the cart before the horse. Last time I checked, the OpenLDAP documentation was also open source. If anyone sincerely wants to improve the docs and make things easier for new users to get off the ground, while getting their edits vetted by people who actually understand how the code works, the obvious (to me anyway) thing to do is to submit updates in the ITS.
I was talking about the NEED for such a document, not talking about who authored / would author it.
My point (perhaps unclear) was that openldap should have such a document, or at least not 'dis those who try..
The Zytrax guys are clearly just out to make a buck, lifting the OpenLDAP Admin Guide content and putting a thin layer of "personal experience" around it. They're not contributing back to the OpenLDAP community; they're not participating in the community at all, and the info they're distributing is (as noted) already outdated.
Such a openldap guide might least serve a purpose, more for newbies as
supposed to the old salts, in that it could reduce chatter regards to getting a server compiled/running/loaded etc., in the first place, but call me an optimist.
If you really believe that helping a 3rd party keep their obsolete plagiarism of the OpenLDAP Project's work up to date is a good idea, "optimist" is not the word I'd use for you.
My reference to being an optimist was thinking that the openldap project might by itself create such a guide. Being an open source project i'm sure there is plenty of other work needing to be done, besides creating such a guide.
I am happy enough to have a go at such a guide, but a poet i am not. What is the preferred document format ?
Cheers Brett
Le 21/10/2011 01:55, Brett @Google a écrit :
I was talking about the NEED for such a document, not talking about who authored / would author it.
My point (perhaps unclear) was that openldap should have such a document, or at least not 'dis those who try..
Maybe, the quick-start guide could be expanded with different sessions.
There's another good source of documentation in the tests/script with all the major features being setup in tests repository.
The Zytrax guys are clearly just out to make a buck, lifting the OpenLDAP Admin Guide content and putting a thin layer of "personal experience" around it. They're not contributing back to the OpenLDAP community; they're not participating in the community at all, and the info they're distributing is (as noted) already outdated. Such a openldap guide might least serve a purpose, more for newbies as supposed to the old salts, in that it could reduce chatter regards to getting a server compiled/running/loaded etc., in the first place, but call me an optimist. If you really believe that helping a 3rd party keep their obsolete plagiarism of the OpenLDAP Project's work up to date is a good idea, "optimist" is not the word I'd use for you.My reference to being an optimist was thinking that the openldap project might by itself create such a guide. Being an open source project i'm sure there is plenty of other work needing to be done, besides creating such a guide.
Don't minimize doc. Easy docs means more successful setup, more visibility, more persons involved and more developers.
I am happy enough to have a go at such a guide, but a poet i am not. What is the preferred document format ?
Admin guide is using sdf at this time. All documents are included in the source tarball. Have a look.
Seb
On Fri, Oct 21, 2011 at 7:32 PM, Sébastien Bernard seb@frankengul.orgwrote:
Le 21/10/2011 01:55, Brett @Google a écrit :
I was talking about the NEED for such a document, not talking about who authored / would author it.
My point (perhaps unclear) was that openldap should have such a document, or at least not 'dis those who try..
Maybe, the quick-start guide could be expanded with different sessions.
There's another good source of documentation in the tests/script with all the major features being setup in tests repository.
I have been looking at the existing doco, in particular the quickstart (bould from source) is pretty good already.
The only thing i can think of, comparing zytrax to openldap docs, is that zytrax is all in the one place. Openldap's information is of much higher quality, but it is segmented into functional areas which require an understanding of openldap architecture before you can find the appropriate documentation. Newbies would not understand the openldap architecture, so would not be able to find docs.
For example, if you have a problem with a particular directive which belongs in a particular backend, you would need to understand the openldap architecture and the relationship between keywords and backends, so that you know to look at the relevent backend documentation. Likewise users would need to know the difference between global and per-backend options, to find the best docs.
Maybe in the documentation, hyperlink or comment could be added to the database sections to highlight the per-database docs ?
The tests directory is a bit of a treasure trove, config wise. But hard to say how to make them acessable to everyone.
Cheers Brett
On 20/10/2011 2:24 μμ, Howard Chu wrote:
Where do you get this "knowledge"? From Zytrax? slaptest tests "the server configuration" - it doesn't matter whether it is in slapd.conf or slapd.d.
I checked man slaptest (e.g. here: http://www.manpagez.com/man/8/slaptest/) which is titled: "slaptest - Check the suitability of the OpenLDAP slapd.conf file"; yet (my fault; I didn't read thoroughly) I now see that at the Description section it says: "It opens the slapd.conf(5) configuration file or the slapd-config(5) backend..."
So, if slaptest checks slapd.d config then fine!
Manually editing slapd.d files is the surest way of causing a problem that prevents slapd from restarting.
OK, understood!
Obvious approach: slapcat -n0 -F old/slapd.d > config.ldif edit config.ldif slapadd -n0 -F new/slapd.d -l config.ldif test using new/slapd.d deploy...
OK, I see. Valuable info.
Finally, there might be cases where ... someone would need to move to slapd.conf configuration
Ask your buddies at Zytrax, they seem to think so.
Hey, Howard, give me a break. I am just trying to research the whereabouts of my new environment (after migration). I have no affiliation with the guys at Zytrax. I just mentioned their witnessed experience.
However, one could say that Zytrax don't mean to cause any harm; after all, they advocate the use of openldap - although we non-experts on OpenLDAP cannot tell if there are minor or major flaws in their "documentation". Their documents probably look appealing to LDAP newcomers because they follow a how-to attitude, which might feel especially helpful for initial deployments.
As far as the OpenLDAP Project is concerned, conversion from slapd.conf to slapd.d is a one-way trip. Migrate everything else forward.
That's what we want too (this is why we migrated in the first place)! cn=config is great in that it includes everything in the directory. I am sure that the OpenLDAP project team will also be adding more and more to this fine structure (at least progressively), like support for comments/descriptions, esp. in ACLs (my thoughts on ACL sorting and commenting in another thread).
Thanks for your valuable time, Nick
--On Thursday, October 20, 2011 6:36 PM +0300 Nick Milas nick@eurobjects.com wrote:
Manually editing slapd.d files is the surest way of causing a problem that prevents slapd from restarting.
OK, understood!
Obvious approach: slapcat -n0 -F old/slapd.d > config.ldif edit config.ldif slapadd -n0 -F new/slapd.d -l config.ldif test using new/slapd.d deploy...
OK, I see. Valuable info.
I would note that OpenLDAP 2.5 (when released) adds a "slapmodify" command per my request. It allows you to do offline modifications of cn=config in a way similar to ldapmodify. This will also keep the CRC checksum intact.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On 20/10/2011 9:03 μμ, Quanah Gibson-Mount wrote:
slapcat -n0 -F old/slapd.d > config.ldif edit config.ldif slapadd -n0 -F new/slapd.d -l config.ldif test using new/slapd.d deploy...
I would note that OpenLDAP 2.5 (when released) adds a "slapmodify" command per my request. It allows you to do offline modifications of cn=config in a way similar to ldapmodify. This will also keep the CRC checksum intact.
slapmodify will surely be an important addition. (Although v2.5 might not be that close.)
Question:
Can we use:
slapadd -n0 -F new/slapd.d -l config.ldif
while slapd is running?
Documentation states: Your slapd should not be running when you do this (i.e. when using slapadd) to ensure consistency of the database... But this command does not really interfere with the current database (which is in old/slapd.d). So please clarify.
If not, could this functionality be added to slaptest, so that it can be run while slapd is running? (e.g. add "-l <config.ldif>" option, which, if used in conjunction with "-F <newconfdir>", it will build the config from <config.ldif> in <newconfdir>).
Thanks, Nick
Nick Milas wrote:
On 20/10/2011 9:03 μμ, Quanah Gibson-Mount wrote:
slapcat -n0 -F old/slapd.d> config.ldif edit config.ldif slapadd -n0 -F new/slapd.d -l config.ldif test using new/slapd.d deploy...
I would note that OpenLDAP 2.5 (when released) adds a "slapmodify" command per my request. It allows you to do offline modifications of cn=config in a way similar to ldapmodify. This will also keep the CRC checksum intact.
slapmodify will surely be an important addition. (Although v2.5 might not be that close.)
Question:
Can we use:
slapadd -n0 -F new/slapd.d -l config.ldifwhile slapd is running?
Documentation states: Your slapd should not be running when you do this (i.e. when using slapadd) to ensure consistency of the database... But this command does not really interfere with the current database (which is in old/slapd.d). So please clarify.
That note is only referring to use of slapadd to add data to a database that slapd is already using. If you're using totally separate filesystem directories, then of course you can slapadd to a config directory different from the one that slapd is currently running. It's not like there's a magical filesystem lock such that slapd knows about everything else occurring on the machine or filesystem. Use some common sense.
On 21/10/2011 3:30 μμ, Howard Chu wrote:
Nick Milas wrote:
But this command does not really interfere with the current database (which is in old/slapd.d). So please clarify.
It's not like there's a magical filesystem lock such that slapd knows about everything else occurring on the machine or filesystem. Use some common sense.
Didn't I? :-)
Thanks, Nick
openldap-technical@openldap.org
-
Brett ＠Google -
Gavin Henry -
Giles Coochey -
Hallvard B Furuseth -
Howard Chu -
Michael Ströder -
Nick Milas -
Quanah Gibson-Mount -
Sébastien Bernard