The numSubordinates value doesn't always match the number of direct subordinate(s).

[389-ds-bot]

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/51100

• Created at 2020-05-19 12:32:34 by tmihinto
• Closed at 2020-06-09 18:44:15 as fixed
• Assigned to spichugi (@droideck)
• Associated bugzillas
  • https://bugzilla.redhat.com/show_bug.cgi?id=1843550

---

Issue Description

The numSubordinates value should give the number of immediate subordinates.
But it could be inaccurate in some cases ( on root entries ).

Package Version and Platform

$ 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
$

Steps to reproduce

1. Install 389-ds 1.4.2 on RHEL 8.2 ( I can reproduce also on RHEL 7 - 389-ds 1.3.10 ).
2. Create a new suffix with some sample entries.
3. Compare the numSubordinates value on the root entry with the actual number of direct subordinate(s).

Actual results

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-.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-.socket'
  -b "o=test_numSubordinates" -s one 1.1 2>/dev/null | grep -c ^dn:
  4

Expected results

Both values should be identical.

[389-ds-bot]

Comment from tmihinto at 2020-05-19 12:37:16

I can only reproduce with root entries including the special suffix "cn=monitor".
The other special suffixes "cn=config" and "cn=schema" behave correctly.

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2020-05-20 02:41:28

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.

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2020-05-20 02:41:29

Metadata Update from @Firstyear:

• Custom field origin adjusted to None
• Custom field reviewstatus adjusted to None

[389-ds-bot]

Comment from tmihinto at 2020-05-20 10:30:31

Thanks William!

That explains it for the root entries:
$ ldapsearch -LLL -Y EXTERNAL -H 'ldapi://%2fvar%2frun%2fslapd-.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-.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-.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-.socket' -b "cn=monitor" -sone "(|(objectclass=*)(objectclass=ldapsubentry))" 1.1 2>/dev/null | grep -c ^dn:
3
$

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2020-05-21 00:59:38

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?

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2020-05-21 17:46:22

Metadata Update from @mreynolds389:

• Issue priority set to: critical
• Issue set to the milestone: 1.4.1

[389-ds-bot]

Comment from spichugi (@droideck) at 2020-05-21 17:46:31

Metadata Update from @droideck:

• Issue assigned to droideck

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2020-06-03 14:39:36

Metadata Update from @mreynolds389:

• Issue set to the milestone: 1.4.2 (was: 1.4.1)

[389-ds-bot]

Comment from spichugi (@droideck) at 2020-06-09 16:56:56

#4194

[389-ds-bot]

Comment from spichugi (@droideck) at 2020-06-09 18:44:05

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

[389-ds-bot]

Comment from spichugi (@droideck) at 2020-06-09 18:44:15

Metadata Update from @droideck:

• Issue close_status updated to: fixed
• Issue status updated to: Closed (was: Open)

[389-ds-bot]

Comment from spichugi (@droideck) at 2020-06-09 18:44:55

Metadata Update from @droideck:

• Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1843550