Localizando Mudanças na Configuração em Pontos de Verificação Delta

Se os pontos de verificação de repositório automáticos estiverem ativados, o produto cria um ponto de verificação delta sempre que uma mudança for feita no repositório de configuração. Um arquivo compactado zip do ponto de verificação delta contém as versões anterior e posterior dos arquivos de configuração que foram alterados. É possível extrair o conteúdo do arquivo compactado e, em seguida, examinar os arquivos extraídos para determinar o que foi alterado na configuração.

Antes de Iniciar

Permitir que o produto crie pontos de verificação delta automaticamente:

  1. No console administrativo, clique em Administração do sistema > Serviço de Repositório Estendido.
  2. Selecione Ativar os pontos de verificação de repositório automáticos.
  3. Para Profundidade do ponto de verificação automático, especifique o número de pontos de verificação delta a serem mantidos.
  4. Salve as mudanças.

Sobre Esta Tarefa

É possível utilizar um ponto de verificação delta para desfazer alterações recentes para a configuração do produto.

É possível também usar um ponto de verificação delta para determinar que mudanças foram feitas à configuração. Esse tópico discute como interpretar o conteúdo de um repositório delta extraído para determinar as mudanças na configuração.

Procedimento

  1. Exportar um ponto de verificação delta.
    1. Clique em Administração do sistema > Serviço de repositório estendido > Pontos de verificação de repositório.
    2. Na página Pontos de verificação de repositório, selecione o ponto de verificação delta e clique em Exportar.
    3. Na página Exportar pontos de verificação de repositório, selecione o nome do arquivo compactado zip.
    4. Salvar o arquivo em um local especificado.
  2. Extraia os arquivos do arquivo compactado exportado.
  3. Examine os arquivos extraídos para determinar as mudanças na configuração.

Exemplo

Revise as informações a seguir para consultar como as várias mudanças à configuração do produto são mostradas nos arquivos extraídos:

Novos arquivos de configuração possuem o sufixo .ADDED
Quando novos arquivos de configuração são criados, a versão anterior é um arquivo marcador com o sufixo .ADDED, como server.xml.ADDED, enquanto a versão posterior é o arquivo real criado. Novos arquivos de configuração resultam de ações como a criação de nós, clusters, servidores de aplicativos, aplicativos ou artefatos SIBus.
Os arquivos de configuração excluídos possuem o sufixo .DELETED
Quando arquivos de configuração são excluídos, a versão anterior é o conteúdo do arquivo que foi excluído, enquanto a versão posterior é um arquivo marcador com o sufixo .DELETED.
Os arquivos de configuração alterados possuem versões anteriores e posteriores
Quando os arquivos de configuração existentes são alterados, a versão anterior é a configuração original, enquanto a versão posterior é o arquivo após as mudanças terem sido feitas. As mudanças feitas nos arquivos de configuração existentes resultam de ações como a criação ou modificação de recursos ou mudança nas configurações da Java virtual machine.

Se os arquivos alterados forem arquivos de texto ou XML, é possível usar uma ferramenta de comparação de texto para comparar a diferença entre as versões anterior e posterior. Uma ferramenta de comparação de texto visual que mostra os dois arquivos em comparações lado a lado é mais efetiva para destacar as diferenças. Se um elemento de configuração mostra apenas as mudanças no atributo xmi:id, é possível ignorar essas mudanças por que elas não modificam nenhum comportamento.

Não é possível usar as ferramentas de comparação de texto para comparar arquivos binários, como arquivos de keystore e de armazenamento, arquivos binários de aplicativos e bibliotecas compartilhadas. Para os arquivos chave e de armazenamento, use ikeyman ou outras ferramentas de gerenciamento de chaves para pesquisar os conteúdos desses arquivos para obter diferenças nos certificados. Para os arquivos Java archive (JAR) de binários de aplicativos ou bibliotecas compartilhadas, compare manualmente usando os utilitários JAR ou zip para descompactar os arquivos.

As mudanças para a configuração do serviço de repositório estendido estão nos arquivos repository.xml
Ao ativar ou alterar a configuração do serviço de repositório estendido, o repositório delta extraído mostra uma mudança no arquivo repository.xml. Por exemplo, o arquivo compactado extraído contém:
before/cells/isthmusCell03/repository/repository.xml
after/cells/isthmusCell03/repository/repository.xml

