Tools like Apache Directory Studio use namingContexts on root DSE to show all available trees. In 389-DS, the multi-valued attribute doesn't contain cn=config and cn=monitor.
cn=config
cn=monitor
$ ldapsearch -x -s base -b '' namingContexts dn: namingContexts: cn=changelog namingContexts: dc=ipa,dc=example namingContexts: o=ipaca
Please consider to include both in-memory databases in namingContexts. The lack of cn=config in namingContexts makes rather inconvenient to explore 389-DS configuration with Apache Directory Studio.
I'm on the fence about this. On one hand the standard says all backends should be in the namingContexts section for discoverability.
On the other, these are internal details of the server, which are not real backends - they are "implementation details". Think of it as the "operational attribute" of backends.
I'm erring to standards correctness however, because I think we should do the "right thing", as obscurity does not add security or other niceness, and this is generally only use by applications like apache dirstudio.
Metadata Update from @firstyear: - Custom field component adjusted to None - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Custom field type adjusted to None - Custom field version adjusted to None
In the sense of https://tools.ietf.org/html/rfc4512#section-5, cn=config and cn=monitor being root of subordinates entries are namingcontext of the server. So I tend to agree with the proposal. I do not see special difficulty to implement it. The only non namingcontext being the root DSE.
Metadata Update from @mreynolds: - Issue set to the milestone: 1.4 backlog
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/2689
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 - Issue status updated to: Closed (was: Open)