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 :
- Dans la console d'administration, cliquez sur .
- Sélectionnez Activer la création de points de contrôle automatiques pour le référentiel.
- Indiquez le nombre de points de contrôle delta à conserver en regard de Points de contrôle automatiques - Profondeur.
- 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
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
- Les fichiers de configuration supprimées portent le suffixe .DELETED
- Les fichiers de configuration modifiés comportent des versions before (avant) et after (après)
- Les modifications apportées à la configuration du service de référentiel étendu figurent dans les fichiers repository.xml
- L'ajout d'un noeud se traduit par la création de trois versions de fichier before (avant) et after (après)
- La création de clusters et de membres de cluster modifie les fichiers cluster.xml, serverindex.xml et server.xml
- La création de sources de données modifie les fichiers resources.xml et variables.xml
- La modification des paramètres de machine virtuelle Java modifie les fichiers server.xml
- La création d'un bus d'intégration de services modifie les fichiers de configuration SIB
- La création de destinations SIBus modifie les fichiers sib-destinations.xml et sib-engines.xml
- La création d'une fabrique de connexions de file d'attente modifie le fichier resources.xml
- La création d'une file d'attente JMS modifie le fichier resources.xml
- Le déploiement d'une application modifie le fichier serverindex.xml et parfois d'autres fichiers
- La désinstallation d'une application change le fichier serverindex.xml
- ^L'ajout d'un rôle pour un mappage utilisateur modifie le fichier admin-authz.xml
- La création d'un domaine de sécurité modifie les fichiers figurant dans les sous-répertoires waspolicies
- L'ajout de configurations SSL modifie le fichier security.xml
- 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: 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.