Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 782975 - krbExtraData is being null modified and replicated on each ssh login
krbExtraData is being null modified and replicated on each ssh login
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base (Show other bugs)
6.3
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Rich Megginson
Sankar Ramalingam
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-18 19:28 EST by Dmitri Pal
Modified: 2013-02-21 03:16 EST (History)
5 users (show)

See Also:
Fixed In Version: 389-ds-base-1.2.11.12-1.el6
Doc Type: Enhancement
Doc Text:
Feature: replication Reason: certain binds would cause only modifiersname/modifystimestamp to be updated, and this would lead to unneccessary replication traffic. Result: less replicatin traffic caused by binds.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-21 03:16:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0503 normal SHIPPED_LIVE Moderate: 389-ds-base security, bug fix, and enhancement update 2013-02-21 03:18:44 EST

  None (edit)
Description Dmitri Pal 2012-01-18 19:28:40 EST
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/freeipa/ticket/2220

krbExtraData is apparently NOT being modified but the ldap server believes it is which triggers an ldap mod & replication event because of it.

ssh logins should not trigger a modification that is replicated to FreeIPA replica servers due to storm concerns.
Comment 1 Rob Crittenden 2012-02-01 13:44:03 EST
The issue is that a ssh login triggers the krbExtraData attribute to be modified. This modification is in the list of attributes to be replicated so a simple login to one host triggers a replication event.

Multiply the number of users logging into the number of hosts by the number of replicas and that is the storm he is talking about.

He says that reproduction is simply create a master and replica and log into one or the other. You should see a replication event as a result of a kerberized ssh login.
Comment 2 Dmitri Pal 2012-03-07 14:01:39 EST
One of the approaches would be to create a configuration that would specify for which of the attributes the time stamp should not be updated if the attribute value is touched but not changed (updated with the same value). I would actually argue that in 80% cases that would be a preference so the default might be not to update time stamp in this case but have a configuration option to define an exception to this rule.
Comment 3 Nathan Kinder 2012-03-14 17:28:53 EDT
Upstream ticket:
https://fedorahosted.org/389/ticket/321
Comment 5 Nathan Kinder 2012-07-23 17:08:10 EDT
Bug 842441 is associated with this bug.  It should be verified at the same time.
Comment 7 Sankar Ramalingam 2013-01-29 13:17:54 EST
Marking this bug as verified since mmrepl/accept tests are passing 100%. Also, the associated bug #842441 is also marked verified.

############## Result  for  backend test :   mmrepl mmraccept run
    mmrepl mmraccept run elapse time : 00:12:12
    mmrepl mmraccept run Tests PASS      : 100% (28/28)
Comment 9 errata-xmlrpc 2013-02-21 03:16:58 EST
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.

http://rhn.redhat.com/errata/RHSA-2013-0503.html

Note You need to log in before you can comment on or make changes to this bug.