[horde] Using separate LDAP write and read servers for Turba

[Andy Dorman]

On 07/29/2014 10:49 AM, A. Schulze wrote:
>
> Andy Dorman:
>> Well I am not having any luck so far...
>
> Andy,
>
> I have no syncrepl setup running here so I could not test. But in theory
> a ldapclient trying to write to a syncreplica should honor the update url.
> You may first try to prove that function without horde but by using
> simply ldapmodify.
>
> If that works I expect php ldap should work too. If not, open a
> bugreport for php-ldap.
>
> Andreas
>

Andreas, thanks again for the ideas.

I am beginning to see why the Horde developers probably thought it 
easier to use separate read-write servers than try and work through 
php-ldap with updateref.  ;-)

I have gotten it working...partially.

While researching the updateref directive, I ran across the chain 
overlay http://www.openldap.org/doc/admin24/overlays.html#Chaining

I tested the following setup in our test slave server:

...
moduleload            back_ldap
overlay               chain
chain-uri             ldap://ldap.mymasterserver.com/

chain-idassert-bind   bindmethod="simple"
                       binddn="cn=Manager,dc=example,dc=com"
                       credentials="<secretadminpwd>"
                       mode="self"
chain-return-error    TRUE
...

and restarted our slave server and it worked...almost.

The problem comes when the client tries to get the address that it just 
added.  The get fails because it tries to read from localhost, but the 
replication had not had enough time to replicate the new address from 
the master so you get:

Read failed: (32) No such object

1. Turba_Form_AddContact->execute() /usr/share/horde/turba/add.php:68
2. Turba_Driver->getObject() 
/usr/share/horde/turba/lib/Form/AddContact.php:87
3. Turba_Driver->getObjects() /usr/share/horde/turba/lib/Driver.php:869
4. Turba_Driver_Ldap->_read() /usr/share/horde/turba/lib/Driver.php:833

A few seconds later I was able to confirm the address was in the 
replica's address book.

FWIW, I also tried your suggestion of using ldapmodify to test it by 
replacing the cn of my test address.  I found that the simple updateref 
directive for openLDAP did not work...I got this response:

replace cn:
	Andy
modifying entry "uid=andydorman at comehome.net,ou=addresses,o=antespam.com"
ldap_modify: Referral (10)
	referrals:
	 
ldap://ldap.ironicdesign.com/uid=andydorman@comehome.net,ou=addresses,o=antespam.com

but the cn did NOT change on either the master or the slave.  When I 
added the chain overlay, ldapmodify DID work on the master instantly and 
the slave, after a second or so delay.

It is also interesting to note that openLDAP had a note in their 
chain-overlay docs about this very problem.

"Occasionally, applications want to read back the data that they just 
wrote. If a modification requested to a shadow server was silently 
chained to its provider, an immediate read could result in receiving 
data not yet synchronized. In those cases, clients should use the 
dontusecopy control to ensure they are directed to the authoritative 
source for that piece of data."

However, Google did not find anything about a "dontusecopy" control that 
could be used with php-ldap.  The RFC 6171 about it is here:

http://tools.ietf.org/html/rfc6171

So it is looking like our options are:

1. Update php-ldap to somehow resolve this...but since I can't even get 
ldapmodify to work from the command line, I am not sure what to tell the 
folks at Zend.  I suppose they could implement the dontusecopy control 
for their client.

2. Modify Turba (and possibly Horde as well?) to support separate 
read-write LDAP hosts.

3. Modify Turba to not immediately try to read the new contact or to 
somehow deal with the fact that replicating the new contact to where it 
can be read is going to take a finite amount of time.  Since the switch 
between read & write server is happening outside of Horde & PHP, Horde 
can not just read the new record back from the master "write host".  BUT 
Horde COULD read back from the write host if option 2 happened.

Anyone see any other options?

-- 
Andy Dorman