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

Re: Inconsistent answer from LDAP Server

> 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 (
        NAME 'apple-xmlplist'
        DESC 'XML plist data'
        EQUALITY caseExactMatch
        SUBSTR caseExactSubstringsMatch

And here is the definition of the object class:

objectclass (
        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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature