Búsqueda de cambios de configuración en los puntos de comprobación delta
Si se habilitan puntos de comprobación de repositorio automáticos, el producto crea un punto de comprobación delta siempre que se realiza un cambio en el repositorio de configuración. Un archivo zip comprimido del punto de comprobación delta contiene las versiones anterior y posterior de los archivos de configuración que han cambiado. Puede extraer el contenido del archivo comprimido y, a continuación, examinar los archivos extraídos para determinar qué ha cambiado en la configuración.
Antes de empezar
Habilite el producto para crear puntos de comprobación delta automáticamente:
- En la consola administrativa, pulse .
- Seleccione Habilitar puntos de comprobación de repositorio automáticos.
- En Profundidad de puntos de comprobación automáticos, especifique el número de puntos de comprobación delta que desea mantener.
- Guarde los cambios.
Acerca de esta tarea
Puede utilizar un punto de comprobación delta para deshacer los cambios recientes de la configuración del producto.
También puede utilizar un punto de comprobación delta para determinar qué cambios se han realizado en la configuración. En este tema se describe cómo interpretar el contenido de un repositorio delta extraído para determinar los cambios en la configuración.
Procedimiento
Ejemplo
Revise la siguiente información para ver cómo se muestran en los archivos extraídos los distintos cambios en la configuración del producto:
- Los nuevos archivos de configuración tienen el sufijo .ADDED
- Los archivos de configuración suprimidos tienen el sufijo .DELETED
- Los archivos de configuración modificados tienen la versión before (anterior) y after (posterior)
- Los cambios en la configuración del servicio de repositorio ampliado están en los archivos repository.xml
- La adición de un nodo genera hasta tres versiones de archivo before y after
- La creación de clústeres y miembros de clúster cambia los archivos cluster.xml, serverindex.xml y server.xml
- La creación de orígenes de datos cambia los archivos resources.xml y variables.xml
- La modificación de los valores de la máquina virtual Java cambia los archivos server.xml
- La creación de un bus de integración de servicios cambia los archivos de configuración de SIB
- La creación de destinos de SIBus cambia los archivos sib-destinations.xml y sib-engines.xml
- La creación de una fábrica de conexiones de cola cambia el archivo resources.xml
- La creación de una cola JMS cambia el archivo resources.xml
- El despliegue de una aplicación cambia serverindex.xml y posiblemente otros archivos
- La desinstalación de una aplicación cambia el archivo serverindex.xml
- La adición de una correlación de roles con usuarios cambia el archivo admin-authz.xml
- La creación de un dominio de seguridad cambia los archivos en los subdirectorios waspolicies
- La adición de configuraciones SSL cambia el archivo security.xml
- Los nuevos archivos de configuración tienen el sufijo .ADDED
- Cuando se crean archivos de configuración, la versión anterior es un archivo de marcador con el sufijo .ADDED, por ejemplo, server.xml.ADDED, mientras que la versión posterior es el archivo que se crea. Los nuevos archivos de configuración son el resultado de acciones como, por ejemplo, crear nodos, clústeres, servidores de aplicaciones, aplicaciones o artefactos de SIBus.
- Los archivos de configuración suprimidos tienen el sufijo .DELETED
- Cuando se suprimen archivos de configuración, la versión anterior es el contenido del archivo que se ha suprimido, mientras que la versión posterior es un archivo de marcador con el sufijo .DELETED.
- Los archivos de configuración modificados tienen la versión before (anterior) y after (posterior)
- Cuando se cambian los archivos de configuración existentes, la versión anterior es la configuración original, mientras que la versión posterior es el archivo después de realizar los cambios. Los cambios en los archivos de configuración existentes son el resultado de acciones como, por ejemplo, crear o modificar recursos, o cambiar los valores de la máquina virtual Java.
Si los archivos son archivos de texto o XML, puede utilizar una herramienta de comparación de texto para comparar las diferencias entre las versiones anterior y posterior. Una herramienta de comparación de texto visual que muestra los dos archivos comparándolos uno al lado del otro es más eficaz para resaltar las diferencias. Si un elemento de configuración sólo muestra los cambios en el atributo xmi:id, puede ignorar estos cambios porque no modifican ningún comportamiento.
No puede utilizar herramientas de comparación de texto para comparar archivos binarios como, por ejemplo, los archivos de almacén de claves y de almacén de confianza, los archivos binarios de aplicación y las bibliotecas compartidas. Para los archivos de almacén de claves y de confianza, utilice ikeyman u otras herramientas de gestión de claves para examinar el contenido de estos archivos y buscar las diferencias en los certificados. Para los archivos JAR (Java Archive) de biblioteca compartida o binarios de aplicación, compárelos manualmente utilizando los programas de utilidad JAR o zip para desempaquetar los archivos.
- Los cambios en la configuración del servicio de repositorio ampliado están en los archivos repository.xml
- Cuando se habilita o se modifica la configuración del servicio de repositorio ampliado, el repositorio delta extraído muestra un cambio en el archivo repository.xml. Por ejemplo, el archivo comprimido extraído contiene:
before/cells/isthmusCell03/repository/repository.xml after/cells/isthmusCell03/repository/repository.xml
La versión after del archivo repository.xml contiene la configuración actualizada. En el ejemplo siguiente, la versión after tiene un valor actualizado para 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"/>
- La adición de un nodo genera hasta tres versiones de archivo before y after
- Cuando añade un nodo, puede ver la creación de hasta tres puntos de comprobación delta. El primer cambio de repositorio es la propia operación addNode. La imagen anterior contiene principalmente archivos de marcador con el formato nombre_archivo.ADDED para mostrar que los archivos no existían previamente. La imagen posterior contiene el archivo que se está añadiendo. Asimismo, addNode también cambia la configuración de las aplicaciones del sistema y los valores de seguridad en security.xml. Por ejemplo:
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
Los cambios en security.xml incluyen las adiciones a la configuración SSL y los almacenes de confianza y de claves. La adición de la nueva configuración SSL es como la siguiente:
<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"/> ...
Los almacenes de confianza y de claves a nivel de nodo y los gestores de confianza son como los siguiente:
<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"/>
Algunas aplicaciones del sistema se dirigen a nuevos servidores en el nuevo nodo. Los cambios pueden incluir nuevas correlaciones de destino. Por ejemplo, los cambios en la aplicación ibmasyncrsp incluyen cambios en el archivo 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 tiene habilitada la generación automática de plug-ins, el producto puede regenerar el archivo de plug-in. Esto provoca la creación de otro punto de comprobación delta, como se muestra a continuación:
before/cells/plugin-cfg.xml.ADDED after/cells/plugin-cfg.xml
Por último, los puertos de los servidores en el nuevo nodo se añaden a las definiciones de host virtual:
before/cells/isthmusCell03/virtualhosts.xml after/cells/isthmusCell03/virtualhosts.xml
Las adiciones a virtualhosts.xml incluyen:
<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 creación de clústeres y miembros de clúster cambia los archivos cluster.xml, serverindex.xml y server.xml
- La creación de un clúster hace que el producto añada un archivo cluster.xml al repositorio de configuración. La creación de un miembro de clúster provoca una actualización en el archivo serverindex.xml del nodo y la creación de nuevos archivos server.xml y otros archivos de configuración relacionados. Por ejemplo, la creación de un clúster denominado TestCluster con miembros en dos nodos diferentes, TestCluster1_Node1_1 y TestCluster1_Node2_1, genera cambios en los archivos siguientes:
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 creación de orígenes de datos cambia los archivos resources.xml y variables.xml
- La creación de un origen de datos hace que el producto cambie los archivos resources.xml y variables.xml; por ejemplo:
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
Una nueva fábrica aparece en los archivos de configuración como se indica a continuación:
<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 nuevo proveedor JBDC con un origen de datos aparece en los archivos de configuración como se indica a continuación:
<resources.jdbc:JDBCProvider xmi:id="JDBCProvider_1326647771343" name="DB2 Universal JDBC Driver Provider (XA)" description="Proveedor DB2 JCC de compromiso de dos fases que da soporte a JDBC 3.0. Los orígenes de datos que utilizan este soporte de proveedor permiten utilizar XA para el proceso de compromiso en dos fases. El uso del tipo de controlador 2 en el servidor de aplicaciones para z/OS no está soportado para los orígenes de datos creados con este proveedor." 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>
Es posible que algunos elementos de configuración sólo contengan cambios en xml:id. Puede ignorar estos cambios. Por ejemplo, los dos elementos siguientes tienen valores xml:id modificados:
<displayNames xmi:id="DisplayName_1326647771359" value="WS_RdbResourceAdapter"/> <displayNames xmi:id="DisplayName_1326647771360" value="WebSphere Default Messaging Provider"/>
- La modificación de los valores de la máquina virtual Java cambia los archivos server.xml
- El producto almacena los cambios en los valores de la máquina virtual Java en el archivo server.xml:
before/cells/isthmusCell03/nodes/isthmusNode01/servers/TestCluster1_Node1_1/server.xml after/cells/isthmusCell03/nodes/isthmusNode01/servers/TestCluster1_Node1_1/server.xml
Los siguiente cambios en los valores de la máquina virtual Java:
- Habilitación de la recogida de basura verbosa
- Cambio del tamaño de almacenamiento dinámico inicial a 512 MB
- Cambio del tamaño de almacenamiento dinámico máximo a 768 MB
- Adición de una propiedad del sistema, MyVar=MVal
Dan como resultado una versión after del archivo 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">
Esta nueva versión del archivo server.xml tiene los atributos XML adicionales executablejarFileName y disableJIT. Estos atributos no introducen ningún cambio de comportamiento porque un servidor de aplicaciones gestionado no necesita executableJarFileName y JIT está inhabilitado de forma predeterminada.
- La creación de un bus de integración de servicios cambia los archivos de configuración de SIB
- La creación de un bus hace que el producto añada nuevos archivos en el directorio cells/nombre_célula/buses/nombre_bus y cambie las configuraciones de miembro de bus. Por ejemplo, el siguiente archivo cambia después de crear un bus denominado TestBus con miembros de bus en el ámbito 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
Los cambios a sib-service.xml para los miembros de clúster existentes y para la plantilla a nivel de clúster habilitan SIBService. En el siguiente ejemplo, la habilitación de SIBService establece la propiedad enable en 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: La versión after de los archivos de configuración puede contener cambios que eliminan comentarios de la versión before de los archivos. gotcha
Se añaden configuraciones adicionales al archivo coregroup.xml, dependiendo de las políticas que elija. El ejemplo siguiente muestra la adición de una política para la alta disponibilidad:
<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 creación de destinos de SIBus cambia los archivos sib-destinations.xml y sib-engines.xml
- La creación de un destino hace que el producto cambie los archivos de configuración de 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
El archivo sib-destinations.xml muestra la adición de una 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>
El archivo sib-engines.xml muestra la adición de un SIBQueueLocaliazationPoint:
<localizationPoints xmi:type="sibresources:SIBQueueLocalizationPoint" xmi:id="SIBQueueLocalizationPoint_1326648599156" identifier="TestBusQeue1@TestCluster1.000-TestBus" uuid="A55E76D18D6F4339" targetUuid="0AA3CFB9BB0FFA92BE5BCB57" highMessageThreshold="50000"/>
El uso de targetUUID se correlaciona con el uuid de la SIBQueue.
- La creación de una fábrica de conexiones de cola cambia el archivo resources.xml
- El producto almacena los cambios en fábricas de conexiones de cola en los archivos resources.xml.
Una fábrica de conexiones de cola que se crea a nivel de clúster cambia el archivo resources.xml a nivel de clúster:
before/cells/isthmusCell03/clusters/TestCluster1/resources.xml after/cells/isthmusCell03/clusters/TestCluster1/resources.xml
A continuación, se muestra la adición a 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>
- La creación de una cola JMS cambia el archivo resources.xml
- La adición de una cola JMS cambia el archivo resources.xml:
before/cells/isthmusCell03/clusters/TestCluster1/resources.xml after/cells/isthmusCell03/clusters/TestCluster1/resources.xml
La creación de una cola JMS a nivel de clúster cambia el archivo resources.xml a nivel de clúster. A continuación, se muestra la adición del archivo resources.xml:
<j2cAdminObjects xmi:id="J2CAdminObject_1326649181984" jndiName="jms/TestClusterQueue" name="TestClustereQueue" description="" adminObject="AdminObject_1326644816218"> ... </j2cAdminObjects>
- El despliegue de una aplicación cambia serverindex.xml y posiblemente otros archivos
- El despliegue de una aplicación implica cambios en el archivo serverindex.xml de los nodos de destino. Los cambios en las configuraciones de unidad de composición y aplicación de nivel empresarial, incluso para las aplicaciones Java EE, dan como resultado cambios en el archivo en el directorio de aplicación bajo el subdirectorio cells/nombre_célula/applications/nombre_aplicación. Por ejemplo, el despliegue de la aplicación IVT en un clúster de dos nodos genera cambios en los archivos siguientes:
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 ...
A continuación, se muestra la adición al archivo serverindex.xml en cada nodo:
<deployedApplications>IVT Application.ear/deployments/IVT Application</deployedApplications>
- La desinstalación de una aplicación cambia el archivo serverindex.xml
- La desinstalación de una aplicación hace que el producto modifique el archivo serverindex.xml para eliminar la aplicación y suprimir los archivos de aplicación. En el archivo comprimido exportado, se añade el sufijo .DELETED a los archivos suprimidos. Por ejemplo, los archivos afectados por la desinstalación de la aplicación IVT de un clúster de dos nodos son:
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 ...
- La adición de una correlación de roles con usuarios cambia el archivo admin-authz.xml
- Los cambios de autorización administrativa afectan al archivo admin-authz.xml:
before/cells/isthmusCell03/admin-authz.xml after/cells/isthmusCell03/admin-authz.xml
Por ejemplo, cuando se añade el usuario user2 al rol operator, la parte afectada de admin-authz.xml en la versión before es:
<authorizations xmi:id="RoleAssignmentExt_2" role="SecurityRoleExt_2"/>
A continuación, se muestra la versión after:
<authorizations xmi:id="RoleAssignmentExt_2" role="SecurityRoleExt_2"> <users xmi:id="UserExt_1326649772453" name="user2" accessId="user:defaultWIMFileBasedRealm/uid=user2,o=defaultWIMFileBasedRealm"/> </authorizations>
- La creación de un dominio de seguridad cambia los archivos en los subdirectorios waspolicies
- Los archivos relacionados con el dominio de seguridad se almacenan en los subdirectorios waspolicies. La adición de un dominio de seguridad denominado, por ejemplo, TestDomain, crea muchos archivos en el directorio 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
- La adición de configuraciones SSL cambia el archivo security.xml
- Las configuraciones SSL se almacenan en security.xml. Por lo tanto, la adición de una configuración SSL cambia archivos como los siguientes:
before/cells/isthmusCell03/security.xml after/cells/isthmusCell03/security.xml
A continuación, se muestra una adición de SSLConfig a security.xml:
<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>
Qué hacer a continuación
Utilice los cambios de archivo identificados para revisar la configuración del producto según sea necesario.