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.