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:
- No console administrativo, clique em .
- Selecione Ativar os pontos de verificação de repositório automáticos.
- Para Profundidade do ponto de verificação automático, especifique o número de pontos de verificação delta a serem mantidos.
- 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
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:
- Os novos arquivos de configuração possuem o sufixo .ADDED
- Os arquivos de configuração excluídos possuem o sufixo .DELETED
- Os arquivos de configuração alterados possuem versões anteriores e posteriores
- As mudanças para a configuração do serviço de repositório estendido estão no arquivo repository.xml
- A inclusão de um nó resulta em até três versões dos arquivos anteriores e posteriores
- A criação de clusters e membros de clusters altera os arquivos cluster.xml, serverindex.xml, e server.xml
- A criação de origens de dados altera os arquivos resources.xml e variables.xml
- A modificação das configurações da Java virtual machine altera os arquivos server.xml
- A criação de um barramento de integração de serviços altera os arquivos de configuração de SIB
- A criação de destinos SIBus altera os arquivos sib-destinations.xml e sib-engines.xml
- A criação de um factory de conexão da fila altera o arquivo resources.xml
- A criação de uma fila JMS altera o arquivo resources.xml
- A implementação de um aplicativo altera serverindex.xml e possivelmente outros arquivos
- A desinstalação de um aplicativo altera o arquivo serverindex.xml
- A inclusão de função ao mapeamento de usuário altera o arquivo admin-authz.xml
- A criação de um domínio de segurança altera os arquivos nos subdiretórios waspolicies
- A inclusão de configurações de SSL altera o arquivo security.xml
- 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: 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.