[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Automatic referral chasing
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
ITS UNIX Systems Architecture
Great-West Life & Annuity Insurance Co.
303-737-1818
email james.schultz@gwl.com