[Date Prev][Date Next] [Chronological] [Thread] [Top]

forgive the newbie q's! :/

Hey there. I was hoping to brick some brains here... so here goes... :)

I'm trying to find a way of carrying "inheritable" (OO-like) code snippets
attached to ldap entries. "like what??"

ok. here's the idea

writing an ldap overlay. it intercepts results etc. etc. from ldap
and can OPTIONALLY process a result modifying it (or completely rewriting it)
based on dynamic data. this of course requires a way of 1. storing the
procedures to apply to the entry (E.g. perl, python, or whatever), and 2.
retrieving these stored procedures, being able to modify these procedures
(remotely via ldap commands) and inspect them, without specially configuring the
ldap server (E.g. back-perl). the aim is to be able to use an ldap client to
add, delete and modify the scripts that affect the output of an entry and to be
able to have a script apply to 1 particular entry, an entire subtree/class of
entries or the entire database too (ie every level in the ldap tree). what
language the script is in is not really relevant at this stage - but just think
that it could be perl, python, java bytecode, C# bytecode or anything else - as
long as it can be machine independent and interpreted, it doesn't matter.

an example is an entry that has someones age AND date of birth as values in the
object, but since the age will change over time, you auto-calculate the age
field BASED on the date of birth information before handing it off to the next
layer up. another example may be "last account payment" field. if the last
account payment is greater than 90 days ago, the account is AUTOMATICALLY locked
and the account validity filed in the account object returned is set to FALSE
automatically by a script for all members of the "users" directory - BUT some
users are special (company employees who don't need to pay, or special customers
with special deals) so you want a different script that ALWAYS lets the account
be active for these special account entries (thus the need to be able to have a
script per-entry than can override a more general script).

now that i've given the idea of what i'm trying to achieve, i am a bit vexed as
to the best way to go about it. sure - i have a test overlay working, and i am
assuming an overlay is the best method, as it means the back-end db is
independent of any modifying scripts. but now i need a way of storing the
scripts. i need to store them in a db accessible by at least a "manager" user. i
have a few ideas.

1. a new type in a schema that you can add to inetorgperson/orgperson etc.
schemas (or make a new schema that inherits from these actually and adds 1
field) and this new field contains any script to be run per entry. if that field
is non-empty, that code is run.

the problem is that the CODE is also returned. is there a way of nicely making
SOME entries visible and others masked/empty depending on the user who is
authenticated? (if not i could just add that to the subsystem that automatically
empties the script var entry if the user is not the Manager or on a list of
users allowed to see the script)

i could also put this in a parallel database under a different top level... but
that just seems a little nasty.

so what i'm wondering is:

1. how far off the planet am i?
2. some signposts pointing back to earth would be useful
3. seriously - am i going down the right path or what? :)

i will contribute back patches once this doesn't look so ugly anymore - so any
help is appreciated. :)

----------------------- VA Linux Systems Japan ----------------------
Carsten Haitzler (Raster)           raster@valinux.co.jp
カークン (数田)                     raster@rasterman.com
Ph: +81 3 3293 5151                 Fax: +81 3 3293 5152