Hi,
I am trying to install openldap 2.3 to work as automatic referral chasing where all update queries should be automatically directed to my master server, I would really appreciate a sample config. The details: I need to setup a master server and a replica, and put both of them behind a load balancer. In case a write operations is sent to the slave, I need the slave to direct the client to the master server rather than having the client chase referrals manually.
Taymour A. El Erian skrev, on 04-09-2007 08:16:
I am trying to install openldap 2.3 to work as automatic referral chasing where all update queries should be automatically directed to my master server, I would really appreciate a sample config.
Well, you just got one (see my post). Now someone tell me the answer to /my/ question?
The details: I need to setup a master server and a replica, and put both of them behind a load balancer. In case a write operations is sent to the slave, I need the slave to direct the client to the master server rather than having the client chase referrals manually.
I only have one (set of) client utilities that understands referrals at all, while shell and Perl scripts running on the consumer - some using OpenLDAP clients (which don't understand referrals) - are absolutely dependent on chaining. So thank deity I found out how by persisting and reading the OL docs.
--Tonni
Tony Earnshaw wrote:
Taymour A. El Erian skrev, on 04-09-2007 08:16:
I am trying to install openldap 2.3 to work as automatic referral chasing where all update queries should be automatically directed to my master server, I would really appreciate a sample config.
Well, you just got one (see my post). Now someone tell me the answer to /my/ question?
The test scripts are not running on my machine as they fail in the middle, so am unable to actually find the configuration. I tried using the configuration which has chain in its name but it does not work.
The details: I need to setup a master server and a replica, and put both of them behind a load balancer. In case a write operations is sent to the slave, I need the slave to direct the client to the master server rather than having the client chase referrals manually.
I only have one (set of) client utilities that understands referrals at all, while shell and Perl scripts running on the consumer - some using OpenLDAP clients (which don't understand referrals) - are absolutely dependent on chaining. So thank deity I found out how by persisting and reading the OL docs.
The docs of openldap are really not clear
--Tonni
Taymour A. El Erian wrote:
The docs of openldap are really not clear
I suggest you make more precise statements: what's not clear, and how should it be improved. Otherwise your statement is simply offensive with respect to the many persons that voluntarily (i.e. without being paid, and often out of their little spare time) dedicated to writing the documentation. In fact, as developers, we shouldn't care too much about documenting our work. All in all, we can read the code, and we already know how it works, so we shouldn't care too much about your needs as soon as they do not match ours. Note that I intentionally ignored your question, since it has been answered many times, as you may find out by searching the archives, and answering it once more seemed to be a real waste of time that I could have dedicated to improving the documents, if I received a valid feedback about where improvement is needed.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati wrote:
Taymour A. El Erian wrote:
The docs of openldap are really not clear
I suggest you make more precise statements: what's not clear, and how should it be improved. Otherwise your statement is simply offensive with respect to the many persons that voluntarily (i.e. without being paid, and often out of their little spare time) dedicated to writing the documentation. In fact, as developers, we shouldn't care too much about documenting our work. All in all, we can read the code, and we already know how it works, so we shouldn't care too much about your needs as soon as they do not match ours. Note that I intentionally ignored your question, since it has been answered many times, as you may find out by searching the archives, and answering it once more seemed to be a real waste of time that I could have dedicated to improving the documents, if I received a valid feedback about where improvement is needed.
p.
Pierangelo,
I don't want to get into a debate about the importance of documentation, but documentation is really one of the most important things about software. If you as a developer understand the code, this doesn't mean the code is usable since most of those who use it are not developers and do not know how to read the code. Everybody appreciates the time and effort given by the developers. The administrator guide has no mention of the overlays (at least not chain) and the man pages do not give enough description, also the administrator guide could add examples for some configurations, maybe like those ones being asked in the mailing list.
I really searched for my question a lot in the list but could not find it.
Thank you anyway.
Taymour A. El Erian wrote:
Pierangelo,
I don't want to get into a debate about the importance of documentation, but documentation is really one of the most important things about software.
Thanks for educating me on the importance of documentation. If you could also instruct me about **how** it should be improved, not just **why**, that would be a "giant leap for the mankind".
If you as a developer understand the code, this doesn't mean the code is usable since most of those who use it are not developers and do not know how to read the code. Everybody appreciates the time and effort given by the developers. The administrator guide has no mention of the overlays (at least not chain) and the man pages do not give enough description, also the administrator guide could add examples for some configurations, maybe like those ones being asked in the mailing list.
I really searched for my question a lot in the list but could not find it.
Did you search the -software for "chain;referral"? I got 51 hits, most of them pertinent.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati wrote:
Taymour A. El Erian wrote:
Pierangelo,
I don't want to get into a debate about the importance of documentation, but documentation is really one of the most important things about software.
Thanks for educating me on the importance of documentation. If you could also instruct me about **how** it should be improved, not just **why**, that would be a "giant leap for the mankind".
As I said below, why not mention the overlays in the administrator guide, add some real life examples (lots of them available from the mailing list questions). The man pages are good for quick reference but not for installation (specially for new admins.).
If you as a developer understand the code, this doesn't mean the code is usable since most of those who use it are not developers and do not know how to read the code. Everybody appreciates the time and effort given by the developers. The administrator guide has no mention of the overlays (at least not chain) and the man pages do not give enough description, also the administrator guide could add examples for some configurations, maybe like those ones being asked in the mailing list.
I really searched for my question a lot in the list but could not find it.
Did you search the -software for "chain;referral"? I got 51 hits, most of them pertinent.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it
Thanks for educating me on the importance of documentation. If you could also instruct me about **how** it should be improved, not just **why**, that would be a "giant leap for the mankind".
As I said below, why not mention the overlays in the administrator guide, add some real life examples (lots of them available from the mailing list questions). The man pages are good for quick reference but not for installation (specially for new admins.).
Like I said, all in the 2.4 Guide, just not quite complete.
On Thu, 6 Sep 2007, Gavin Henry wrote:
Like I said, all in the 2.4 Guide, just not quite complete.
And I'd like to publically thank you for your documentation efforts.
I just wish I had more time to help with the project...
<quote who="Dave Horsfall">
On Thu, 6 Sep 2007, Gavin Henry wrote:
Like I said, all in the 2.4 Guide, just not quite complete.
And I'd like to publically thank you for your documentation efforts.
You haven't read them yet! ;-)
I just wish I had more time to help with the project...
Just send some comments in when it's out.
-- Dave Horsfall DTM VK2KFU Ph: +61 2 9552-5509 (direct) +61 2 9552-5500 (switch) Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU
Gavin Henry wrote:
Thanks for educating me on the importance of documentation. If you could also instruct me about **how** it should be improved, not just **why**, that would be a "giant leap for the mankind".
As I said below, why not mention the overlays in the administrator guide, add some real life examples (lots of them available from the mailing list questions). The man pages are good for quick reference but not for installation (specially for new admins.).
Like I said, all in the 2.4 Guide, just not quite complete.
Thanks Gavin, I will go check the new guide
Like I said, all in the 2.4 Guide, just not quite complete.
Hi Gavin, a quick question on this... how relevant or otherwise would the 2.4 guide be for people running 2.3? It sounds like it provides a lot of useful information, but how much of this applies to 2.3, as well as 2.4, or is it likely to prove confusing?
Cheers Toby
<quote who="Toby Blake">
Like I said, all in the 2.4 Guide, just not quite complete.
Hi Gavin, a quick question on this... how relevant or otherwise would the 2.4 guide be for people running 2.3? It sounds like it provides a lot of useful information, but how much of this applies to 2.3, as well as 2.4, or is it likely to prove confusing?
A lot of it will be useful, but obviously some features won't be available like certain overlays and various options.
It builds on 2.3 and adds various things, see:
http://suretec.org/our_docs/index.html
More general admin stuff. Read over:
http://suretec.org/our_docs/appendix-changes.html
The above links are old content, more is added now in HEAD and all will be complete for the first stable release of 2.4.x
Gavin.
A lot of it will be useful, but obviously some features won't be available like certain overlays and various options.
It builds on 2.3 and adds various things, see:
http://suretec.org/our_docs/index.html
More general admin stuff. Read over:
http://suretec.org/our_docs/appendix-changes.html
The above links are old content, more is added now in HEAD and all will be complete for the first stable release of 2.4.x
Excellent, looks really useful. Thanks.
Toby
On Wednesday 05 September 2007 03:57:41 Taymour A. El Erian wrote:
Pierangelo Masarati wrote:
Taymour A. El Erian wrote:
The docs of openldap are really not clear
I suggest you make more precise statements: what's not clear, and how should it be improved. Otherwise your statement is simply offensive with respect to the many persons that voluntarily (i.e. without being paid, and often out of their little spare time) dedicated to writing the documentation. In fact, as developers, we shouldn't care too much about documenting our work. All in all, we can read the code, and we already know how it works, so we shouldn't care too much about your needs as soon as they do not match ours. Note that I intentionally ignored your question, since it has been answered many times, as you may find out by searching the archives, and answering it once more seemed to be a real waste of time that I could have dedicated to improving the documents, if I received a valid feedback about where improvement is needed.
p.
Pierangelo,
I don't want to get into a debate about the importance ofdocumentation, but documentation is really one of the most important things about software. If you as a developer understand the code, this doesn't mean the code is usable since most of those who use it are not developers and do not know how to read the code. Everybody appreciates the time and effort given by the developers. The administrator guide has no mention of the overlays (at least not chain) and the man pages do not give enough description, also the administrator guide could add examples for some configurations, maybe like those ones being asked in the mailing list.
Oh please, stop bitching and moaning about the documentation! I can't take it anymore on this list. Why don't you go to work and send in documentation improvements? I'm not a developer but I fully agree with them. If you want better documentation, send your improvements to ITS or to the FAQ. As a good LDAP admin you can figure out how it works.
kk
Pierangelo,
I don't want to get into a debate about the importance ofdocumentation, but documentation is really one of the most important things about software. If you as a developer understand the code, this doesn't mean the code is usable since most of those who use it are not developers and do not know how to read the code. Everybody appreciates the time and effort given by the developers. The administrator guide has no mention of the overlays (at least not chain) and the man pages do not give enough description, also the administrator guide could add examples for some configurations, maybe like those ones being asked in the mailing list.
Oh please, stop bitching and moaning about the documentation! I can't take it anymore on this list. Why don't you go to work and send in documentation improvements? I'm not a developer but I fully agree with them. If you want better documentation, send your improvements to ITS or to the FAQ. As a good LDAP admin you can figure out how it works.
kk++
+1 from me.
Taymour A. El Erian wrote:
Pierangelo Masarati wrote:
Taymour A. El Erian wrote:
The docs of openldap are really not clear
I suggest you make more precise statements: what's not clear, and how should it be improved. Otherwise your statement is simply offensive with respect to the many persons that voluntarily (i.e. without being paid, and often out of their little spare time) dedicated to writing the documentation. In fact, as developers, we shouldn't care too much about documenting our work. All in all, we can read the code, and we already know how it works, so we shouldn't care too much about your needs as soon as they do not match ours. Note that I intentionally ignored your question, since it has been answered many times, as you may find out by searching the archives, and answering it once more seemed to be a real waste of time that I could have dedicated to improving the documents, if I received a valid feedback about where improvement is needed.
p.
Pierangelo,
I don't want to get into a debate about the importance of documentation, but documentation is really one of the most important things about software. If you as a developer understand the code, this doesn't mean the code is usable since most of those who use it are not developers and do not know how to read the code. Everybody appreciates the time and effort given by the developers. The administrator guide has no mention of the overlays (at least not chain) and the man pages do not give enough description, also the administrator guide could add examples for some configurations, maybe like those ones being asked in the mailing list.
These may just magically appear if we wish hard enough, but in reality someone has to write them. You've written a nice long paragraph above, which is probably longer than the text needed to document some missing information. Nice use of your time.
I really searched for my question a lot in the list but could not find it.
Thank you anyway.
These are all just about done and the new Admin Guide will be out when 2.4 is out of Beta.
You can download 2.4.5 beta as of today and see the new docs for yourself (they are still wip).
As always, this is a community effort, so please reply with a list of "I'd love to see in the docs"
There's nothing I hate more than people using community developed software, complaining and not contributing.
Gavin.
Gavin Henry wrote:
Taymour A. El Erian wrote:
Pierangelo Masarati wrote:
Taymour A. El Erian wrote:
The docs of openldap are really not clear
I suggest you make more precise statements: what's not clear, and how should it be improved. Otherwise your statement is simply offensive with respect to the many persons that voluntarily (i.e. without being paid, and often out of their little spare time) dedicated to writing the documentation. In fact, as developers, we shouldn't care too much about documenting our work. All in all, we can read the code, and we already know how it works, so we shouldn't care too much about your needs as soon as they do not match ours. Note that I intentionally ignored your question, since it has been answered many times, as you may find out by searching the archives, and answering it once more seemed to be a real waste of time that I could have dedicated to improving the documents, if I received a valid feedback about where improvement is needed.
p.
Pierangelo,
I don't want to get into a debate about the importance of documentation, but documentation is really one of the most important things about software. If you as a developer understand the code, this doesn't mean the code is usable since most of those who use it are not developers and do not know how to read the code. Everybody appreciates the time and effort given by the developers. The administrator guide has no mention of the overlays (at least not chain) and the man pages do not give enough description, also the administrator guide could add examples for some configurations, maybe like those ones being asked in the mailing list.
These may just magically appear if we wish hard enough, but in reality someone has to write them. You've written a nice long paragraph above, which is probably longer than the text needed to document some missing information. Nice use of your time.
I'd help write the admin guide if I knew how to do the configuration, I love community software.
I really searched for my question a lot in the list but could not find it.
Thank you anyway.
These are all just about done and the new Admin Guide will be out when 2.4 is out of Beta.
You can download 2.4.5 beta as of today and see the new docs for yourself (they are still wip).
As always, this is a community effort, so please reply with a list of "I'd love to see in the docs"
I'd love to see this in the docs:
1- Real life examples (replication, chaining) 2- More detailed explanation (without so much technical details about how things are implemented internally with a note to where to read that)
There's nothing I hate more than people using community developed software, complaining and not contributing.
Gavin.
I'd help write the admin guide if I knew how to do the configuration, I love community software.
Of course.
I really searched for my question a lot in the list but could not find it.
Thank you anyway.
These are all just about done and the new Admin Guide will be out when 2.4 is out of Beta.
You can download 2.4.5 beta as of today and see the new docs for yourself (they are still wip).
As always, this is a community effort, so please reply with a list of "I'd love to see in the docs"
I'd love to see this in the docs:
1- Real life examples (replication, chaining)
These are planned.
2- More detailed explanation (without so much technical details about how things are implemented internally with a note to where to read that)
As above.
There's nothing I hate more than people using community developed software, complaining and not contributing.
Gavin.
-- Taymour A El Erian System Division Manager RHCE, LPIC, CCNA, MCSE, CNA TE Data E-mail: taymour.elerian@tedata.net Web: www.tedata.net Tel: +(202)-33320700 Fax: +(202)-33320800 Ext: 1101
Taymour A. El Erian skrev, on 05-09-2007 08:13:
[...]
The test scripts are not running on my machine as they fail in the middle, so am unable to actually find the configuration. I tried using the configuration which has chain in its name but it does not work.
Then for some reason your build has failed and you have a useless installation. Until you can get a build whereby all tests pass, you might as well give up.
[...]
The docs of openldap are really not clear
Yep, many have pointed this out in the past, and the docs *have* been vastly improved - but even after several years' of OL sysadminning I still have problems in interpreting them. In many cases, if it hadn't been for this list I'd still be completely at sea.
Best,
--Tonni
Tony Earnshaw wrote:
Taymour A. El Erian skrev, on 05-09-2007 08:13:
[...]
The test scripts are not running on my machine as they fail in the middle, so am unable to actually find the configuration. I tried using the configuration which has chain in its name but it does not work.
Then for some reason your build has failed and you have a useless installation. Until you can get a build whereby all tests pass, you might as well give up.
Some of the tests do run but some do not and I can't really understand the reason. I am using the rpms provided by Buchan on RHEL 3 U9. I can start slapd with any configuration which means (I think) that the binaries are fine.
[...]
The docs of openldap are really not clear
Yep, many have pointed this out in the past, and the docs *have* been vastly improved - but even after several years' of OL sysadminning I still have problems in interpreting them. In many cases, if it hadn't been for this list I'd still be completely at sea.
Best,
Would it be possible to help me get out of the sea ?
--Tonni
Taymour A. El Erian skrev, on 05-09-2007 13:01:
[...]
Some of the tests do run but some do not and I can't really understand the reason. I am using the rpms provided by Buchan on RHEL 3 U9. I can start slapd with any configuration which means (I think) that the binaries are fine.
Unless all the tests pass you have a duff product. Reading the test logs produced by tests that fail should help, but the log level is pretty high and needs some parsing. Personally I try to rebuild from srpms on a similar machine to my production machines, especially with something as complicated as what Buchan offers. One has the opportunity to alter the spec file to suit one's own needs, too.
[...]
The docs of openldap are really not clear
Yep, many have pointed this out in the past, and the docs *have* been vastly improved - but even after several years' of OL sysadminning I still have problems in interpreting them. In many cases, if it hadn't been for this list I'd still be completely at sea.
Would it be possible to help me get out of the sea ?
I'm sure that most people here are here who do help, are here because they want to help. But you have to do as the ones who can make (almost) everything work advise.
Best,
--Tonni
Tony Earnshaw wrote:
Some of the tests do run but some do not and I can't really understand the reason. I am using the rpms provided by Buchan on RHEL 3 U9. I can start slapd with any configuration which means (I think) that the binaries are fine.
Unless all the tests pass you have a duff product. Reading the test logs produced by tests that fail should help, but the log level is pretty high and needs some parsing.
That was probably intended, I never questioned the default loglevel of tests. Personally, I often run tests with SLAP_DEBUG set to the loglevel I prefer, usually just "stats". It helps pointing out real trouble, and then re-running with more verbose loglevel allows to get a deeper insight into issues. Unfortunately there's no level that's good for any test. In some cases, adding "stats2" may be important; in other cases, "config" is the real killer, as many small misconfigurations, which are valid for the parser but produce unintended results may slip in.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
On Wednesday 05 September 2007 13:01:38 Taymour A. El Erian wrote:
Tony Earnshaw wrote:
Taymour A. El Erian skrev, on 05-09-2007 08:13:
[...]
The test scripts are not running on my machine as they fail in the middle, so am unable to actually find the configuration. I tried using the configuration which has chain in its name but it does not work.
You can quite easily inspect the script to see which configuration file it is using, or start the specific test, e.g.:
./run test002
If it fails, you will still have all the configs for that test.
Then for some reason your build has failed and you have a useless installation. Until you can get a build whereby all tests pass, you might as well give up.
Some of the tests do run but some do not and I can't really understand the reason. I am using the rpms provided by Buchan on RHEL 3 U9.
My packages run full test suite during build (I don't upload them if they don't). From 2.3.38-1, the separate openldap2.3-tests package contains the test suite packaged such that any user can run the full test suite as follows:
$ export TMPDIR=/tmp #if not set for some reason $ cd /usr/share/openldap2.3/tests $ make tests
(there may be a missing symlink in the /usr/share/openldap2.3/tests directory ... I am not sure if I fixed it).
I haven't tested this on RHEL3 (as I don't have a spare server or VM for that), but there's almost no difference between the RHEL3 and RHEL4 packages, and I did test this on the RHEL4 packages.
There were some really really minor issues with some replacements that had been done in the defines.sh in packages prior to 2.3.38, but you could fix them yourself in 30 seconds.
I can start slapd with any configuration which means (I think) that the binaries are fine.
[...]
The docs of openldap are really not clear
Yep, many have pointed this out in the past, and the docs *have* been vastly improved - but even after several years' of OL sysadminning I still have problems in interpreting them. In many cases, if it hadn't been for this list I'd still be completely at sea.
Would it be possible to help me get out of the sea ?
There are some basic skills you seem to be missing here. There isn't any detailed document of how the test suite works, but it is obvious enough how it works (by reading the few shell scripts that do most of the work) that I have been able to repackage it so it can be run on an installed system (as opposed to just inside the build directory). You should be able to follow the logic, see how to run one script, get a configuration example from the test suite.
No one is going to waste their time writing documentation on how to interpret the shell script.
Regards, Buchan
Tony Earnshaw wrote:
Taymour A. El Erian skrev, on 05-09-2007 08:13:
[...]
The test scripts are not running on my machine as they fail in the middle, so am unable to actually find the configuration. I tried using the configuration which has chain in its name but it does not work.
Then for some reason your build has failed and you have a useless installation. Until you can get a build whereby all tests pass, you might as well give up.
[...]
The docs of openldap are really not clear
Yep, many have pointed this out in the past, and the docs *have* been vastly improved - but even after several years' of OL sysadminning I still have problems in interpreting them. In many cases, if it hadn't been for this list I'd still be completely at sea.
And did you not take a note of missing.lackign information and inform us of what you like to see?
You can download 2.4.5 beta as of today and see the new docs for yourself (they are still wip).
As always, this is a community effort, so please reply with a list of "I'd love to see in the docs"
There's nothing I hate more than people using community developed software, complaining and not contributing.
Gavin.
Gavin Henry skrev, on 05-09-2007 16:58:
[...]
And did you not take a note of missing.lackign information and inform us of what you like to see?
Nope, like all others I attempt to puzzle it out for myself. Enough people have posted about lacking stuff, I get by perfectly well with what there is and this list (as I wrote). Sometimes I get into knots (see other threads), but, being a trout fisherman, I can usually untie these myself. Where I need someone else's help in untying I ask for help.
Do you see many posts on this list from me asking for help?
You can download 2.4.5 beta as of today and see the new docs for yourself (they are still wip).
I'll try that. "wip" is presumably ""Work In Progress", rather than the Dutch slang "wip" (which is something you probably didn't intend)?
As always, this is a community effort, so please reply with a list of "I'd love to see in the docs"
There's nothing I hate more than people using community developed software, complaining and not contributing.
I never complained, that was someone else. Nuff said ...
--Tonni
<quote who="Tony Earnshaw">
Gavin Henry skrev, on 05-09-2007 16:58:
[...]
And did you not take a note of missing.lackign information and inform us of what you like to see?
Nope, like all others I attempt to puzzle it out for myself. Enough people have posted about lacking stuff, I get by perfectly well with what there is and this list (as I wrote). Sometimes I get into knots (see other threads), but, being a trout fisherman, I can usually untie these myself. Where I need someone else's help in untying I ask for help.
Understood.
Do you see many posts on this list from me asking for help?
Some, not many.
You can download 2.4.5 beta as of today and see the new docs for yourself (they are still wip).
I'll try that. "wip" is presumably ""Work In Progress", rather than the Dutch slang "wip" (which is something you probably didn't intend)?
The former ;-)
As always, this is a community effort, so please reply with a list of "I'd love to see in the docs"
There's nothing I hate more than people using community developed software, complaining and not contributing.
I never complained, that was someone else. Nuff said ...
Agreed. "There's nothing to see here. Move along now.."
Cheers.
--Tonni
-- Tony Earnshaw Email: tonni at hetnet dot nl
On Tue, Sep 04, 2007 at 09:16:22AM +0300, Taymour A. El Erian wrote:
Hi,
I am trying to install openldap 2.3 to work as automatic referral chasing where all update queries should be automatically directed to my master server, I would really appreciate a sample config. The details: I need to setup a master server and a replica, and put both of them behind a load balancer. In case a write operations is sent to the slave, I need the slave to direct the client to the master server rather than having the client chase referrals manually.
Rather than enter the discussion fray of lack of documentation in OpenLdap, I thought I would publish my solution to this common question. My environment is one master server and three syncrepl slaves. All these machines are running Openldap 2.3.27 (stable) now, but I plan to upgrade them to 2.3.38 (stable) very soon. Our requirement also includes TLS.
If you have this environment or something similar, you can make this work very easily with some simple and short changes to the replicas slapd.conf files. You do NOT need to change the master's slapd.conf
On each replica, add this near the top of the file (global), before any database definitions:
----------------------------------------------------------------------- overlay chain chain-uri ldap://ldapmaster.example.com chain-idassert-bind bindmethod=simple binddn="cn=Manager,dc=example,dc=com" credentials=<secret> mode=self chain-tls start chain-idassert-authzFrom "*" -----------------------------------------------------------------------
You will also need an 'updateref' statement. Mine looks like this just after the syncrepl stanza:
----------------------------------------------------------------------- updateref ldap://ldapmaster.example.com/ -----------------------------------------------------------------------
Note that I need the chain-tls statement to enable TLS from the slave to the ldap master. The chain-idassert-authzFrom statement will assert the identity of whatever bound dn on the slave is making the update request. Our DITs are exactly the same between these machines so whatever user bound to the slave will also exist on the master. If that DN does not have permissions to update an attribute on the master it won't happen, otherwise it will.
You will need to restart the slave after these changes. Then, if you are using loglevel 256 you can monitor an ldapmodify by tail -f on both the slave slapd.log and the master slapd.log
Now start an ldapmodify on the slave and watch the logs. I get something like this on the slave:
Sep 6 09:27:25 slave1 slapd[29274]: conn=11 fd=31 ACCEPT from IP=143.199.102.216:45181 (IP=143.199.102.216:389) Sep 6 09:27:25 slave1 slapd[29274]: conn=11 op=0 STARTTLS Sep 6 09:27:25 slave1 slapd[29274]: conn=11 op=0 RESULT oid= err=0 text= Sep 6 09:27:25 slave1 slapd[29274]: conn=11 fd=31 TLS established tls_ssf=256 ssf=256 Sep 6 09:27:28 slave1 slapd[29274]: conn=11 op=1 BIND dn="uid=user1,ou=people,dc=example,dc=com" method=128 Sep 6 09:27:28 slave1 slapd[29274]: conn=11 op=1 BIND dn="uid=user1,ou=People,dc=example,dc=com" mech=SIMPLE ssf=0 Sep 6 09:27:28 slave1 slapd[29274]: conn=11 op=1 RESULT tag=97 err=0 text= Sep 6 09:27:28 slave1 slapd[29274]: conn=11 op=2 MOD dn="uid=user1,ou=People,dc=example,dc=com" Sep 6 09:27:28 slave1 slapd[29274]: conn=11 op=2 MOD attr=mail Sep 6 09:27:28 slave1 slapd[29274]: conn=11 op=2 RESULT tag=103 err=0 text= Sep 6 09:27:28 slave1 slapd[29274]: conn=11 op=3 UNBIND Sep 6 09:27:28 slave1 slapd[29274]: conn=11 fd=31 closed Sep 6 09:27:28 slave1 slapd[29274]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Sep 6 09:27:28 slave1 slapd[29274]: syncrepl_entry: be_search (0) Sep 6 09:27:28 slave1 slapd[29274]: syncrepl_entry: uid=user1,ou=People,dc=example,dc=com Sep 6 09:27:28 slave1 slapd[29274]: syncrepl_entry: be_modify (0)
And on the master I see this:
Sep 6 09:23:57 ldapmaster slapd[2961]: conn=55902 op=3 PROXYAUTHZ dn="uid=user1,ou=people,dc=example,dc=com" Sep 6 09:23:57 ldapmaster slapd[2961]: conn=55902 op=3 MOD dn="uid=user1,ou=People,dc=example,dc=com" Sep 6 09:23:57 ldapmaster slapd[2961]: conn=55902 op=3 MOD attr=mail Sep 6 09:23:57 ldapmaster slapd[2961]: conn=55902 op=3 RESULT tag=103 err=0 text=
Note the PROXYAUTHZ line on the master indicating the proper identity assertion for the update on the master. Also note the slave immediately receiving the syncrepl update from the master.
I hope this helps at least some folks out there who need to set this up.
I will add this content to the OpenLdap software faq in order to contribute at least a little bit to the documentation.
Jim Schultz wrote:
I will add this content to the OpenLdap software faq in order to contribute at least a little bit to the documentation.
The above sounds basically correct. Perhaps you could coordinate with Gavin in contributing it directly into the admin guide. This topic belongs to both replication and chaining, so I'd leave him any editing choice. I'd just add that you may want to add
chain-return-error TRUE
in fact, by default, if chaining fails, the original referral is returned to the client, under the assumption that the client might want to try different measures to reach its goal. With this statement, if chaining fails at the provider's side, the actual error is returned to the client.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
<quote who="Pierangelo Masarati">
Jim Schultz wrote:
I will add this content to the OpenLdap software faq in order to contribute at least a little bit to the documentation.
The above sounds basically correct. Perhaps you could coordinate with Gavin in contributing it directly into the admin guide. This topic belongs to both replication and chaining, so I'd leave him any editing choice. I'd just add that you may want to add
I've already taken a copy. This brings me to adding an "Aknowlegdements" section or similar for tracking this.
I'll add a new Appendix.
Yes, in the Chaining overlay section and a discussion with a pointer in the replication section back to it.
chain-return-error TRUE
in fact, by default, if chaining fails, the original referral is returned to the client, under the assumption that the client might want to try different measures to reach its goal. With this statement, if chaining fails at the provider's side, the actual error is returned to the client.
Shall we update the man page regarding re-assert bind etc.?
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it
This is now in the OpenLdap software FAQ as: http://www.openldap.org/faq/data/cache/1425.html
-Jim Schultz
On Thu, Sep 06, 2007 at 06:17:47PM +0100, Gavin Henry wrote:
<quote who="Pierangelo Masarati"> > Jim Schultz wrote: > >> I will add this content to the OpenLdap software faq in order to >> contribute >> at least a little bit to the documentation. > > The above sounds basically correct. Perhaps you could coordinate with > Gavin in contributing it directly into the admin guide. This topic > belongs to both replication and chaining, so I'd leave him any editing > choice. I'd just add that you may want to add
I've already taken a copy. This brings me to adding an "Aknowlegdements" section or similar for tracking this.
I'll add a new Appendix.
Yes, in the Chaining overlay section and a discussion with a pointer in the replication section back to it.
chain-return-error TRUE
in fact, by default, if chaining fails, the original referral is returned to the client, under the assumption that the client might want to try different measures to reach its goal. With this statement, if chaining fails at the provider's side, the actual error is returned to the client.
Shall we update the man page regarding re-assert bind etc.?
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it
Thanks Pierangelo,
I will add the 'chain-return-error TRUE' as soon as it is available in the current 2.3 'stable' release ;-)
Jim-
On Thu, Sep 06, 2007 at 06:33:42PM +0200, Pierangelo Masarati wrote:
Jim Schultz wrote:
I will add this content to the OpenLdap software faq in order to contribute at least a little bit to the documentation.
The above sounds basically correct. Perhaps you could coordinate with Gavin in contributing it directly into the admin guide. This topic belongs to both replication and chaining, so I'd leave him any editing choice. I'd just add that you may want to add
chain-return-error TRUE
in fact, by default, if chaining fails, the original referral is returned to the client, under the assumption that the client might want to try different measures to reach its goal. With this statement, if chaining fails at the provider's side, the actual error is returned to the client.
Jim Schultz wrote:
I will add the 'chain-return-error TRUE' as soon as it is available in the current 2.3 'stable' release ;-)
It's there since 2.3.33; only the man page slipped thru, sorry. Probably because man page updates were not considered a priority in re23 as it's feature frozen, while this was indeed a new feature.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
<quote who="Pierangelo Masarati">
Jim Schultz wrote:
I will add the 'chain-return-error TRUE' as soon as it is available in the current 2.3 'stable' release ;-)
It's there since 2.3.33; only the man page slipped thru, sorry. Probably because man page updates were not considered a priority in re23 as it's feature frozen, while this was indeed a new feature.
Latest version of docs, with Jim's FAQ added:
http://suretec.org/our_docs/overlays.html#Chaining
Thanks.
Gavin Henry wrote:
I will add the 'chain-return-error TRUE' as soon as it is available in the current 2.3 'stable' release ;-)
It's there since 2.3.33; only the man page slipped thru, sorry. Probably because man page updates were not considered a priority in re23 as it's feature frozen, while this was indeed a new feature.
Latest version of docs, with Jim's FAQ added:
http://suretec.org/our_docs/overlays.html#Chaining
Thanks Gavin. Quick note: probably in this case chain-idassert-authzFrom "*" is not appropriate, because the consumer should only return referrals on write, and the above statement would allow to chain anonymous modifications, which the provider will likely reject. Although this does not break security or anything like that, it seems to add a needless round trip for a definitely incorrect operation, unless someone explicitly allows anonymous modifications. I wouldn't put this in a (basic) example, though.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
<quote who="Pierangelo Masarati">
Gavin Henry wrote:
I will add the 'chain-return-error TRUE' as soon as it is available in the current 2.3 'stable' release ;-)
It's there since 2.3.33; only the man page slipped thru, sorry. Probably because man page updates were not considered a priority in re23 as it's feature frozen, while this was indeed a new feature.
Latest version of docs, with Jim's FAQ added:
http://suretec.org/our_docs/overlays.html#ChainingThanks Gavin. Quick note: probably in this case chain-idassert-authzFrom "*" is not appropriate, because the consumer should only return referrals on write, and the above statement would allow to chain anonymous modifications, which the provider will likely reject. Although this does not break security or anything like that, it seems to add a needless round trip for a definitely incorrect operation, unless someone explicitly allows anonymous modifications. I wouldn't put this in a (basic) example, though.
Removed and link above updated.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it
Gavin Henry wrote:
Removed and link above updated.
I have more comments :). It would be worth stressing that the client will be notified about a successful modification as soon as the producer replies to the consumer's chain overlay. But there might be a time lag between the success notification to the client and the successful completion of the replication, if ever, so an immediate lookup at the consumer's side of the data whose modification was successfully notified could result in a temporary inconsistency, until replication is over.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
<quote who="Pierangelo Masarati">
Gavin Henry wrote:
Removed and link above updated.
I have more comments :). It would be worth stressing that the client will be notified about a successful modification as soon as the producer replies to the consumer's chain overlay. But there might be a time lag between the success notification to the client and the successful completion of the replication, if ever, so an immediate lookup at the consumer's side of the data whose modification was successfully notified could result in a temporary inconsistency, until replication is over.
I'll discuss this in the replication section when I organise the section better.
I'll also mention the overlay somehow in the firewall section, as a client could be blocked trying to handle referrals, so we can advise to use this technique instead. Pretty handy, as you can then hide your master anywhere!
Jim Schultz wrote:
Rather than enter the discussion fray of lack of documentation in OpenLdap, I thought I would publish my solution to this common question. My environment is one master server and three syncrepl slaves. All these machines are running Openldap 2.3.27 (stable) now, but I plan to upgrade them to 2.3.38 (stable) very soon. Our requirement also includes TLS.
do they have to be syncrepl slaves, if slurpd is used what changes are necessary.
is there a good slurpd to syncrepl migration howto? If not would you consider a similar submission?
Regards,
Rob
Robert Brooks wrote:
Jim Schultz wrote:
Rather than enter the discussion fray of lack of documentation in OpenLdap, I thought I would publish my solution to this common question. My environment is one master server and three syncrepl slaves. All these machines are running Openldap 2.3.27 (stable) now, but I plan to upgrade them to 2.3.38 (stable) very soon. Our requirement also includes TLS.
do they have to be syncrepl slaves, if slurpd is used what changes are necessary.
is there a good slurpd to syncrepl migration howto? If not would you consider a similar submission?
We always welcome contributions. Feel free to submit somethign via out ITS; http://www.openldap.org/its/ in any format.
Thanks,
Gavin.
openldap-software@openldap.org
-
Buchan Milne -
Dave Horsfall -
Gavin Henry -
Gavin Henry -
Jim Schultz -
Karsten Künne -
Pierangelo Masarati -
Robert Brooks -
Taymour A. El Erian -
Toby Blake -
Tony Earnshaw