Bug 40089 - bad propagation with openldap replica server
Summary: bad propagation with openldap replica server
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: openldap   
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2001-05-10 15:49 UTC by Alberto Gianoli
Modified: 2007-04-18 16:33 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-05-10 15:49:33 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Alberto Gianoli 2001-05-10 15:49:30 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.2.17-14 i686)

Description of problem:
I'm setting up a main server with a replica server. The updates are not
sent to the
replica server. After a bit of investigation I discovered the following:
slapd creates the
replog file (/usr/tmp/slapd.replog), and this file is copied to
/var/lib/ldap/replica/slurpd.replog, but slurpd does not send it. Manually
starting the servers with debug option on, I saw that slurpd was reading
correctly the file but
was saying "not mine". After checking the format, I discover that the first
line is missing. The replog format should be:
1) first line with "replica: machine:port" (or more than one line if there
are more than one replica
2) line with the timestamp
3) body of the modification (several lines)
In my case the file starts with the timestamp. I tried adding the line by
hand and restarting the daemon and this time the modification was done on
the replica.
I don't know if the problem is in slurpd "forgetting" the line or in slurpd
chopping the line when it copies the file.

How reproducible:

Steps to Reproduce:
1.set up a main server and a replica server
2.populate the main
3.copy the db files to the replica
4.restart both server
5.try to modify something in the main server. You will see that the replica
still has the old data

Actual Results:  You will find the replica server without the modifications
done in step 5.

Expected Results:  You should have found the new data

Additional info:

As I sai before, to me the problem seems to be in the format of the replog
file (even if I don't know if it is produced wrong or if something happens
later on).
Just to be more complete: I'm using two PCs with i686. On both of them
RH7.1 has been installed from scratch. From the point of view of the
severity of the bug I'm not sure if it should be considered a security
problem or not

Comment 1 Nalin Dahyabhai 2001-07-03 22:54:07 UTC
I suspect you have a configuration problem.  Replicas are associated with
particular databases, so if you're using a single LDBM database (as the default
supplied configuration file does), you need to place the replica directive
after the database directive.

Marking as WORKSFORME because I made this exact mistake when attempting to
reproduce the reported bug, and reording the directives in slapd.conf fixes it.

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