[OPENAM-6457] DirectoryContentUpgrader causes Entry Already Exists exception for CTS suffix when upgrading OpenAM Created: 27/Jul/15  Updated: 20/Nov/16  Resolved: 23/May/16

Status: Resolved
Project: OpenAM
Component/s: upgrade
Affects Version/s: 12.0.0, 12.0.1, 13.0.0
Fix Version/s: 12.0.2, 12.0.3, 13.0.0

Type: Bug Priority: Major
Reporter: Ian Packer [X] (Inactive) Assignee: Peter Major [X] (Inactive)
Resolution: Fixed Votes: 1
Labels: EDISON, release-notes
Remaining Estimate: 0h
Time Spent: 3h
Original Estimate: 0h

Sprint: Sustaining Sprint 10
Support Ticket IDs:
Verified Version/s:

 Description   

When upgrading to OpenAM 12, the DirectoryContentUpgrader part of the process tries to process various ldif modification tasks.

In the case of 'CreateCTSContainer':

    private class CreateCTSContainer implements Upgrader {

        @Override
        public String getLDIFPath() {
            return "/WEB-INF/template/ldif/sfha/cts-container.ldif";
        }

        @Override
        public boolean isUpgradeNecessary(Connection conn, Schema schema) throws UpgradeException {
            return !entryExists(conn, new LDAPConfig(baseDN).getTokenStoreRootSuffix());
        }
    }

In a scenario where CTS is external with a non-default suffix, this logic is still executed and the end result is:

amUpgrade:05/09/2015 10:23:22:557 AM BST: Thread[http-bio-8080-exec-10,5,main]
ERROR: An error occurred while processing /WEB-INF/template/ldif/sfha/cts-container.ldif
org.forgerock.opendj.ldap.ErrorResultIOException: org.forgerock.opendj.ldap.ConstraintViolationException: Entry Already Exists: The entry ou=tokens,dc=example,dc=com cannot be added because an entry with that name already exists
        at org.forgerock.opendj.ldif.ConnectionChangeRecordWriter.writeChangeRecord(ConnectionChangeRecordWriter.java:109)
        at org.forgerock.opendj.ldif.ConnectionChangeRecordWriter.writeChangeRecord(ConnectionChangeRecordWriter.java:56)
        at org.forgerock.opendj.ldif.ChangeRecordVisitorWriter.visitChangeRecord(ChangeRecordVisitorWriter.java:59)
        at org.forgerock.opendj.ldif.ChangeRecordVisitorWriter.visitChangeRecord(ChangeRecordVisitorWriter.java:39)
        at org.forgerock.opendj.ldap.requests.AddRequestImpl.accept(AddRequestImpl.java:58)
        at org.forgerock.opendj.ldif.ConnectionChangeRecordWriter.writeChangeRecord(ConnectionChangeRecordWriter.java:131)
        at org.forgerock.opendj.ldif.ConnectionChangeRecordWriter.writeChangeRecord(ConnectionChangeRecordWriter.java:56)
        at org.forgerock.openam.upgrade.DirectoryContentUpgrader.processLDIF(DirectoryContentUpgrader.java:180)
        at org.forgerock.openam.upgrade.DirectoryContentUpgrader.upgrade(DirectoryContentUpgrader.java:212)
        at org.forgerock.openam.upgrade.steps.UpgradeDirectoryContentStep.perform(UpgradeDirectoryContentStep.java:72)
        at org.forgerock.openam.upgrade.UpgradeServices.upgrade(UpgradeServices.java:186)
        at com.sun.identity.config.upgrade.Upgrade.doUpgrade(Upgrade.java:79)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

This is because OpenAM uses a configuration store connection factory to run the isUpgradeNecessary() check, but it uses the 'getTokenStoreRootSuffix' which corresponds to external CTS configuration. It therefore looks up a suffix that doesn't exist in the config store.

Additionally, in the actual cts-container.ldif file, this contains default ou=tokens,<configstoresuffix> based entries that have no relation to an external CTS suffix. So because it hasn't found the 'external suffix', it then tries to add the configstore based suffix (which does already exist).

As a result the overall upgrade fails.



 Comments   
Comment by Peter Major [X] (Inactive) [ 04/Aug/15 ]

Resolved with R14917 and R14936.
The solution is that the CTS containers shall be only ever created by the upgrade framework, if the CTS storage mode is DEFAULT, and if the root suffix is the default root suffix which doesn't already exist yet.
In the reported scenario CTS was set to external, which would mean that the containers will never be attempted to be created.

Comment by Nemanja Lukic [ 07/Oct/15 ]

Verified in: OpenAM 12.0.2 Build 15797 (2015-September-21 17:41)

Steps to reproduce:

  • Deploy two external OpenDJs: will serve as external OpenAM config and data store (let's call it 'ds1') and the other one as external CTS directory ('ds2' for example)
    • the suffix used for 'ds1' and for 'ds2' has to be different for this case: `ds1`might have 'o=forgerock' for users and 'o=openam' for configuration while 'ds2' might have 'o=cts'
  • Deploy an OpenAM 11.0.x instance with custom configuration similar to this:
    SERVER_URL=http://openam.example.com:8080
    DEPLOYMENT_URI=/openam
    BASE_DIR=/root/openam
    locale=en_US
    PLATFORM_LOCALE=en_US
    AM_ENC_KEY=123456789012
    ADMIN_PWD=password
    AMLDAPUSERPASSWD=password1
    COOKIE_DOMAIN=.example.com
    ACCEPT_LICENSES=true
    DATA_STORE=dirServer
    DIRECTORY_SSL=SIMPLE
    DIRECTORY_SERVER=localhost
    DIRECTORY_PORT=389
    DIRECTORY_ADMIN_PORT=4444
    DIRECTORY_JMX_PORT=1689
    ROOT_SUFFIX=o=openam
    DS_DIRMGRDN=cn=Directory Manager
    DS_DIRMGRPASSWD=password
    USERSTORE_TYPE=LDAPv3ForOpenDS
    USERSTORE_SSL=SIMPLE
    USERSTORE_HOST=localhost
    USERSTORE_PORT=389
    USERSTORE_SUFFIX=o=forgerock
    USERSTORE_MGRDN=cn=Directory Manager
    USERSTORE_PASSWD=password
    LB_SITE_NAME=lb
    LB_PRIMARY_URL=http://lb.example.com:80/openam
    LB_SESSION_HA_SFO=true
    
    • From the silent file you can see that the site configuration with session failover is enabled which is another requirement for this setup
  • Configuration->Servers and Sites->Default Server Parameters->CTS
    • configure the parameters for the external CTS
    • save
  • log out, shut down the server and perform the upgrade
Comment by Nemanja Lukic [ 28/Apr/16 ]

Verified in: 12.0.3-RC2

Comment by Nemanja Lukic [ 28/Apr/16 ]

closed prematurely, pending verification for 13.0.0

Generated at Sat Oct 24 00:42:27 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.