Re: Subsuffixes not displaying

[Pierre Rogier]

Hi Jason,

In theory you should be able to have the same behavior:
  Here is a small table that summarizes the behavior.

Old Version
New version

subsuffix 2 suffixes subsuffix 2 suffixes
subtree search behavior on “parent” suffix see entries on both suffix see
only parent suffix see entries on both suffix see only parent suffix
subsuffix mapping tree attribute: nsslapd-parent-suffix set unset ignored
ignored
subsuffix mapping tree attribute: orphan N/A N/A unset set

default when using dsconf backend create –suffix subsuffix
without setting –parent-suffix No Yes Yes No

IMHO you should first check  the mapping tree entries: i.e ldapsearch -b
cn=config "(objectclass=nsMappingTree)"
in your case you should not orphan the subsuffix as you want to be able to
able to get the subsuffix entries while searching the parent suffix

Regards,
   Pierre

On Wed, May 3, 2023 at 5:56 PM Jason Villarroel  wrote:
> Hello,
>
> We are having an issue when using an ldap browser or even the ldapsearch
> command subsuffixes that are on a separate backend database are not
> displayed when specifying the parent suffix as the base dn.  In previous
> versions when specifying the parent suffix as the base dn the subsuffixes
> were listed.  Currently only entries related to the primary userRoot
> database are displayed.  The root dse also does not display the subsuffixes.
>
> If we run the "dsconf INSTANCE backend suffix set --enable-orphan dbname"
> command the missing suffix appears in the root dse but still does not
> appear in when listing the entries in the base dn.
>
> The subsuffixes are accessible if we specify them as the base dn or access
> them via the built in ldap browser vi cockpit.
>
> You can perform the following ldap search on V11 and V12 and will see the
> differences in the results:
>
> ldapsearch -D "cn=manager" -W -b "dc=example,dc=com" -s one -x
> "(objectclass=*)" dn
>
> V11 returns
>
> # numResponses: 15
> # numEntries: 14
>
> V12 returns
>
> # numResponses: 12
> # numEntries: 11
>
> Version we have installed
>
> 389-ds-base-libs-2.2.6-2.el8.x86_64
>
> 389-ds-base-2.2.6-2.el8.x86_64
>
> Previous versions we were running
>
> 389-ds-base-libs-1.4.3.13-1
>
> 389-ds-base-1.4.3.13-1
>
> Jason Villarroel
>
> Systems Administrator
>
> Florida International University
>
> Division of Information Technology – Enterprise Systems
>
> PC 120
>
> 305-348-2687 (Office)
>
> 305-348-3686 (Fax)
>
> https://fiu.service-now.com/sp?id=kb_article&sys_id=dd81ca14db54fa4019f173921f961945
>
> *Division of Information Technology staff will never ask for your
> password.*
>
> *Never email your password or share confidential information in emails.*
>
> 389-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]....
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

Subsuffixes not displaying

[Jason Villarroel]

Hello Pierre,

We created a new root suffix on one of our DR servers called dc=oestest,dc=fiu and created a sub suffix ou=testentry,ou=oestest,dc=fiu and still encountered same behavior.

Performing the search ldapsearch -D "cn=manager" -W -b cn=config "(objectclass=nsMappingTree)" displayed the test entry having dc=oestest,dc=fiu as the parent suffix.

dn: cn=dc\3Doestest\2Cdc\3Dfiu,cn=mapping tree,cn=config
objectClass: top
objectClass: extensibleObject
objectClass: nsMappingTree
cn: dc=oestest,dc=fiu
cn: dc=oestest,dc=fiu
nsslapd-state: backend
nsslapd-backend: testoestest

# ou\3Dtestentry\2Cdc\3Doestest\2Cdc\3Dfiu, mapping tree, config
dn: cn=ou\3Dtestentry\2Cdc\3Doestest\2Cdc\3Dfiu,cn=mapping tree,cn=config
objectClass: top
objectClass: extensibleObject
objectClass: nsMappingTree
cn: ou=testentry,dc=oestest,dc=fiu
cn: ou=testentry,dc=oestest,dc=fiu
nsslapd-state: backend
nsslapd-backend: testentrydb
nsslapd-parent-suffix: dc=oestest,dc=fiu

Using an ldap browser and using the the manager account with the base dn of the root suffix only displayed the root suffix and not the subsuffix. Similar behavior was seen when running an ldap search with the -s one parameter.  If the ldapsearch was performed with the -s sub parameter, then the OU was displayed.

It seems that with this version subsuffixes on different databases are not displayed and only OUs from the root suffix are displayed.

Please advise.
Thank you.

Jason Villarroel
Systems Administrator
Florida International University
Division of Information Technology – Enterprise Systems
PC 120
305-348-2687 (Office)
305-348-3686 (Fax)

