Hi,

For my part, I have seen mapping tree misconfiguration popping from time to time but it is quite rare (maybe 7 or 8 times in 15 years)
So although in pure term or architecture your proposal is IMHO the cleanest, in term of risks it is not a good solution:
there will likely be regressions (it always happens when a component get redesigned)
and that means that the number of people that will be annoyed by the change will be far greater than the few people that will be helped by the change.

So my feeling is that we should rather go for a trade off.
Since the goal is to prevent that user misconfigures the mapping tree without warning,
we should do that without changing the way the mapping tree is handled internally.
simply by adding a consistency check when starting the server or changing the mapping tree configuration.

If we want to limit the risk we could phase things:
in first phase we only log warning if inconsistency are found
and latter on when we get more confident about the code we could reject the configuration change in case of inconsistency

I know that my proposal is less appealing in term of architecture but such a solution is safer because it does not change the way mapping tree are handled and that drastically limits the regression risks

Regards,
Pierre

On Wed, Oct 14, 2020 at 11:23 PM William Brown <wbrown@suse.de> wrote:

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 configuration silently.

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 <krispenz@t-online.de> wrote:
>
> Hi,
>
> 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 ?
>
>
> Regards,
>
> Ludwig
>
>
> On 14.10.20 08:12, William Brown wrote:
>> https://github.com/mreynolds389/389wiki/pull/48
>>
>> This is a draft design, and probably of interest to thierry whom I discussed this with last night :)
>>
>> Thanks!
>>
>> —
>> Sincerely,
>>
>> William Brown
>>
>> Senior Software Engineer, 389 Directory Server
>> SUSE Labs, Australia
>> _______________________________________________
>> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
>> To unsubscribe send an email to 389-devel-leave@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
>> List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
> _______________________________________________
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave@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
> List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave@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
List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org