Recherche des modifications de configuration dans les point de contrôle delta

Si les points de contrôle de référentiel automatiques sont activés, le produit crée un point de contrôle delta chaque fois qu'une modification est apportée au référentiel de configuration. Un fichier zip compressé de point de contrôle delta contient les versions antérieures et postérieures des fichiers de configuration qui ont été modifiés. Vous pouvez extraire le contenu du fichier compressé et examiner les fichiers extraits afin de déterminer ce qui a été modifié dans la configuration.

Avant de commencer

Activation du produit pour la création des points de contrôle delta automatiquement :

  1. Dans la console d'administration, cliquez sur Administration du système > Service de référentiel de données.
  2. Sélectionnez Activer la création de points de contrôle automatiques pour le référentiel.
  3. Indiquez le nombre de points de contrôle delta à conserver en regard de Points de contrôle automatiques - Profondeur.
  4. Sauvegardez les modifications.

Pourquoi et quand exécuter cette tâche

Vous pouvez utiliser un point de contrôle delta pour annuler des modifications récentes apportées à la configuration du produit.

Vous pouvez également utiliser un point de contrôle delta afin de déterminer les modifications qui ont été apportées à la configuration. Cette rubrique explique comment interpréter le contenu d'un référentiel de delta extrait afin de déterminer les modifications apportées à la configuration.

Procédure

  1. Exportez un point de contrôle delta.
    1. Cliquez sur Administration système > Service de référentiel étendu > Points de contrôle de référentiel.
    2. Dans la page Points de contrôle de référentiel, sélectionnez le point de contrôle delta et cliquez sur Exporter.
    3. Dans la page Exporter des points de contrôle de référentiel, sélectionnez le nom du fichier fichier zip compressé.
    4. Sauvegardez le fichier dans un emplacement spécifique.
  2. Procédez à l'extraction des fichiers du fichier compressé exporté.
  3. Examinez les fichiers extraits afin de déterminer les modifications apportées à la configuration.

Exemple

Passez en revue les informations suivantes afin de voir comment sont indiquées dans les fichiers extraits les différentes modifications apportées à la configuration du produit :

Les nouveaux fichiers de configuration portent le suffixe .ADDED
Lorsque des fichiers de configuration sont créés, la version before (avant) est un fichier de marquage avec le suffixe .ADDED, par exemple server.xml.ADDED, tandis que la version after (après) est le fichier qui est effectivement créé. De nouveaux fichiers de configuration sont créés lors d'opérations telles que la création de noeuds, de clusters, de serveurs d'applications ou d'artefacts SIBus.
Les fichiers de configuration supprimés portent le suffixe .DELETED
Lorsque des fichiers de configuration sont supprimés, la version before (avant) est le contenu du fichier qui a été supprimé, tandis que la version after (après) est un fichier de marquage avec le suffixe .DELETED.
Les fichiers de configuration modifiés comportent des versions before (avant) et after (après)
Lorsque des fichiers de configuration existants sont modifiés, la version d'avant est la configuration d'origine, tandis que la version d'après est le fichier une fois les modifications effectuées. Les modifications apportées à des fichiers de configuration existants proviennent d'opérations telles que la création ou la modification de ressources ou la modification des paramètres de machine virtuelle Java.

Si les fichiers modifiés sont des fichiers texte ou XML, vous pouvez utiliser un outil de comparaison de texte pour comparer les différences entre les versions before (avant) et after (après). Un outil de comparaison de texte visuel affichant les deux fichiers dans des comparaisons côte à côte text est plus efficace pour mettre en évidence les différences. Si un élément de configuration indique uniquement des modifications de l'attribut xmi:id, vous pouvez ignorer ces modifications car elles ne changent aucun comportement.

Vous ne pouvez pas utiliser des outils de comparaison pour comparer des fichiers binaires tels que des fichiers de clés et des fichiers de clés certifiées, des fichiers binaires d'application et des bibliothèques partagées. Pour les fichiers de clés et les fichiers de clés certifiées, utilisez l'outil Ikeyman ou d'autres outils de gestion des clés pour consulter le contenu des fichiers et rechercher d'éventuelles différences dans les certificats. Pour les fichiers binaires d'application ou les fichiers JAR de bibliothèque partagée, effectuez une comparaison manuelle à l'aide d'utilitaires JAR ou zip pour décompresser les fichiers.

Les modifications apportées à la configuration du service de référentiel étendu figurent dans les fichiers repository.xml
Lors de l'activation ou de la modification de la configuration du service de référentiel étendu, le delta de référentiel extrait indique une modification du fichier repository.xml. Le fichier compressé extrait comporte par exemple :
before/cells/isthmusCell03/repository/repository.xml
after/cells/isthmusCell03/repository/repository.xml

