(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 -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
