attachment
ticket48976_test.py

Per scrum, setting the target milestone to 1.3.5...
Thierry, please reset it to the older versions (e.g., 1.3.4, if needed...)

After offline discussion with Thierry we arrived at the following proposal:

• add an option to set the backend into 'referral on update' after a restore or import.

• the default could be on, so that the problematic scenario is handled by default

• handle the reset of this flag, so that the server is accepting updates again, this could be done under different conditions
  1] allow a manual reset by an admin, admin should ensure replicas are in sync for this replicaID
  2] return to accepting updates after a configured time period, assuming that replicas will get in sync
  3] try to verify if all servers are in sync for the initialized/restored replica ID. This could be done by a method similar to cleanallruv, sending out a EXT op and requesting the maxCSN for the RID and start accepting updates once this maxCSN is available on the current replica.
  Of course, 1] .. 3] should not be exclusive. 1] should always be possible, 3] should stop once a timeout 2] is reached

I'm afraid we have still problems with this approach:

for external ops we can send referrals until state is switched, but what about internal ops, triggered by password policy attr updates or login recording or by plugins.

The proposed solution would show the problems of readonly replicas

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/2035

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.