La version après (after) du fichier repository.xml contient la configuration mise à jour. Dans l'exemple suivant, la version after comporte une valeur mise à jour pour 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"/>
L'ajout d'un noeud se traduit par la création de trois versions de fichier before (avant) et after (après)
Lors de l'ajout d'un noeud, vous pouvez constater la création de trois points de contrôle delta. La première modification de référentiel est l'opération addNode elle-même. L'image before (avant) contient la plupart des fichiers de marquage sous la forme nom_fichier.ADDED, ce qui signifie que ces fichiers n'existaient pas auparavant. L'image after (après) contient le fichier qui est ajouté. En outre, l'opération modifie également la configuration des applications système, ainsi que les paramètres de sécurité dans security.xml. Par exemple :
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

Les modifications apportées au fichier security.xml incluent les ajouts aux configurations SSL et aux fichiers de clés ou fichiers de clés certifiées. L'ajout d'une nouvelle configuration SSL est indiqué comme suit :

<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"/>
...

Les fichiers de clés et les fichiers de clés certifiées, ainsi que les gestionnaires d'accréditation sont représentés comme suit :

<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"/>

Certaines applications système sont ciblées pour les nouveaux serveurs sur le nouveau noeud. Les modifications peuvent comporter de nouveaux mappages cibles. Par exemple, les modifications apportées à l'application ibmasyncrsp incluent les modifications apportées au fichier 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"/>

Si la génération de plug-in automatique est activée, il se peut que le produit régénère le fichier plug-in. Cela entraîne la création d'un autre point de contrôle delta, semblable au suivant :

before/cells/plugin-cfg.xml.ADDED
after/cells/plugin-cfg.xml

Enfin, les ports de serveurs du nouveau noeud sont ajoutés aux définitions hôtes virtuelles :

before/cells/isthmusCell03/virtualhosts.xml
after/cells/isthmusCell03/virtualhosts.xml

Les ajouts dans virtualhosts.xml sont les suivants :

<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"/>
La création de clusters et de membres de cluster modifie les fichiers cluster.xml, serverindex.xml et server.xml
En cas de création d'un cluster, le produit ajoute un fichier cluster.xml au référentiel de configuration. En cas de création d'un membre de cluster, le noeud serverindex.xml est mis à jour et un nouveau fichier server.xml ainsi que d'autres fichiers de configuration connexes sont créés. Par exemple, la création d'un cluster appelé TestCluster avec des membres sur deux noeuds différents, TestCluster1_Node1_1 et TestCluster1_Node2_1, se traduit par des modifications des fichiers suivants :
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
La création de sources de données modifié les fichiers resources.xml et variables.xml
Si une source de données est créée,le produit modifie les fichiers resources.xml et variables.xml ; par exemple :
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

Une nouvelle fabrique apparaît dans les fichiers de configuration comme suit :

<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>

Un nouveau fournisseur JDBC avec une source de données apparaît dans les fichiers de configuration comme suit :

<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>

Vous remarquerez peut-être que certains éléments de configuration comportent des modifications de l'élément xml:id uniquement. Vous pouvez ignorer ces modifications. Par exemple, les deux éléments suivants comportent des modifications des valeurs xml:id :

<displayNames xmi:id="DisplayName_1326647771359" value="WS_RdbResourceAdapter"/>
<displayNames xmi:id="DisplayName_1326647771360" value="WebSphere Default Messaging Provider"/>
La modification des paramètres de machine virtuelle Java modifie les fichiers server.xml
Le produit enregistre les modifications apportées aux paramètre de machine virtuelle Java dans le fichier server.xml :
before/cells/isthmusCell03/nodes/isthmusNode01/servers/TestCluster1_Node1_1/server.xml
after/cells/isthmusCell03/nodes/isthmusNode01/servers/TestCluster1_Node1_1/server.xml 

Les modifications suivantes sont apportées aux paramètres de machine virtuelle Java :

  • Activation du processus de récupération de place en mode prolixe
  • Définition de la taille de pile initiale sur 512 Mo
  • Définition de la taille de pile maximale sur 768 Mo
  • Ajout de la propriété système, MyVar=MVal

Résultat dans la version after du fichier 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">

Cette nouvelle version du fichier server.xml comporte les attributs XML supplémentaires executablejarFileName et disableJIT. Ces attributs n'impliquent aucun changement de comportement car executableJarFileName n'est pas nécessaire pour un serveur d'applications et JIT est désactivé par défaut.

La création d'un bus d'intégration de services modifie les fichiers de configuration SIB
Lors de la création d'un bus, le produit ajoute de nouveaux fichiers sous le répertoire cells/nom_cellule/buses/nom_bus et modifie les configurations de membre de bus. Par exemple, le fichier suivant est modifié après la création d'un bus nommé TestBus avec des membres de bus sous la portée TestCluster1 :
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  

Les modifications apportées au fichier sib-service.xml pour les membres de cluster existants et pour le modèle de niveau cluster activent le service SIBService. Dans l'exemple suivant, l'activation du service SIBService définit la propriété enable sur la valeur 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"/>
Eviter les incidents Eviter les incidents: La version after des fichiers de configuration peut contenir des modifications qui suppriment des commentaires de la version before des fichiers.gotcha

Des configurations supplémentaires sont ajoutées au fichier coregroup.xml, en fonction des règles que vous avez choisies. L'exemple suivant illustre l'ajout d'une règle pour la haute disponibilité :

