Hello,
I was wondering if there are any concrete examples of using syncrepl to monitor a slapd for changes, and perform some scripted operation if the monitored data changes. I can think of several cases where this might be very handy, where you want to run a script or custom business logic, on receipt of some data being changed.
I have seen some examples in the 2.3.x days, where slurpd was used to push changes to a back-perl script, which then did some custom business logic and it did fill an very useful niche. I imagine these post-slurp syncrepl days you could use the syncrepl protocol in a push mode via a proxy to push changes at a back-perl instance to the same sort of thing.
But perhaps using syncrepl directly might seem like a better option, as this has been touted as a benefit of syncrepl, although i have not seen any specific examples.. To this end, i am wondering are the syncrepl client parts of slapd usable outside the context of the slapd binary? Has anyone tried this and has any examle code they are willing to share ?
Cheers Brett
"Brett @Google" brett.maxfield@gmail.com writes:
Hello,
I was wondering if there are any concrete examples of using syncrepl to monitor a slapd for changes, and perform some scripted operation if the monitored data changes. I can think of several cases where this might be very handy, where you want to run a script or custom business logic, on receipt of some data being changed.
I have seen some examples in the 2.3.x days, where slurpd was used to push changes to a back-perl script, which then did some custom business logic and it did fill an very useful niche. I imagine these post-slurp syncrepl days you could use the syncrepl protocol in a push mode via a proxy to push changes at a back-perl instance to the same sort of thing.
But perhaps using syncrepl directly might seem like a better option, as this has been touted as a benefit of syncrepl, although i have not seen any specific examples.. To this end, i am wondering are the syncrepl client parts of slapd usable outside the context of the slapd binary? Has anyone tried this and has any examle code they are willing to share ?
A simple example is supplied by ldapsearch(1),
ldapsearch -E '!sync=rp' -b dc=example,dc=com
-Dieter
At Mon, 28 Sep 2009 01:39:32 +1000, Brett @Google wrote:
I was wondering if there are any concrete examples of using syncrepl to monitor a slapd for changes, and perform some scripted operation if the monitored data changes. I can think of several cases where this might be very handy, where you want to run a script or custom business logic, on receipt of some data being changed.
I have seen some examples in the 2.3.x days, where slurpd was used to push changes to a back-perl script, which then did some custom business logic and it did fill an very useful niche. I imagine these post-slurp syncrepl days you could use the syncrepl protocol in a push mode via a proxy to push changes at a back-perl instance to the same sort of thing.
But perhaps using syncrepl directly might seem like a better option, as this has been touted as a benefit of syncrepl, although i have not seen any specific examples.. To this end, i am wondering are the syncrepl client parts of slapd usable outside the context of the slapd binary? Has anyone tried this and has any examle code they are willing to share ?
I'm writing a syncrepl consumer Perl script to implement an LDAP->NIS gateway (WIP):
http://www.osstech.co.jp/download/fumiyas/ldap2nssfiles.pl
But I don't know this script (and Net::LDAP) has correct syncrepl consumer implementation or not because I'm a newbie of syncrepl implementation...
SATOH Fumiyasu fumiyas@osstech.jp writes:
At Mon, 28 Sep 2009 01:39:32 +1000, Brett @Google wrote:
[...]
I'm writing a syncrepl consumer Perl script to implement an LDAP->NIS gateway (WIP):
http://www.osstech.co.jp/download/fumiyas/ldap2nssfiles.pl
But I don't know this script (and Net::LDAP) has correct syncrepl consumer implementation or not because I'm a newbie of syncrepl implementation...
I have just written a working simple perl prototype: http://pastebin.de/276
-Dieter
On Mon, Sep 28, 2009 at 5:43 PM, Dieter Kluenter dieter@dkluenter.de wrote:
SATOH Fumiyasu fumiyas@osstech.jp writes:
At Mon, 28 Sep 2009 01:39:32 +1000, Brett @Google wrote:
[...]
I'm writing a syncrepl consumer Perl script to implement an LDAP->NIS gateway (WIP):
http://www.osstech.co.jp/download/fumiyas/ldap2nssfiles.pl
But I don't know this script (and Net::LDAP) has correct syncrepl consumer implementation or not because I'm a newbie of syncrepl implementation...
I have just written a working simple perl prototype: http://pastebin.de/276
Thank you both very much for your suggestions.
This would seem reasonable complexity wise, but i was wondering, is there any way to skip the refresh phase, other in just ignoring the objects, waiting for the persist stage ?
Sometimes you only care about new information. But i guess if your state cookie is stored persistently, then provided the database is not reloaded, you should only have a short refresh phase, say the next day, if you wait through the first long refresh time ?
For this purpose, i presume the rid=xx value only indicates a unique consumer of updates ?
So as long as you connect again using the same rid, the sync state will be preserved ?
Cheers Brett
Brett @Google wrote:
On Mon, Sep 28, 2009 at 5:43 PM, Dieter Kluenterdieter@dkluenter.de wrote:
SATOH Fumiyasufumiyas@osstech.jp writes:
At Mon, 28 Sep 2009 01:39:32 +1000, Brett @Google wrote:
[...]
I'm writing a syncrepl consumer Perl script to implement an LDAP->NIS gateway (WIP):
http://www.osstech.co.jp/download/fumiyas/ldap2nssfiles.pl
But I don't know this script (and Net::LDAP) has correct syncrepl consumer implementation or not because I'm a newbie of syncrepl implementation...
I have just written a working simple perl prototype: http://pastebin.de/276
Thank you both very much for your suggestions.
This would seem reasonable complexity wise, but i was wondering, is there any way to skip the refresh phase, other in just ignoring the objects, waiting for the persist stage ?
Just read the server's contextCSN and include it in the cookie when you send the actual sync search request.
"Brett @Google" brett.maxfield@gmail.com writes:
On Mon, Sep 28, 2009 at 5:43 PM, Dieter Kluenter dieter@dkluenter.de wrote:
SATOH Fumiyasu fumiyas@osstech.jp writes:
At Mon, 28 Sep 2009 01:39:32 +1000, Brett @Google wrote:
[...]
[...]
This would seem reasonable complexity wise, but i was wondering, is there any way to skip the refresh phase, other in just ignoring the objects, waiting for the persist stage ?
[...]
An example based on ldapsearch: ldapsearch -E'!sync=ro/rid=042,csn=20090928054615.449093Z#000000#000#000000' -H ldap://localhost -b dc=example,dc=com -s sub "*" +
As a result you either get a sync done control, that is no modification to the database control: 1.3.6.1.4.1.4203.1.9.1.3 false MIQAAAADAQH/ or you get a syncInfo, a sync state control, the modified entries and an new cookie.
-Dieter
On Sunday, 27 September 2009 16:39:32 Brett @Google wrote:
Hello,
I was wondering if there are any concrete examples of using syncrepl to monitor a slapd for changes, and perform some scripted operation if the monitored data changes. I can think of several cases where this might be very handy, where you want to run a script or custom business logic, on receipt of some data being changed.
I have seen some examples in the 2.3.x days, where slurpd was used to push changes to a back-perl script, which then did some custom business logic and it did fill an very useful niche. I imagine these post-slurp syncrepl days you could use the syncrepl protocol in a push mode via a proxy to push changes at a back-perl instance to the same sort of thing.
But perhaps using syncrepl directly might seem like a better option, as this has been touted as a benefit of syncrepl, although i have not seen any specific examples.. To this end, i am wondering are the syncrepl client parts of slapd usable outside the context of the slapd binary? Has anyone tried this and has any examle code they are willing to share ?
I used Net::LDAPapi's syncrepl support to do this. A few hundred line script is the integration between a qmail-ldap installation and a zimbra installation (most of the script is actually handling differences between the two systems; formats, e.g. catchalls, out of office settings etc.) until the provisioning system catches up to provision directly ...
If you need an example I may be able to send it to you off-list.
Regards, Buchan
openldap-technical@openldap.org
-
Brett ＠Google -
Buchan Milne -
Dieter Kluenter -
Howard Chu -
SATOH Fumiyasu