-
Bug
-
Resolution: Unresolved
-
Undefined
-
rhel-8.10
-
None
-
No
-
None
-
rhel-idm-ds
-
ssg_idm
-
0
-
False
-
False
-
-
None
-
None
-
None
-
None
-
Unspecified
-
Unspecified
-
Unspecified
-
-
x86_64
-
None
What were you trying to do that didn't work?
By default changelog maxage (nsslapd-changelogmaxage) is set to -1.
By default the replica purge delay (nsds5ReplicaPurgeDelay) is 7 days.
I think the default maxage should be forced to be proportional (computed from) the purge delay. Indeed the purge delay remove the timestamp (csn) of a given value. Making it very old. If we receive an update from a old changelog, the update whatever its age, will supersede the current value.
I believe maxage should be equal to purgedelay.
What is the impact of this issue to you?
I am afraid that entry could diverge.
In addition it is frequent to forget to set CL maxage. So it grows indefinitely and it is useless and possibly dangereous
Please provide the package NVR for which the bug is seen:
all versions
How reproducible is this bug?:
A 'possible' test case for example (I have not tested it) is
* in S1-S2 topology, add an entry with an attribute 'desc'
* pause the RAs
* On S1 set the value 'desc: value_1'
* On S2, add value 'desc: value_1'
* On S2, del value 'desc: value_1'
* wait for longer that purgedelay
* On S2, add value 'desc: value_2'
* Here on S1 we have 'desc: value_1', on S2 we have 'desc: value_2'
* resume RA
* S1 sends 'value_1' that is more recent (because it has a csn) the deleted:value_1 on S2
So after replication S1 should have 'value_2' and S2 should have 'value_1 and value_2'
Expected results
No need to keep a changelog significantly larger than purgedelay
Actual results
CL is by default not limited in age and can grow indefinitely
Risk of entry that diverge on servers