<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>
La création de destinations SIBus modifie les fichiers sib-destinations.xml et sib-engines.xml
Lorsqu'une destination est créée, le produit modifie les fichiers de configuration 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

Le fichier sib-destinations.xml indique l'ajout d'une file 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>

Le fichier sib-engines.xml indique l'ajout d'un élément SIBQueueLocaliazationPoint :

<localizationPoints xmi:type="sibresources:SIBQueueLocalizationPoint"
  xmi:id="SIBQueueLocalizationPoint_1326648599156" identifier="TestBusQeue1@TestCluster1.000-TestBus"
  uuid="A55E76D18D6F4339" targetUuid="0AA3CFB9BB0FFA92BE5BCB57" highMessageThreshold="50000"/>

L'utilisation de targetUUID correspond à l'uuid de SIBQueue.

La création d'une fabrique de connexions de file d'attente modifie le fichier resources.xml
Le produit enregistre les modifications apportées aux fabriques de connexions de file d'attente dans les fichiers resources.xml. Une fabrique de connexions qui est créée au niveau d'un cluster modifie ce niveau de cluster dans le fichier resources.xml :
before/cells/isthmusCell03/clusters/TestCluster1/resources.xml
after/cells/isthmusCell03/clusters/TestCluster1/resources.xml

L'ajout au fichier resources.xml est indiqué comme suit :

<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>
La création d'une file d'attente JMS modifie le fichier resources.xml
L'ajout d'une file d'attente JMS modifie le fichier resources.xml :
before/cells/isthmusCell03/clusters/TestCluster1/resources.xml
after/cells/isthmusCell03/clusters/TestCluster1/resources.xml

La création d'une file d'attente JMS au niveau d'un cluster modifie ce niveau de cluster dans le fichier resources.xml. L'ajout du fichier resources.xml est indiqué comme suit :

<j2cAdminObjects xmi:id="J2CAdminObject_1326649181984" jndiName="jms/TestClusterQueue"
  name="TestClustereQueue" description="" adminObject="AdminObject_1326644816218">
  ...
</j2cAdminObjects>
Le déploiement d'une application modifie le fichier serverindex.xml et parfois d'autres fichiers
Le déploiement d'applications implique des modifications des fichiers serverindex.xml des noeuds cibles. Des modifications apportées à une application de niveau métier et aux configurations d'unité de composition, même pour des applications Java EE, entraînentn des modifications de fichier dans le répertoire d'applications dans le sous-répertoire cells/nom_cellule/applications/nom_application. Par exemple, le déploiement de l'application IVT dans un cluster de deux noeuds modifie les fichiers suivants :
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
...  

L'ajout au fichier serverindex.xml sur chaque noeud est indiqué comme suit :

<deployedApplications>IVT Application.ear/deployments/IVT Application</deployedApplications>
La désinstallation d'une application modifie le fichier serverindex.xml
Lors de la désinstallation d'une application, le produit modifie le fichier serverindex.xml pour supprimer l'application et supprimer les fichiers d'application. Dans le fichier compressé exporté, les fichiers supprimés portent le suffixe .DELETED. Par exemple, les fichiers affectés par la désinstallation de l'application IVT d'un cluster de deux noeuds sont les suivants :
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
...
L'ajout d'un rôle pour un mappage utilisateur modifie le fichier admin-authz.xml
Les modifications d'autorisations d'administration affectent le fichier admin-authz.xml :
before/cells/isthmusCell03/admin-authz.xml after/cells/isthmusCell03/admin-authz.xml

Par exemple, lors de l'ajout de l'utilisateur user2 au rôle operator, la partie affectée du fichier admin-authz.xml dans la version before est la suivante :

<authorizations xmi:id="RoleAssignmentExt_2" role="SecurityRoleExt_2"/>

La version after est comme suit :

<authorizations xmi:id="RoleAssignmentExt_2" role="SecurityRoleExt_2">
  <users xmi:id="UserExt_1326649772453" name="user2"
    accessId="user:defaultWIMFileBasedRealm/uid=user2,o=defaultWIMFileBasedRealm"/>
</authorizations>
La création d'un domaine de sécurité modifie les fichiers figurant dans les sous-répertoires waspolicies
Les fichiers liés au domaine de sécurité sont stockés dans les sous-répertoires waspolicies. L'ajour d'un domaine de sécurité appelé, par exemple TestDomain, crée de nombreux fichiers sous le répertoire 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
L'ajout de configurations SSL modifie le fichier security.xml
Les configurations SSL sont stockées dans security.xml. Ainsi, l'ajout d'une configuration SSL modifie les fichiers tels que le suivant :
before/cells/isthmusCell03/security.xml
after/cells/isthmusCell03/security.xml

un ajout SSLConfig dans le fichier security.xml ressemble à ce qui suit :

<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>

Que faire ensuite

Utilisez les modifications de fichier identifiées pour revoir la configuration produit si nécessaire.


Icône indiquant le type de rubrique Rubrique de tâche



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=twve_checkpoint_changes
Nom du fichier : twve_checkpoint_changes.html