The numSubordinates value should give the number of immediate subordinates. But it could be inaccurate in some cases ( on root entries ).
$ cat /etc/redhat-release Red Hat Enterprise Linux release 8.2 (Ootpa) $ $ rpm -qa | grep 389-ds-base 389-ds-base-libs-1.4.2.12-2.module+el8dsrv+6428+6e54c518.x86_64 389-ds-base-1.4.2.12-2.module+el8dsrv+6428+6e54c518.x86_64 $
The numSubordinates value for the root entry is always higher ( +1 ) than the number of immediate children.
Value of the numSubordinates attribute on the root entry: $ ldapsearch -LLL -Y EXTERNAL -H 'ldapi://%2fvar%2frun%2fslapd-<INSTANCE>.socket' \ -b "o=test_numSubordinates" -s base "objectclass=*" 1.1 numSubordinates 2> /dev/null dn: o=test_numsubordinates numSubordinates: 5
Actual number of direct children: $ ldapsearch -LLL -Y EXTERNAL -H 'ldapi://%2fvar%2frun%2fslapd-<INSTANCE>.socket' \ -b "o=test_numSubordinates" -s one 1.1 2>/dev/null | grep -c ^dn: 4
Both values should be identical.
I can only reproduce with root entries including the special suffix "cn=monitor". The other special suffixes "cn=config" and "cn=schema" behave correctly.
There are entries that are marked ldapsubentry in the root that you aren't seeing in a search, which is why this number isn't showing you the right amount.
Metadata Update from @firstyear: - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None
Thanks William!
That explains it for the root entries: $ ldapsearch -LLL -Y EXTERNAL -H 'ldapi://%2fvar%2frun%2fslapd-<INSTANCE>.socket' -b "dc=example,dc=com" -s base "objectclass=*" 1.1 numSubordinates 2> /dev/null dn: dc=example,dc=com numSubordinates: 5
$ ldapsearch -LLL -Y EXTERNAL -H 'ldapi://%2fvar%2frun%2fslapd-<INSTANCE>.socket' -b "dc=example,dc=com" -sone "(|(objectclass=*)(objectclass=ldapsubentry))" 1.1 2>/dev/null | grep -c ^dn: 5 $
There seems to be a miscalculation for the "cn=monitor" entry though: $ ldapsearch -LLL -Y EXTERNAL -H 'ldapi://%2fvar%2frun%2fslapd-<INSTANCE>.socket' -b "cn=monitor" -s base "objectclass=*" 1.1 numSubordinates 2> /dev/null dn: cn=monitor numSubordinates: 4
$ ldapsearch -LLL -Y EXTERNAL -H 'ldapi://%2fvar%2frun%2fslapd-<INSTANCE>.socket' -b "cn=monitor" -sone "(|(objectclass=*)(objectclass=ldapsubentry))" 1.1 2>/dev/null | grep -c ^dn: 3 $
cn=monitor is generated in memory and a bit magic, so that's probably not going to be accurate sadly. It's not really worth fixing unless something there is breaking?
Metadata Update from @mreynolds: - Issue priority set to: critical - Issue set to the milestone: 1.4.1
Metadata Update from @spichugi: - Issue assigned to spichugi
Metadata Update from @mreynolds: - Issue set to the milestone: 1.4.2 (was: 1.4.1)
https://pagure.io/389-ds-base/pull-request/51141
af87048..ac58ddf master -> origin/master d3e9456..f5d5fd8 389-ds-base-1.4.2 -> 389-ds-base-1.4.2 a8eca1a..ab22bc8 389-ds-base-1.4.3 -> 389-ds-base-1.4.3
Metadata Update from @spichugi: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Metadata Update from @spichugi: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1843550
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/4153
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.