(2011年01月06日 09:31), Orion Poplawski wrote:
On 01/05/2011 02:10 PM, Noriko Hosoi wrote:
> I might have missed something in the discussion, but even if
> numsubordinates
> is indexed only with presence:
>
> # dbscan -f numsubordinates.db4 -n -r
> + 3
> 1 3 4
>
> the range search should return the expected result:
>
> $ ldapsearch [...] -b "dc=example,dc=com"
> "*(&(numsubordinates=*)(numsubordinates>=1))*" numsubordinates
entryid
> dn: dc=example,dc=com
> numsubordinates: 4
> entryid: 1
>
> dn: ou=Groups,dc=example,dc=com
> numsubordinates: 4
> entryid: 3
>
> dn: ou=People,dc=example,dc=com
> numsubordinates: 2
> entryid: 4
>
Perhaps the index got corrupted then some how. I've updated the bug
https://bugzilla.redhat.com/show_bug.cgi?id=667488
with some further thoughts about why db2index fails with numsubordinates.
Is there any other way to recreate the index? As it stands now, it is
completely broken.
Could you try exporting the backend into an ldif file and
importing it back?
# cd /usr/lib[64]/dirsrv/slapd-ID
# ./db2ldif -n <backend_name>
If the corrupted index is for o=netscaperoot, <backend_name> is
netscaperoot.
The command returns the exported ldif file path (assuming it is
/path/to/the/exported/ldif/file)
# ./ldif2db -n <backend_name> -i /path/to/the/exported/ldif/file
# ./start-slapd