Bug 144295
| Summary: | slapd adds extra lines to replog during selective replication | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Bryan Wann <bwann> |
| Component: | openldap | Assignee: | Nalin Dahyabhai <nalin> |
| Status: | CLOSED DEFERRED | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 2 | CC: | mattdm |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-06-30 14:40:44 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: | |||
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 lingering around. |
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.