#47620 389-ds rejects nsds5ReplicaProtocolTimeout attribute
Closed: wontfix None Opened 10 years ago by rmeggins.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1038639

Description of problem:
The 389 directory server refuses to add nsds5ReplicaProtocolTimeout to either
replica entry or replication agreement entry.

Version-Release number of selected component (if applicable):
389-ds-base-1.3.1.6-11.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Set up replica on a DS instance. We don't need complete MMR setup for this.
2. Perform ldapmodify to add nsds5ReplicaProtocolTimeout to replica entry.
3. If complete setup is in place, do this on some replication agreement as
well.

Actual results:
Server refuses to add the attribute to the entry. Returns 53 - unwilling to
perform.

Expected results:
The attribute will be added to tyhe entry.

Additional info:
The attribute is in schema and is listed as allowed attribute in both
nsDS5Replica and nsDS5ReplicationAgreement object classes.

----
$ rpm -qa 389-ds-base
389-ds-base-1.3.1.6-11.el7.x86_64

$ grep nsds5ReplicaProtocolTimeout /etc/dirsrv/slapd-s1/schema/01core389.ldif
>/dev/null
$ echo $?
0

$ cat timeout.ldif
dn: cn=24202_to_24206,cn=replica,cn=o\=airius.com,cn=mapping tree,cn=config
changetype: modify
add: nsds5ReplicaProtocolTimeout
nsds5ReplicaProtocolTimeout: 15
-

