hello,
I may have a need soon to implement "computed" attributes in LDAP, to accommodate dumb clients that are unable to properly update the database
for example, an attribute masterAttr may have values like "A:B" (its value updated by the dumb client), but other clients need the A or B part separately. So whenever masterAttr is updated with value "A:B", firstPartAttr have to be updated with "A" and secondPartAttr with "B"
what are my options to achieve this? - is there an overlay like slapo-rwm but for attribute values? I searched but did not found anything. So I guess the answer is no. - using a combination of back-perl, back-relay and slapo-translucent? is that even possible - using back-sock as an overlay to monitor modifications and update the modified objects accordingly? - a script that monitor the accesslog database and update the modified objects accordingly? - biting the bullet and writing an overlay myself?
before diving too deep into this issue (and possibly drowning), I figured I would ask. any thoughts? ideas?
thanks in advance, best regards, Jephté CLAIN
hello again,
I searched a bit and found a paper by luke howard about extending openldap what is the state of native plugins with respect to slapi plugins? which is better (read: simpler to implement) for the need expressed below? Indeed, I also found a comment by Howard Chu on http://jpmens.net/2008/07/11/i-finally-get-openldap-triggers/ """"SLAPI is defined by Sun/Netscape, you can refer to their documentation. Probably would do better discussing this on the openldap-technical mailing list. And of course, I would have written a native slapd overlay instead, SLAPI is slower and clumsier."
I was able to find some documentation about slapi on oracle site, but I can't manage to find any docs about native plugins. maybe I'm just stupid :-) slapd.plugin manpage seems to be about slapi plugins only
for those who know slapi plugins: am I right to believe the computed attribute created with "object" type plugins are dynamic? I mean they are not stored in the backend but "created" each time the attribute is requested, right?
thanks in advance for any insights. best regards, Jephté CLAIN
2015-12-04 13:46 GMT+04:00 Jephte Clain jephte.clain@univ-reunion.fr:
hello,
I may have a need soon to implement "computed" attributes in LDAP, to accommodate dumb clients that are unable to properly update the database
for example, an attribute masterAttr may have values like "A:B" (its value updated by the dumb client), but other clients need the A or B part separately. So whenever masterAttr is updated with value "A:B", firstPartAttr have to be updated with "A" and secondPartAttr with "B"
what are my options to achieve this?
- is there an overlay like slapo-rwm but for attribute values? I searched
but did not found anything. So I guess the answer is no.
- using a combination of back-perl, back-relay and slapo-translucent? is
that even possible
- using back-sock as an overlay to monitor modifications and update the
modified objects accordingly?
- a script that monitor the accesslog database and update the modified
objects accordingly?
- biting the bullet and writing an overlay myself?
before diving too deep into this issue (and possibly drowning), I figured I would ask. any thoughts? ideas?
thanks in advance, best regards, Jephté CLAIN
-- *Jephté CLAIN | Développeur, Intégrateur d'applications* Service Systèmes d'Information Direction des Systèmes d'Information http://dsi.univ-reunion.fr Tél: +262 262 93 86 31 tel:+262262938631 || Gsm: +262 692 29 58 24 tel:+262692295824 www.univ-reunion.fr http://www.univ-reunion.fr || Facebook http://www.facebook.com/pages/Universit%C3%A9-de-La-R%C3%A9union-OFFICIEL/197176816990430 || Twitter http://twitter.com/univ_reunion
Jephte Clain wrote:
I may have a need soon to implement "computed" attributes in LDAP, to accommodate dumb clients that are unable to properly update the database
for example, an attribute masterAttr may have values like "A:B" (its value updated by the dumb client), but other clients need the A or B part separately. So whenever masterAttr is updated with value "A:B", firstPartAttr have to be updated with "A" and secondPartAttr with "B"
Note that splitting the value pairs into distinct attributes within the same entry does not work for multi-valued attributes.
- is there an overlay like slapo-rwm but for attribute values? I searched but
did not found anything. So I guess the answer is no.
AFAICS, no.
- using a combination of back-perl, back-relay and slapo-translucent? is that
even possible
Yes. Many moving parts though.
- using back-sock as an overlay to monitor modifications and update the modified
objects accordingly?
Yes. Not the best performance though. And you need a recent OpenLDAP release with back-sock fixes.
- a script that monitor the accesslog database and update the modified objects
accordingly?
Yes.
- biting the bullet and writing an overlay myself?
Yes, most probably gives the best performance.
Ciao, Michael.
Le 04/12/2015 15:30, Michael Ströder a écrit :
Jephte Clain wrote:
I may have a need soon to implement "computed" attributes in LDAP, to accommodate dumb clients that are unable to properly update the database
for example, an attribute masterAttr may have values like "A:B" (its value updated by the dumb client), but other clients need the A or B part separately. So whenever masterAttr is updated with value "A:B", firstPartAttr have to be updated with "A" and secondPartAttr with "B"
Hello,
thank you for your response,
Note that splitting the value pairs into distinct attributes within the same entry does not work for multi-valued attributes.
what do you mean? if masterAttr, firstPartAttr and secondPartAttr are multivalued, shouldn't it be possible? I mean, with: masterAttr: A:B masterAttr: A:C
I would get: firstPartAttr: A firstPartAttr: A secondPartAttr: B secondPartAttr: C
Or am I missing something? Would the *PartAttr attributes have to have special syntax to allow duplicate values?
- is there an overlay like slapo-rwm but for attribute values? I searched but
did not found anything. So I guess the answer is no.
AFAICS, no.
- using a combination of back-perl, back-relay and slapo-translucent? is that
even possible
Yes. Many moving parts though.
- using back-sock as an overlay to monitor modifications and update the modified
objects accordingly?
Yes. Not the best performance though. And you need a recent OpenLDAP release with back-sock fixes.
- a script that monitor the accesslog database and update the modified objects
accordingly?
Yes.
- biting the bullet and writing an overlay myself?
Yes, most probably gives the best performance.
OK. So what do you recommend? I know a bit of C, but I haven't written in that language for some years now (the last thing I wrote was a plugin for PostgreSQL) I could use some help, especially where to start? I have trouble finding docs about native plugins.
Thanks in advance for any suggestion.
Best regards, Jephté CLAIN
Ciao, Michael.
Jephte Clain wrote:
Le 04/12/2015 15:30, Michael Ströder a écrit :
Jephte Clain wrote:
I may have a need soon to implement "computed" attributes in LDAP, to accommodate dumb clients that are unable to properly update the database
for example, an attribute masterAttr may have values like "A:B" (its value updated by the dumb client), but other clients need the A or B part separately. So whenever masterAttr is updated with value "A:B", firstPartAttr have to be updated with "A" and secondPartAttr with "B"
thank you for your response,
Note that splitting the value pairs into distinct attributes within the same entry does not work for multi-valued attributes.
what do you mean? if masterAttr, firstPartAttr and secondPartAttr are multivalued, shouldn't it be possible? I mean, with: masterAttr: A:B masterAttr: A:C
I would get: firstPartAttr: A firstPartAttr: A secondPartAttr: B secondPartAttr: C
Or am I missing something? Would the *PartAttr attributes have to have special syntax to allow duplicate values?
Strictly speaking it's an information loss.
You can of course do that if the value pairing has no special meaning/relation in your deployment.
- using back-sock as an overlay to monitor modifications and update the modified
objects accordingly?
Yes. Not the best performance though. And you need a recent OpenLDAP release with back-sock fixes.
- a script that monitor the accesslog database and update the modified objects
accordingly?
Yes.
- biting the bullet and writing an overlay myself?
Yes, most probably gives the best performance.
OK. So what do you recommend? I know a bit of C, but I haven't written in that language for some years now (the last thing I wrote was a plugin for PostgreSQL) I could use some help, especially where to start? I have trouble finding docs about native plugins.
I'm also not a C developer, so I wrote a back-sock listener in Python.
If you want to implement a native overlay it might be useful to have a look at the sources of various small overlays in contrib/slapd-modules/.
YMMV.
Ciao, Michael.
openldap-technical@openldap.org
-
Jephte Clain -
Michael Ströder