A versão posterior do arquivo repository.xml contém a configuração atualizada. No exemplo a seguir, a versão posterior possui um valor atualizado 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"/>
A inclusão de um nó resulta em até três versões dos arquivos anteriores e posteriores
Ao incluir um nó, é possível ver até três pontos de verificação delta sendo criados. A primeira mudança do repositório é a operação addNode em si. A imagem anterior contém principalmente arquivos marcadores do formato file_name.ADDED para mostrar que os arquivos não existiam anteriormente. A imagem posterior contém o arquivo incluído. Além disso, addNode também altera a configuração para os aplicativos de sistema eas configurações de segurança em security.xml. Por exemplo:
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

As mudanças em security.xml incluem as adições na configuração SSL e chaves ou armazenamentos confiáveis. A adição de uma nova configuração SSL tem a seguinte aparência:

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

A chave de nível do nó, armazenamentos de confiança e gerenciadores de confiança tem a seguinte aparência:

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

Alguns aplicativos de sistema são destinados aos novos servidores no novo nó. As mudanças podem incluir novos mapeamentos de destino. Por exemplo, as mudanças no aplicativo ibmasyncrsp incluem mudanças no arquivo 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"/>

Se você possui a geração automática de plug-ins ativada, o produto pode gerar o arquivo de plug-in novamente. Isso resulta na criação de outro ponto de verificação delta com a seguinte aparência:

before/cells/plug-in-cfg.xml.ADDED
after/cells/plug-in-cfg.xml

E, finalmente, as portas dos servidores em um novo nó são incluídos às definições do host virtual:

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

As adições ao virtualhosts.xml incluem:

<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"/>
A criação de clusters e membros de cluster altera os arquivos cluster.xml, serverindex.xml e server.xml
A criação de um cluster faz com que o produto inclua um arquivo cluster.xml ao repositório de configuração. A criação de um membro de cluster causa uma atualização do arquivo serverindex.xml do nó e a criação de um novo server.xml e outros arquivos de configuração relacionados. Por exemplo, a criação de um cluster denominado TestCluster com membros em dois nós diferentes, TestCluster1_Node1_1 e TestCluster1_Node2_1, resulta em mudanças nos arquivos a seguir:
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
A criação de origens de dados altera os arquivos resources.xml e variables.xml
A criação de uma origem de dados causa a mudança dos arquivos resources.xml e variables.xml do produto, por exemplo:
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

Um novo factory é mostrado nos arquivos de configuração, como mostrado a seguir:

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

Um novo provedor JDBC com uma origem de dados é mostrado nos arquivos de configuração, como mostrado a seguir:

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

É possível ver que alguns elementos de configuração contêm mudanças apenas em xml:id. Você poder ignorar essas mudanças. Por exemplo, os dois elementos a seguir possuem valores xml:id alterados:

<displayNames xmi:id="DisplayName_1326647771359" value="WS_RdbResourceAdapter"/>
<displayNames xmi:id="DisplayName_1326647771360" value="WebSphere Default Messaging Provider"/>
A modificação das configurações da Java virtual machine altera os arquivos server.xml
O produto armazena mudanças nas configurações de Java virtual machine no arquivo server.xml:
before/cells/isthmusCell03/nodes/isthmusNode01/servers/TestCluster1_Node1_1/server.xml
after/cells/isthmusCell03/nodes/isthmusNode01/servers/TestCluster1_Node1_1/server.xml 

As mudanças a seguir nas configurações de Java virtual machine:

  • Ativação da coleta de lixo detalhado
  • Alteração de tamanho de heap inicial para 512 MB
  • Alteração de tamanho de heap máximo para 768 MB
  • Inclusão de uma propriedade de sistema, MyVar=MVal

Resultam em uma versão posterior de 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">

Essa nova versão do arquivo server.xml possui os atributos XML adicionais executablejarFileName e disableJIT. Esses atributos não introduzem nenhuma mudança de comportamento, porque um servidor de aplicativos gerenciado não precisa de executableJarFileName e JIT está desativado por padrão.

A criação de um barramento de integração de serviços altera os arquivos de configuração de SIB
A criação de um barramento faz com que o produto inclua novos arquivos no diretório cells/cell_name/buses/bus_name e altere as configurações de membros do barramento. Por exemplo, o arquivo a seguir é alterado após a criação de um barramento denominado TestBus com membros do barramento no escopo 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  

As mudanças em sib-service.xml para os membros de cluster existentes e para o modelo de nível de cluster ativam o SIBService. No exemplo a seguir, a ativação de SIBService configura a propriedade enable como 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"/>
Evitar Problemas Evitar Problemas: A versão posterior dos arquivos de configuração pode conter mudanças que removem comentários da versão anterior dos arquivos.gotcha

