On 8/10/2010 6:16 μμ, Buchan Milne wrote: > On Thursday, 7 October 2010 20:32:49 Nick Milas wrote: >> It all started for me when I wanted to watch a serial number value from >> an ldap-stored SOArecord (using powerdns with openldap backend) and when >> it changes to fire a bash script. I reached the conclusion it was not >> easy to be done with higher-level means within openldap and I created a >> bash script which scans (using ldapsearch and other linux tools) the >> SOArecords regularly (using cron) to find out if any change has happend >> and do whatever is required. It would be much more elegant if I could >> get a trigger from openldap when the SOArecord changes. > Maybe you need this: > > http://memberwebs.com/stef/software/slapi-dnsnotify/ > > A more generic solution would be nice, but as far as I can tell, this software > satisfies your current need. > > Regards, > Buchan > After more than seven months (when I started this thread), and having tried slapi-dnsnotify in the meantime, please allow me to request if any progress would by any chance be expected any time soon re. the preparation of a draft for LDAP Triggers (, stored procedures and views), and its implementation in OpenLDAP.

On 23/5/2011 7:35 πμ, Howard Chu wrote: > > The recommended approach now is to use back-sock as an overlay and > pass all notifications to an external service. This provides isolation > so that whatever actions are triggered by the notification will not > interfere with normal slapd processing.

Thanks. Has anyone developed a generic back-sock application as an overlay to "detect" attribute changes and pass notifications in a meaningful way to an external service, so that they can be handled?

On 23/5/2011 1:41 ??, Howard Chu wrote: > Look before you ask. The code is in HEAD and there's a sample perl > script provided. I feel embarrassed to ask, and excuse me for my ignorance, but, what is HEAD?

On Sun, 22 May 2011 21:35:39 -0700 Howard Chu<hyc(a)symas.com> wrote: > The recommended approach now is to use back-sock as an overlay and pass all > notifications to an external service. This sounds like just what the doctor ordered for me too. But I can't seem to find any directions in the docs for how to set up back-sock as an overlay. Sorry to be such a gormless n00b, but if someone could point me to the right man page or an example setup, I'd be most humbly grateful.

On Sun, 22 May 2011 21:35:39 -0700 Howard Chu <hyc(a)symas.com&gt; wrote: > The recommended approach now is to use back-sock as an overlay and pass > all notifications to an external service. This sounds like just what the doctor ordered for me too. But I can't seem to find any directions in the docs for how to set up back-sock as an overlay. Sorry to be such a gormless n00b, but if someone could point me to the right man page or an example setup, I'd be most humbly grateful.

On 8/10/2010 6:16 μμ, Buchan Milne wrote: > On Thursday, 7 October 2010 20:32:49 Nick Milas wrote: >> It all started for me when I wanted to watch a serial number value from >> an ldap-stored SOArecord (using powerdns with openldap backend) and when >> it changes to fire a bash script. I reached the conclusion it was not >> easy to be done with higher-level means within openldap and I created a >> bash script which scans (using ldapsearch and other linux tools) the >> SOArecords regularly (using cron) to find out if any change has happend >> and do whatever is required. It would be much more elegant if I could >> get a trigger from openldap when the SOArecord changes. > > Maybe you need this: > > http://memberwebs.com/stef/software/slapi-dnsnotify/ > > A more generic solution would be nice, but as far as I can tell, this > software satisfies your current need. > > Regards, > Buchan After more than seven months (when I started this thread), and having tried slapi-dnsnotify in the meantime, please allow me to request if any progress would by any chance be expected any time soon re. the preparation of a draft for LDAP Triggers (, stored procedures and views), and its implementation in OpenLDAP. It is interesting that, although the reaction since the 1st International Conference on LDAP in Cologne (Sep. 2007) and even earlier towards the idea of adding triggers, views, and stored procedures to LDAP (starting perhaps from X.500) along with the proper tooling was very positive, no serious progress seems to have been made to standardize these important constructs in the LDAP framework at least as an initial draft which would serve as a feasible starting point. Maybe we can hope to something more mature to have been prepared for LDAPCon 2011? Is there any active work inside the OpenLDAP project and across the LDAP industry to that end? By the way, the problem with slapi-dnsnotify is that, although it works as documented with OpenLDAP (which is great), it doesn't offer a degree of flexibility: it sends notify to all NS of the zone (even to itself!); but, what if we want to send notify to other servers too (e.g. hidden slaves) and we do not want to send notify messages to some of the NS of the zone (because replication is done at the backend level)? Thanks, Nick

On 23/5/2011 9:20 μμ, Maarten Vanraes wrote: > this may be totally besides the point or request, but i've made a very > simple > modtrigger overlay, which triggers modifications and calls an external > command. > > I should make it cn=config ready, but it works, is fully tested, and i'm > using it in a production environment... It's exactly to the point! I would surely be interested in trying it! Is it available for download (with basic directions)? Thanks for letting us know, Nick

On 23/5/2011 10:07 μμ, Maarten Vanraes wrote: > Well, i haven't had any time yet of cleaning it up, and atm it doesn't > even > say yet WHAT exactly was modified, but i was planning on doing that, > together with the cn=config adaptation, and put it somewhere for > download (and since i'm a Mageia packager probably package it for > mageia). > > i can probably give you it privately, if you're urgently insterested. Thanks Maarten, Quite nice of you. Actually, I am not in a panic (thankfully); additionally I am not a developer, so it would not be easy for me to work on it, even if I would surely have uses for it. Thinking from an admin's point of view, I look forward to something that would be usable, safe and (at least) a bit flexible, hopefully without resorting to (anything more than very basic high-level) programming. I would think that for such an overlay to be generic enough, it should be able to accept a config on what attribute(s) we want to monitor (whose change will trigger an event), and then provide a notification with (probably the initial and) the new value of the attribute and call an external command (using back-sock?). [It could also be extended to allow the definition of filters to narrow the monitoring range, if needed.] Such an overlay, I humbly believe, would be a valuable addition to openldap standard collection of overlays. All the best, Nick

in my case, atm, i handle stuff via the shell script and decide if i do something for this modified DN or not.