On 01/05/2011 09:16 AM, Orion Poplawski wrote:
> On 01/05/2011 09:06 AM, Rich Megginson wrote:
>> Try doing the ldapsearch you used to test, but add numSubordinates to
>> the list
>> of attributes to return:
>>
>> ldapsearch .... "big filter with (numSubordinates>=1) clause removed" *
>> numSubordinates
>
> Okay, something is wrong here. These results appear correct:
Looks like a problem with the numSubordinates index - it looks like it
is only indexed for presence - try adding an equality index for
numSubordinates and reindex.

I don't know when or why this changed - looks like a regression.

>
> [root@earth slapd-cora]# ldapsearch -Z -x -b "dc=cora,dc=nwra,dc=com"
> -s one numSubordinates
> # extended LDIF
> #
> # LDAPv3
> # base <dc=cora,dc=nwra,dc=com> with scope oneLevel
> # filter: (objectclass=*)
> # requesting: numSubordinates
> #
>
> # nis, cora.nwra.com
> dn: ou=nis,dc=cora,dc=nwra,dc=com
> numSubordinates: 0
>
> # auto.master, cora.nwra.com
> dn: ou=auto.master,dc=cora,dc=nwra,dc=com
> numSubordinates: 4
>
> # auto.home, cora.nwra.com
> dn: ou=auto.home,dc=cora,dc=nwra,dc=com
> numSubordinates: 88
>
> # auto.data, cora.nwra.com
> dn: ou=auto.data,dc=cora,dc=nwra,dc=com
> numSubordinates: 21
>
> # auto.nfs, cora.nwra.com
> dn: ou=auto.nfs,dc=cora,dc=nwra,dc=com
> numSubordinates: 3
>
> # auto.datag, cora.nwra.com
> dn: ou=auto.datag,dc=cora,dc=nwra,dc=com
> numSubordinates: 21
>
> # auto.data4, cora.nwra.com
> dn: ou=auto.data4,dc=cora,dc=nwra,dc=com
> numSubordinates: 21
>
> # auto.data4g, cora.nwra.com
> dn: ou=auto.data4g,dc=cora,dc=nwra,dc=com
> numSubordinates: 21
>
> # search result
> search: 3
> result: 0 Success
>
> # numResponses: 9
> # numEntries: 8
>
>
> But this is wrong:
>
> [root@earth slapd-cora]# ldapsearch -Z -x -b "dc=cora,dc=nwra,dc=com"
> -s one 'numSubordinates>=1' numSubordinates
> # extended LDIF
> #
> # LDAPv3
> # base <dc=cora,dc=nwra,dc=com> with scope oneLevel
> # filter: numSubordinates>=1
> # requesting: numSubordinates
> #
>
> # auto.home, cora.nwra.com
> dn: ou=auto.home,dc=cora,dc=nwra,dc=com
> numSubordinates: 88
>
> # auto.data, cora.nwra.com
> dn: ou=auto.data,dc=cora,dc=nwra,dc=com
> numSubordinates: 21
>
> # auto.datag, cora.nwra.com
> dn: ou=auto.datag,dc=cora,dc=nwra,dc=com
> numSubordinates: 21
>
> # auto.data4, cora.nwra.com
> dn: ou=auto.data4,dc=cora,dc=nwra,dc=com
> numSubordinates: 21
>
> # auto.data4g, cora.nwra.com
> dn: ou=auto.data4g,dc=cora,dc=nwra,dc=com
> numSubordinates: 21
>
> # search result
> search: 3
> result: 0 Success
>
> # numResponses: 6
> # numEntries: 5
>
>
> This works:
> ldapsearch -Z -x -b "dc=cora,dc=nwra,dc=com" -s one
> 'numSubordinates>0' numSubordinates
> # numResponses: 9
> # numEntries: 8
>
> I also tried >=2 through >=4 but none returned auto.master. >=22
> successfully eliminated the auto.data* entries.
>
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

On 01/05/2011 09:55 AM, Rich Megginson wrote:
> On 01/05/2011 09:16 AM, Orion Poplawski wrote:
>> On 01/05/2011 09:06 AM, Rich Megginson wrote:
>>> Try doing the ldapsearch you used to test, but add numSubordinates to the list
>>> of attributes to return:
>>>
>>> ldapsearch .... "big filter with (numSubordinates>=1) clause removed" *
>>> numSubordinates
>>
>> Okay, something is wrong here. These results appear correct:
> Looks like a problem with the numSubordinates index - it looks like it is only
> indexed for presence - try adding an equality index for numSubordinates and
> reindex.
>
> I don't know when or why this changed - looks like a regression.

