Thanks,
I may have missed it, but your suggestion about configuring and
behaviour sounds good. I will update my doc.
Regards,
Ludwig
On 10/12/2016 05:19 PM, thierry bordaz wrote:
Hello,
I would think of two options
* If admin decides to switch to backend, it should not be prevented
a
Hello,
I would think of two options
* If admin decides to switch to backend, it should not be prevented
and the backend moves to 'backend'
* periodic (hourly) checking (IMHO not configurable and always run),
checking being the same mechanism as 'auto'
o in-sync->backend
o not-i
On Fri, 2016-10-07 at 17:58 +0200, Ludwig Krispenz wrote:
> there is a problem not yet covered in the proposal: setting the backend
> to "referral-on-update" until the topology is in sync prevents to ealry
> client updates, but what to do about internal updates, eg passwordpolicy
> attributes.
>
there is a problem not yet covered in the proposal: setting the backend
to "referral-on-update" until the topology is in sync prevents to ealry
client updates, but what to do about internal updates, eg passwordpolicy
attributes.
I have a wild idea, but maybe someone has a suggestion on how to
On 09/30/2016 02:15 AM, Noriko Hosoi wrote:
Hi Ludwig,
On 09/29/2016 05:43 AM, Ludwig Krispenz wrote:
This is the initial proposal, thanks for your feedback
http://www.port389.org/docs/389ds/design/delay-accepting-updates-after-init.html
Please help me understanding the design...
I'm ha
Hi Ludwig,
On 09/29/2016 05:43 AM, Ludwig Krispenz wrote:
This is the initial proposal, thanks for your feedback
http://www.port389.org/docs/389ds/design/delay-accepting-updates-after-init.html
Please help me understanding the design...
I'm having a bit hard time to figure out the relatio
