Yes, I have been using the Net::LDAP lib quite abit...

What I am most interested in is the LDAP replication feature.

Here's what I currently have:

As stated by Netscape "Replication is the mechanism by which directory data is automatically copied from one directory server to another. Using replication, you can copy everything from entire directory trees to individual directory entries between servers."

Once you have configured Netscape LDAP for replication, it updates the:

/usr/netscape/server4/slapd-Directory/changelogdb/log.00001

file every time an LDAP operation occurs.

By monitoring this file, I can trigger my event. But, this is not an optimal solution, because every time it changes, I have to make a changelog call such as the following:

$mesg = $ldap->search(
                       base => 'cn=changelog',
                             scope => 'sub',
                             filter => '(changetype=add)',
                             attrs => $attrs,
                             callback => &callback
                             );
[download]

And then parse the return to check for changes. This is CPU expensive.

The method I am looking for is a way for perl to emulate another LDAP database so that Netscape will automatically send replication updates to it, I would then trigger on only the updates I'm interested in.

I don't think that iDS uses a standard LDAP call to update its replicas. It transfers more data, like changelognumber and credentials, between the both servers. This means that you can't use an, for example, OpenLdap server as a consumer for an iDS supplier. If it had used standard LDAP calls, you should have been able to use a LDAP server from any vendor as a consumer, which you can't.

So you will not only need to emulate an iDS but also its Admin Server and the changelognumber transfering.

If your application uses the LDAP server in a normal way (i.e. >95% of the requests are reads) I would write a plug-in that triggers on SLAPI_PLUGIN_POST_MODIFY_FN operation and write the modified data to a file. You could run that plug-in on a dedicated consumer and have a perl deamon poll for changes to that file.

Just some thougths...

/brother t0mas

I would like to thank brother t0mas, and everyone who responded to my question. I looked into the Plug-in idea and I think this will work very well. I plan to implement a veriant of the suggested solution, I will have the plug-in write the info to a socket and setup a perl daemon to watch a specific port and trigger the event. This will allow it to field events from multiple LDAP instances. I will let you know how it turns out. -mlm

OK...As a follow up...I setup a prototype of the netscape plugin with a routine to send the add request info out a tcp port everytime an add operation occured, and a perl tcp server watching that port to trigger the event upon receiving data...And it worked great!!!...If anyone is interested in the code, I can mock up a simplified version of each and post them.

-mlm