I was wondering is it possible to set a slapd syncprov consumer to trigger a script when it receives changes to the db (updates of specific attributes).
Basically we have a bunch of flat files that are created and maintained based on information kept in slapd which need to either: - run every X time and just dumbly regenerate the files. - run every X time and somehow establish whether changes happened before regenerating the files (maybe by using the contextCSN attribute of the root object) - run whenever a change happens
In a situation with not too many changes the third option is best, and in situations with lots of changes the second option is probably better. But is the third option even possible?
Thanks and best regards, Eli
E.S. Rosenberg wrote:
I was wondering is it possible to set a slapd syncprov consumer to trigger a script when it receives changes to the db (updates of specific attributes).
You might want to try something with a synclrepl consumer served by back-sock. But I think getting this right is almost as much work as implementing your own syncrepl client.
Ciao, Michael.
Michael Ströder wrote:
E.S. Rosenberg wrote:
I was wondering is it possible to set a slapd syncprov consumer to trigger a script when it receives changes to the db (updates of specific attributes).
You might want to try something with a synclrepl consumer served by back-sock. But I think getting this right is almost as much work as implementing your own syncrepl client.
That's almost on the right track. Use back-sock as an overlay.
Howard Chu wrote:
Michael Ströder wrote:
E.S. Rosenberg wrote:
I was wondering is it possible to set a slapd syncprov consumer to trigger a script when it receives changes to the db (updates of specific attributes).
You might want to try something with a synclrepl consumer served by back-sock. But I think getting this right is almost as much work as implementing your own syncrepl client.
That's almost on the right track. Use back-sock as an overlay.
That's what I was thinking first. But I'd be afraid that a blocking/misbehaving script would lock up slapd. I'd prefer to decouple such components to be on the safe side.
Ciao, Michael.
Thanks! For now I wrote a script that compares the contextCSN of the root object, but I am definitely going to play around with that backend when I get the chance.
All the best, Eli
2011/11/14 Michael Ströder michael@stroeder.com
Howard Chu wrote:
Michael Ströder wrote:
E.S. Rosenberg wrote:
I was wondering is it possible to set a slapd syncprov consumer to trigger a script when it receives changes to the db (updates of specific attributes).
You might want to try something with a synclrepl consumer served by
back-sock.
But I think getting this right is almost as much work as implementing
your own
syncrepl client.
That's almost on the right track. Use back-sock as an overlay.
That's what I was thinking first. But I'd be afraid that a blocking/misbehaving script would lock up slapd. I'd prefer to decouple such components to be on the safe side.
Ciao, Michael.
2011/11/14 Michael Ströder michael@stroeder.com
Howard Chu wrote:
Michael Ströder wrote:
E.S. Rosenberg wrote:
I was wondering is it possible to set a slapd syncprov consumer to trigger a script when it receives changes to the db (updates of specific attributes).
You might want to try something with a synclrepl consumer served by back-sock. But I think getting this right is almost as much work as implementing your own syncrepl client.
That's almost on the right track. Use back-sock as an overlay.
That's what I was thinking first. But I'd be afraid that a blocking/misbehaving script would lock up slapd. I'd prefer to decouple such components to be on the safe side.
If the consumer is not a master I would assume that a misbehaving script would only block the instance running the consumer and not the actual LDAP servers running on other machines, or am I making a wrong assumption here?
Thanks, Eli
Ciao, Michael.
Eli,
E.S. Rosenberg schrieb (13.11.2011 17:13 Uhr):
I was wondering is it possible to set a slapd syncprov consumer to trigger a script when it receives changes to the db (updates of specific attributes).
I think you might be able to replicate to a server instance with back-perl or back-shell backend and add a script checking for changes. http://www.openldap.org/doc/admin24/backends.html http://linux.die.net/man/5/slapd-perl
Marc
openldap-technical@openldap.org
-
E.S. Rosenberg -
Howard Chu -
Marc Patermann -
Michael Ströder