[Pdns-users] LDAP backend notify capability

[Norbert Sendetzky]

On Saturday 25 June 2005 13:54, Fabian Fagerholm wrote:
> I've done some thinking and some digging. As you say, one option is to
> regularly scan for changes, which is of course an ugly way. And you
> rightly imply that the elegant and "correct" solution would be to have
> the LDAP server notify the client of a change.
>
> LDAP Persistent Search, an expired draft (?)
> http://www.mozilla.org/directory/ietf-docs/draft-smith-psearch-ldap-01.txt
> http://nimbus.ocis.temple.edu/ldap/controls.htm#2850472

It describes what we would need but it never made it into an official RFC and 
thus will not be implemented into a LDAP server.

> LDAP Client Update Protocol (LCUP), which has progressed into RFC3928:
> http://www.ietf.org/rfc/rfc3928.txt

Seems more complex than the first one but would also do the job. It is an RFC 
but not yet implemented - at least not in OpenLDAP. Up to now (looking at 
Debian Sarge's libldap2-dev) only server side sorting and virtual list 
controls are available.

> Things seemed to clear up when reading the OpenLDAP Administrator's
> Guide, particularly chapter 15 (LDAP Sync Replication) and some ideas
> from chapter 16 (The Proxy Cache Engine). What if the Pdns LDAP backend
> would cache the search result and receive a notification using the
> methods described in this document? First I thought it would be OpenLDAP
> specific, but it seems to relate to RFC3928 and RFC3384 and other
> published material, and thus there are probably other LDAP servers that
> implement it.

I haven't found any references to the RFCs you mention in the OpenLDAP 
Administrators Guide, so I have to consider the OpenLDAP Sync Replication 
proprietary which renders it useless against other implementations.

Furthermore I doubt that caching all LDAP entries in the backend would be a 
good idea. It means that you would create a slave LDAP server (instead of a 
client today) and if I think about installations with several million DNS 
entries, it makes me a little bit scary.

> Another option would be to use Sync Replication to just receive the
> notification from the LDAP server and otherwise operate as now, but I
> think that would not be taking full advantage of the features provided.

The implementation would be easier (but still not easy, because the PDNS LDAP 
backend has then to act as server) to just receive modified entries as 
notifications if the different LDAP server implementations would support the 
same replication protocol. I doubt that you can use an OpenLDAP master to 
replicate to an eDirectory slave.

> Norbert, what do you think?

The easiest and most elegant way would be to wait until LCUP will be 
implemented into the LDAP servers. Otherwise, maybe I am terribly wrong and 
you are right ;-)

Nevertheless, thank you very much for the overview of possibilities. It is 
always very interesting to me to learn new things (LCUP), to see new 
possibilities of doing the job and to discuss alternative ideas. This make me 
confident that the coding was not done in vain :-)

Everybody should feel free to join the discussion and to express different 
opinions.

Thanks a lot


Norbert
-- 
OpenPGP public key
http://www.linuxnetworks.de/norbert.pubkey.asc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20050626/bdca4eac/attachment-0001.sig>