#51023 nsUniqueId appears in rootDSE search
Closed: wontfix by spichugi. Opened by vashirov.

Issue Description

I was investigating failures reported by rfc3673_all_oper_attrs_test.py.
On the latest master it fails because nsUniqueId is no longer present during the search on rootDSE. On 1.3.x it's there and the test passes.
But looks like this attribute is present right after the instance is created, but after a reboot it's no longer present.

[root@server-rhel78 ds]# ldapsearch -xLLL -D cn=directory\ manager -w password -b "" -s base -h localhost:38901 "(objectClass=*)"  nsUniqueId
dn:
nsUniqueId: d366bd00-7b0511ea-80000000-00000000
[root@server-rhel78 ds]# restart-dirsrv 
Restarting instance "standalone1"
[root@server-rhel78 ds]# ldapsearch -xLLL -D cn=directory\ manager -w password -b "" -s base -h localhost:38901 "(objectClass=*)"  nsUniqueId
dn:
[root@server-rhel78 ds]# 

I amended the test in PR#51011 to exclude this attribute on rootDSE search if found, but I feel we should not be adding it in the first place.


I'd say at least we should be consistent - we either have it or dont. I see no harm in having it in the rootDSE, and could be easier to amke it persistent over trying to remove it ....

Metadata Update from @firstyear:
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.4.4

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/4076

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.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

Metadata