Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 184155 - Dual winsync paths results in LDAP DEL collision on DS
Dual winsync paths results in LDAP DEL collision on DS
Product: 389
Classification: Retired
Component: Replication - General (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Rich Megginson
Ben Levenson
Depends On:
Blocks: 512820 690316
  Show dependency treegraph
Reported: 2006-03-06 16:55 EST by Ulf Weltman
Modified: 2015-11-19 18:07 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-11-19 18:07:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ulf Weltman 2006-03-06 16:55:46 EST
Description of problem:
In a configuration with two DS in MMR (M1 and M2) and two AD in the same domain
(AD1 and AD2), if we configure M1 to sync with AD1 and M2 to sync with AD2, we
have a ring configuration with good availability.  Changes will be available
everywhere even if a server crashes.

If you delete a user on AD1, M1 will pick up that update within 5 minutes.  It
will send the change to M2, and M2 will attempt to replay it on AD2.  However,
because of the 5 minute lag, AD1 will already have deleted the entry from AD2 so
M2 will log errors, retrying every couple of seconds.  The error is a reference
to the garbage collection fqdn, which is usually not resolvable unless the RHDS
is using ADS based DNS, but I don't think we even want to touch the garbage
collector anyway.

This is similar to the problem with LDAP ADD in a dual winsync topology:

[06/Mar/2006:13:34:24 -0800] NSMMReplicationPlugin - changelog program - agmt="c
n=hpntc782" (hpntc782:636): CSN 440ca1c3000000010000 found, position set for rep
[06/Mar/2006:13:34:24 -0800] agmt="cn=hpntc782" (hpntc782:636) - load=1 rec=1 cs
[06/Mar/2006:13:34:24 -0800] NSMMReplicationPlugin - agmt="cn=hpntc782" (hpntc78
2:636): windows_replay_update: Looking at delete operation local dn="uid=fbar3,o
u=winsync,dc=cup,dc=hp,dc=com" (ours,user,not group)
[06/Mar/2006:13:34:24 -0800] NSMMReplicationPlugin - agmt="cn=hpntc782" (hpntc78
2:636): windows_replay_update: Processing delete operation local dn="uid=fbar3,o
u=winsync,dc=cup,dc=hp,dc=com" remote dn="<GUID=91598cbce3e2004e90a75ac8f6474ef2
[06/Mar/2006:13:34:24 -0800] NSMMReplicationPlugin - agmt="cn=hpntc782" (hpntc78
2:636): Received result code 10 (0000202B: RefErr: DSID-031006E0, data 0, 1 acce
ss points       ref 1: 'gc._msdcs.ulftest.net:3268' ) for delete operation
[06/Mar/2006:13:34:24 -0800] NSMMReplicationPlugin - agmt="cn=hpntc782" (hpntc78
2:636): windows_replay_update: deleted remote entry, dn="<GUID=91598cbce3e2004e9
0a75ac8f6474ef2>", result=1
[06/Mar/2006:13:34:24 -0800] NSMMReplicationPlugin - agmt="cn=hpntc782" (hpntc78
2:636): Consumer failed to replay change (uniqueid 41485081-ad5311da-8013a4b8-9c
ccd5f1, CSN 440ca2ed000100010000): Referral received. Will retry later.
[06/Mar/2006:13:34:24 -0800] agmt="cn=hpntc782" (hpntc782:636) - session end: st
ate=0 load=1 sent=1 skipped=0

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Ulf Weltman 2006-03-06 17:07:14 EST
Oh the reference is to the Global Catalog server (port 3268), not Garbage
Collection.  ADS does have a garbage collection process that reaps tombstones
and defrags the jet database files but that's another "gc".
Comment 2 Rich Megginson 2009-01-14 12:52:47 EST
Latering to 8.2
Comment 3 Martin Kosek 2012-01-04 08:49:30 EST
Upstream ticket:
Comment 5 Noriko Hosoi 2015-11-19 18:07:33 EST
Closing this bug since we moved to the ticket system:

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