Red Hat Bugzilla – Bug 144295
slapd adds extra lines to replog during selective replication
Last modified: 2007-11-30 17:10:57 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
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)=======
[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):
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
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.
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.
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