hyc@symas.com wrote:
ryans@aweber.com wrote:
I am experiencing what appears to be the same issue, and opened a ticket - http://www.openldap.org/its/index.cgi?findid=6831 - because this one did not pop up when I searched for existing ITS's (perhaps my search terms did not match or I just overlooked it). As I mentioned in the ticket I opened, this is not a schema issue; all the schema match on every server, and if that were the problem, none of the users would be served properly. What I found is that the keys that proxycache was looking for did not exist in the bdb it was searching. Why exactly that is, I'm not sure. Hopefully the information I provided in that ITS (or, perhaps some additional debugging information - gdb output or copies of databases exhibiting the problem) will help shed some light. If it is indeed the same issue, I'm all for coalescing the two. I have tested this all the way up through 2.4.23, and there are no commits to pcache.c or back-ldap/search.c since 2.4.23 was released that addresses this problem.
Since you are not having the objectclass-related problem described in this ticket it is not the same issue.
Actually, having just tested that theory, I think my problem is actually objectclass-related, because it seems that it only happens when the objectClass attribute is included in the filter, and I can get different results by swapping the order of the filter components. Consider these two users, who have the same objectclasses, same attributes, and differ only in the attribute values (e.g., their name, phone number, and so on):
bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe1))' uid dn: uid=jdoe1,ou=Users,dc=example,dc=com uid: jdoe1
bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe2))' uid
So, one entry doesn't get returned when it should. If I reverse the filter, I get the expected results:
bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe1))' uid dn: uid=jdoe1,ou=Users,dc=example,dc=com uid: jdoe1
bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe2))' uid dn: uid=jdoe2,ou=Users,dc=example,dc=com uid: jdoe2
Furthermore, if I now try the first query again, it too works:
bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe1))' uid dn: uid=jdoe1,ou=Users,dc=example,dc=com uid: jdoe1
bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe2))' uid dn: uid=jdoe2,ou=Users,dc=example,dc=com uid: jdoe2
And, like Jim, I already have the patch for ITS#5756 applied in 2.4.17, 2.4.21, and 2.4.23. I can give you an example database exhibiting this behavior, if you like?