This content has been marked as final. Show 5 replies
just looking at the access log, the output of the first search (the one performed by the Solaris client) basically queries/handles the first 1000 records, whereas the second search (issued by the linux client) is getting far more results even though the search filter in theory is more restrictive (having a logical AND plus: &(objectClass=tsgposixaccount) )
Did you by chance implemented the nsslapd-search-tune parameter in the dse.ldif, activating bits 8 and 16? We don't see the 'notes=F' that is generally applied when filters are skipped, but it could be due to the fact that we already have the 'notes=U' for the unindexed search on (presumably: objectClass=tsgposixaccount). And in the end, the fact that one of the components of the filter is unindexed could lead to have in the result set also entries not matching the search filter.
No - I have not implemented nsslapd-search-tune on any of the directory servers. The only real change I have made was adding a second VLV to handle linux systems. It seems that in Solaris, with the NS_LDAP_SERVICE_SEARCH_DESC set to (&(tsgunixstatus=A)(|(tsgservergroup=USERS)(tsgservergroup=ec_prod))) for a filter that that is the filter that it uses in the search. Linux, on the other hand, tags an additional &(objectclass=tsgposixaccount) on to the front of the filter, so I added a second VLV to match that.
Now the one thing that I am not sure about on the Linux side is what to set the vlvSort to in the VLV index. I set it to the same as solaris uses, cn uid, but I never could find any documentation to see if this was correct.
Since the filters are different, you can't have a single VLV index match both requests.
The filter used to construct the VLV index HAS to match the request filter for the VLV index to be used (base has to match too - does in this case).
Yu either need to modify the search filter coming from Linux or create a second VLV index using the Linux filter.
I did create a separate Linux filter. It matches to the filter that I see in the access log. Still does not work.
What happens if you change the linux query or just run an ldapsearch command with the following filter:
filter="(&(tsgunixstatus=A)(|(tsgservergroup=USERS)(tsgservergroup=nec_dev)))" attrs="uid userPassword uidNumber gidNumber cn tsglinuxhomedirectory tsglinuxloginshell gecos description objectClass"