RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1067090 - Missing warning for invalid replica backoff configuration
Summary: Missing warning for invalid replica backoff configuration
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.0
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: rc
: ---
Assignee: mreynolds
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-19 16:24 UTC by Milan Kubík
Modified: 2020-09-13 20:57 UTC (History)
4 users (show)

Fixed In Version: 389-ds-base-1.3.3.1-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-05 09:33:53 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 1045 0 None None None 2020-09-13 20:57:31 UTC
Red Hat Product Errata RHSA-2015:0416 0 normal SHIPPED_LIVE Important: 389-ds-base security, bug fix, and enhancement update 2015-03-05 14:26:33 UTC

Description Milan Kubík 2014-02-19 16:24:19 UTC 
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.
Comment 2 Noriko Hosoi 2014-02-20 18:08:30 UTC 
Upstream ticket:
https://fedorahosted.org/389/ticket/47710
Comment 4 mreynolds 2014-07-14 19:47:36 UTC 
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
Comment 5 Milan Kubík 2014-07-15 10:03:26 UTC 
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.
Comment 6 mreynolds 2014-07-15 16:53:23 UTC 
Ah ok, I see - its no problem.

Fixed upstream.
Comment 8 Viktor Ashirov 2015-01-23 14:45:16 UTC 
$ 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.
Comment 9 Viktor Ashirov 2015-01-23 14:46:54 UTC 
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?
Comment 10 mreynolds 2015-01-23 14:53:39 UTC 
(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...
Comment 11 Noriko Hosoi 2015-01-23 17:21:48 UTC 
(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...
Comment 12 mreynolds 2015-01-23 18:01:52 UTC 
(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...
Comment 13 Viktor Ashirov 2015-01-26 09:22:26 UTC 
Marking this bug as VERIFIED. New bug for 7.2: https://bugzilla.redhat.com/show_bug.cgi?id=1185774
Comment 15 errata-xmlrpc 2015-03-05 09:33:53 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.