I added an index for equality by adding nsIndexTypes: eq to:

cn=numsubordinates,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,dn=config
cn=numsubordinates,cn=index,cn=NetscapeRoot,cn=ldb m database,cn=plugins,dn=config
cn=numsubordinates,cn=default indexes,cn=config,cn=ldbm
database,cn=plugins,dn=config

I triggered an index rebuild by adding:


dn: cn=db2index_2011_1_5_11_21_50, cn=index, cn=tasks, cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
cn: db2index_2011_1_5_11_21_50
nsInstance: userRoot
nsIndexAttribute: numsubordinates:eq


Saw in the error log:

[05/Jan/2011:11:30:26 -0700] - userRoot: Indexing attribute: numsubordinates
[05/Jan/2011:11:30:27 -0700] - userRoot: Finished indexing.

But now my numSubordinates>=1 search comes up empty. Interestingly,
numSubordinates>4 doesn't work either, but in this case it returns all, even
those with numSubordinates <= 4.

Restarting the slapd process didn't help.

Filed https://bugzilla.redhat.com/show_bug.cgi?id=667488

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

On 01/05/2011 11:39 AM, Orion Poplawski wrote:
> On 01/05/2011 09:55 AM, Rich Megginson wrote:
>> On 01/05/2011 09:16 AM, Orion Poplawski wrote:
>>> On 01/05/2011 09:06 AM, Rich Megginson wrote:
>>>> Try doing the ldapsearch you used to test, but add numSubordinates
>>>> to the list
>>>> of attributes to return:
>>>>
>>>> ldapsearch .... "big filter with (numSubordinates>=1) clause
>>>> removed" *
>>>> numSubordinates
>>>
>>> Okay, something is wrong here. These results appear correct:
>> Looks like a problem with the numSubordinates index - it looks like
>> it is only
>> indexed for presence - try adding an equality index for
>> numSubordinates and
>> reindex.
>>
>> I don't know when or why this changed - looks like a regression.
>
> I added an index for equality by adding nsIndexTypes: eq to:
>
> cn=numsubordinates,cn=index,cn=userRoot,cn=ldbm
> database,cn=plugins,dn=config
> cn=numsubordinates,cn=index,cn=NetscapeRoot,cn=ldb m
> database,cn=plugins,dn=config
> cn=numsubordinates,cn=default indexes,cn=config,cn=ldbm
> database,cn=plugins,dn=config
>
> I triggered an index rebuild by adding:
>
>
> dn: cn=db2index_2011_1_5_11_21_50, cn=index, cn=tasks, cn=config
> changetype: add
> objectclass: top
> objectclass: extensibleObject
> cn: db2index_2011_1_5_11_21_50
> nsInstance: userRoot
> nsIndexAttribute: numsubordinates:eq
>
>
> Saw in the error log:
>
> [05/Jan/2011:11:30:26 -0700] - userRoot: Indexing attribute:
> numsubordinates
> [05/Jan/2011:11:30:27 -0700] - userRoot: Finished indexing.
>
> But now my numSubordinates>=1 search comes up empty. Interestingly,
> numSubordinates>4 doesn't work either, but in this case it returns
> all, even those with numSubordinates <= 4.
>
> Restarting the slapd process didn't help.
>
> Filed https://bugzilla.redhat.com/show_bug.cgi?id=667488
What does dbscan say?
dbscan -f /var/lib/dirsrv/slapd-instancename/db/userRoot/numsubordinates.db4
?

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

On 01/05/2011 01:46 PM, Rich Megginson wrote:
> On 01/05/2011 11:39 AM, Orion Poplawski wrote:
>> Filed https://bugzilla.redhat.com/show_bug.cgi?id=667488
> What does dbscan say?
> dbscan -f /var/lib/dirsrv/slapd-instancename/db/userRoot/numsubordinates.db4
> ?

So, my numsubordinates.db4 file has been wiped out apparently by db2index, and
I cannot get it back. I've updated the bug with this information.

Thanks everyone for their help. Hopefully we can figure this out soon.

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users