Hello,
I’m working with OS X Server 10.9 who’s using OpenLDAP to provide directory services.
I’ve a problem with a simple LDAP request who is not consistent depending of the attribute filter requested.
Here are the two commands I’ve used in my CLI:
ldapsearch -x -H ldap://192.168.42.10 -b "cn=passwordserver,cn=config,dc=example,dc=com" "(objectclass=*)"
and
ldapsearch -x -H ldap://192.168.42.10 -b "cn=passwordserver,cn=config,dc=example,dc=com" "(objectclass=*)" apple-xmlplist
For each request, the content of apple-xmlplist is different. The problem is the same with ldap_search_ext_s in C.
I’ve looked the request with wireshark and the only difference I see is the presence or not of the attribute request. The rest of the request is exactly the same.
I don’t understand how is it possible.
Do you know this bug? Do you have a way to edit the stored record used for the request with the filter (it’s the one used by Apple internal tools, so it’s not really possible for me to change it).
Here are version info:
@(#) $OpenLDAP: slapd 2.4.28 (Nov 12 2013 12:02:47) $ root@hikkaduwa.apple.com:/private/var/tmp/OpenLDAP/OpenLDAP-491.1~1/servers/slapd
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.28 (Nov 12 2013 12:04:43) $ root@hikkaduwa.apple.com:/private/var/tmp/OpenLDAP/OpenLDAP-491.1~1/clients/tools (LDAP library: OpenLDAP 20428)
Best regards, Yoann Gini
Yoann Gini wrote:
I’m working with OS X Server 10.9 who’s using OpenLDAP to provide directory services.
I’ve a problem with a simple LDAP request who is not consistent depending of the attribute filter requested.
Here are the two commands I’ve used in my CLI:
ldapsearch -x -H ldap://192.168.42.10 -b "cn=passwordserver,cn=config,dc=example,dc=com" "(objectclass=*)"
and
ldapsearch -x -H ldap://192.168.42.10 -b "cn=passwordserver,cn=config,dc=example,dc=com" "(objectclass=*)" apple-xmlplist
Could you please elaborate on what exactly "not consistent" means to you? Seeing the output generated would be good.
Also note that there might be special case where you see an attribute only if you request it explicitly.
If you don't specify an attribute list it means "*" (return all user attributes).
Ciao, Michael.
Le 12 févr. 2015 à 20:01, Michael Ströder michael@stroeder.com a écrit :
Could you please elaborate on what exactly "not consistent" means to you? Seeing the output generated would be good.
Sorry if I'm not clear. What is inconsistent is the value of that attribute.
Of course, without the attribute specified, I get the whole object, but the problem is not here.
For each request on the same object, if I look at the value of the apple-xmlplist field, the first say blue and the second say red.
If I try to edit this field with any tools I have (Apache directory studio, ldapmodify, custom C code), only the object returned by the request without any attribute specifier is modified. The request with the attribute specified still return the wrong value.
Le 13 févr. 2015 à 00:30, Yoann Gini yoann.gini@gmail.com a écrit :
Le 12 févr. 2015 à 20:01, Michael Ströder michael@stroeder.com a écrit :
Could you please elaborate on what exactly "not consistent" means to you? Seeing the output generated would be good.
Sorry if I'm not clear. What is inconsistent is the value of that attribute.
Of course, without the attribute specified, I get the whole object, but the problem is not here.
For each request on the same object, if I look at the value of the apple-xmlplist field, the first say blue and the second say red.
If I try to edit this field with any tools I have (Apache directory studio, ldapmodify, custom C code), only the object returned by the request without any attribute specifier is modified. The request with the attribute specified still return the wrong value.
Sometime, pictures and video are better than any word.
I’ve made a quick video and make it available on YouTube if you want to see the bug: https://www.youtube.com/watch?v=iPwN-wsegy8
I can’t understand how is it possible.
Yoann Gini wrote:
Le 13 févr. 2015 à 00:30, Yoann Gini yoann.gini@gmail.com a écrit :
Le 12 févr. 2015 à 20:01, Michael Ströder michael@stroeder.com a écrit :
Could you please elaborate on what exactly "not consistent" means to you? Seeing the output generated would be good.
Sorry if I'm not clear. What is inconsistent is the value of that attribute.
Of course, without the attribute specified, I get the whole object, but the problem is not here.
For each request on the same object, if I look at the value of the apple-xmlplist field, the first say blue and the second say red.
If I try to edit this field with any tools I have (Apache directory studio, ldapmodify, custom C code), only the object returned by the request without any attribute specifier is modified. The request with the attribute specified still return the wrong value.
Sometime, pictures and video are better than any word.
I’ve made a quick video and make it available on YouTube if you want to see the bug: https://www.youtube.com/watch?v=iPwN-wsegy8
I can’t understand how is it possible.
This has nothing to do with OpenLDAP. You're talking about Apple's privately hacked version of the code. Whatever they do in their custom attributes with their custom plugins is anybody's guess, but don't expect any Standards documented behavior to cover it.
Le 13 févr. 2015 à 11:13, Howard Chu hyc@symas.com a écrit :
This has nothing to do with OpenLDAP. You're talking about Apple's privately hacked version of the code. Whatever they do in their custom attributes with their custom plugins is anybody's guess, but don't expect any Standards documented behavior to cover it.
I was hoping to not see an answer like that. So common in all Open Source communities.
You seems really fast to conclude that’s a problem of an hypothetic Apple hack. The source code used by Apple is available here http://opensource.apple.com/source/OpenLDAP/OpenLDAP-491.1/
Do you see a difference with the official repository who can lead to this problem?
I’m not asking for a « go to hell, it’s an Apple hack » answer.
If I’m asking here, it’s because I’m looking for a real valuable answer. Like for example what kind of mechanism in OpenLDAP source code can lead to this situation. An index or something like that for example.
Maybe it’s linked to an Apple hack, maybe not. In any case the only valuable answer for my question is a troubleshooting procedure for this kind of behavior. Nothing else.
On 02/13/2015 07:29 AM, Yoann Gini wrote:
Le 13 févr. 2015 à 11:13, Howard Chu hyc@symas.com a écrit :
This has nothing to do with OpenLDAP. You're talking about Apple's privately hacked version of the code. Whatever they do in their custom attributes with their custom plugins is anybody's guess, but don't expect any Standards documented behavior to cover it.
I was hoping to not see an answer like that. So common in all Open Source communities.
You seems really fast to conclude that’s a problem of an hypothetic Apple hack. The source code used by Apple is available here http://opensource.apple.com/source/OpenLDAP/OpenLDAP-491.1/
Do you see a difference with the official repository who can lead to this problem?
I’m not asking for a « go to hell, it’s an Apple hack » answer.
If I’m asking here, it’s because I’m looking for a real valuable answer. Like for example what kind of mechanism in OpenLDAP source code can lead to this situation. An index or something like that for example.
Maybe it’s linked to an Apple hack, maybe not. In any case the only valuable answer for my question is a troubleshooting procedure for this kind of behavior. Nothing else.
The reason you so often see an answer like this is because people like you want Open Source developers to do work for you for free...
The answer is as Howard said, Apple has modified the code, so pay for a support contract with them and ask them. Or see if they will work for you for free.
Our company has been using OpenLDAP for almost 15 years with billions of transactions and have found the query results to always be utterly deterministic...ie, we have always gotten out exactly what we put in and asked for. Out inconsistencies have always been traced back to either our inconsistent input or queries.
In your particular case, without working for you for free for several hours to answer your question, it looks to me like you are adding an additional query criteria that Apple's code is handling differently based on the existence of the criteria.
For example, if I was querying an "unordered" hash data structure and asking for any single element vs a specific element I would expect similar behavior...with no criteria I get whichever element happens to be first in the hash structure at that time and when I specify a hash key I get the specific element data. But you would have to take the time to research Apple's attribute & code to determine if that is a valid analogy in this case.
Good luck!
Le 13 févr. 2015 à 15:09, Andy Dorman adorman@ironicdesign.com a écrit :
The reason you so often see an answer like this is because people like you want Open Source developers to do work for you for free…
You seem to have forgotten what is OpenSource.
I don’t ask you to do my work, just to share idea like you’ve just did.
OpenSource communities tend more and more to stop sharing their knowledge to make money.
I’m not asking you to do my work of troubleshooting, I’m asking you to show me entries points to look at. But again, more and more people in OpenSource communities try to stop knowledge sharing.
This is funny, because in Apple communities, people tend to share more and more knowledge AND work for free.
The answer is as Howard said, Apple has modified the code, so pay for a support contract with them and ask them. Or see if they will work for you for free.
Our company has been using OpenLDAP for almost 15 years with billions of transactions and have found the query results to always be utterly deterministic...ie, we have always gotten out exactly what we put in and asked for. Out inconsistencies have always been traced back to either our inconsistent input or queries.
In your particular case, without working for you for free for several hours to answer your question, it looks to me like you are adding an additional query criteria that Apple's code is handling differently based on the existence of the criteria.
For example, if I was querying an "unordered" hash data structure and asking for any single element vs a specific element I would expect similar behavior...with no criteria I get whichever element happens to be first in the hash structure at that time and when I specify a hash key I get the specific element data. But you would have to take the time to research Apple's attribute & code to determine if that is a valid analogy in this case.
I’m perfectly OK to say it’s something wrong with the way Apple use OpenLDAP, but starting to say it’s a hack and in bug in the Apple code when it’s a simple LDAP schema extension is not a good idea.
My next message, before your message, was this one:
For information, here is the definition of this attribute:
attributetype ( 1.3.6.1.4.1.63.1000.1.1.1.17.1 NAME 'apple-xmlplist' DESC 'XML plist data' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
And here is the definition of the object class:
objectclass ( 1.3.6.1.4.1.63.1000.1.1.2.12 NAME 'apple-configuration' DESC 'configuration' SUP top STRUCTURAL MAY ( cn $ apple-config-realname $ apple-data-stamp $ apple-password-server-location $ apple-password-server-list $ apple-ldap-replica $ apple-ldap-writable-replica $ apple-keyword $ apple-kdc-authkey $ apple-kdc-configdata $ apple-xmlplist $ ttl $ apple-last-serverid $ apple-enabled-auth-mech ) )
I see nothing unusual here.
Yoann Gini wrote:
Le 13 févr. 2015 à 15:09, Andy Dorman adorman@ironicdesign.com a écrit :
The reason you so often see an answer like this is because people like you want Open Source developers to do work for you for free…
You seem to have forgotten what is OpenSource.
Now I'm really getting angry: While Apple has made many billion dollars also with Open Source software they don't contribute to Open Source communities. At least I don't see any contributions.
You should really remind *Apple* about what is Open Source while they are selling it to people like you willing to pay for it.
So don't ask OSS developers to look for Apple's bugs.
Ciao, Michael.
On 02/13/2015 08:33 AM, Yoann Gini wrote:
This is funny, because in Apple communities, people tend to share more and more knowledge AND work for free.
Then please ask them since no one in the openLDAP community has ever seen the behavior you describe.
And it might be interesting to hear their response.
Andy Dorman wrote:
The reason you so often see an answer like this is because people like you want Open Source developers to do work for you for free...
The answer is as Howard said, Apple has modified the code, so pay for a support contract with them and ask them. Or see if they will work for you for free.
Even worse it boils down to work for Apple for free. AFAICS there hasn't been any Apple contribution to the OpenLDAP project.
Ciao, Michael.
Yoann Gini wrote:
Le 13 févr. 2015 à 11:13, Howard Chu hyc@symas.com a écrit :
This has nothing to do with OpenLDAP. You're talking about Apple's privately hacked version of the code. Whatever they do in their custom attributes with their custom plugins is anybody's guess, but don't expect any Standards documented behavior to cover it.
I was hoping to not see an answer like that. So common in all Open Source communities.
You seems really fast to conclude that’s a problem of an hypothetic Apple hack. The source code used by Apple is available here http://opensource.apple.com/source/OpenLDAP/OpenLDAP-491.1/
Do you see a difference with the official repository who can lead to this problem?
I’m not asking for a « go to hell, it’s an Apple hack » answer.
If I’m asking here, it’s because I’m looking for a real valuable answer. Like for example what kind of mechanism in OpenLDAP source code can lead to this situation. An index or something like that for example.
There is no such mechanism in OpenLDAP.
Maybe it’s linked to an Apple hack, maybe not. In any case the only valuable answer for my question is a troubleshooting procedure for this kind of behavior. Nothing else.
There's no MAYBE about it.
Feel free to continue wasting your own time if you don't want to believe me.
Le 13 févr. 2015 à 15:52, Howard Chu hyc@symas.com a écrit :
Maybe it’s linked to an Apple hack, maybe not. In any case the only valuable answer for my question is a troubleshooting procedure for this kind of behavior. Nothing else.
There's no MAYBE about it.
Feel free to continue wasting your own time if you don't want to believe me.
The level of presumptuousness here is too damn high…
Try to read nothing and always say it’s the other guy. Wonderful.
I’m not here to find a man to blame, I’m here to understand how is it possible, asking people who have knowledge on OpenLDAP to explain how it’s possible to troubleshoot such a problem.
And all I found here is presumptuous people who just wan’t to make money. Wonderful…
Yoann Gini wrote:
And all I found here is presumptuous people who just wan’t to make money. Wonderful…
You asked for it. Actually it's only a response on your presumptuous attitude blaming others that they don't know what Open Source means.
Note that you're offending people who have developed and published Open Source code for many many years.
Ciao, Michael.
Le 13 févr. 2015 à 16:17, Michael Ströder michael@stroeder.com a écrit :
Yoann Gini wrote:
And all I found here is presumptuous people who just wan’t to make money. Wonderful…
You asked for it. Actually it's only a response on your presumptuous attitude blaming others that they don't know what Open Source means.
Note that you're offending people who have developed and published Open Source code for many many years.
I’m not offending people who make Open Source software and explain how it works.
I’m offending people who make Open Source software and keep their knowledge for them self just to force selling of support contracts.
The first group is a benediction for all people using computers nowadays. The second one are the bad one.
But don’t worry, I will leave this list. I’m not interested by communities who just don’t care about peoples who want to learn.
Yoann Gini wrote:
Le 13 févr. 2015 à 15:52, Howard Chu hyc@symas.com a écrit :
Maybe it’s linked to an Apple hack, maybe not. In any case the only valuable answer for my question is a troubleshooting procedure for this kind of behavior. Nothing else.
There's no MAYBE about it.
Feel free to continue wasting your own time if you don't want to believe me.
The level of presumptuousness here is too damn high…
Yes, by you. Moron.
Try to read nothing and always say it’s the other guy. Wonderful.
I wrote 80% of the OpenLDAP codebase as it exists today. I know perfectly well what is or isn't in the code. Moron.
I’m not here to find a man to blame, I’m here to understand how is it possible, asking people who have knowledge on OpenLDAP to explain how it’s possible to troubleshoot such a problem.
And all I found here is presumptuous people who just wan’t to make money. Wonderful…
Le 13 févr. 2015 à 17:40, Howard Chu hyc@symas.com a écrit :
The level of presumptuousness here is too damn high…
Yes, by you. Moron.
Try to read nothing and always say it’s the other guy. Wonderful.
I wrote 80% of the OpenLDAP codebase as it exists today. I know perfectly well what is or isn't in the code. Moron.
lol !
So, if you really write 80% of the OpenLDAP codebase, I perfectly understand why you report the error on other people by default.
This is pretty common in computer science « I have the true, other people are moron, I don’t want to share my knowledge because you are too dumb to receive my instructions ».
By the way, buying and selling knowledge is my work. If you really want to have people buying support contract, start by answering their question and then offer a contract instead of sending invoice for each question you don’t want to answer. You will get way more contracts like that.
I fact, I could be interested some day in such a support contract, after all, I’ve a lot of network under my responsibility who use OpenLDAP, but definitively not with you, not with a people with such a lack of modesty, even if you wrote 80% of OpenLDAP.
--On Friday, February 13, 2015 6:11 PM +0100 Yoann Gini yoann.gini@gmail.com wrote:
This is pretty common in computer science « I have the true, other people are moron, I don't want to share my knowledge because you are too dumb to receive my instructions ».
You seem to have a massive misconception that people are trying to hide knowledge from you. No one is attempting to do any such thing. Apple makes significant changes to the OpenLDAP code base that they derive their OpenDirectory platform from. The behavior you are reporting simply does not occur with *stock* OpenLDAP. Ever. So there is no way in which anyone on this list can help you determine why Apple's OpenDirectory is behaving the way it does. The only people with the answer to that information are the people who made the modifications to OpenLDAP for OpenDirectory. That would be Apple, not the OpenLDAP project.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Yoann Gini wrote:
Le 13 févr. 2015 à 17:40, Howard Chu hyc@symas.com a écrit :
The level of presumptuousness here is too damn high…
Yes, by you. Moron.
Try to read nothing and always say it’s the other guy. Wonderful.
I wrote 80% of the OpenLDAP codebase as it exists today. I know perfectly well what is or isn't in the code. Moron.
lol !
So, if you really write 80% of the OpenLDAP codebase, I perfectly
understand why you report the error on other people by default.
This is pretty common in computer science « I have the true, other
people are moron, I don’t want to share my knowledge because you are too dumb to receive my instructions ».
I shared my knowledge with you - I told you there is no such function as you asked about in the OpenLDAP code base, and the question you're asking is specific to Apple's proprietary changes in their build. Those are facts, which you moronically chose to ignore.
By the way, buying and selling knowledge is my work. If you really
want to have people buying support contract, start by answering their question and then offer a contract instead of sending invoice for each question you don’t want to answer. You will get way more contracts like that.
Nobody on this list mentioned support contracts besides *you*. No one here wants to sell you anything. Moron.
openldap-technical@openldap.org
-
Andy Dorman -
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount -
Yoann Gini