Hello list.
I'm looking for a way to reduce information duplication in an LDAP directory, using the equivalence of joint in SQL databases. Basically, all my user entries (inetorgperson + posixAccount) need to have a 'secretary' and a 'manager' field, but given than all users from the same group have the same secretary and the same manager, I'd prefer to refer to them at the group level, and refer to the group from the user entry.
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).
Ideally, I would also use the same system to get the userGid attribute for the users.
Does it sound like a good idea ?
Guillaume Rousse Guillaume.Rousse@inria.fr writes:
Hello list.
I'm looking for a way to reduce information duplication in an LDAP directory, using the equivalence of joint in SQL databases. Basically, all my user entries (inetorgperson + posixAccount) need to have a 'secretary' and a 'manager' field, but given than all users from the same group have the same secretary and the same manager, I'd prefer to refer to them at the group level, and refer to the group from the user entry.
An other aproach would be a collective attribute, RFC 3671.
-Dieter
Dieter Kluenter a écrit :
Guillaume Rousse Guillaume.Rousse@inria.fr writes:
Hello list.
I'm looking for a way to reduce information duplication in an LDAP directory, using the equivalence of joint in SQL databases. Basically, all my user entries (inetorgperson + posixAccount) need to have a 'secretary' and a 'manager' field, but given than all users from the same group have the same secretary and the same manager, I'd prefer to refer to them at the group level, and refer to the group from the user entry.
An other aproach would be a collective attribute, RFC 3671.
Interesting. From what I read sofar, it is implemented in the collect overlay, whose sources are included but not build in openldap 2.3. I didn't found any additional schema, tough, and there is no documentation available neither, as it is meant to be an experimental module. Not really encouraging to use :)
Guillaume Rousse Guillaume.Rousse@inria.fr writes:
Dieter Kluenter a écrit :
Guillaume Rousse Guillaume.Rousse@inria.fr writes:
Hello list.
I'm looking for a way to reduce information duplication in an LDAP directory, using the equivalence of joint in SQL databases. Basically, all my user entries (inetorgperson + posixAccount) need to have a 'secretary' and a 'manager' field, but given than all users from the same group have the same secretary and the same manager, I'd prefer to refer to them at the group level, and refer to the group from the user entry.
An other aproach would be a collective attribute, RFC 3671.
Interesting. From what I read sofar, it is implemented in the collect overlay, whose sources are included but not build in openldap 2.3. I didn't found any additional schema, tough, and there is no documentation available neither, as it is meant to be an experimental module. Not really encouraging to use :)
There is a collective.schema bundled with openldap and a grep -i -r collective on the source code supplies lots of matches.
-Dieter
Dieter Kluenter a écrit :
Guillaume Rousse Guillaume.Rousse@inria.fr writes:
Dieter Kluenter a écrit :
Guillaume Rousse Guillaume.Rousse@inria.fr writes:
Hello list.
I'm looking for a way to reduce information duplication in an LDAP directory, using the equivalence of joint in SQL databases. Basically, all my user entries (inetorgperson + posixAccount) need to have a 'secretary' and a 'manager' field, but given than all users from the same group have the same secretary and the same manager, I'd prefer to refer to them at the group level, and refer to the group from the user entry.
An other aproach would be a collective attribute, RFC 3671.
Interesting. From what I read sofar, it is implemented in the collect overlay, whose sources are included but not build in openldap 2.3. I didn't found any additional schema, tough, and there is no documentation available neither, as it is meant to be an experimental module. Not really encouraging to use :)
There is a collective.schema bundled with openldap
Not in 2.3.38 apparently.
and a grep -i -r collective on the source code supplies lots of matches.
This doesn't really constitute documentation...
Guillaume Rousse wrote:
Dieter Kluenter a écrit :
Guillaume Rousse Guillaume.Rousse@inria.fr writes:
Dieter Kluenter a écrit :
Guillaume Rousse Guillaume.Rousse@inria.fr writes:
Hello list.
I'm looking for a way to reduce information duplication in an LDAP directory, using the equivalence of joint in SQL databases. Basically, all my user entries (inetorgperson + posixAccount) need to have a 'secretary' and a 'manager' field, but given than all users from the same group have the same secretary and the same manager, I'd prefer to refer to them at the group level, and refer to the group from the user entry.
An other aproach would be a collective attribute, RFC 3671.
Interesting. From what I read sofar, it is implemented in the collect overlay, whose sources are included but not build in openldap 2.3. I didn't found any additional schema, tough, and there is no documentation available neither, as it is meant to be an experimental module. Not really encouraging to use :)
There is a collective.schema bundled with openldap
Not in 2.3.38 apparently.
and a grep -i -r collective on the source code supplies lots of matches.
This doesn't really constitute documentation...
collect.c is just a demonstration of overlay code for developers, hence no docs.
Gavin Henry a écrit :
and a grep -i -r collective on the source code supplies lots of matches.
This doesn't really constitute documentation...
collect.c is just a demonstration of overlay code for developers, hence no docs.
That's what I understood also, hence my lack of motivation to consider it as a viable implementation of collective attributes for openldap 2.3 currently.
Guillaume Rousse wrote:
Gavin Henry a écrit :
collect.c is just a demonstration of overlay code for developers, hence no docs.
That's what I understood also, hence my lack of motivation to consider it as a viable implementation of collective attributes for openldap 2.3 currently.
Although written as a demonstration of overlay code, and thus perhaps probably not as optimal as it could be, it doesn't differ from the rest of the overlays; I think right now the only way one would implement collective attributes would probably be by means of an overlay, and its architecture wouldn't probably differ too much from that of current slapo-collect. If you're fine with, say, slapo-accesslog, slapo-chain, slapo-dynlist, slapo-rwm, slapo-syncprov, most of which implement key features of OpenLDAP, I don't see why you shouldn't give slapo-collect the same respect. All in all, it's out of usefulness for regular users that OpenLDAP experimental code becomes release-grade code. Or, to reverse the point of view, please feel free to consider the rest of OpenLDAP code the same you consider slapo-collect.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati a écrit :
Guillaume Rousse wrote:
Gavin Henry a écrit :
collect.c is just a demonstration of overlay code for developers, hence no docs.
That's what I understood also, hence my lack of motivation to consider it as a viable implementation of collective attributes for openldap 2.3 currently.
Although written as a demonstration of overlay code, and thus perhaps probably not as optimal as it could be, it doesn't differ from the rest of the overlays;
Yes it does: - it is not build by default, and doesn't even have corresponding entries in the makefile - it does not have a man page
I'm not judging code quality (I have absolutly no clue), I'm judging ease of deployment, and ease of maintainance, both for myself and the rest of my colleagues.
Guillaume Rousse wrote:
I'm not judging code quality (I have absolutly no clue), I'm judging ease of deployment, and ease of maintainance, both for myself and the rest of my colleagues.
OK, let me try to re-state it in yet another manner. It seems that what you exactly need is collective attributes. Someone designed some piece of software that implements connective attributes in OpenLDAP, that piece of software seems to work as expected, and it's distributed, but it doesn't configure or make seamlessly because of historical reasons. Moreover, there's no documentation, although a quick look at the code shows that the only configuration is
collectinfo <dn> <c-attr>
repeated as many times as required for each superior entry/collective attribute pair (the configuration is almost self-documented by the code, in this case, in the error message that's returned in case of syntax error).
Your solution to the problem consists in sitting by the river until anyone makes it compile straightforwardly and writes a man page. I'd rather:
1) compile it myself and see if it really fits my needs
2) open an ITS to describe how useful it was and how well it worked, and to request its addition to officially released overlays, possibly providing the required patch myself.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati wrote:
Guillaume Rousse wrote:
I'm not judging code quality (I have absolutly no clue), I'm judging ease of deployment, and ease of maintainance, both for myself and the rest of my colleagues.
OK, let me try to re-state it in yet another manner. It seems that what you exactly need is collective attributes. Someone designed some piece of software that implements connective attributes in OpenLDAP, that piece of software seems to work as expected, and it's distributed, but it doesn't configure or make seamlessly because of historical reasons. Moreover, there's no documentation, although a quick look at the code shows that the only configuration is
collectinfo <dn> <c-attr>
repeated as many times as required for each superior entry/collective attribute pair (the configuration is almost self-documented by the code, in this case, in the error message that's returned in case of syntax error).
Your solution to the problem consists in sitting by the river until anyone makes it compile straightforwardly and writes a man page. I'd rather:
compile it myself and see if it really fits my needs
open an ITS to describe how useful it was and how well it worked, and
to request its addition to officially released overlays, possibly providing the required patch myself.
Here, here.
Here, here.
Hear, hear! ;-)
Pierangelo Masarati a écrit :
Your solution to the problem consists in sitting by the river until anyone makes it compile straightforwardly and writes a man page.
No, my solution consisted to evaluate different strategies, taking into account their initial cost for testing, and their subsequent cost for deploying in productions.
You're basically assuming reading C source code, RFC documents, and producing tuned binaries has a negligeable cost. That's not my case, and I'm heavily time short there.
I'd rather:
compile it myself and see if it really fits my needs
open an ITS to describe how useful it was and how well it worked, and
to request its addition to officially released overlays, possibly providing the required patch myself.
Granted, I could have done it. I prefered to spend some time testing alternative solution (see my questions about repo-dyngroup), that didn't involved recompilation, and finally implemented it outside ldap (we already have external content synchronisation from outside sources).
I'll try to give a look at this extension later, tough.
Guillaume Rousse wrote:
Pierangelo Masarati a écrit :
Your solution to the problem consists in sitting by the river until anyone makes it compile straightforwardly and writes a man page.
No, my solution consisted to evaluate different strategies, taking into account their initial cost for testing, and their subsequent cost for deploying in productions.
You're basically assuming reading C source code, RFC documents, and producing tuned binaries has a negligeable cost. That's not my case, and I'm heavily time short there.
Be assured that Pierangelo knows about these costs quite well.
Ciao, Michael.
Pierangelo Masarati wrote:
Guillaume Rousse wrote:
Gavin Henry a écrit :
collect.c is just a demonstration of overlay code for developers, hence no docs.
That's what I understood also, hence my lack of motivation to consider it as a viable implementation of collective attributes for openldap 2.3 currently.
Although written as a demonstration of overlay code, and thus perhaps probably not as optimal as it could be, it doesn't differ from the rest of the overlays; I think right now the only way one would implement collective attributes would probably be by means of an overlay, and its architecture wouldn't probably differ too much from that of current slapo-collect. If you're fine with, say, slapo-accesslog, slapo-chain, slapo-dynlist, slapo-rwm, slapo-syncprov, most of which implement key features of OpenLDAP, I don't see why you shouldn't give slapo-collect the same respect. All in all, it's out of usefulness for regular users that OpenLDAP experimental code becomes release-grade code. Or, to reverse the point of view, please feel free to consider the rest of OpenLDAP code the same you consider slapo-collect.
I like that last sentence!
I was going to say it didn't have cn=config support, but Howard added that a while ago.
Gavin.
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 schema: attributetype ( 1.3.6.1.4.1.12559.11.1.1 NAME 'ouURL' SUP labeledURI ) objectclass ( 1.3.6.1.4.1.12559.11.2.1 NAME 'futursPerson' DESC 'Personne Futurs' AUXILIARY MAY ( ouURL ) )
Next, I configured dynlist overlay: overlay dynlist dynlist-attrset futursPerson ouURL
Next, i added the following entry to one of my user entry: ouURL: ldap:///ou=futurs,ou=groups,dc=futurs,dc=inria,dc=fr?cn?sub?(gidNumber= 5029)
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 method: - 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 attribute) - I can't refer to current entry values in the URL filter (ie: something as: ldap:///ou=futurs,ou=groups,dc=futurs,dc=inria,dc=fr?cn?sub?(gidNumber=$self->{gidNumber})), 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.
openldap-software@openldap.org
-
Dieter Kluenter -
Gavin Henry -
Gavin Henry -
Guillaume Rousse -
Michael Ströder -
Pierangelo Masarati