[Date Prev][Date Next]
Re: reducing information duplication
Guillaume Rousse a écrit :
> I've had a quick look at slapo-dynlist man page, it seems it could
> achieve it using 'see-also' attribute to refer to the group dn, and
> probably an additional schema to add 'secretary' and 'manager'
> attributes to my group entries (posixGroup + groupOfNames).
My first attempt was to automatically retrieve primary group (posix
semantics) name (cn attribute) at user level entry.
Reading the splapo-dynlist man page, I understood I had to add new
attributes derived from labeledURI to my user entries. Hence this test
attributetype ( 184.108.40.206.4.1.125220.127.116.11 NAME 'ouURL' SUP labeledURI )
objectclass ( 18.104.22.168.4.1.12522.214.171.124
DESC 'Personne Futurs'
MAY ( ouURL ) )
Next, I configured dynlist overlay:
dynlist-attrset futursPerson ouURL
Next, i added the following entry to one of my user entry:
However, all my request for this entry get the unexpanded attribute
value, instead of its result.
Manually trying the request for the group cn gives the expected result
(I don't know if there is a way to test the URL directly, tough):
ldapsearch -x -h localhost -b
ou=futurs,ou=groups,dc=futurs,dc=inria,dc=fr -s sub gidNumber=5029 cn
Using the canonical exemple of slap-dynlist man page, with a groupOfURLs
group, works ok, so the overlay seems to be OK.
So, what's wrong here ?
Anyway, I'm doubtful I can really achieve what I'm looking for with this
- I can only have dynamic value for new attributes, I can't masquerade
existing ones (ie: having URL stored in ouURL attribute expanded in ou
- I can't refer to current entry values in the URL filter (ie: something as:
meaning information is duplicated anyway: if my user ever change of
gidNumber, i'll have to modify its ouURL value also.
I also had a quick look at slapo-rwm as an alternative, but it's a bit
complex to figure if it can be used here.
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62