Bug 782975

Summary:	krbExtraData is being null modified and replicated on each ssh login
Product:	Red Hat Enterprise Linux 6	Reporter:	Dmitri Pal <dpal>
Component:	389-ds-base	Assignee:	Rich Megginson <rmeggins>
Status:	CLOSED ERRATA	QA Contact:	Sankar Ramalingam <sramling>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.3	CC:	jgalipea, mkosek, mreynolds, nkinder, rcritten
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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 08:16:58 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Dmitri Pal 2012-01-19 00:28:40 UTC

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 18:44:03 UTC

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 19:01:39 UTC

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 21:28:53 UTC

Upstream ticket:
https://fedorahosted.org/389/ticket/321

Comment 4 Rob Crittenden 2012-03-14 21:40:25 UTC

Replaced https://fedorahosted.org/freeipa/ticket/2220 with https://fedorahosted.org/freeipa/ticket/2354

Comment 5 Nathan Kinder 2012-07-23 21:08:10 UTC

Bug 842441 is associated with this bug.  It should be verified at the same time.

Comment 7 Sankar Ramalingam 2013-01-29 18:17:54 UTC

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 08:16:58 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.

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