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
"Brett @Google" brett.maxfield@gmail.com writes:
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".
You don't need a perl-backend, just create a ldapclient with Net::LDAP::Control::SyncRequest. Unfortunately RefreshAndPersist doesn't do what ist should do, so only RefreshOnly will work.
-Dieter
On Thu, Jan 28, 2010 at 5:31 AM, Dieter Kluenter dieter@dkluenter.dewrote:
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".
You don't need a perl-backend, just create a ldapclient with Net::LDAP::Control::SyncRequest. Unfortunately RefreshAndPersist doesn't do what ist should do, so only RefreshOnly will work.
Hmm.. so how do you set the rid in this case ?
If the inial value of the cookie is "" when creating Net::LDAP::Control::SyncRequest then the server must create the actual cookie value?
Also if using this approach, i presume the server will need to create a contextCSN, how does the perl client tell the ldap server the rid to use in the contextCSN ?
I can't see any mention of anything like a rid parameter on the perl client side.
Cheers Brett
Brett @Google wrote:
On Thu, Jan 28, 2010 at 5:31 AM, Dieter Kluenter <dieter@dkluenter.de mailto:dieter@dkluenter.de> wrote:
> 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". You don't need a perl-backend, just create a ldapclient with Net::LDAP::Control::SyncRequest. Unfortunately RefreshAndPersist doesn't do what ist should do, so only RefreshOnly will work.Hmm.. so how do you set the rid in this case ?
If the inial value of the cookie is "" when creating Net::LDAP::Control::SyncRequest then the server must create the actual cookie value?
Also if using this approach, i presume the server will need to create a contextCSN, how does the perl client tell the ldap server the rid to use in the contextCSN ?
I can't see any mention of anything like a rid parameter on the perl client side.
providers don't care about RIDs. They are solely a convenience mechanism used to give unique handles to each syncrepl config in a consumer.
CSNs do not contain RIDs.
Am Donnerstag, den 28.01.2010, 21:00 +1000 schrieb Brett @Google:
On Thu, Jan 28, 2010 at 5:31 AM, Dieter Kluenter dieter@dkluenter.de wrote:
> 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". You don't need a perl-backend, just create a ldapclient with Net::LDAP::Control::SyncRequest. Unfortunately RefreshAndPersist doesn't do what ist should do, so only RefreshOnly will work.Hmm.. so how do you set the rid in this case ?
If the inial value of the cookie is "" when creating Net::LDAP::Control::SyncRequest then the server must create the actual cookie value?
Also if using this approach, i presume the server will need to create a contextCSN, how does the perl client tell the ldap server the rid to use in the contextCSN ?
I can't see any mention of anything like a rid parameter on the perl client side.
The cookie contains rid and contextcsn
my $cookie = 'rid=123,csn=20100111155236.576336Z#000000#000#000000';
my $req = Net::LDAP::Control::SyncRequest->new( mode => LDAP_SYNC_REFRESH_ONLY, critical => 'TRUE', cookie => "$cookie" );
my $mesg = $ldap->search( base => "$base", scope => "$scope", control => [ $req ], callback => &searchCallback, filter => "$filter", attrs => ["$attrs[0]","$attrs[1]" ] );
-Dieter
openldap-software@openldap.org
-
Brett ＠Google -
Dieter Kluenter -
Dieter Klünter
-
Howard Chu