If automatic repository checkpoints are enabled, the product creates a delta checkpoint whenever a change is made to the configuration repository. A delta checkpoint compressed zip file contains the before and after versions of configuration files that have changed. You can extract the contents of the compressed file and then examine the extracted files to determine what has changed in the configuration.
Enable the product to create delta checkpoints automatically:
You can use a delta checkpoint to undo recent changes to the product configuration.
You can also use a delta checkpoint to determine what changes were made to the configuration. This topic discusses how to interpret the contents of an extracted delta repository to determine changes in the configuration.
Review the following information to see how various changes to the product configuration are shown in extracted files:
If the changed files are text or XML files, you can use a text comparison tool to compare the difference between the before and after versions. A visual text comparison tool that shows the two files in side by side comparisons is more effective to highlight the differences. If a configuration element shows only changes to the xmi:id attribute, you can ignore these changes because they do not modify any behavior.
You cannot use text comparison tools to compare binary files such as keystore and truststore files, application binary files, and shared libraries. For key and truststore files, use ikeyman or other key management tools to look at the contents of these files for any differences in the certificates. For application binary or shared library Java archive (JAR) files, manually compare them using JAR or zip utilities to unpack the files.
before/cells/isthmusCell03/repository/repository.xml
after/cells/isthmusCell03/repository/repository.xml
The after version of the repository.xml file contains the updated configuration. In the following example, the after version has an updated value for autoCheckpointsDepth:
repositorycheckpoint:ExtendedRepositoryService xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:repositorycheckpoint="http://www.ibm.com/websphere/appserver/schemas/6.0/repositorycheckpoint.xmi"
xmi:id="ExtendedRepositoryService_1" checkpointRoot="${USER_INSTALL_ROOT}/checkpoints"
autoCheckpointsEnabled="true" autoCheckpointsDepth="50"/>
before/cells/isthmusCell03/nodes/isthmusNode02/node.xml.ADDED
...
before/cells/isthmusCell03/applications/ibmasyncrsp.ear/deployments/ibmasyncrsp/deployment.xml
...
before/cells/isthmusCell03/security.xml
...
after/cells/isthmusCell03/nodes/isthmusNode02/node.xml
after/cells/isthmusCell03/applications/ibmasyncrsp.ear/deployments/ibmasyncrsp/deployment.xml
after/cells/isthmusCell03/security.xml
The changes to security.xml include additions to SSL configuration and key or trust stores. The addition of new SSL configuration looks like:
<repertoire xmi:id="SSLConfig_1326647216593" alias="NodeDefaultSSLSettings"
managementScope="ManagementScope_1326647216593">
<setting xmi:id="SecureSocketLayer_1326647216593" clientAuthentication="false" securityLevel="HIGH"
enabledCiphers="" jsseProvider="IBMJSSE2" sslProtocol="SSL_TLS" keyStore="KeyStore_1326647216593"
trustStore="KeyStore_2" trustManager="TrustManager_1326647216593"
keyManager="KeyManager_1326647216593"/>
</repertoire>
...
<managementScopes xmi:id="ManagementScope_1326647216593"
scopeName="(cell):isthmusCell03:(node):isthmusNode02" scopeType="node"/>
...
Node level key and trust stores, and trust managers, resemble:
<keyStores xmi:id="KeyStore_1326647216593" name="NodeDefaultKeyStore" password="{xor}CDo9Hgw="
provider="IBMJCE" location="${CONFIG_ROOT}/cells/isthmusCell03/nodes/isthmusNode02/key.p12"
type="PKCS12" fileBased="true" hostList="" description="Default key store for isthmusNode02"
usage="SSLKeys" managementScope="ManagementScope_1326647216593"/>
<keyStores xmi:id="KeyStore_1326647216594" name="NodeDefaultTrustStore"
password="{xor}CDo9Hgw=" provider="IBMJCE"
location="${CONFIG_ROOT}/cells/isthmusCell03/nodes/isthmusNode02/trust.p12" type="PKCS12"
fileBased="true" hostList="" description="Default trust store for isthmusNode02"
usage="SSLKeys" managementScope="ManagementScope_1326647216593"/>
...
<trustManagers xmi:id="TrustManager_1326647216594" name="IbmX509" provider="IBMJSSE2"
algorithm="IbmX509" managementScope="ManagementScope_1326647216593"/>
<trustManagers xmi:id="TrustManager_1326647216593" name="IbmPKIX" provider="IBMJSSE2"
algorithm="IbmPKIX" trustManagerClass="" managementScope="ManagementScope_1326647216593">
<additionalTrustManagerAttrs xmi:id="DescriptiveProperty_1326647216593"
name="com.ibm.security.enableCRLDP" value="false" type="boolean" displayNameKey=""
nlsRangeKey="" hoverHelpKey="" range="" inclusive="false" firstClass="false"/>
...
</trustManagers>
...
<keyManagers xmi:id="KeyManager_1326647216593" name="IbmX509" provider="IBMJSSE2"
algorithm="IbmX509" keyManagerClass="" managementScope="ManagementScope_1326647216593"/>
...
<sslConfigGroups xmi:id="SSLConfigGroup_1326647216593" name="isthmusNode02" direction="inbound"
sslConfig="SSLConfig_1326647216593" managementScope="ManagementScope_1326647216593"/>
<sslConfigGroups xmi:id="SSLConfigGroup_1326647216594" name="isthmusNode02" direction="outbound"
sslConfig="SSLConfig_1326647216593" managementScope="ManagementScope_1326647216593"/>
...
<properties xmi:id="Property_1326647216593" name="com.ibm.websphere.security.DeferTAItoSSO"
value="com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl"
description="Trust Association Interceptors are invoked after Single Sign On user validation."
required="false"/>
Some system applications are targeted to new servers on the new node. The changes might include new target mappings. For example, the changes to the ibmasyncrsp application include changes to the isthmusCell03/applications/ibmasyncrsp.ear/deployments/ibmasyncrsp/deployment.xml file:
<targetMappings xmi:id="DeploymentTargetMapping_1326647226406" enable="true"
target="ServerTarget_1326647226406"/>
...
<targetMappings xmi:id="DeploymentTargetMapping_1326647226407"
target="ServerTarget_1326647226406"/>
...
<deploymentTargets xmi:type="appdeployment:ServerTarget" xmi:id="ServerTarget_1326647226406"
name="server1" nodeName="isthmusNode02"/>
If you have automatic plug-in generation enabled, the product might regenerate the plug-in file. This results in another delta checkpoint being created, resembling:
before/cells/plugin-cfg.xml.ADDED
after/cells/plugin-cfg.xml
And finally, the ports of the servers in new node are added to virtual host definitions:
before/cells/isthmusCell03/virtualhosts.xml
after/cells/isthmusCell03/virtualhosts.xml
The additions to virtualhosts.xml include:
<aliases xmi:id="HostAlias_1326647278546" hostname="*" port="9130"/>
<aliases xmi:id="HostAlias_1326647278609" hostname="*" port="9508"/>
<aliases xmi:id="HostAlias_1326647278671" hostname="*" port="5113"/>
<aliases xmi:id="HostAlias_1326647278718" hostname="*" port="5112"/>
before/cells/isthmusCell03/clusters/TestCluster1/cluster.xml.ADDED
before/cells/isthmusCell03/nodes/isthmusNode01/serverindex.xml
before/cells/isthmusCell03/nodes/isthmusNode02/serverindex.xml
before/cells/isthmusCell03/nodes/isthmusNode02/servers/TestCluster1_Node2_1/server.xml.ADDED
before/cells/isthmusCell03/nodes/isthmusNode01/servers/TestCluster1_Node1_1/server.xml.ADDED
...
after/cells/isthmusCell03/clusters/TestCluster1/cluster.xml
after/cells/isthmusCell03/nodes/isthmusNode01/serverindex.xml
after/cells/isthmusCell03/nodes/isthmusNode02/server
after/cells/isthmusCell03/nodes/isthmusNode02/servers/TestCluster1_Node2_1/server.xml
after/cells/isthmusCell03/nodes/isthmusNode01/servers/TestCluster1_Node1_1/server.xml
before/cells/isthmusCell03/clusters/TestCluster1/resources.xml
before/cells/isthmusCell03/clusters/TestCluster1/variables.xml
after/cells/isthmusCell03/clusters/TestCluster1/resources.xml
after/cells/isthmusCell03/clusters/TestCluster1/variables.xml
A new factory is shown in configuration files as follows:
<factories xmi:type="resources.jdbc:CMPConnectorFactory" xmi:id="CMPConnectorFactory_1326647771671"
name="TestCluster1DataSource_CF" authMechanismPreference="BASIC_PASSWORD"
connectionDefinition="ConnectionDefinition_1054132487569" cmpDatasource="DataSource_1326647771656">
<propertySet xmi:id="J2EEResourcePropertySet_1326647771671"/>
</factories>
A new JDBC provider with a data source is shown in configuration files as follows:
<resources.jdbc:JDBCProvider xmi:id="JDBCProvider_1326647771343"
name="DB2 Universal JDBC Driver Provider (XA)"
description="Two-phase commit DB2 JCC provider that supports JDBC 3.0. Data sources that use
this provider support the use of XA to perform 2-phase commit processing. Use of driver
type 2 on the application server for z/OS is not supported for data sources created under
this provider."
providerType="DB2 Universal JDBC Driver Provider (XA)" isolatedClassLoader="false"
implementationClassName="com.ibm.db2.jcc.DB2XADataSource" xa="true">
...
<factories xmi:type="resources.jdbc:DataSource" xmi:id="DataSource_1326647771656"
name="TestCluster1DataSource" jndiName="TestCluster1DataSource"
description="DB2 Universal Driver Datasource"
providerType="DB2 Universal JDBC Driver Provider (XA)" authMechanismPreference="BASIC_PASSWORD"
authDataAlias="" manageCachedHandles="false" logMissingTransactionContext="true"
xaRecoveryAuthAlias="" diagnoseConnectionUsage="false" relationalResourceAdapter="builtin_rra"
statementCacheSize="10"
datasourceHelperClassname="com.ibm.websphere.rsadapter.DB2UniversalDataStoreHelper">
...
</factories>
</resources.jdbc:JDBCProvider>
You might see that some configuration elements contain changes to xml:id only. You can ignore these changes. For example, the following two elements have changed xml:id values:
<displayNames xmi:id="DisplayName_1326647771359" value="WS_RdbResourceAdapter"/>
<displayNames xmi:id="DisplayName_1326647771360" value="WebSphere Default Messaging Provider"/>
before/cells/isthmusCell03/nodes/isthmusNode01/servers/TestCluster1_Node1_1/server.xml
after/cells/isthmusCell03/nodes/isthmusNode01/servers/TestCluster1_Node1_1/server.xml
The following changes to Java virtual machine settings:
Result in an after version of the server.xml:
<jvmEntries xmi:id="JavaVirtualMachine_1326647543890" verboseModeClass="false"
verboseModeGarbageCollection="true" verboseModeJNI="false" initialHeapSize="512"
maximumHeapSize="768" runHProf="false" hprofArguments="" debugMode="false"
debugArgs="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=7777"
genericJvmArguments="-DMyVar=MyVal" executableJarFileName="" disableJIT="false">
This new version of the server.xml file has the additional XML attributes executablejarFileName and disableJIT. These attributes do not introduce any behavior change because a managed application server does not need executableJarFileName and JIT is disabled by default.
before/cells/isthmusCell03/nodes/isthmusNode01/servers/TestCluster1_Node1_1/sib-service.xml
before/cells/isthmusCell03/nodes/isthmusNode02/servers/TestCluster1_Node2_1/sib-service.xml
before/templates/clusters/TestCluster1/servers/V8MemberTemplate/sib-service.xml
before/cells/isthmusCell03/coregroups/DefaultCoreGroup/coregroup.xml
before/cells/isthmusCell03/buses/TestBus/sib-authorisations.xml.ADDED
before/cells/isthmusCell03/buses/TestBus/sib-bus.xml.ADDED
before/cells/isthmusCell03/buses/TestBus/sib-destinations.xml.ADDED
before/cells/isthmusCell03/clusters/TestCluster1/sib-engines.xml.ADDED
after/cells/isthmusCell03/nodes/isthmusNode02/servers/TestCluster1_Node2_1/sib-service.xml
after/cells/isthmusCell03/nodes/isthmusNode01/servers/TestCluster1_Node1_1/sib-service.xml
after/templates/clusters/TestCluster1/servers/V8MemberTemplate/sib-service.xml
after/cells/isthmusCell03/coregroups/DefaultCoreGroup/coregroup.xml
after/cells/isthmusCell03/buses/TestBus/sib-authorisations.xml
after/cells/isthmusCell03/buses/TestBus/sib-bus.xml
after/cells/isthmusCell03/buses/TestBus/sib-destinations.xml
after/cells/isthmusCell03/clusters/TestCluster1/sib-engines.xml
Changes to sib-service.xml for the existing cluster members and for the cluster level template enable the SIBService. In the following example, enabling SIBService sets the enable property to true:
sibservice:SIBService xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
xmlns:sibservice="http://www.ibm.com/websphere/appserver/schemas/6.0/sibservice.xmi"
xmi:id="SIBService_1" enable="true"/>
Additional configurations are added to coregroup.xml file, depending on the policies you chose. The following example shows the addition of a policy for high availability:
<policies xmi:type="coregroup:OneOfNPolicy" xmi:id="OneOfNPolicy_1326648336750"
name="TestCluster1.000-TestBus-3423A696EADD6FA7Policy"
policyFactory="com.ibm.ws.hamanager.coordinator.policy.impl.OneOfNPolicyFactory"
isAlivePeriodSec="120" quorumEnabled="false" failback="false" preferredOnly="false">
<MatchCriteria xmi:id="MatchCriteria_1326648336765" name="type" value="WSAF_SIB"/>
<MatchCriteria xmi:id="MatchCriteria_1326648336781" name="WSAF_SIB_MESSAGING_ENGINE"
value="TestCluster1.000-TestBus"/>
</policies>
before/cells/isthmusCell03/buses/TestBus/sib-destinations.xml
before/cells/isthmusCell03/clusters/TestCluster1/sib-engines.xml
after/cells/isthmusCell03/buses/TestBus/sib-destinations.xml
after/cells/isthmusCell03/clusters/TestCluster1/sib-engines.xml
The sib-destinations.xml file shows the addition of a SIBQueue:
<sibresources:SIBQueue xmi:id="SIBQueue_1326648599140" identifier="TestBusQeue1"
uuid="0AA3CFB9BB0FFA92BE5BCB57" description="" overrideOfQOSByProducerAllowed="true"
exceptionDestination="$DEFAULT_EXCEPTION_DESTINATION" sendAllowed="true" receiveAllowed="true">
<localizationPointRefs xmi:id="SIBLocalizationPointRef_1326648599156" cluster="TestCluster1"
engineUuid="3423A696EADD6FA7"/>
</sibresources:SIBQueue>
The sib-engines.xml shows the addition of a SIBQueueLocaliazationPoint:
<localizationPoints xmi:type="sibresources:SIBQueueLocalizationPoint"
xmi:id="SIBQueueLocalizationPoint_1326648599156" identifier="TestBusQeue1@TestCluster1.000-TestBus"
uuid="A55E76D18D6F4339" targetUuid="0AA3CFB9BB0FFA92BE5BCB57" highMessageThreshold="50000"/>
The use of targetUUID correlates with the uuid of the SIBQueue.
before/cells/isthmusCell03/clusters/TestCluster1/resources.xml
after/cells/isthmusCell03/clusters/TestCluster1/resources.xml
The addition to resources.xml looks like:
<factories xmi:type="resources.j2c:J2CConnectionFactory"
xmi:id="J2CConnectionFactory_1326648753984" name="TestClusterQCF" jndiName="TestClusterQCF"
description="" category="" authDataAlias="" manageCachedHandles="false"
logMissingTransactionContext="false" xaRecoveryAuthAlias=""
connectionDefinition="ConnectionDefinition_1326644816218">
...
</factories>
before/cells/isthmusCell03/clusters/TestCluster1/resources.xml
after/cells/isthmusCell03/clusters/TestCluster1/resources.xml
Creation of a JMS queue at the cluster level changes the cluster level resources.xml file. The addition of the resources.xml file looks like:
<j2cAdminObjects xmi:id="J2CAdminObject_1326649181984" jndiName="jms/TestClusterQueue"
name="TestClustereQueue" description="" adminObject="AdminObject_1326644816218">
...
</j2cAdminObjects>
before/cells/isthmusCell03/nodes/isthmusNode01/serverindex.xml
before/cells/isthmusCell03/nodes/isthmusNode02/serverindex.xml
before/cells/isthmusCell03/blas/IVT Application/bver/BASE/bla.xml.ADDED
before/cells/isthmusCell03/cus/IVT Application/cver/BASE/controlOpDefs.xml.ADDED
before/cells/isthmusCell03/applications/IVT Application.ear/deployments/IVT Application/deployment.xml.ADDED
...
after/cells/isthmusCell03/nodes/isthmusNode01/serverindex.xml
after/cells/isthmusCell03/nodes/isthmusNode02/serverindex.xml
after/cells/isthmusCell03/blas/IVT Application/bver/BASE/bla.xml
after/cells/isthmusCell03/cus/IVT Application/cver/BASE/controlOpDefs.xml
after/cells/isthmusCell03/applications/IVT Application.ear/deployments/IVT Application/deployment.xml
...
The addition to the serverindex.xml on each node looks like:
<deployedApplications>IVT Application.ear/deployments/IVT Application</deployedApplications>
before/cells/isthmusCell03/nodes/isthmusNode01/serverindex.xml
before/cells/isthmusCell03/nodes/isthmusNode02/serverindex.xml
before/cells/isthmusCell03/blas/IVT Application/bver/BASE/bla.xml
before/cells/isthmusCell03/cus/IVT Application/cver/BASE/controlOpDefs.xml
before/cells/isthmusCell03/applications/IVT Application.ear/deployments/IVT Application/deployment.xml
...
after/cells/isthmusCell03/nodes/isthmusNode01/serverindex.xml
after/cells/isthmusCell03/nodes/isthmusNode02/serverindex.xml
after/cells/isthmusCell03/blas/IVT Application/bver/BASE/bla.xml.DELETED
after/cells/isthmusCell03/cus/IVT Application/cver/BASE/controlOpDefs.xml.DELETED
after/cells/isthmusCell03/applications/IVT Application.ear/deployments/IVT Application/deployment.xml.DELETED
...
before/cells/isthmusCell03/admin-authz.xml after/cells/isthmusCell03/admin-authz.xml
As an example, when adding user2 user to the operator role, the affected portion of admin-authz.xml in the before version is:
<authorizations xmi:id="RoleAssignmentExt_2" role="SecurityRoleExt_2"/>
The after version looks like:
<authorizations xmi:id="RoleAssignmentExt_2" role="SecurityRoleExt_2">
<users xmi:id="UserExt_1326649772453" name="user2"
accessId="user:defaultWIMFileBasedRealm/uid=user2,o=defaultWIMFileBasedRealm"/>
</authorizations>
before/waspolicies/default/securitydomains/TestDomain/domain-security-map.xml.ADDED
before/waspolicies/default/securitydomains/TestDomain/domain-security.xml.ADDED
before/waspolicies/default/securitydomains/TestDomain/wim/config/wimconfig.xml.ADDED
...
before/waspolicies/default/securitydomains/TestDomain/domain-security-map.xml
before/waspolicies/default/securitydomains/TestDomain/domain-security.xml
before/waspolicies/default/securitydomains/TestDomain/wim/config/wimconfig.xml
before/cells/isthmusCell03/security.xml
after/cells/isthmusCell03/security.xml
A SSLConfig addition to security.xml looks like:
<repertoire xmi:id="SSLConfig_1326650114281" alias="TestSSLConfig" type="JSSE"
managementScope="ManagementScope_1">
<setting xmi:id="SecureSocketLayer_1326650114296" clientAuthentication="false"
securityLevel="HIGH" jsseProvider="IBMJSSE2" sslProtocol="SSL_TLS" keyStore="KeyStore_1"
trustStore="KeyStore_1"/>
</repertoire>
Used the identified file changes to revise the product configuration as needed.