the ldapsearch should read -Z -x, not -X -x.

You wrote "only about half of my posixgroup objects are returned". Could you tell us what's the difference between the 2 sets -- a returned posixgroup set and another not-returned set?

I'm guessing the cause now... Do you have an index on gidnumber? Did you have a chance to generate it in the middle that the server already has posixgroup entries? For instance, you had posixgroup entries gidnumber={1,2,3}, generate an index on gidnumber, then added more posixgroup entries gidnumber={4,5,6}? Did the server return only gidnumber={4,5,6} to your ldapsearch request?

If that's the case, you could reindex gidnumber using db2index{.pl} utility.

And your sample filter '(&objectClass=posixGroup)(cn=)(&(gidNumber=)(!gidNumber=0))))' is invalid... Could it be '(&(objectClass=posixGroup)(cn=)(&(gidNumber=)(!(gidNumber=0))))'?

yes, your corrected filter is what I intended to type, my ldap server is on a disconnected network, and I had to retype it.

I have not yet figured out what is different between those groups that are returned and those that are not. I will try regenerating indexes with the db2index command as you suggest and get back to you.

dbindex and dbindex.pl both give errors, dbindex that ./ns-slapd is not a command (using the epel rpms, ns-slapd is in /usr/sbin) and dbindex.pl saying that it cannot add an entry under tasks.

However, I was able to delete a bunch of indexes through the console UI, under userRoot "Additional Indexes" and now all groups are returned.

Is that the expected behavior? that once I create an index it does not get updated?

Replying to [comment:4 lschierer]:

dbindex and dbindex.pl both give errors, dbindex that ./ns-slapd is not a command (using the epel rpms, ns-slapd is in /usr/sbin) and dbindex.pl saying that it cannot add an entry under tasks.

That's really odd. The utility "db2index" change dir to /usr/sbin, then call ./ns-slapd. What do you get if you run "file /usr/sbin/ns-slapd"?

db2index.pl requires Directory manager privilege. Did you run like this?

./db2index.pl -D 'cn=directory manager' -w password -n userRoot -t cn

adding new entry "cn=db2index_2013_1_11_11_5_51, cn=index, cn=tasks, cn=config"

However, I was able to delete a bunch of indexes through the console UI, under userRoot "Additional Indexes" and now all groups are returned.

What indexes did you delete? If you don't need them, that's fine. But some search speed would go down without indexes. For instance, search with "(gidNumber=100)", if you have an index file on gidnumber, it searches "(gidNumber=100)" in the index file and gets the entry ID. Using the entry ID, you can retieve the entry from the primary db file id2entry. Without the index file, it directly goes to the primary db file and check every single entry to look for the entry that satisfies "(gidNumber=100)". You'll get the same result, but the elapsed time would be different.

Is that the expected behavior? that once I create an index it does not get updated?

Once you create an index file, entries added or modified after the creation would be taken care correctly. (So no problem to worry about.) But if you already have some entries, then you decide to index one of the attributes, then the pre-existing attribute values are not automatically put into the index file unless you reindex it.

Here's the latter scenario I meant.
{{{
1. You have 2 entries:
dn: cn=A,o=X
uidNumber: 500
gidNumber: 500

dn: cn=B,o=X
uidNumber: 501
gidNumber: 501
2. You create an index on uidNumber and gidNumber
3. You add 2 more entries.
dn: cn=C,o=X
uidNumber: 502
gidNumber: 502

dn: cn=D,o=X
uidNumber: 503
gidNumber: 503
4. If you run search with "(uidNumber=)" or "(gidNumber=)", search would return only cn=C and cn=D.
}}}
That is, entries added after generating the index files are correctly added to the indexes, but not the pre-existing ones.

To fix this problem, after the operation 2, you could reindex uidNumber and gidNumber using the command-line tools or Console.
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Indexes-Creating_Indexes.html

I deleted gidnumber memberuid cn sn memberof uniquemember

looking at your example command of db2index.pl, I had misunderstood the -n flag. when I use the right value, userRoot, the db2index.pl works.

Thanks for your help!!!

Replying to [comment:6 lschierer]:

I deleted gidnumber memberuid cn sn memberof uniquemember

looking at your example command of db2index.pl, I had misunderstood the -n flag. when I use the right value, userRoot, the db2index.pl works.

Thanks for your help!!!

Great news!! Now, your search with the filter '(&(objectClass=posixGroup)(cn=)(&(gidNumber=)(!(gidNumber=0))))' is working as expected?

If yes, may I close this ticket?

Yes, and yes, this ticket can be closed.

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/553

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.