[OPENDS-2811] dsreplication disable doesn't remove references to current
server from replicated servers Created: 11/Jan/08 Updated: 17/Jan/08 Resolved: 17/Jan/08
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Resolved
opends
Administration/Command Line
pre-1.0
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Environment:
Bug
cmuchinsky
Fixed
None
Not Specified
Issuezilla Id:
Tags:
2,811
doc_not_impacted
untargetted
Priority:
Assignee:
Votes:
Major
jvergara
0
Not Specified
Not Specified
Operating System: All
Platform: All
Description
The dsreplication disable command doesn't appear to be removing references to
replication server being disabled from the other replication servers
configurations. Here are the steps that caused the error output you see below:
1.) create server 1389
2.) create server 1390
3.) dsreplication enable and initialize between 1389 and 1390
4.) create server 1391
5.) dsreplication enable and initialize between 1390 and 1391
6.) dsreplication disable 1391 (appeared to work fine)
7.) dsreplication disable 1390 (complains about connectivity to 1391)
Here is the stdout of step 7:
Establishing connections ..... Done.
The following errors were encountered reading the configuration of the
existing servers:
Error on foohost:1391: An error occurred connecting to the
server. Details: javax.naming.CommunicationException:
foohost:1391 [Root exception is java.net.ConnectException:
Connection refused: connect]
The replication tool will to try to update the configuration of all the
servers in a best-effort mode. However it cannot guarantee that the servers
that are generating errors will be updated.
Disabling replication on base DN dc=foo,dc=com of server
foohost:1390 .....Done.
Removing references on base DN dc=foo,dc=com of server
foohost:1389 .....Done.
Comments
Comment by jvergara [ 14/Jan/08 ]
I cannot reproduce the problem.
Is the server with port 1391 offline when trying to disable replication on the
other server (step 7)? Could you provide the precise command that you launch to
disable replication on 1391 and the log output?
If 1391 is down and considering the current choices made with "dsreplication
disable" this is expected. Even if replication on all the suffixes is disabled
the registration information on the server is not removed; this registration
information is used to retrieve the replication topology and that is why it
tries co connect to 1391. This is done because the registration information in
the future might be used for other things that replication.
However considering the current state of things maybe we should consider to
remove all the references to the server (and to stop replicating cn=admin data
and cn=schema) so that dsreplication enable and dsreplication disable are
perfectly symmetric (currently they are not since all that is configured by
dsreplication enable is not unconfigured by dsreplication disable).
Comment by cmuchinsky [ 14/Jan/08 ]
Yes, 1391 is down, in fact it was completely removed. I am using OpenDS as an
embedded LDAP server. When I uninstall my application I first detect if I'm in
a cluster, and if so I run dsreplication disable before completing my uninstall.
From what you describe, the behavior is expected, although not ideal for my
situation. Is there another command I can issue to clean up the references to
the server I'm uninstalling? If not, your suggestion to make dsreplication
enable/disable symmetrical would be ideal.
If you still need log files and command lines I can provide them, however I
think you've figured out exactly what is happenning in my environment.
Thanks,
Craig M.
Comment by jvergara [ 14/Jan/08 ]
Thanks for your answer. Logs are not required.
I think that for the current release, and since there is no other tool using the
registration information, the code of dsreplication should be symmetrical.
Concerning a way of interacting with the contents of cn=admin data, the
command-line dsframework deals with it and it allows to update the registration
information.
I have another question, did you use the uninstall utility to remove your
server? If you did, it implies that there is a bug, since the user is required
to provide authentication information in order to remove references on the
server that is being uninstalled.
Comment by cmuchinsky [ 14/Jan/08 ]
I did not use an uninstall utility to remove my instance, which is likely the
cause of my problems. I do however start up the ldap server in order to run
dsreplication disable, and then I remove the files from the filesystem
completely. Is there another step I should have been taking?
To give you a better picture of what I'm doing, here is my install procedure. I
use ldifmodify to set up the adminbackend.ldif and config.ldif files, and then
I use the EmbeddedUtils.startServer() and EmbeddedUtils.stopServer() methods to
manage the embedded ldap server. When I detect I'm in a cluster, I start the
ldap server and then run dsreplication enable.
Comment by cmuchinsky [ 14/Jan/08 ]
As a workaround I was able to use the dsframework unregister-server command,
after calling dsreplication disable, to remove the server from the
configuration.
Comment by jvergara [ 17/Jan/08 ]
The fix makes dsreplication enable and dsreplication disable symmetric. When th
e user disables the last replicated suffix, we inform that the replication serve
r will also be disabled. So when the last repilcated suffix is disabled, replic
ation on cn=schema and cn=admin data are also disabled and the registration info
rmation updated properly.
Some changes have been made in ADSContext to make registerServer and unregisterS
erver symmetric: unregisterServer removes the references to the server keys and
also the references to the server in the different server groups.
The code of DsFrameworkCliServer.java has also been updated since ADSContext.unr
egisterServer already updates the server groups.
Fixed in revision 3687.
Generated at Tue Feb 09 21:50:11 UTC 2016 using JIRA 6.2.3#6260sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.