Red Hat Bugzilla – Bug 1067090
Missing warning for invalid replica backoff configuration
Last modified: 2015-03-05 04:33:53 EST
Description of problem: In the scenarios where nsds5ReplicaBackoffMin > nsds5ReplicaBackoffMax, an error/warning is logged to indicate the inconsistency. The warning is not displayed when nsds5ReplicaBackoffMax is set to zero. (The default value is used.) Version-Release number of selected component (if applicable): 389-ds-base-1.3.1.6-18.el7 Steps to Reproduce: 1. Set up a replica 2. Configure the attributes such as nsds5ReplicaBackoffMin > nsds5ReplicaBackoffMax and nsds5ReplicaBackoffMax == 0 3. Start the instance/Trigger the replication backoff Actual results: The warning is not logged. Expected results: The warning is logged.
Upstream ticket: https://fedorahosted.org/389/ticket/47710
Milan, How exactly are you setting the configuration attributes? You should be using ldapmodify, and not directly editing the dse.ldif ldapmodify ... dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype: modify add: nsds5ReplicaBackoffMax nsds5ReplicaBackoffMax: 0 modifying entry "cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" ldap_modify: Server is unwilling to perform (53) additional info: attribute nsds5ReplicaBackoffMax value (0) is invalid, must be a number greater than zero. Now, directly editing the dse.ldif file does not report a warning at server startup. I will work on this, although it's really an invalid way to set the configuration. Regards, Mark
I think this bug was opened after bug1064986. If I recall correctly, Nathan suggested that I test the new feature by manually updating dse.ldif this way.
Ah ok, I see - its no problem. Fixed upstream.
$ rpm -qa | grep 389 389-ds-base-debuginfo-1.3.3.1-11.el7.x86_64 389-ds-base-libs-1.3.3.1-11.el7.x86_64 389-ds-base-1.3.3.1-11.el7.x86_64 In dse.ldif: [1] nsds5ReplicaBackoffMin > nsds5ReplicaBackoffMax nsds5ReplicaBackoffMax: 3 nsds5ReplicaBackoffMin: 10 After start in error log: [23/Jan/2015:15:37:48 +0100] NSMMReplicationPlugin - Backoff minimum (10) can not be greater than the backoff maximum (3). Using default values: min (3) max (300) [2] Zero values: nsds5ReplicaBackoffMax: 0 nsds5ReplicaBackoffMin: 0 After start in error log: [23/Jan/2015:15:39:10 +0100] NSMMReplicationPlugin - Invalid value for nsds5ReplicaBackoffMin: 0 Using default value (3) [23/Jan/2015:15:39:10 +0100] NSMMReplicationPlugin - Invalid value for nsds5ReplicaBackoffMax: 0 Using default value (300) Marking bug as VERIFIED.
The only issue is that in case [1] when I update nsds5ReplicaBackoffMin and nsds5ReplicaBackoffMax dynamically via cn=config, it silently accepts new values, no warning message is logged. Should I open another bug for that?
(In reply to Viktor Ashirov from comment #9) > The only issue is that in case [1] when I update nsds5ReplicaBackoffMin and > nsds5ReplicaBackoffMax dynamically via cn=config, it silently accepts new > values, no warning message is logged. Should I open another bug for that? No, we can use this same bug to address this...
(In reply to mreynolds from comment #10) > (In reply to Viktor Ashirov from comment #9) > > The only issue is that in case [1] when I update nsds5ReplicaBackoffMin and > > nsds5ReplicaBackoffMax dynamically via cn=config, it silently accepts new > > values, no warning message is logged. Should I open another bug for that? > > No, we can use this same bug to address this... Is it severe enough to convince PM to give us a blocker+ flag at this very late moment? It does not look so to me... In such case, as Viktor suggested, we should set VERIFIED to this bug for RHEL-7.1 and open a new one for RHEL-7.2...
(In reply to Noriko Hosoi from comment #11) > (In reply to mreynolds from comment #10) > > (In reply to Viktor Ashirov from comment #9) > > > The only issue is that in case [1] when I update nsds5ReplicaBackoffMin and > > > nsds5ReplicaBackoffMax dynamically via cn=config, it silently accepts new > > > values, no warning message is logged. Should I open another bug for that? > > > > No, we can use this same bug to address this... > > Is it severe enough to convince PM to give us a blocker+ flag at this very > late moment? It does not look so to me... No, of course not. Sorry I did not mean it should be a blocker. > > In such case, as Viktor suggested, we should set VERIFIED to this bug for > RHEL-7.1 and open a new one for RHEL-7.2... Agreed. Putting it back on QA so it can be marked verified...
Marking this bug as VERIFIED. New bug for 7.2: https://bugzilla.redhat.com/show_bug.cgi?id=1185774
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0416.html