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]:
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?
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.
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]:
Sounds good, I've already started working on it.
Revision - allow dynamic config updates 0001-Ticket-47620-389-ds-rejects-nsds5ReplicaProtocolTime.patch
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...
Fix cherry-pick errors in 1.3.2 amd 1.3.1 0001-Ticket-47620-Fix-cherry-pick-error-for-1.3.2-and-1.3.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
attachment 0001-Ticket-47620-Config-value-validation-improvement.patch
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(-)
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
Fix minor coverity issues 0001-Ticket-47620-Fix-logically-dead-code.patch
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(-)
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
Fix crash 0001-Ticket-47620-Fix-dereferenced-NULL-pointer-in-agmtli.patch
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
attachment 0001-Ticket-47620-Fix-missing-left-bracket.patch
attachment 0001-Ticket-47620-Unable-to-delete-protocol-timeout-attri.patch
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
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
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.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Log in to comment on this ticket.