Configurações adicionais são incluídas ao arquivo coregroup.xml, dependendo das políticas escolhidas. O exemplo a seguir mostra a adição de uma política para alta disponibilidade:

<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>
A criação de destinos SIBus altera os arquivos sib-destinations.xml e sib-engines.xml
A criação de um destino faz com que o produto altere os arquivos de configuração 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

O arquivo sib-destinations.xml mostra a adição a um 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 mostra uma adição a um SIBQueueLocaliazationPoint:

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

O uso de targetUUID está correlacionado com o uuid de SIBQueue.

A criação de um factory de conexão da fila altera o arquivo resources.xml
O produto armazena mudanças nos factories de conexão de filas nos arquivos resources.xml. Um factory de conexão da fila criado no nível do cluster altera o arquivo resources.xml do nível de cluster:
before/cells/isthmusCell03/clusters/TestCluster1/resources.xml
after/cells/isthmusCell03/clusters/TestCluster1/resources.xml

A adição ao resources.xml tem a seguinte aparência:

<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>
Criar uma fila JMS altera o arquivo resources.xml
A inclusão de uma fila JMS altera o arquivo resources.xml:
before/cells/isthmusCell03/clusters/TestCluster1/resources.xml
after/cells/isthmusCell03/clusters/TestCluster1/resources.xml

A criação de uma fila JMS no nível do cluster altera o arquivo resources.xml de nível do cluster. A adição do arquivo resources.xml tem a seguinte aparência:

<j2cAdminObjects xmi:id="J2CAdminObject_1326649181984" jndiName="jms/TestClusterQueue"
  name="TestClustereQueue" description="" adminObject="AdminObject_1326644816218">
  ...
</j2cAdminObjects>
A implementação de um aplicativo altera serverindex.xml e possivelmente outros arquivos
A implementação do aplicativo envolve mudanças no arquivo serverindex.xml dos nós de destino. As mudanças no aplicativo em nível de negócios e configurações das unidades de composição, mesmo para aplicativos Java EE, resultam em mudanças no arquivo no diretório do aplicativo no subdiretório cells/cell_name/applications/application_name. Por exemplo, a implementação do aplicativo IVT para um cluster de dois nós causa mudanças nos arquivos a seguir:
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 adição ao serverindex.xml em cada nó tem a seguinte aparência:

<deployedApplications>IVT Application.ear/deployments/IVT Application</deployedApplications>
Desinstalar um aplicativo altera o arquivo serverindex.xml
A desinstalação de um aplicativo faz com que o produto modifique o arquivo serverindex.xml para remover o aplicativo e excluir os arquivos de aplicativo. No arquivo compactado exportado, os arquivos excluídos são anexados com o sufixo .DELETED. Por exemplo, os arquivos afetados pela desinstalação do aplicativo IVT de um cluster de dois nós são:
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
...
A inclusão de função ao mapeamento de usuário altera o arquivo admin-authz.xml
As mudanças de autorização administrativa afetam o arquivo admin-authz.xml:
before/cells/isthmusCell03/admin-authz.xml after/cells/isthmusCell03/admin-authz.xml

Como exemplo, ao incluir o usuário user2 para a função operator, a parte afetada de admin-authz.xml na versão anterior é:

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

A versão posterior tem a seguinte aparência:

<authorizations xmi:id="RoleAssignmentExt_2" role="SecurityRoleExt_2">
  <users xmi:id="UserExt_1326649772453" name="user2"
    accessId="user:defaultWIMFileBasedRealm/uid=user2,o=defaultWIMFileBasedRealm"/>
</authorizations>
A criação de um domínio de segurança altera os arquivos nos subdiretórios waspolicies
Os arquivos relacionados do domínio de segurança são armazenados nos subdiretórios waspolicies. A inclusão de um domínio de segurança denominado, por exemplo, TestDomain cria vários arquivos no diretório 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
A inclusão de configurações de SSL altera o arquivo security.xml
As configurações de SSL são armazenadas em security.xml. Assim, a inclusão de uma configuração de SSL altera arquivos como mostrado a seguir:
before/cells/isthmusCell03/security.xml
after/cells/isthmusCell03/security.xml

Uma adição SSLConfig para security.xml tem a seguinte aparência:

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

O que Fazer Depois

Use as mudanças de arquivos identificadas para revisar a configuração do produto conforme a necessidade.


Ícone que indica o tipo de tópico Tópico de Tarefa



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=twve_checkpoint_changes
Nome do arquivo: twve_checkpoint_changes.html