Bug 144295 - slapd adds extra lines to replog during selective replication
slapd adds extra lines to replog during selective replication
Status: CLOSED DEFERRED
Product: Fedora
Classification: Fedora
Component: openldap (Show other bugs)
2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-05 13:21 EST by Bryan Wann
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-06-30 10:40:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bryan Wann 2005-01-05 13:21:57 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

Description of problem:
Whenever selective replication is used to withhold attributes using
the "attr!" option, slapd prints blank lines in place of the withheld
attributes for the replica servers.  This specifically only happens
when there are more than one replicas configured and only when an
"add: objectClass" is performed.  Slurpd happily reads in the master
replog, copies it to slurpd.replog, but nothing after the blank lines
are processed.  The lines must be removed, then slurpd must be
restarted before it will continue processing the replog.

For instance, if four replicas are configured, each with
"attr!=entryCSN,entryUUID,modifiersName,modifyTimestamp", this is what
is written to the master-slapd.replog:

=========(this line to show start)=======
time: 1104947913
dn: cn=bryan,ou=People,o=wann
changetype: modify
replace: entryCSN
entryCSN: 2005010517:58:33Z#0x0002#0#0000
-
replace: modifiersName
modifiersName: cn=admin,o=wann
-
replace: modifyTimestamp
modifyTimestamp: 20050105175833Z
-

   [four blank lines here]


=========(this line to show EOF)=======

I found this problem while replicating the directory between our FC2
(openldap 2.1) servers to our RH9 (openldap 2.0) boxes.  I entered
this at OpenLDAP.org as ITS #3459.  My best guess is that this is
happening in servers/slapd/repl.c in replog1() somewhere.

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

How reproducible:
Always

Steps to Reproduce:
This can be tested without having to setup actual slaves since slapd
is the cause.

1. Configure replication on a 2.1 server for at least two replicas. 
Add the line "attr!=entryCSN,entryUUID,modifiersName,modifyTimestamp"
to the "replica" section for the specified servers.
2. Use ldapmodify to feed in an "add: objectClass" modification
3. View the master replication log written by slapd  (easiest to see
when slurpd isn't running).  There should be an extra \n for each
replica after the last dash for the modifyTimestamp entry.
    

Actual Results:  Actual results are described in the description field

Expected Results:  There should be only a single \n after the dash
after modifyTimestamp.

time: 1104947913
dn: cn=bryan,ou=People,o=wann
changetype: modify
replace: entryCSN
entryCSN: 2005010517:58:33Z#0x0002#0#0000
-
replace: modifiersName
modifiersName: cn=admin,o=wann
-
replace: modifyTimestamp
modifyTimestamp: 20050105175833Z
-


Additional info:

A person on the openldap-its list says since 2.1 is a historic
release, it is unlikely that this will be fixed.  However, 2.1.29-1 is
the current package level in FC2.  The same replication code is in
2.1.30, so it is likely it is not corrected there either.
Comment 1 Matthew Miller 2005-04-26 11:35:00 EDT
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.
Comment 2 Bryan Wann 2005-06-30 10:40:44 EDT
I haven't checked to see if it's in FC3 or FC4, as I think those version of
openldap use a new form of replication.  I am resolving this so it's not
lingering around.

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