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

[Andy Dorman]

On 07/29/2014 04:46 PM, Andy Dorman wrote:
> 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?
>

Another data point... information from the OpenLDAP team confirms what I 
think we all suspected... php-ldap does not implement the dontusecopy 
control.

And even if php-ldap DID support passing dontusecopy to LDAP for a "get" 
command so it could read from the Master/write server, Turba would have 
to be modified to set dontusecopy when it does the get after adding a 
contact.

So it looks to me like we are going to want to modify Horde/Turba no 
matter which way we go....and waiting until php-ldap is updated to 
support the dontusecopy control is not going to work for us.

So unless someone else has another idea, Jan, what would be the next 
step in adding the separate write/read LDAP servers feature for Turba?

-- 
Andy Dorman