Hi Pierre,
you expressed my concerns much clearer. I agree with you,
Thanks,
Ludwig
On 15.10.20 13:00, Pierre Rogier wrote:
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(a)suse.de
<mailto: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(a)t-online.de
<mailto: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(a)lists.fedoraproject.org
<mailto:389-devel@lists.fedoraproject.org>
>> To unsubscribe send an email to
389-devel-leave(a)lists.fedoraproject.org
<mailto: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.fedoraproje...
> _______________________________________________
> 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
<mailto:389-devel@lists.fedoraproject.org>
> To unsubscribe send an email to
389-devel-leave(a)lists.fedoraproject.org
<mailto: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.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
_______________________________________________
389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
<mailto:389-devel@lists.fedoraproject.org>
To unsubscribe send an email to
389-devel-leave(a)lists.fedoraproject.org
<mailto: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.fedoraproje...
--
--
389 Directory Server Development Team
_______________________________________________
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
List Archives:
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproje...