Hello.
I deployed an LDAP system and a set of applications around it that is highly sensitive to the order of values, e.g first telephoneNumber must be the main contact method, first value of companyRepresentative must be the DN of the main contact person. The value of the data is almost rely on the order of the values, and I used referential integrity overlay without first checking if it preserve the order of values
my discovery: referential integrity overlay always puts the last modified value at the bottom.
e.g.
companyRepresentative: cn=David Jone,ou=sales,o=example.com companyRepresentative: cn=John Carmack,ou=development,o=example.com
Now if David Jone is renamed to "David Jones" because people find his name is misspelled, then after modrdn operation, the result is:
companyRepresentative: cn=John Carmack,ou=development,o=example.com companyRepresentative: cn=David Jones,ou=sales,o=example.com
So people begin to contact John Carmack for all affairs.
What's the best way to solve this problem? I can only think of 1) try to modify source code of slapo-refint to make it maintain order (big problem, never worked on C source code before, or 2) try to use several attributes like "FirstCompanyRepresentative", "SecondCompanyRepresentative", "ThirdCompanyRepresentative"
Zhang Weiwu wrote:
Hello.
I deployed an LDAP system and a set of applications around it that is highly sensitive to the order of values, e.g first telephoneNumber must be the main contact method, first value of companyRepresentative must be the DN of the main contact person.
That is a complete misuse of LDAP. Attributes are *SETS* of values. "Sets" are inherently unordered. The LDAP and X.500 specs and plenty of other docs tell you not to rely on the order in which values are returned.
What's the best way to solve this problem? I can only think of 1) try to modify source code of slapo-refint to make it maintain order (big problem, never worked on C source code before,
Obviously not the way to go.
or 2) try to use several
attributes like "FirstCompanyRepresentative", "SecondCompanyRepresentative", "ThirdCompanyRepresentative"
Clumsy, and only feasible if you have a fixed limit on the number of values you want to manage.
You might consider something like http://www.highlandsun.com/hyc/drafts/draft-chu-ldap-xordered-xx.html which is only slightly less clumsy, and that spec needs to be revised anyway. Whatever solution you choose is going to require your clients to be modified to adapt to the solution.
在 2007-08-14二的 02:01 -0700，Howard Chu写道：
Zhang Weiwu wrote:
Hello.
I deployed an LDAP system and a set of applications around it that is highly sensitive to the order of values, e.g first telephoneNumber must be the main contact method, first value of companyRepresentative must be the DN of the main contact person.
That is a complete misuse of LDAP. Attributes are *SETS* of values. "Sets" are inherently unordered. The LDAP and X.500 specs and plenty of other docs tell you not to rely on the order in which values are returned.
The misuse of this is first introduced by being able to have multiple values of telephone number, where we always put the primary number the first one and it worked several years. Later we used businessCategory which also have strict order requirements and that worked several years. So I begin to think I can do the same to companyRepresentative. Call me stupid or having not learnt true spirit of LDAP, I learn by starting with some theory and complete most of the theory with self experience, this worked with almost all other IT systems except LDAP. I don't know why. In LDAP world things often arranged different than my understanding.
What's the best way to solve this problem? I can only think of 1) try to modify source code of slapo-refint to make it maintain order (big problem, never worked on C source code before,
Obviously not the way to go.
or 2) try to use several
attributes like "FirstCompanyRepresentative", "SecondCompanyRepresentative", "ThirdCompanyRepresentative"
Clumsy, and only feasible if you have a fixed limit on the number of values you want to manage.
That's my trouble, it's clear the number of representative is not limited, many records have 6 or 8 of them!
You might consider something like http://www.highlandsun.com/hyc/drafts/draft-chu-ldap-xordered-xx.html which is only slightly less clumsy, and that spec needs to be revised anyway. Whatever solution you choose is going to require your clients to be modified to adapt to the solution.
Yeah very helpful source of information. I am reading it and hope to find a solution...
Zhang Weiwu wrote:
The misuse of this is first introduced by being able to have multiple values of telephone number, where we always put the primary number the first one and it worked several years.
against the specs, which warned you about not relying on this.
Later we used businessCategory which also have strict order requirements and that worked several years.
same as above.
So I begin to think I can do the same to companyRepresentative. Call me stupid or having not learnt true spirit of LDAP, I learn by starting with some theory
actually, the theory taught you not to do so.
and complete most of the theory with self experience, this worked with almost all other IT systems except LDAP. I don't know why. In LDAP world things often arranged different than my understanding.
Trial and error may be good when you have no alternatives. I understand LDAP may have a steep learning curve when non-trivial things need to be dealt with. So I'd recommend you take this opportunity to give up "bad habits based on experience" and try to stick with specs, instead of trying to force OpenLDAP into letting you preserve them.
In the LDAP world, you'd need to define your own "myPreferredTelephoneNumber" and put the preferred telephone number there as well as in the telephoneNumber, so that it can be collected both ways. Or, if the dumbest client you need to stick with is the one that wants the preferred number in the telephoneNumber attribute, leave it there, and add a "myAlternateTelephoneNumber" containing the perferred as well as the non preferred ones.
Going down the X-ORDERED trail would probably mean lots of pain. We needed to introduce it as a quick and reliable way to force ordering for internal purposes, but it is very unlikely that normal clients (I mean: clients whose sources you can't or don't want to modify) will be willing to cooperate with it.
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 ---------------------------------------
--On Tuesday, August 14, 2007 5:23 PM +0800 Zhang Weiwu zhangweiwu@realss.com wrote:
Yeah very helpful source of information. I am reading it and hope to find a solution...
The valsort overlay in OpenLDAP, of course. Although you'll need to define a custom attribute to hold the values for it, and you can't index them for searching, currently (or at least not for eq type searches in a meaningful way).
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Thanks. I already read a bit about valsort before I posed the original message, I think you mean to re-format the values like this:
nationality: 1 DE nationality: 2 CN
I think it really should work for me except I am going to need ordered values in DN syntax
companyRepresentative: 1 cn=John,... companyRepresentative: 2 cn=Paul,...
I am not sure if I can re-format string representation of DN (likely not) so I'd try Chu's solution first to see if it works.
在 2007-08-14二的 08:53 -0700，Quanah Gibson-Mount写道：
--On Tuesday, August 14, 2007 5:23 PM +0800 Zhang Weiwu zhangweiwu@realss.com wrote:
Yeah very helpful source of information. I am reading it and hope to find a solution...
The valsort overlay in OpenLDAP, of course. Although you'll need to define a custom attribute to hold the values for it, and you can't index them for searching, currently (or at least not for eq type searches in a meaningful way).
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
--On Wednesday, August 15, 2007 9:07 AM +0800 Zhang Weiwu zhangweiwu@realss.com wrote:
Thanks. I already read a bit about valsort before I posed the original message, I think you mean to re-format the values like this:
nationality: 1 DE nationality: 2 CN
I think it really should work for me except I am going to need ordered values in DN syntax
companyRepresentative: 1 cn=John,... companyRepresentative: 2 cn=Paul,...
I am not sure if I can re-format string representation of DN (likely not) so I'd try Chu's solution first to see if it works.
I think you don't understand how valsort works.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
--On Wednesday, August 15, 2007 8:02 AM -0700 Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Wednesday, August 15, 2007 9:07 AM +0800 Zhang Weiwu zhangweiwu@realss.com wrote:
Thanks. I already read a bit about valsort before I posed the original message, I think you mean to re-format the values like this:
nationality: 1 DE nationality: 2 CN
I think it really should work for me except I am going to need ordered values in DN syntax
companyRepresentative: 1 cn=John,... companyRepresentative: 2 cn=Paul,...
I am not sure if I can re-format string representation of DN (likely not) so I'd try Chu's solution first to see if it works.
I think you don't understand how valsort works.
Although for the attribute being used by valsort, it'd probably have to be something other than DN syntax, although the client querying it wouldn't have to know that (just to note). Not sure how that may or may not affect matching rules. But the point is to the client, unless it exerts the control, it doesn't see the weights, just ordered results.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
One dump question, the draft you composed expires at end of 2006, does that mean this draft will no longer become RFC and (thus?) have no implementation yet?
Having to require client modification might be the big reason to not having it implemented, I guess.
在 2007-08-14二的 02:01 -0700，Howard Chu写道：
Zhang Weiwu wrote:
Hello.
I deployed an LDAP system and a set of applications around it that is highly sensitive to the order of values, e.g first telephoneNumber must be the main contact method, first value of companyRepresentative must be the DN of the main contact person.
That is a complete misuse of LDAP. Attributes are *SETS* of values. "Sets" are inherently unordered. The LDAP and X.500 specs and plenty of other docs tell you not to rely on the order in which values are returned.
What's the best way to solve this problem? I can only think of 1) try to modify source code of slapo-refint to make it maintain order (big problem, never worked on C source code before,
Obviously not the way to go.
or 2) try to use several
attributes like "FirstCompanyRepresentative", "SecondCompanyRepresentative", "ThirdCompanyRepresentative"
Clumsy, and only feasible if you have a fixed limit on the number of values you want to manage.
You might consider something like http://www.highlandsun.com/hyc/drafts/draft-chu-ldap-xordered-xx.html which is only slightly less clumsy, and that spec needs to be revised anyway. Whatever solution you choose is going to require your clients to be modified to adapt to the solution.
Zhang Weiwu wrote:
One dump question, the draft you composed expires at end of 2006, does that mean this draft will no longer become RFC and (thus?) have no implementation yet?
The draft is intended to document what we've already implemented in OpenLDAP. The OpenLDAP implementation will continue to exist regardless of the document status.
There are some flaws/errors in that draft that make it unsuitable for general purpose usage. I haven't had time to address those points, and since what we have already works for us, I haven't had much incentive to make time for it.
Having to require client modification might be the big reason to not having it implemented, I guess.
在 2007-08-14二的 02:01 -0700，Howard Chu写道：
Zhang Weiwu wrote:
Hello.
I deployed an LDAP system and a set of applications around it that is highly sensitive to the order of values, e.g first telephoneNumber must be the main contact method, first value of companyRepresentative must be the DN of the main contact person.
That is a complete misuse of LDAP. Attributes are *SETS* of values. "Sets" are inherently unordered. The LDAP and X.500 specs and plenty of other docs tell you not to rely on the order in which values are returned.
What's the best way to solve this problem? I can only think of 1) try to modify source code of slapo-refint to make it maintain order (big problem, never worked on C source code before,
Obviously not the way to go.
or 2) try to use several
attributes like "FirstCompanyRepresentative", "SecondCompanyRepresentative", "ThirdCompanyRepresentative"
Clumsy, and only feasible if you have a fixed limit on the number of values you want to manage.
You might consider something like http://www.highlandsun.com/hyc/drafts/draft-chu-ldap-xordered-xx.html which is only slightly less clumsy, and that spec needs to be revised anyway. Whatever solution you choose is going to require your clients to be modified to adapt to the solution.
在 2007-08-14二的 10:30 -0700，Howard Chu写道：
Zhang Weiwu wrote:
One dump question, the draft you composed expires at end of 2006, does that mean this draft will no longer become RFC and (thus?) have no implementation yet?
The draft is intended to document what we've already implemented in OpenLDAP. The OpenLDAP implementation will continue to exist regardless of the document status.
Thanks for openldap team to having implemented this and for your draft to presented a solution. I think i will use this feature. Updating clients may be a bit difficult but had I used RDBMS updating table structure is also troublesome (although probably in that case the table can be pre-designed to be more flexible). Especially there are only a few attributes, not all attributes, in real business use have very important requirement on their order.
在 2007-08-14二的 10:30 -0700，Howard Chu写道：
Zhang Weiwu wrote:
One dump question, the draft you composed expires at end of 2006, does that mean this draft will no longer become RFC and (thus?) have no implementation yet?
The draft is intended to document what we've already implemented in OpenLDAP.
Thanks for the info. Sorry for having to ask so many questions before I can start using this feature: since which version this feature is enabled? The testbed I am using runs openldap 2.3.37. I got some error using this feature:
zhangweiwu@emerson ~ $ ldapadd -x -D uid=... -W Enter LDAP Password: dn: uid=BESG,ou=contacts,ou=china,dc=ahk,dc=de objectClass: olcCompany o: BASG companyRepresentative: {0}cn=Xiaowen Zheng,uid=BESG,ou=... companyRepresentative: {1}cn=Joerg Wuttker,uid=BESG,ou=...
adding new entry "uid=BASG,ou=contacts,ou=china,dc=ahk,dc=de" ldap_add: Invalid syntax (21) additional info: contactPerson: value #0 invalid per syntax
The sensitive data is replaced with '...' before posting.
Schema is defined as below, following examples in draft-chu-ldap-xordered-00.txt
attributetype ( ... NAME 'companyRepresentative' DESC 'DN of the company representative' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORDERED 'VALUES' )
Zhang Weiwu wrote:
在 2007-08-14二的 10:30 -0700，Howard Chu写道：
Zhang Weiwu wrote:
One dump question, the draft you composed expires at end of 2006, does that mean this draft will no longer become RFC and (thus?) have no implementation yet?
The draft is intended to document what we've already implemented in OpenLDAP.
Thanks for the info. Sorry for having to ask so many questions before I can start using this feature: since which version this feature is enabled? The testbed I am using runs openldap 2.3.37. I got some error using this feature:
This has been present since 2.3.1, i.e., all 2.3 releases.
zhangweiwu@emerson ~ $ ldapadd -x -D uid=... -W Enter LDAP Password: dn: uid=BESG,ou=contacts,ou=china,dc=ahk,dc=de objectClass: olcCompany o: BASG companyRepresentative: {0}cn=Xiaowen Zheng,uid=BESG,ou=... companyRepresentative: {1}cn=Joerg Wuttker,uid=BESG,ou=...
adding new entry "uid=BASG,ou=contacts,ou=china,dc=ahk,dc=de" ldap_add: Invalid syntax (21) additional info: contactPerson: value #0 invalid per syntax
What makes you think that an error in "contactPerson" has anything to do with the "companyRepresentative" attribute?
The sensitive data is replaced with '...' before posting.
Schema is defined as below, following examples in draft-chu-ldap-xordered-00.txt
attributetype ( ... NAME 'companyRepresentative' DESC 'DN of the company representative' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORDERED 'VALUES' )
在 2007-08-15三的 01:58 -0700，Howard Chu写道：
Zhang Weiwu wrote:
在 2007-08-14二的 10:30 -0700，Howard Chu写道：
Zhang Weiwu wrote:
One dump question, the draft you composed expires at end of 2006, does that mean this draft will no longer become RFC and (thus?) have no implementation yet?
The draft is intended to document what we've already implemented in OpenLDAP.
Thanks for the info. Sorry for having to ask so many questions before I can start using this feature: since which version this feature is enabled? The testbed I am using runs openldap 2.3.37. I got some error using this feature:
This has been present since 2.3.1, i.e., all 2.3 releases.
zhangweiwu@emerson ~ $ ldapadd -x -D uid=... -W Enter LDAP Password: dn: uid=BESG,ou=contacts,ou=china,dc=ahk,dc=de objectClass: olcCompany o: BASG companyRepresentative: {0}cn=Xiaowen Zheng,uid=BESG,ou=... companyRepresentative: {1}cn=Joerg Wuttker,uid=BESG,ou=...
adding new entry "uid=BASG,ou=contacts,ou=china,dc=ahk,dc=de" ldap_add: Invalid syntax (21) additional info: contactPerson: value #0 invalid per syntax
What makes you think that an error in "contactPerson" has anything to do with the "companyRepresentative" attribute?
Sorry this is purely my mistake, the actual commandline script is:
zhangweiwu@emerson ~ $ ldapadd -xH ldap://emerson -D uid=... -w ... dn: uid=BESG,ou=contacts,ou=china,dc=ahk,dc=de objectClass: olcCompany o: BASG companyRepresentative: {0}cn=Xiaowen Zheng,uid=BESG,ou=... companyRepresentative: {1}cn=Joerg Wuttker,uid=BESG,ou=...
adding new entry "uid=BASG,ou=contacts,ou=china,dc=ahk,dc=de" ldap_add: Invalid syntax (21) additional info: companyRepresentative: value #0 invalid per syntax
After I failed with companyRepresentative I try define a new attributetype in similiar way and give it a name contactPerson, and failed again. When I write the email I mixed commandline output of the two test cases by mistake. (first time tested companyRepresentative, second time tested contactPerson)
I am not sure if I need to post my slapd.conf, do I have to make special setting in that file to enable X-ORDERED extension?
Thanks!
On 2007-08-14 09:01, Howard Chu wrote:
You might consider something like http://www.highlandsun.com/hyc/drafts/draft-chu-ldap-xordered-xx.html which is only slightly less clumsy, and that spec needs to be revised anyway.
Client-side ordering seems to me a suitable use of attribute option-based subtypes, e.g.:
telephonenumber;x-preference-1: (888) 555-1212 telephonenumber;x-preference-10: (202) 555-1212
IIRC, the last time I tried defining private attribute options in openldap I was disappointed in its support for extension of the option namespace, but that was a long time ago.
Top-posted responses will be ignored.
Hi,
On Tuesday, 14. August 2007 11:01, Howard Chu wrote:
Zhang Weiwu wrote:
Hello.
I deployed an LDAP system and a set of applications around it that is highly sensitive to the order of values, e.g first telephoneNumber must be the main contact method, first value of companyRepresentative must be the DN of the main contact person.
That is a complete misuse of LDAP. Attributes are *SETS* of values. "Sets" are inherently unordered. The LDAP and X.500 specs and plenty of other docs tell you not to rely on the order in which values are returned.
What's the best way to solve this problem? I can only think of 1) try to modify source code of slapo-refint to make it maintain order (big problem, never worked on C source code before,
Obviously not the way to go.
or 2) try to use several
attributes like "FirstCompanyRepresentative", "SecondCompanyRepresentative", "ThirdCompanyRepresentative"
Clumsy, and only feasible if you have a fixed limit on the number of values you want to manage.
You might consider something like http://www.highlandsun.com/hyc/drafts/draft-chu-ldap-xordered-xx.html which is only slightly less clumsy, and that spec needs to be revised anyway. Whatever solution you choose is going to require your clients to be modified to adapt to the solution.
Maybe as another alternative attribute options might work (with some help from clients): telephoneNumber;x-sort-1: .... telephoneNumber;x-sort-2: ....
Then the client needs to sort the values according to the value after "x-sort-".
I have always wondered why this approach was not considered for the OpenLDAP configuration.
Regards Peter
Peter Marschall wrote:
Maybe as another alternative attribute options might work (with some help from clients): telephoneNumber;x-sort-1: .... telephoneNumber;x-sort-2: ....
Then the client needs to sort the values according to the value after "x-sort-".
I have always wondered why this approach was not considered for the OpenLDAP configuration.
Good question. IMHO this would have also avoided some inconsistency regarding matching rules.
Ciao, Michael.
openldap-software@openldap.org
-
Howard Chu -
Jefferson Ogata -
Michael Ströder -
Peter Marschall -
Pierangelo Masarati -
Quanah Gibson-Mount -
Zhang Weiwu