$ ldapmodify -h localhost -p 24202 -D "cn=directory manager" -w Secret123 -f
timeout.ldif -v
ldap_initialize( ldap://localhost:24202 )
add nsds5ReplicaProtocolTimeout:
        15
modifying entry "cn=24202_to_24206,cn=replica,cn=o\=airius.com,cn=mapping
tree,cn=config"
ldap_modify: Server is unwilling to perform (53)

$ cat timeout.ldif
dn: cn=replica,cn=o\=airius.com,cn=mapping tree,cn=config
changetype: modify
add: nsds5ReplicaProtocolTimeout
nsds5ReplicaProtocolTimeout: 15
-

$ ldapmodify -x -h localhost -p 24202 -D "cn=directory manager" -w Secret123 -f
timeout.ldif -v
ldap_initialize( ldap://localhost:24202 )
add nsds5ReplicaProtocolTimeout:
        15
modifying entry "cn=replica,cn=o\=airius.com,cn=mapping tree,cn=config"
ldap_modify: Server is unwilling to perform (53)
        additional info: modification of attribute nsds5ReplicaProtocolTimeout
is not allowed in replica entry

Where does it store the value that was set by the add or modify? Is it stored in the replica or the replica agreement object?

Replying to [comment:3 rmeggins]:

Where does it store the value that was set by the add or modify? Is it stored in the replica or the replica agreement object?

Both. You can have unique protocol timeouts per agreement, or for all the agmts under one replica root. Agreements will look for the replica's timeout if there is not one set for itself.

Replying to [comment:4 mreynolds]:

Replying to [comment:3 rmeggins]:

Where does it store the value that was set by the add or modify? Is it stored in the replica or the replica agreement object?

Both. You can have unique protocol timeouts per agreement, or for all the agmts under one replica root. Agreements will look for the replica's timeout if there is not one set for itself.

Ok, so this is the protocol_timeout field in the replica and the agreement object? I don't see where this is set.

Replying to [comment:5 rmeggins]:

Replying to [comment:4 mreynolds]:

Replying to [comment:3 rmeggins]:

Where does it store the value that was set by the add or modify? Is it stored in the replica or the replica agreement object?

Both. You can have unique protocol timeouts per agreement, or for all the agmts under one replica root. Agreements will look for the replica's timeout if there is not one set for itself.

Ok, so this is the protocol_timeout field in the replica and the agreement object? I don't see where this is set.

For the replica, it is set in _replica_init_from_config()

For the agmt it is set in agmt_new_from_entry()

This is the original patch:

https://fedorahosted.org/389/attachment/ticket/558/0001-Ticket-558-Replication-make-timeout-for-protocol-shu.patch

Replying to [comment:6 mreynolds]:

Replying to [comment:5 rmeggins]:

Replying to [comment:4 mreynolds]:

Replying to [comment:3 rmeggins]:

Where does it store the value that was set by the add or modify? Is it stored in the replica or the replica agreement object?

Both. You can have unique protocol timeouts per agreement, or for all the agmts under one replica root. Agreements will look for the replica's timeout if there is not one set for itself.

Ok, so this is the protocol_timeout field in the replica and the agreement object? I don't see where this is set.

For the replica, it is set in _replica_init_from_config()

Is this called when you modify a replica attribute?

For the agmt it is set in agmt_new_from_entry()

Is this called when you modify an agreement attribute?

I guess I can't see where protocol_timeout is set during a modify operation.

This is the original patch:

https://fedorahosted.org/389/attachment/ticket/558/0001-Ticket-558-Replication-make-timeout-for-protocol-shu.patch

Replying to [comment:7 rmeggins]:

Replying to [comment:6 mreynolds]:

Replying to [comment:5 rmeggins]:

Replying to [comment:4 mreynolds]:

Replying to [comment:3 rmeggins]:

Where does it store the value that was set by the add or modify? Is it stored in the replica or the replica agreement object?

Both. You can have unique protocol timeouts per agreement, or for all the agmts under one replica root. Agreements will look for the replica's timeout if there is not one set for itself.

Ok, so this is the protocol_timeout field in the replica and the agreement object? I don't see where this is set.

For the replica, it is set in _replica_init_from_config()

Is this called when you modify a replica attribute?

For the agmt it is set in agmt_new_from_entry()

Is this called when you modify an agreement attribute?

I guess I can't see where protocol_timeout is set during a modify operation.

Ahh I see. Yeah the change currently requires a server restart to take effect. At the time I did not want to add any locking to replication(via ticket 558), but I could use a slapi_counter and make it dynamic.

This is the original patch:

https://fedorahosted.org/389/attachment/ticket/558/0001-Ticket-558-Replication-make-timeout-for-protocol-shu.patch

Most of the other attributes in the replica object and the agreement object are dynamic - when you change them using ldapmodify, the new values take effect immediately. I would like to preserve this behavior unless it's not applicable for nsds5ReplicaProtocolTimeout

Replying to [comment:9 rmeggins]:

Most of the other attributes in the replica object and the agreement object are dynamic - when you change them using ldapmodify, the new values take effect immediately. I would like to preserve this behavior unless it's not applicable for nsds5ReplicaProtocolTimeout

Sounds good, I've already started working on it.

Replying to [comment:10 mreynolds]:

Replying to [comment:9 rmeggins]:

Most of the other attributes in the replica object and the agreement object are dynamic - when you change them using ldapmodify, the new values take effect immediately. I would like to preserve this behavior unless it's not applicable for nsds5ReplicaProtocolTimeout

Sounds good, I've already started working on it.

Ok, new patch is attached...

git merge ticket47620
Updating 25e91e8..9a0fb6a
Fast-forward
ldap/servers/plugins/replication/repl5.h | 7 ++-
ldap/servers/plugins/replication/repl5_agmt.c | 35 ++++++++-----
ldap/servers/plugins/replication/repl5_agmtlist.c | 27 ++++++++--
.../plugins/replication/repl5_inc_protocol.c | 23 +++++++--
.../plugins/replication/repl5_prot_private.h | 1 -
ldap/servers/plugins/replication/repl5_protocol.c | 11 +---
ldap/servers/plugins/replication/repl5_replica.c | 54 +++++++++++++-------
.../plugins/replication/repl5_replica_config.c | 25 +++++++++-
.../plugins/replication/repl5_tot_protocol.c | 17 +++++-
9 files changed, 144 insertions(+), 56 deletions(-)

git push origin master

25e91e8..9a0fb6a master -> master

commit 9a0fb6a
Author: Mark Reynolds mreynolds@redhat.com
Date: Fri Dec 6 16:57:41 2013 -0500

pushed to 1.3.2:

d1aba44..58fca2c 389-ds-base-1.3.2 -> 389-ds-base-1.3.2

commit 58fca2c

1.3.1

8e40fa9..490360f 389-ds-base-1.3.1 -> 389-ds-base-1.3.1

commit 490360f

This might have introduced a crash, investigating...

There was a cherry-picking error in 1.3.2 & 1.3.1 where we destroyed the replication schedule object twice(deferenced NULL pointer). Working on the new patch...

commit 3ae6900
Author: Mark Reynolds mreynolds@redhat.com
Date: Thu Dec 12 15:36:11 2013 -0500

42ba3dc..3ae6900 389-ds-base-1.3.2 -> 389-ds-base-1.3.2

a1e3861..5d4ac7c 389-ds-base-1.3.1 -> 389-ds-base-1.3.1

git merge ticket47620
Updating 614b7bb..8a4bbc7
Fast-forward
ldap/servers/plugins/replication/repl5_agmtlist.c | 32 ++++++++++---------
.../plugins/replication/repl5_replica_config.c | 12 +++++--
2 files changed, 25 insertions(+), 19 deletions(-)

git push origin master

614b7bb..8a4bbc7 master -> master

commit 8a4bbc7
Author: Mark Reynolds mreynolds@redhat.com
Date: Fri Dec 13 11:43:47 2013 -0500

3ae6900..3f28f45 389-ds-base-1.3.2 -> 389-ds-base-1.3.2

5d4ac7c..1bbb27b 389-ds-base-1.3.1 -> 389-ds-base-1.3.1

Coverity fixes:

git merge ticket47620
Updating a71633d..080cb44
Fast-forward
ldap/servers/plugins/replication/repl5_agmtlist.c | 10 ----------
.../plugins/replication/repl5_replica_config.c | 2 +-
2 files changed, 1 insertions(+), 11 deletions(-)

git push origin master

a71633d..080cb44 master -> master

commit 080cb44
Author: Mark Reynolds mreynolds@redhat.com
Date: Mon Dec 16 09:48:12 2013 -0500

c8b44e1..862f0d6 389-ds-base-1.3.2 -> 389-ds-base-1.3.2

1bbb27b..c094a9f 389-ds-base-1.3.1 -> 389-ds-base-1.3.1

git merge ticket47620
Updating 16dc94f..8baed89
Fast-forward
ldap/servers/plugins/replication/repl5_agmtlist.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)

git push origin master
Counting objects: 13, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 805 bytes, done.
Total 7 (delta 5), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
16dc94f..8baed89 master -> master

commit 8baed89
Author: Mark Reynolds mreynolds@redhat.com
Date: Tue Dec 17 13:11:03 2013 -0500

fde9ed5..887fd19 389-ds-base-1.3.2 -> 389-ds-base-1.3.2

c9d0b6c..60d263f 389-ds-base-1.3.1 -> 389-ds-base-1.3.1

Typo in the last patch, missing left bracket.

git merge ticket47620
Updating 8baed89..3a4d39e
Fast-forward
ldap/servers/plugins/replication/repl5_agmtlist.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

git push origin master
Counting objects: 13, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 645 bytes, done.
Total 7 (delta 5), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
8baed89..3a4d39e master -> master

commit 3a4d39e
Author: Mark Reynolds mreynolds@redhat.com
Date: Tue Dec 17 14:01:34 2013 -0500

887fd19..19660fa 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
60d263f..b143477 389-ds-base-1.3.1 -> 389-ds-base-1.3.1

git merge ticket47620
Updating 03c90f0..9c41a36
Fast-forward
ldap/servers/plugins/replication/repl5.h | 1 -
ldap/servers/plugins/replication/repl5_agmtlist.c | 46 ++++++++++-----------
ldap/servers/plugins/replication/repl_globals.c | 1 -
3 files changed, 22 insertions(+), 26 deletions(-)

git push origin master
03c90f0..9c41a36 master -> master

commit 9c41a36
Author: Mark Reynolds mreynolds@redhat.com
Date: Fri Jan 17 15:13:21 2014 -0500

1.3.2

50ad64a..668903c 389-ds-base-1.3.2 -> 389-ds-base-1.3.2

1.3.1

e0d85be..7738016 389-ds-base-1.3.1 -> 389-ds-base-1.3.1

Metadata Update from @mreynolds:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.3.1.17

7 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/957

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

3 years ago

Login to comment on this ticket.