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
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
Nick Milas wrote:
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.
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.
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?
Thanks again, Nick
Nick Milas wrote:
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?
Look before you ask. The code is in HEAD and there's a sample perl script provided.
Nick Milas writes:
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?
He means the Git repository's "master" branch, which is currently the main development branch. When we were using CVS, that branch was called HEAD.
On Sun, 22 May 2011 21:35:39 -0700 Howard Chu hyc@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.
Michael Smith wrote:
On Sun, 22 May 2011 21:35:39 -0700 Howard Chuhyc@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.
Read the slapd-sock(5) manpage in current git master.
On Mon, 23 May 2011 08:56:54 -0700 Howard Chu hyc@symas.com wrote:
Michael Smith wrote: 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.
Read the slapd-sock(5) manpage in current git master.
Many thanks for this and the other prompt and helpful responses.
--On May 23, 2011 11:39:59 AM -0400 Michael Smith mjs@smithbowen.net wrote:
On Sun, 22 May 2011 21:35:39 -0700 Howard Chu hyc@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.
Look at the example code supplied in that directory.
--Quanah
On 23/5/2011 6:57 μμ, Quanah Gibson-Mount wrote:
Look at the example code supplied in that directory.
Ahhh, so here it is!
Thanks guys for showing the path to a poor man lost in the dark. ;-)
I confess I am clueless when I enter the developers' hidden tracks!
Nick
Op zondag 22 mei 2011 13:34:14 schreef Nick Milas:
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
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...
Kind regards,
Maarten
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
Op maandag 23 mei 2011 20:44:05 schreef Nick Milas:
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
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.
Kind Regards,
Maarten
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
Op maandag 23 mei 2011 21:50:39 schreef Nick Milas:
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
it's not nearly that fancy: atm it does this:
- accept a configuration item that gives a command (in my case, a shell script) - it triggers this command via forking a execve call, ie: it calls that script, in the background - it passes the DN being modified - it passes the type of operation - it passes the old DN (MODRDN)
planned features: - cn=config handling - passing the attribute being modified (MODIFY)
possibly, i might pass all attributes and values of the modified DN
in my case, atm, i handle stuff via the shell script and decide if i do something for this modified DN or not.
Kind regards,
Maarten
On Mon, 23 May 2011 22:18:21 +0200 Maarten Vanraes maarten.vanraes@gmail.com wrote:
it's not nearly that fancy: atm it does this:
- accept a configuration item that gives a command (in my case, a shell script)
- it triggers this command via forking a execve call, ie: it calls that
script, in the background
- it passes the DN being modified
- it passes the type of operation
- it passes the old DN (MODRDN)
I would be interested in trying it out, Maarten, if you want another beta-tester.
On 23/5/2011 11:18 μμ, Maarten Vanraes wrote:
in my case, atm, i handle stuff via the shell script and decide if i do something for this modified DN or not.
Thanks Maarten,
When you think you are ready to allow others to have a look at it and test it, please be kind to give us a notice.
It sounds like a very interesting and flexible tool.
Without such a tool, one has no alternative than to use a cron job to scan the directory periodically for modifications of the required attributes (that's what I am currently doing). This works well in my case, because I have a relatively small DIT, but this method doesn't scale well (when you have thousands of entries to scan periodically), and I am thinking in a more global perspective than my own case.
Of course one could also use back-sock to develop something, as suggested, but I haven't looked at it yet in depth; the solution I am currently using is more straightforward to me. Yet, I am also looking at something that can become more formal, which, when approved and added to openldap standard distribution, will serve a whole group of developers by enabling a wide range of applications which require triggers (like, for example, PowerDNS Notify support ["Master" functionality] in the LDAP backend).
I feel we should contribute to the future of OpenLDAP and LDAP in general, adding our little piece, if we can. That's why I raised the issue of trigger mechanism standardization across the industry in a previous message.
All the best, Nick
openldap-technical@openldap.org