デルタ・チェックポイントでの構成変更の検出
自動リポジトリー・チェックポイント が使用可能になっている場合、構成リポジトリーに変更が加えられるたびに、1 つのデルタ・チェックポイント が製品によって作成されます。デルタ・チェックポイント圧縮 zip ファイル 内には、変更された構成ファイルのそれぞれについて、変更前バージョンと変更後バージョン が含まれます。圧縮ファイルの内容を解凍し、 解凍されたファイルを検査すれば、構成にどのような変更が加えられたのかを 判別できます。
始める前に
次のようにして、デルタ・チェックポイントの自動作成を有効にします。
- 管理コンソールから、 をクリックします。
- 「自動リポジトリー・チェックポイントを使用可能にする」を選択します。
- 「自動チェックポイントの深さ」に、保持するデルタ・チェックポイント の数を指定します。
- 変更を保存します。
このタスクについて
デルタ・チェックポイントを使用して、製品構成に対する最近の変更を元に戻すことができます。
また、デルタ・チェックポイントを 使用して、どのような変更が構成に加えられたのかを判別することもできます。このトピック では、抽出されたデルタ・リポジトリーの内容を解釈して、構成の変更を判別する方法について 説明します。
手順
例
以下の情報を検討して、抽出されたファイル内で製品構成に対する各種の変更がどのように表されるのかを確認してください。
- 新規構成ファイル には、サフィックス .ADDED が付いています
- 削除された構成ファイル には、サフィックス .DELETED が付いています
- 変更された構成ファイル には、before バージョンと after バージョンがあります
- 拡張リポジトリー・サービス構成 に対する変更は repository.xml ファイル内にあります
- ノードを 追加すると、最高 3 つの、before および after ファイル・バージョン ができます
- クラスターおよびクラスター・メンバーの作成 は、cluster.xml ファイル、serverindex.xml ファイル、 および server.xml ファイルを変更します
- データ・ソース の作成は、resources.xml ファイルおよび variables.xml ファイルを変更します
- Java 仮想マシン 設定の変更は、server.xml ファイルを変更します
- サービス統合バスの作成 は、SIB 構成ファイルを変更します
- SIBus 宛先の作成 は、sib-destinations.xml ファイルおよび sib-engines.xml ファイルを変更します
- キュー接続ファクトリーの 作成は、resources.xml ファイルを変更します
- JMS キューの作成 は、resources.xml ファイルを変更します
- アプリケーションのデプロイ では、serverindex.xml ファイルが変更され、場合によっては他のファイルも変更されます
- アプリケーションのアンインストール は、serverindex.xml ファイルを変更します
- ロールとユーザーとのマッピングの 追加は、admin-authz.xml ファイルを変更します
- セキュリティー・ドメインの 作成は、waspolicies のサブディレクトリー下のファイルを変更します
- SSL 構成の追加 は、security.xml ファイルを変更します
- 新規構成ファイルには、サフィックス .ADDED が付いています
- 構成ファイルの作成の場合、before バージョン は .ADDED というサフィックスが付いたマーカー・ファイル (例えば server.xml.ADDED) であり、 after バージョンは作成された実際のファイルです。新規構成ファイル は、ノード、クラスター、アプリケーション・サーバー、アプリケーション、または SIBus 成果物の 作成といったアクションの結果として生じます。
- 削除された構成ファイルには、サフィックス .DELETED が付いています
- 構成ファイルの削除の場合、before バージョンは削除されたファイルの 内容であり、after バージョンは .DELETED というサフィックス が付いたマーカー・ファイルです。
- 変更された構成ファイル には、before バージョンと after バージョンがあります
- 既存の構成ファイルの変更の場合、before バージョン
は元の構成であり、after バージョンは変更が加えられた後のファイル
です。既存の構成ファイルに対する変更は、
リソースの作成や変更、または Java 仮想マシン設定の変更といった
アクションの結果として生じます。
変更されたファイルがテキスト・ファイル または XML ファイルである場合、テキスト比較ツールを使用して、before バージョン と after バージョンの相違点を確認できます。2 つのファイルを横並びに 表示して比較できるビジュアルなテキスト比較ツール を使用すると、より効果的に相違点を強調表示できます。構成エレメント が xmi:id 属性への変更のみを示している場合、 これらの変更は、振る舞いを何も変更しないので無視することができます。
テキスト比較 ツールを使用して、バイナリー・ファイル (鍵ストア・ファイルやトラストストア・ファイルなど)、 アプリケーション・バイナリー・ファイル、および共有ライブラリーを比較することはできません。 鍵ファイルおよびトラストストア・ファイルについては、ikeyman または 他の鍵管理ツールを使用して、これらのファイルの内容を表示し、証明書内の 相違点を確認することができます。アプリケーション・バイナリー・ファイルまたは共有ライブラリー Java アーカイブ・ファイル については、JAR または zip ユーティリティーを使用してファイルを解凍し、手動で 比較します。
- 拡張リポジトリー・サービス構成に対する変更は repository.xml ファイル内にあります
- 拡張リポジトリー・サービス構成の使用可能化または変更の場合、
抽出されたデルタ・リポジトリーは repository.xml ファイルに対する変更を示します。
例えば、抽出された圧縮ファイルの内容は次のようなものです。
before/cells/isthmusCell03/repository/repository.xml after/cells/isthmusCell03/repository/repository.xml
after バージョン の repository.xml ファイルは、更新後の構成 を含んでいます。次の例では、after バージョン には、更新された後の 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"/>
- ノードの追加の結果、最高 3 つの、before および after ファイル・バージョン ができます
- ノードの追加の場合、最大 3 個のデルタ・チェックポイントが
作成されます。最初のリポジトリー変更は、addNode 操作自体
です。before イメージには、file_name.ADDED という形式の
マーカー・ファイルが主に含まれていて、それらのファイルが以前には存在していなかったことを示します。after イメージには、
追加されたファイルが含まれています。また、addNode は、システム・アプリケーションの構成
および security.xml 内のセキュリティー設定も変更します。
以下に例を示します。
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
security.xml に対する変更 には、SSL 構成、および鍵ストアまたはトラストストアへの追加が含まれます。新規 SSL 構成 の追加の例を以下に示します。
<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"/> ...
ノード・レベルの鍵ストアおよびトラストストア、およびトラスト・マネージャー の例を以下に示します。
<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"/>
一部のシステム・アプリケーションは、 新規ノード上の新規サーバーをターゲットとします。変更は、新しいターゲット・マッピング を伴う場合があります。例えば、ibmasyncrsp アプリケーションに 対する変更には、isthmusCell03/applications/ibmasyncrsp.ear/deployments/ibmasyncrsp/deployment.xml ファイルへの変更が含まれます。
<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"/>
自動プラグイン生成 を有効にしている場合、プラグイン・ファイルが再生成 される可能性があります。この結果、次の例に似た、もう 1 つのデルタ・チェックポイントが作成 されます。
before/cells/plugin-cfg.xml.ADDED after/cells/plugin-cfg.xml
さらに、次のように、新規ノード内のサーバーの ポートが仮想ホスト定義に追加されます。
before/cells/isthmusCell03/virtualhosts.xml after/cells/isthmusCell03/virtualhosts.xml
virtualhosts.xml への追加には、以下が含まれます。
<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"/>
- クラスターおよびクラスター・メンバーの作成は、cluster.xml ファイル、serverindex.xml ファイル、 および server.xml ファイルを変更します
- クラスターが作成されると、構成リポジトリーに cluster.xml ファイル
が追加されます。クラスター・メンバーが作成されると、
ノードの serverindex.xml ファイルが更新
され、新規 server.xml ファイルおよび関連する他の構成ファイル
が作成されます。例えば、2 つの異なるノード TestCluster1_Node1_1 と TestCluster1_Node2_1 に
メンバーを持つ、TestCluster という名前の
クラスターを作成すると、以下のファイルに変更が加えられます。
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
- データ・ソースの作成は、resources.xml ファイルおよび variables.xml ファイルを変更します
- データ・ソースが作成されると resources.xml ファイルおよび variables.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
以下のように、構成ファイル 内に新規ファクトリーが示されます。
<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>
以下のように、構成ファイル内に、データ・ソースを伴う新規 JDBC プロバイダーが 示されます。
<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>
いくつかの 構成エレメントが xml:id のみに対する変更を含んでいる場合があります。 これらの変更は無視してもかまいません。例えば、 次の 2 つのエレメントは xml:id 値を変更しています。
<displayNames xmi:id="DisplayName_1326647771359" value="WS_RdbResourceAdapter"/> <displayNames xmi:id="DisplayName_1326647771360" value="WebSphere Default Messaging Provider"/>
- Java 仮想マシン設定の変更は、server.xml ファイルを変更します
- Java 仮想マシン設定に対する変更
は server.xml ファイルに保管されます。
before/cells/isthmusCell03/nodes/isthmusNode01/servers/TestCluster1_Node1_1/server.xml after/cells/isthmusCell03/nodes/isthmusNode01/servers/TestCluster1_Node1_1/server.xml
Java 仮想マシン設定に対して以下の変更があったとします。
- 冗長ガーベッジ・コレクションの使用可能化
- 初期ヒープ・サイズを 512 MB に変更
- 最大ヒープ・サイズを 768 MB に変更
- システム・プロパティー MyVar=MVal の追加
これらの変更の結果、以下のような、after バージョンの 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">
この新 バージョンの server.xml ファイルには、 XML 属性 executablejarFileName および disableJIT が追加されています。 これらの属性によって何らかの動作変更が生じることはありません。なぜなら、 管理対象アプリケーション・サーバーは executableJarFileNameを 必要とせず、JIT はデフォルトで使用不可にされるためです。
- サービス統合バスの作成は、SIB 構成ファイルを変更します
- バスの作成によって、新規ファイルが cells/cell_name/buses/bus_name ディレクトリー
の下に追加され、バス・メンバー構成が変更されます。例えば、
TestCluster1 有効範囲にあるバス・メンバーを持つ、TestBus という名前のバス
を作成した後には、次のファイルが変更されます。
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
既存のクラスター・メンバー およびクラスター・レベル・テンプレートの sib-service.xml への変更 は、SIBService を使用可能にします。次の 例では、SIBService の使用可能化によって、enable プロパティー が 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"/>
トラブルの回避 (Avoid trouble): after バージョンの構成ファイル には、before バージョンのファイルからコメントを削除する という変更が含まれている場合があります。gotcha
選択したポリシーに基づいて、追加の構成が coregroup.xml ファイル に追加されます。次の例は、高可用性のポリシーの 追加を示しています。
<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>
- SIBus 宛先の作成は、sib-destinations.xml ファイルおよび sib-engines.xml ファイルを変更します
- 宛先を作成すると、SIB 構成ファイルが変更されます。
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
sib-destinations.xml ファイル に、次のように 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>
sib-engines.xml ファイル に、次のように SIBQueueLocaliazationPoint の追加が示されます。
<localizationPoints xmi:type="sibresources:SIBQueueLocalizationPoint" xmi:id="SIBQueueLocalizationPoint_1326648599156" identifier="TestBusQeue1@TestCluster1.000-TestBus" uuid="A55E76D18D6F4339" targetUuid="0AA3CFB9BB0FFA92BE5BCB57" highMessageThreshold="50000"/>
targetUUID の 使用は、SIBQueue の uuid と相関します。
- キュー接続ファクトリーの作成は、resources.xml ファイルを変更します
- キュー接続ファクトリーへの変更は resources.xml ファイルに保管されます。
クラスター・レベルで作成されたキュー接続ファクトリーは、
クラスター・レベルの resources.xml ファイルを変更します。
before/cells/isthmusCell03/clusters/TestCluster1/resources.xml after/cells/isthmusCell03/clusters/TestCluster1/resources.xml
resources.xml への追加の例を以下に示します。
<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>
- JMS キューの作成は、resources.xml ファイルを変更します。
- JMS キューの追加は、resources.xml ファイルを変更します。
before/cells/isthmusCell03/clusters/TestCluster1/resources.xml after/cells/isthmusCell03/clusters/TestCluster1/resources.xml
クラスター・レベル での JMS キューの作成は、クラスター・レベルの resources.xml ファイルを変更します。 以下に、resources.xml ファイルの追加の例を 示します。
<j2cAdminObjects xmi:id="J2CAdminObject_1326649181984" jndiName="jms/TestClusterQueue" name="TestClustereQueue" description="" adminObject="AdminObject_1326644816218"> ... </j2cAdminObjects>
- アプリケーションのデプロイでは、serverindex.xml ファイルが変更され、 場合によっては他のファイルも変更されます
- アプリケーションのデプロイメントでは、ターゲット・ノードの serverindex.xml ファイル
が変更されます。ビジネス・レベル・アプリケーションおよび構成単位の構成に対する変更
は、Java EE アプリケーションの場合であっても、
cells/cell_name/applications/application_name サブディレクトリーの下のアプリケーション・ディレクトリー内のファイルの変更につながります。
例えば、2 つのノードから成るクラスターへの IVT アプリケーションのデプロイ
は、以下のファイルに対する変更を引き起こします。
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 ...
以下に、各ノード上の serverindex.xml への 追加の例を示します。
<deployedApplications>IVT Application.ear/deployments/IVT Application</deployedApplications>
- アプリケーションのアンインストールは、serverindex.xml ファイルを変更します
- アプリケーションのアンインストールの結果として、そのアプリケーションの除去とアプリケーション・ファイルの削除のため、serverindex.xml ファイル
が変更されます。エクスポートされた圧縮ファイル内
で、削除されたファイルは .DELETED サフィックス付きで付加されます。
例えば、2 つのノードからなるクラスターからの IVT アプリケーションのアンインストール
に影響を受けるファイルは、次のとおりです。
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 ...
- ロールとユーザーとのマッピングの追加は、admin-authz.xml ファイルを変更します
- 管理許可の変更は、admin-authz.xml ファイルに影響を及ぼします。
before/cells/isthmusCell03/admin-authz.xml after/cells/isthmusCell03/admin-authz.xml
例と して、user2 ユーザーを operator ロールに 追加した場合、before バージョンの admin-authz.xml の 影響される部分は、次のとおりです。
<authorizations xmi:id="RoleAssignmentExt_2" role="SecurityRoleExt_2"/>
after バージョン は次のようになります。
<authorizations xmi:id="RoleAssignmentExt_2" role="SecurityRoleExt_2"> <users xmi:id="UserExt_1326649772453" name="user2" accessId="user:defaultWIMFileBasedRealm/uid=user2,o=defaultWIMFileBasedRealm"/> </authorizations>
- セキュリティー・ドメインの作成は、waspolicies のサブディレクトリー下のファイルを変更します
- セキュリティー・ドメインに関連するファイルは、waspolicies のサブディレクトリーの下に保管されます。
例えば、TestDomain という名前のセキュリティー・ドメインを追加すると、
多くのファイルが waspolices/default/securitydomains/TestDomain ディレクトリーの下に作成されます。
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
- SSL 構成の追加は、security.xml ファイルを変更します
- SSL 構成は security.xml に保管されます。
したがって、SSL 構成を追加すると、以下のようなファイルが変更されます。
before/cells/isthmusCell03/security.xml after/cells/isthmusCell03/security.xml
以下に、security.xml への SSLConfig 追加の例を示します。
<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>
次のタスク
特定されたファイル変更を使用して、必要に応じて製品構成を改訂します。