This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1251288 - Replication not working for "delete: attr"
Replication not working for "delete: attr"
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base (Show other bugs)
6.6
x86_64 Linux
high Severity high
: rc
: ---
Assigned To: Noriko Hosoi
Viktor Ashirov
Petr Bokoc
: ZStream
: 1254410 1254662 (view as bug list)
Depends On:
Blocks: 1257776
  Show dependency treegraph
 
Reported: 2015-08-06 18:47 EDT by Thang Nguyen
Modified: 2016-05-10 15:20 EDT (History)
9 users (show)

See Also:
Fixed In Version: 389-ds-base-1.2.11.15-67.el6
Doc Type: Bug Fix
Doc Text:
Deletion of attributes without a value on the master server now replicates correctly Previously, when an attribute which does not have a value on the master server was deleted, the deletion was not replicated to other servers. The regression that caused this bug has been fixed and the change now replicates as expected.
Story Points: ---
Clone Of:
: 1257776 (view as bug list)
Environment:
Last Closed: 2016-05-10 15:20:30 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Backport the fix for #561 was missing this additional fix for the regression. (1.31 KB, patch)
2015-08-07 15:59 EDT, Noriko Hosoi
no flags Details | Diff

  None (edit)
Description Thang Nguyen 2015-08-06 18:47:12 EDT
Description of problem:

In a replication (master-master or master-consumer) environment, when doing a 

dn: cn=user1,dc=ou,dc=o
changetype: modify
delete: any_attribute

Or

dn: cn=user1,dc=ou,dc=o
changetype: modify
replace: any_attribute

on the master server, the attribute is deleted from the master but the attribute is not deleted on the replicated server (master or consumer).

However, if I have

dn: cn=user1,dc=ou,dc=o
changetype: modify
replace: any_attribute
any_attribute: value

Or 

dn: cn=user1,dc=ou,dc=o
changetype: modify
delete: any_attribute
any_attribute: value

the change is replicated to the consumer.

Version-Release number of selected component (if applicable):
1.2.11.15-60.el6

There are no errors in the error log.

Please provide a fix for this.
Comment 1 Thang Nguyen 2015-08-06 18:49:35 EDT
BTW, this issue doesn't exist on 1.2.11.15-50.el6.
Comment 5 Thang Nguyen 2015-08-13 16:02:46 EDT
Can I get an update on this please?  Thank you.
Comment 6 Noriko Hosoi 2015-08-13 16:24:09 EDT
(In reply to Thang Nguyen from comment #5)
> Can I get an update on this please?  Thank you.

Fixed in upstream.  Do you need a patch?
Comment 7 Thang Nguyen 2015-08-13 16:56:29 EDT
Hi Noriko,

Thanks.  Can you provide a patch?  When will the fix be in Redhat repo?
Comment 8 Noriko Hosoi 2015-08-13 17:06:50 EDT
(In reply to Thang Nguyen from comment #7)
> Hi Noriko,
> 
> Thanks.  Can you provide a patch?  When will the fix be in Redhat repo?

Hello Thang,

Can you see the attachment: #1060475?

In terms of the release, we are working on it.

Thanks for your patience,
--noriko
Comment 9 Thang Nguyen 2015-08-13 19:01:40 EDT
Thanks Noriko!

--thang
Comment 10 Hiroko Miura 2015-08-18 01:21:05 EDT
*** Bug 1254410 has been marked as a duplicate of this bug. ***
Comment 11 German Parente 2015-08-18 11:41:01 EDT
*** Bug 1254662 has been marked as a duplicate of this bug. ***
Comment 15 Noriko Hosoi 2015-08-28 17:55:29 EDT
Steps to verify:
1. Set up MMR (hosts: Master1 and Master2)
2. delete an attribute without the value.
ldapmodify -h Master1 ... << EOF
dn: <DN>
changetype: modify
delete: <ATTR>
EOF
3. check the attribute <ATTR> in Master2.
   If it is deleted, the fix is verified.
Comment 17 Simon Pichugin 2016-03-15 11:11:20 EDT
$ rpm -qa | grep 389-ds-base
389-ds-base-libs-1.2.11.15-74.el6.x86_64
389-ds-base-1.2.11.15-74.el6.x86_64

Verification steps:
1) Set up MMR:
master1 - 389
master2 - 390

2) Add user entry to master1:
$ ldapmodify -h localhost -p 389 -D "cn=Directory Manager" -w Secret123
dn: uid=user,dc=example,dc=com
changetype: add
objectClass: top
objectClass: person
objectClass: inetUser
uid: user
sn: user
cn: user
description: test

adding new entry "uid=user,dc=example,dc=com"

3) Check master2 for this entry:
$ ldapsearch -h localhost -p 390 -D "cn=Directory Manager" -w Secret123 -b "uid=user,dc=example,dc=com"

# user, example.com
dn: uid=user,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: inetUser
uid: user
sn: user
cn: user
description: test

4) Delete attribute "description" from master1:
$ ldapmodify -h localhost -p 389 -D "cn=Directory Manager" -w Secret123
dn: uid=user,dc=example,dc=com
changetype: modify
delete: description

modifying entry "uid=user,dc=example,dc=com"

5) Check master2 for this attribute:
$ ldapsearch -h localhost -p 390 -D "cn=Directory Manager" -w Secret123 -b "uid=user,dc=example,dc=com"

# user, example.com
dn: uid=user,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: inetUser
uid: user
sn: user
cn: user

Marking as verified.
Comment 19 errata-xmlrpc 2016-05-10 15:20:30 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0737.html

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