Hello,

I am trying to find a way to drive a perl backend to receive changes from a
master.

Assume we have something like :

include /usr/local/openldap/etc/openldap/schema/core.schema
include /usr/local/openldap/etc/openldap/schema/cosine.schema
include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema

pidfile         /data/openldap/run/slapd_log.pid
argsfile        /data/openldap/run/slapd_log.args

database        perl
suffix          "dc=example,dc=com"
rootdn          "cn=admin, dc=example, dc=com"
rootpw          <mypass>

# log example module
perlModulePath  /usr/local/perl-lib
perlModule      MyPerlModule

loglevel 256

Which is pretty straightforward. In the ye olde days of 2.3.x there was
slurp, you could point a slurp at the above slap instance, and you could
perform custom perl code when changes were pushed incrementally to it by
slurp replication. It would appear that since syncrepl, as responsibility
for replication replication has moved from the server to the client, having
a somewhat "dumb" client now is not so easy.

It would appear out of the box that there is no (trivial) way with syncrepl
to push delta changes after a given epoch, towards a perl backend under
2.4.x ?

Slurp used to be able to push add/modify/delete operations, to a perl or
shell backend which could then "snoop" for interesting information.

Doing the same for syncrepl would seem to require maintainance of a full
syncrepl state (or replica), in order for a perl/shell backend to snoop for
interesting changes.

Anyone got any thoughts on this ?

Is there a way of getting syncrepl to emit simple add/modify/delete changes
(ala slurp-like) to a perl backend, without the prerequisite present search
?

Or maybe the perl backend in question would need to "fake" or pass through
syncrepl searches and responses, well enough to force syncrepl to either
always perform the prerequisite change, and/or perhaps only call the
add/modify/delete in the perl backend for leaf objects or other objects of
interest, maybe given a particular time epoch or starting date/time ?

Being able to call a perl (threaded) or shell backend (unthreaded) for
changes is a useful ability which seems to have apparently been lost in the
upgrade from 2.3.x to 2.4.x ??

The 2.4.x series seems to require a perl backend to require knowledge of
syncrepl, even if it's pushing to a perl backend on another server via a
"standalone ldap proxy".

Cheers
Brett

Reply via email to