[cid:image001.png@01D97E6B.C46F9DF0]https://fiu.service-now.com/sp?id=kb_article&sys_id=dd81ca14db54fa4019f173921f961945
Division of Information Technology staff will never ask for your password.
Never email your password or share confidential information in emails.

From: Pierre Rogier 
Sent: Wednesday, May 3, 2023 12:41 PM
To: General discussion list for the 389 Directory server project. 
Subject: [389-users] Re: Subsuffixes not displaying

Note: This message originated from outside the FIU Faculty/Staff email system.

Hi Jason,

In theory you should be able to have the same behavior:
  Here is a small table that summarizes the behavior.
Old Version
New version
subsuffix
2 suffixes
subsuffix
2 suffixes
subtree search behavior on “parent” suffix
see entries on both suffix
see only parent suffix
see entries on both suffix
see only parent suffix
subsuffix mapping tree attribute: nsslapd-parent-suffix
set
unset
ignored
ignored
subsuffix mapping tree attribute: orphan
N/A
N/A
unset
set
default when using dsconf backend create –suffix subsuffix
without setting –parent-suffix
No
Yes
Yes
No

IMHO you should first check  the mapping tree entries: i.e ldapsearch -b cn=config "(objectclass=nsMappingTree)"
in your case you should not orphan the subsuffix as you want to be able to able to get the subsuffix entries while searching the parent suffix

Regards,
   Pierre

On Wed, May 3, 2023 at 5:56 PM Jason Villarroel <[e-mail]> wrote:
Hello,
We are having an issue when using an ldap browser or even the ldapsearch command subsuffixes that are on a separate backend database are not displayed when specifying the parent suffix as the base dn.  In previous versions when specifying the parent suffix as the base dn the subsuffixes were listed.  Currently only entries related to the primary userRoot database are displayed.  The root dse also does not display the subsuffixes.

If we run the "dsconf INSTANCE backend suffix set --enable-orphan dbname" command the missing suffix appears in the root dse but still does not appear in when listing the entries in the base dn.

The subsuffixes are accessible if we specify them as the base dn or access them via the built in ldap browser vi cockpit.

You can perform the following ldap search on V11 and V12 and will see the differences in the results:

ldapsearch -D "cn=manager" -W -b "dc=example,dc=com" -s one -x "(objectclass=*)" dn

V11 returns
# numResponses: 15
# numEntries: 14

V12 returns
# numResponses: 12
# numEntries: 11

Version we have installed
389-ds-base-libs-2.2.6-2.el8.x86_64
389-ds-base-2.2.6-2.el8.x86_64

Previous versions we were running
389-ds-base-libs-1.4.3.13-1
389-ds-base-1.4.3.13-1

Jason Villarroel
Systems Administrator
Florida International University
Division of Information Technology – Enterprise Systems
PC 120
305-348-2687 (Office)
305-348-3686 (Fax)

[cid:image001.png@01D97E6B.C46F9DF0]https://urldefense.com/v3/__https:/fiu.service-now.com/sp?id=kb_article&sys_id=dd81ca14db54fa4019f173921f961945__;!!FjuHKAHQs5udqho!N0b20VqfDVYeyNKIsCxzdw2GMlMjUh2CIpe5miNdHLs-k5-TpUpkLyk6oIxILuBie2CvZOWeZasaDG1O$
Division of Information Technology staff will never ask for your password.
Never email your password or share confidential information in emails.

_______________________________________________
389-users mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/https://urldefense.com/v3/__https:/docs.fedoraproject.org/en-US/project/code-of-conduct/__;!!FjuHKAHQs5udqho!N0b20VqfDVYeyNKIsCxzdw2GMlMjUh2CIpe5miNdHLs-k5-TpUpkLyk6oIxILuBie2CvZOWeZaoA4P_9$
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelineshttps://urldefense.com/v3/__https:/fedoraproject.org/wiki/Mailing_list_guidelines__;!!FjuHKAHQs5udqho!N0b20VqfDVYeyNKIsCxzdw2GMlMjUh2CIpe5miNdHLs-k5-TpUpkLyk6oIxILuBie2CvZOWeZVMhiBdc$
List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....https://urldefense.com/v3/__https:/lists.fedoraproject.org/archives/list/[e-mail]__;!!FjuHKAHQs5udqho!N0b20VqfDVYeyNKIsCxzdw2GMlMjUh2CIpe5miNdHLs-k5-TpUpkLyk6oIxILuBie2CvZOWeZREaC4TI$
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issuehttps://urldefense.com/v3/__https:/pagure.io/fedora-infrastructure/new_issue__;!!FjuHKAHQs5udqho!N0b20VqfDVYeyNKIsCxzdw2GMlMjUh2CIpe5miNdHLs-k5-TpUpkLyk6oIxILuBie2CvZOWeZV1J6VcU$

--
--

389 Directory Server Development Team