This has come up because there is a set of customer cases where they have configured it
incorrectly, due to bugs in lib389. The issues in lib389 arise from a lack of
validation/constraint in the checking of the nsslapd-parent-suffix value in the server,
allowing the client to create invalid configurations.
So today, our own tools can easily, and trivially cause this situation.
One thought is to either document this issue or to fix lib389 - but neither of the actions
really fix the underlying problem, which is that our server accepts an invalid
So the best thing for us to do is to make it impossible for the server to get it wrong,
which means we fix lib389 *and* any other admin tooling/scripts in a single pass.
Which is what led to the interest in changing something that has been "working"
for a long time :)
On 14 Oct 2020, at 19:47, Ludwig Krispenz
you are right that it is possible to configure suffix hierarchies which are broken, but
in my experience this wasn't an issue. people using sub suffixes did get it right.
So is there really a need to change something that is working for a long time ?
On 14.10.20 08:12, William Brown wrote:
> This is a draft design, and probably of interest to thierry whom I discussed this
with last night :)
> William Brown
> Senior Software Engineer, 389 Directory Server
> SUSE Labs, Australia
> 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia