[OPENDS-2904] Can't configure a B11 DS in a B10 replication topology Created:
04/Feb/08 Updated: 21/Oct/08 Resolved: 21/Oct/08
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Resolved
opends
Replication
pre-1.0
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Environment:
Bug
bbaret
Fixed
None
Not Specified
Attachments:
opends-replication-51171.log
2,904
MS1_rel_notes_included, doc_not_impacted
Issuezilla Id:
Tags:
untargetted
Priority:
Assignee:
Votes:
Critical
pgamba
0
Not Specified
Not Specified
Operating System: All
Platform: All
Description
Build used OpenDS-1.0.0-build011 on solaris10 X86
An existing Replication topology is configured using Build 10
One server is uninstalled and replaced with a B11 Server
During the configuration and the initialization of this server an error occurs :
Error during the initialization with contents from server cacao-14:13892. Last
log details: [04/Feb/2008:14:16:55 +0100] severity="INFORMATION" msgCount=0
msgID=-1 message="The definition for the objectclass with OID
1.3.6.1.4.1.26027.1.2.180 declared that it should include optional attribute
"ds-cfg-cache-preload". No attribute type matching this name or OID exists in
the server schema". Task state: STOPPED_BY_ERROR. Check the error logs of
cacao-14:13892 for more information.
org.opends.quicksetup.installer.Installer.initializeSuffix(Installer.java:4286)
org.opends.quicksetup.installer.Installer.initializeSuffixes(Installer.java:2165)
org.opends.quicksetup.installer.offline.OfflineInstaller.run(OfflineInstaller.java:173)
java.lang.Thread.run(Thread.java:595)
Comments
Comment by jvergara [ 05/Feb/08 ]
Created an attachment (id=310)
Log file
Comment by jvergara [ 05/Feb/08 ]
This is not an install issue since it can be reproduced with dsreplication.
In my opinion the problem is on the schema import code. My guess is that the
following is happening:
Let's call schema A the schema that we are importing from (the source) and
schema B the old schema that we are updating.
Schema A has a objectclass definition change: a new optional attribute has been
added to an objectclass and this attribute is new (not defined in schema B). So
the code is trying to update the definition of this objectclass in schema B but
since the new attribute is not defined yet it throws an error.
I think that is a good strategy to update first the attribute definitions of the
schema (which in general do not depend on the objectclass definitions) and then
update the objectclass definitions. This does not cover all the cases (for
instance inheritance problems between objectclasses or attributes) but it will
solve a number of issues.
Here are the steps to reproduce it using the command line:
1. Install one server with current build (build 11):
$ OpenDS-1.0.0/setup --cli -p 1389 -w s -a -n
2. Install the second server with build 10:
$ OpenDS-1.0.0-build010/setup --cli -p 2389 -w s -a -n
3. Try to enable replication between both servers (note that the order of the
port is important: we must specify first the port of the server on build 10):
$ OpenDS-1.0.0-build010/bin/dsreplication enable --port1 2389 --port2 1389 -R
9989 --bindDN1 "cn=directory manager" --bindDN2 "cn=directory manager"
--bindPassword1 s --bindPassword2 s -w admin -b "dc=example,dc=com" -n
Establishing connections ..... Done.
Checking Registration information ..... Done.
Configuring Replication port on server 192.168.0.2:2389 ..... Done.
Configuring Replication port on server 192.168.0.2:1389 ..... Done.
Updating replication configuration for baseDN dc=example,dc=com on server
192.168.0.2:2389 .....Done.
Updating replication configuration for baseDN dc=example,dc=com on server
192.168.0.2:1389 .....Done.
Updating Registration configuration on server 192.168.0.2:2389 ..... Done.
Updating Registration configuration on server 192.168.0.2:1389 ..... Done.
Updating replication configuration for baseDN cn=schema on server
192.168.0.2:2389 .....Done.
Updating replication configuration for baseDN cn=schema on server
192.168.0.2:1389 .....Done.
Initializing Registration information on server 192.168.0.2:1389 with the
contents of server 192.168.0.2:2389 .....Done.
Initializing schema on server 192.168.0.2:1389 with the contents of server
192.168.0.2:2389 .....
Error during the initialization with contents from server 192.168.0.2:2389.
Last log details: [05/Feb/2008:15:23:53 +0100] severity="INFORMATION"
msgCount=0 msgID=-1 message="The definition for the objectclass with OID
1.3.6.1.4.1.26027.1.2.180 declared that it should include optional attribute
"ds-cfg-cache-preload". No attribute type matching this name or OID exists in
the server schema". Task state: STOPPED_BY_ERROR. Check the error logs of
192.168.0.2:2389 for more information.
See /tmp/opends-replication-51171.log for a detailed log of this operation.
The log file is attached.
Reassigning to Philippe who as far as I remember worked on the import code of
the schema.
Comment by pgamba [ 15/Feb/08 ]
Fix 2904: "dsreplication enable" cannot initialize b11 from b10 because the
schema initialization fails on the config schema.
The code already tests whether the new objectclass is part of the config schema
and then excludes it from the import. That's fine.
Except that the test relies on the decoding of the OC and fails if the new OC
comes with a new attribute.
The fix consists in relaxing the decoding when doing the test .. and really
doing a strict decoding after the test once we know the new OC is not a config OC.
Sending src/server/org/opends/server/backends/SchemaBackend.java
Transmitting file data .
Committed revision 3886.
Comment by lfrost [ 15/Feb/08 ]
Not sure whether this one stays in with Philippe's fix - depends on whether B12
is the M1 build.
Comment by gbellato [ 15/Feb/08 ]
This fix a problem in the schema import code.
However it does not fix all the problem that can happen because
the replication protocol have seen some changes before the M1 build.
It therefore does not guarantee that replication between M1 and older revision
will work.
I believe that the not should therefore be kept.
Generated at Mon Mar 07 05:57:16 UTC 2016 using JIRA 6.2.3#6260sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.