IBM DISTRIBUTED COMPUTING ENVIRONMENT (DCE) VERSÃO 3.2 PARA AIX E SOLARIS - ANEXO LEIA ME ===================================================== Copyright IBM Corporation 2001. Todos os direitos reservados. NOTA: Consulte 12.0 AVISOS para obter a citação completa de direitos autorais. ===================================================== CONTEÚDO 1.0 SOBRE ESTE ANEXO LEIA ME 2.0 CONSIDERAÇÕES DE LDAP 2.1 Correção eletrônica para o servidor IBM SecureWay Directory 2.2 Requisito de leitura/gravação simultânea 2.3 Alteração do limite de tamanho de LDAP para comandos dcecp catalog no servidor IBM SecureWay Directory 2.4 Atributo CreatorsName usando ldif2db e réplica 2.5 Erros durante a modificação do esquema 3.0 CONSIDERAÇÕES SOBRE AIX 3.1 Considerações ao executar aplicativos do cliente no AIX 3.2 Comando dcf_ulimit incluído em dcecp 3.3 Comando dcf_ulimit 4.0 CONSIDERAÇÕES SOBRE DESEMPENHO E DICAS DE AJUSTE DO DCE 3.2 4.1 Ajustando secd 4.1.1 Ajustando conexões múltiplas para o servidor LDAP 4.1.2 Ajustando o número de encadeamentos de propagação 4.1.3 Ajustando qual secd será o iniciador de init_rep 4.2 Ajustando DB2 ao usar IBM SecureWay LDAP 4.3 Ajustando LDAP 4.3.1 Ajustando o servidor IBM SecureWay LDAP 4.3.2 Ajustando o servidor iPlanet/Netscape LDAP 4.4 Hardware 4.5 Rede 4.6 Expectativas da migração inicial 4.7 Considerações sobre o aplicativo DCE 4.8 Tarefas do Usuário (login, chpasswd) 4.9 Tarefas do Administrador (user create, user delete) 5.0 CONSIDERAÇÕES SOBRE CARACTERÍSTICAS LOCAIS (LOCALE) 5.1 Problema do cliente Solaris LDAP com UTF-8 (somente Solaris) 5.2 Falhas de LDAP relacionadas com as definições de características locais (locales) não suportadas 6.0 MODIFICAÇÃO REQUERIDA DA VERSÃO DE REGISTRO 6.1 Verifique se todas as réplicas têm o mesmo número da versão de registro antes de migrar para o LDAP principal 6.2 Tentativas de modificar a versão de registro para aguardar pelos números de seqüência para correspondência 7.0 CONSIDERAÇÕES SOBRE MIGRAÇÃO E POSSÍVEIS SITUAÇÕES DE ERRO 7.1 A migração do registro requer alguns parâmetros para ser completada 7.2 A interrupção da migração do registro não pára a propagação de dados DCE para LDAP 7.3 Falhas da migração do dependente LDAP 7.4 Falha da migração do principal LDAP 7.5 Mensagens após expiração do ticket durante a migração 8.0 CONDIÇÕES PARA REINÍCIO DE SECD 8.1 Reiniciar secd para alterar arquivos dos bancos de dados chave com SSL 8.2 Condição LDAP_SERVER_DOWN 9.0 SELEÇÃO DE REGISTRO COM A VARIÁVEL DE AMBIENTE TRY PE_SITE 9.1 Apontar sempre o servidor CDS principal para um servidor de segurança em serviço 9.2 Deve existir um endereço IP adicional do servidor de segurança no arquivo pe_site em uma migração obrigatória 10.0 LIMITAÇÕES DE REGISTRO USANDO LDAP 10.1 Restrições de nomenclatura 10.2 Não foi possível excluir as contas pré-existentes de LDAP 11.0 DIVERSOS 11.1 Efetuar backup manual dos arquivos em que o dceback não pode efetuar 11.2 Alterando o endereço IP em um ambiente de configuração dividida 11.3 Documentação do DCE - start_dcedoc 12.0 AVISOS 12.1 Marcas e marcas de serviço ===================================================== 1.0 SOBRE ESTE ANEXO LEIA ME Este arquivo contém alterações e atualizações adicionais para o arquivo README fornecido com o DCE Versão 3.2 para AIX e Solaris. Nota: Não coloque comandos entre aspas. ===================================================== 2.0 CONSIDERAÇÕES SOBRE LDAP ===================================================== 2.1 Correção eletrônica para o servidor IBM SecureWay Directory Em "DCE Security Registry and LDAP Integration Guide", "Chapter 2, Planning Considerations", na seção "Supported versions of LDAP", a seguinte sentença está incorreta: "The IBM SecureWay Directory client requires a minimum e-fix of 3.2.2-SWD-0001". A sentença anterior deve ser substituída pela seguinte: "The IBM SecureWay Directory server requires a minimum e-fix of 3.2.1-SWD-004". Além disso, se você estiver executando a característica local (locale) UTF-8 no Solaris, a correção eletrônica 3.2.1-SWD-005 será solicitada. Consulte a seção 5.1 para obter mais detalhes. As correções eletrônicas (e-fixes) estão disponíveis no site Web IBM SecureWay em www.ibm.com/secureway/directory. ===================================================== 2.2 Requisito de leitura/gravação simultânea Se estiver usando o servidor IBM SecureWay Directory como um armazenamento de backup, o servidor LDAP deverá ser configurado para usar leitura/gravação simultânea. Se isto não for feito, poderão ocorrer bloqueios entre LDAP e DCE. Modifique a seguinte sub-rotina no arquivo slapd32.conf para incluir o atributo LDAP_CONCURRENTRW: dn: cn=Front End, cn=Configuration cn: Front End ibm-slapdSetenv: LDAP_CONCURRENTRW=ON objectClass: top objectClass: ibm-slapdFrontEnd Com um iPlanet/Netscape Directory, a leitura/gravação simultânea será a configuração padrão. ===================================================== 2.3 Alteração do limite de tamanho de LDAP para comandos dcecp catalog no servidor IBM SecureWay Directory Comandos dcecp catalog como "dcecp -c principal cat" e "dcecp -c account cat" poderão não retornar todos os dados principais se o valor de ibm-slapdSizeLimit estiver muito baixo. O valor padrão é 500, permitindo que as informações retornem para aproximadamente 480 proprietários. O ibm-slapdSizeLimit está definido em /usr/ldap/etc/slapd32.conf. ===================================================== 2.4 Atributo CreatorsName usando ldif2db e réplica O atributo krbTrustedAdmObject, ou o atributo krbKdcServiceObject, devem conter Nomes Distintos (Distinguished Names - DNs) para todos os usuários ou aplicativos que são esperados com a finalidade de criar dados DCE no LDAP. Isto inclui todos os servidores de segurança do DCE, servidores Network Authentication Service KDC e outros aplicativos de administração LDAP. Se o diretório LDAP para a célula DCE foi restaurado com uma ferramenta de importação de diretório, os atributos krbTrustedAdmObject ou krbKdcServiceObject da entrada LDAP da célula deverão ser atualizados para incluir o DN de autorização usado pela ferramenta antes de iniciar o DCE. No caso de uso de ldif2db para restaurar um diretório IBM SecureWay, este é o DN do administrador de diretório LDAP. Além disso, se recurso de réplica do servidor de diretórios for usado para fornecer réplicas do registro de LDAP, os atributos krbTrustedAdmObject e krbKdcServiceObject da entrada da célula no servidor LDAP principal deverão ser atualizados para incluir o DN usado pelo fornecedor ou consumidor de LDAP para cada réplica. ===================================================== 2.5 Erros durante a modificação do esquema Ao modificar o esquema do servidor iPlanet Directory, poderá ser informado um erro na modificação tentada dos atributos passwordMinAge e gecos. Estas modificações trabalham com o OID ou a sintaxe do atributo. Nenhum destes erros afeta a operação do DCE ou de qualquer outro aplicativo que use o servidor iPlanet Directory. ===================================================== 3.0 CONSIDERAÇÕES SOBRE O AIX ===================================================== 3.1 Considerações ao executar aplicativos do cliente no AIX Se seu aplicativo encontrar a mensagem (ou exceção): Não há memória para RPC (dce/rpc) é possível que seu aplicativo tenha alcançado o limite do tamanho de dados padrão de 128 MB. Aumente o limite para que o aplicativo supere esse problema. Além disso, convém considerar o uso do modelo de memória extensa do AIX para aplicativos que possuem uma base maior que 256 MB. ===================================================== 3.2 Comando dcf_ulimit incluído em dcecp Se você deseja alterar o ulimit do tamanho de dados somente para DCE e não para qualquer outro aplicativo executado no sistema, poderá usar o comando "dcecp -c dcf_ulimit" dentro do arquivo /opt/dcelocal/tcl/user_cmd.tcl. Uma amostra de como usar este comando em um arquivo user_cmd.tcl pode ser encontrada em /opt/dcelocal/tcl/user_cmd.sample.tcl. Consulte a Seção 3.3 para obter a sintaxe deste comando. ===================================================== 3.3 Comando dcf_ulimit Um comando que foi incluído em dcecp, chamado dcf_ulimit. dcf_ulimit atua de modo semelhante a ulimit. Ele usa múltiplos parâmetros da linha de comandos. Se -?, -help ou help forem digitados com o comando dcf_ulimit, será exibido o seguinte: dcf_ulimit [-S|-H] -f -c -t -d -s -m -n Você pode usar o comando ulimit -a a partir do interior de dcecp (ou de um script tcl) para exibir as definições atuais de ulimit. Contudo, o parâmetro -a não é suportado com dcf_ulimit. O comando ulimit no sistema operacional usa valores de 64 bits. Como dcecp é um programa de 32 bits, fica restrito ao tamanho do inteiro que deverá transmitir para a API setrlimit. Estes são os valores máximos que podem ser transmitidos ao usar-se o comando dcf_ulimit: -f FSIZE 4194303 -c CORE 4194303 -t CPU 2147483647 -d DATA 2097151 -s STACK 2097151 -m RSS 2097151 -n NOFILE 2147483647 A palavra-chave "unlimited" também é permitida como um valor para qualquer dos parâmetros. Em geral, o comando dcf_ulimit atua da mesma forma que o comando ulimit. ===================================================== 4.0 CONSIDERAÇÕES SOBRE DESEMPENHO E DICAS DE AJUSTE DO DCE 3.2 ===================================================== A utilização do recurso do DCE 3.2 para migrar informações de segurança do DCE para um diretório LDAP possui certas considerações sobre desempenho. Mover o registro de segurança do DCE de um banco de dados na memória (o modelo no DCE existente) para um banco de dados LDAP no disco apresenta impactos no desempenho. Esses impactos variam de acordo com o estágio de migração em que uma célula se localiza. Os clientes poderão ver um impacto maior no desempenho em uma célula híbrida (uma célula que contenha servidores de segurança existentes e servidores LDAP coexistindo) versus uma célula que foi migrada inteira para LDAP. Isto é devido à sobrecarga associada com atualizações propagadas para LDAP, assim como a servidores de segurança existentes do DCE. Em geral, recomenda-se aos clientes com aplicativos DCE que fazem atualizações freqüentes no registro de segurança e que esperam acessar imediatamente estas atualizações, que procedam de uma das seguintes formas: o Evitem executar em um ambiente híbrido por um período de tempo muito grande. o Usem a segurança preferencial para pedidos de segurança diretos feitos por estes aplicativos para servidores de segurança existentes do DCE. Há diversas outras considerações de ajuste de desempenho associadas ao recurso de integração de LDAP, conforme está descrito nas seções a seguir. ===================================================== 4.1 Ajustando secd ===================================================== 4.1.1 Ajustando conexões múltiplas para o servidor LDAP A variável de ambiente MAX_CONNECTIONS determina o número de conexões que um servidor de segurança tem no banco de dados LDAP. O padrão atual é 8 e é suficiente para a maioria dos ambientes de cliente. Contudo, existem cenários que podem exigir conexões adicionais. Um exemplo seria um ambiente que mantém uma carga de trabalho simultânea de login significativa. Em um ambiente de multiprocessador, é conveniente, também, aumentar o número de conexões para aproveitar a capacidade elevada do sistema. A qualquer momento em que a variável de ambiente MAX_CONNECTIONS for modificada, o servidor de segurança nesse sistema deverá ser reiniciado. O número máximo de conexões suportadas é 64. ===================================================== 4.1.2 Ajustando o número de encadeamentos de propagação Para ter uma propagação simultânea até uma réplica existente e um servidor de migração LDAP na célula que contém somente 3 servidores de segurança, defina a variável de ambiente MAX_SEC_PROP_THREADS existente no servidor de segurança principal como 2. Se existirem mais de 3 servidores de segurança na célula, o número de encadeamentos será elevado automaticamente para 2 por secd. ===================================================== 4.1.3 Ajustando qual secd será o iniciador de init_rep Use a variável de ambiente SEC_REP_INIT_FROM_UUID no servidor de segurança principal para especificar a réplica existente a partir da qual o registro de segurança foi recebido durante a migração para LDAP. Defina essa variável com o Universal Unique Identifier (UUID) de uma réplica existente antes de emitir o comando dcecp registry migrate no servidor de migração. Para obter o UUID, emita o comando "sec_admin" e digite "lr -all". O UUID é o ID de Instância do servidor. Depois de definir esta variável de ambiente, você deverá encerrar e reiniciar o servidor de segurança principal. O uso desta variável de ambiente evita que o principal existente seja usado para a inicialização. Se o principal existente for usado para a inicialização, será colocado no modo de manutenção enquanto durar a migração. Embora as réplicas de segurança existentes possam executar esta função, os servidores LDAP não conseguem. Não defina a variável de ambiente SEC_REP_INIT_FROM_UUID com o UUID de um LDAP dependente. ===================================================== 4.2 Ajustando DB2 ao usar IBM SecureWay LDAP Nota: As instruções nesta seção supõem que você esteja usando o id de usuário padrão do DB2 de LDAP (ldapdb2). Se estiver usando um id de usuário do DB2 de LDAP diferente, faça as substituições necessárias. Nem sempre é o caso de quanto maior for o cache do DB2, menores serão os acessos de E/S. Uma estratégia melhor é aumentar a capacidade dos caches do LDAP. Em geral, minimizar o tamanho do conjunto de buffers do DB2 e maximizar a entrada e os caches do filtro de LDAP. Os exemplos a seguir utilizam comandos do AIX. Use os comandos aplicáveis do seu sistema operacional, dependendo de onde seu servidor LDAP estiver localizado. Etapas de Exemplo - DB2 (ao usar o IBM SecureWay LDAP) 1. Efetue login como o superusuário do DB2 ldapdb2, por exemplo: su -ldapdb2 2. Verifique SHEAPTHRES existentes (o limite de heap ordenado), por exemplo: db2 get dbm config | grep SHEAP 3. Redefina SHEAPTHRES existente em 20000, por exemplo: db2 update db manager config using SHEAPTHRES 20000 4. Inicie o DB2, por exemplo: db2start 5. Conecte-se ao LDAP/DB2, por exemplo: db2 connect to ldapdb2 6. Verifique o BUFFPAGE existente (o tamanho de conjunto do buffer), por exemplo: db2 get db config for ldapdb2 | grep BUFF 7. Obtenha o tamanho da memória do sistema (em MB), por exemplo: lsattr -E -l mem0 8. O BUFFPAGE padrão fornecido com o DB2 é 1000 (páginas de 4 KB) o que pode não ser grande o suficiente para um banco de dados extenso. Se seu sistema tem uma grande quantidade de memória (1 GB ou mais), utilize uma abordagem convencional para descobrir a quantidade de memória (provavelmente, não mais que 50%) que alocará para a quantidade de BUFFPAGE. Se estiver executando com aproximadamente 512 MB de memória ou menos, será útil seguir o algoritmo. Para redefinir BUFFPAGE: db2 update db config for ldapdb2 using BUFFPAGE nnnnn em que nnnnn é calculado como segue (50% do sistema alocado para o conjunto de buffers): nnnnn = memória do sistema MB * 50% / 4KB (Tendo 1 página = 4 KB) 9. Se você aumentar o parâmetro BUFFPAGE, aumente também o tamanho de DBHEAP em 1 para cada 30 acrescentados no parâmetro BUFFPAGE. Para verificar o DBHEAP existente (o heap do banco de dados), por exemplo: db2 get db config for ldapdb2 | grep DBHEAP 10. Como exemplo, para redefinir o DBHEAP em 1700, você executaria o seguinte comando: db2 update db config for ldapdb2 using DBHEAP 1700 11. Verifique o SORTHEAP existente (o heap da lista de ordenação), por exemplo: db2 get db config for ldapdb2 | grep SORTHEAP 12. Use a ferramenta Monitor do Banco de Dados DB2 para descobrir um valor apropriado para o parâmetro SORTHEAP. Para redefinir SORTHEAP: db2 update db config for ldapdb2 using SORTHEAP nnnn em que nnnn = aumentado pelo BUFFPAGE / 30 13. Verifique MAXLOCKS existente (a porcentagem das listas de travas de segurança por aplicativo), por exemplo: db2 get db config for ldapdb2 | grep MAXLOCKS 14. Use a ferramenta do Monitor do Banco de Dados DB2 para descobrir um valor apropriado para o parâmetro MAXLOCKS. Por exemplo, para redefinir MAXLOCKS em 100: db2 update db config for ldapdb2 using MAXLOCKS 100 15. Redefina o conjunto de buffers, por exemplo: db2 alter bufferpool ibmdefaultbp size -1 Nota: -l é "um", não a letra L 16. Reinicie o db2 para ativar as alterações acima, por exemplo: db2stop db2start Para obter maiores informações sobre como ajustar o DB2, consulte www.software.ibm.com/data/db2/library ===================================================== 4.3 Ajustando LDAP O desempenho de LDAP pode ser afetado por vários aspectos. O ajuste e a realização de alterações na configuração padrão é essencial para elevar o desempenho. O preparo do LDAP (e dos caches do DB2, se estiver usando IBM SecureWay LDAP) é necessário antes que os benefícios destes caches sejam concretizados. Existem vários tipos de cache do LDAP incluindo entrada e filtro. Escolha o número de entradas para o cache com base no ambiente específico do cliente. Alguns testes poderão ser necessários para descobrir o melhor tamanho. Em geral, minimize o tamanho do conjunto de buffers do DB2 e maximize a entrada e os caches do filtro de LDAP. O banco de dados do DCE 3.2 é indexado automaticamente quando você carrega o esquema do DCE no IBM SecureWay LDAP. Se estiver usando um servidor iPlanet/Netscape Directory, você deverá indexar o esquema manualmente. Recomenda-se que LDAP seja executado com leitura/gravação simultânea. Você deve definir como ativada a leitura/gravação simultânea (LDAP_CONCURRENTRW=ON) se estiver usando o IBM SecureWay Directory. Ela será ativada por padrão se você estiver usando o iPlanet/Netscape Directory. Depois que definir leitura/gravação simultânea, reinicie slapd. ===================================================== 4.3.1 Ajustando o servidor IBM SecureWay LDAP Nota: As instruções nesta seção supõem que você esteja usando o arquivo de configuração slapd padrão (/usr/ldap/etc/slapd32.conf no AIX) e o arquivo de log de erros slapd padrão (/tmp/slapd.errors no AIX). Se o servidor LDAP não usar estes padrões, faça as substituições apropriadas. Se o arquivo IBM SecureWay slapd.errors (/tmp/slapd.errors no AIX; /var/ldap/slapd.errors no Solaris; C:\Program Files\IBM\LDAP\tmp\slapd32.errors no NT) ficar grande, o desempenho do LDAP poderá decair. Não é esperado que você receba muitos erros; porém, em ambientes de execução longa, este arquivo às vezes é negligenciado. Ele pode ser excluído ou renomeado durante a execução do LDAP. Um novo arquivo slapd.errors será criado automaticamente se este for excluído ou renomeado. Existem quatro variáveis de ambiente que afetam diretamente os tamanhos de cache em um cache do servidor IBM SecureWay LDAP. Estes valores dependem da plataforma, do tamanho da memória, da carga de trabalho, etc. em um ambiente em particular. O modo preferido para definir os valores para as variáveis é através do arquivo /usr/ldap/etc/slapd32.conf. Etapas de Exemplo - IBM SecureWay LDAP 1. Inclua o seguinte no arquivo de configuração LDAP /usr/ldap/etc/slapd32.conf: #ADDED LDAP TUNING dn: cn=Front End, cn=Configuration objectclass: top objectclass: ibm-slapdFrontEnd #Ative a leitura/gravação simultânea. Isto pode evitar condições de #saída que resultariam em retorno de entradas que não correspondem #mais ao filtro de pesquisa. Este mecanismo de trava pode ter um #impacto dramático no desempenho das pesquisas de LDAP quando #operações de atualização estão em andamento. O padrão é FALSE. #Observe que esta variável pode ser definida em ON ou TRUE na v3.2.2 #do IBM SecureWay LDAP. ibm-slapdSetEnv: LDAP_CONCURRENTRW=ON #RDBM_CACHE_SIZE=; O padrão é 1000. #Especifica os números máximos de entradas para manter no cache de Entrada. ibm-slapdSetEnv: RDBM_CACHE_SIZE=100000 #RDBM_FCACHE_SIZE=; O padrão é um quarto do tamanho de #RDBM_CACHE_SIZE. #Especifica o número máximo de entrada para manter no cache do filtro de #pesquisa. ibm-slapdSetEnv: RDBM_FCACHE_SIZE=100000 #ACLCACHE=; O padrão é YES. #Controla as informações ACL no cache do servidor. ibm-slapdSetEnv: ACLCACHE=YES #ACLCACHESIZE=; O padrão é = RDBM_CACHE_SIZE. #Especifica o número máximo de entradas para manter no cache ACL. ibm-slapdSetEnv: ACLCACHESIZE=25000 2. Encerre o servidor LDAP. 3. No AIX, exporte a seguinte variável de ambiente antes de reiniciar o servidor LDAP: export MALLOCMULTIHEAP=heaps:n em que n = nr. de processadores para esta máquina host LDAP + 1 4. Inicie o servidor LDAP. ===================================================== 4.3.2 Ajustando o servidor iPlanet/Netscape LDAP Se estiver usando o servidor iPlanet/Netscape Directory, reveja as informações e dicas sobre ajuste na documentação disponível para esse produto. Especificamente, "iPlanet Directory Server Performance Tuning Guide", de maio de 2001, contém "Top 10 List of Performance Tuning Tips". O esquema deverá ser indexado manualmente quando o servidor iPlanet/Netscape Directory for usado. O servidor iPlanet/Netscape Directory armazena dados na memória. Isto, no cache de memória, também é ajustável. Etapas de Exemplo - iPlanet/Netscape LDAP Configure os seguintes atributos de DCE LDAP como atributos do índice de igualdade: - krbRealmName-v2 - krbPrincipalName - krbPolicyName - krbKeyVersion - dceDirName - dceXattrName - dceGroupName - dceUUID - unixID Antes de executar qualquer migração do DCE LDAP, calcule e defina o tamanho máximo do cache de entrada e os valores de tamanho do cache do banco de dados com iPlanet/Netscape LDAP. O tamanho do cache de entrada (cachesize) especifica o número de itens de entrada por cache, não o tamanho da memória do cache. A regra básica é dedicar 75% da memória cache para dbcachesize e 25% para o tamanho do cache de entrada. Consulte "The iPlanet Market Maker 1.0 Deployment Guide", Capítulo 6, "Performance Tuning and Monitoring". Certifique-se de atualizar cachesize e dbcachesize no arquivo de configuração do servidor LDAP para ter os valores novos. Reinicie o servidor LDAP para ativar os ajustes anteriores. Consulte http://docs.iplanet.com/docs/manuals/directory.html para obter especificações sobre como ajustar 4.13, 5.0 e outras recomendações para iPlanet/Netscape. ===================================================== 4.4 Hardware Máquinas com velocidade maior e memória adicional fizeram uma diferença significativa no desempenho durante o teste deste recurso. Os cenários de teste da IBM mostram que o desempenho de uma célula do DCE que usa LDAP para o registro de segurança está diretamente relacionado à capacidade do sistema que executa LDAP. Os testes intensivos da IBM foram executados com um IBM eServer pSeries(TM) 620 Modelo 6F1 com 4 GB de memória como a máquina servidora LDAP/DB2. É necessária memória suficiente para os caches de LDAP e DB2. A configuração mínima de memória recomendada é 128 MB. Para ajudar a melhorar o desempenho de E/S, considere a inclusão de unidades adicionais na máquina servidora LDAP/DB2. Você pode monitorar (por exemplo, através do utilitário vmstat) a porcentagem de tempo gasto para espera de E/S. Se não for 0%, isto pode sugerir que o banco de dados está limitado por E/S, o que pode indicar que LDAP está efetivamente saturado. Aumentar o tamanho do buffer do banco de dados até que o tempo de espera de E/S aproxime-se de 0% geralmente é a abordagem mais efetiva. ===================================================== 4.5 Rede A execução de um servidor LDAP e do servidor de migração de segurança DCE na mesma máquina pode melhorar o desempenho, especialmente durante a migração. O uso de SSL em uma rede pode ter impactos significativos no desempenho; os períodos de atividade de propagação e atualização podem aumentar. ===================================================== 4.6 Expectativas da migração inicial A migração inicial do registro de segurança para LDAP através do servidor de migração demora muito mais que a inicialização de uma réplica existente. Onde a migração em um ambiente de registro de 10.000 proprietários/contas pode levar alguns minutos para uma réplica existente, em um ambiente LDAP, isto pode demorar até 15 horas. ===================================================== 4.7 Considerações sobre o aplicativo DCE Em uma célula híbrida, a réplica, especialmente a propagação de informações de segurança, demora mais para entrar no banco de dados LDAP. As aplicações do cliente que atualizam as informações de segurança e, em seguida, acessam imediatamente esses dados podem gerar erros do tipo "Objeto de Registro Não Encontrados". Isto é devido ao atraso de propagação necessário para obter as informações no LDAP. Diversas abordagens podem ser usadas para atenuar esse problema. Um método é usar o arquivo pe_site. Use a variável de ambiente TRY_PE_SITE e solicite aos servidores de segurança que o servidor de migração LDAP não seja o primeiro no arquivo pe_site. O aplicativo então se ligará a um servidor secd existente no qual o atraso de propagação não é significativo. Outro método é incluir código aos aplicativos existentes para realizar uma repetição em caso de erro após uma atualização e, assim, permitir o tempo necessário para a propagação. Depois de migrada a célula inteira para LDAP, não ocorre mais a migração. ===================================================== 4.8 Tarefas do usuário (login, chpasswd) A IBM implementou suporte para conexões múltiplas ao servidor LDAP, ajudando, deste modo, a melhorar o desempenho da atividade simultânea de login. Consulte a seção anterior "Ajustando secd" para uma discussão da variável de ambiente MAX_CONNECTIONS. Os usuários poderão sofrer, ocasionalmente, o atraso de propagação quando alterarem sua senha e efetuarem login imediatamente. Uma falha inicial poderá ocorrer se a troca de senha ainda não foi propagada para LDAP. O usuário pode tentar novamente e, nesse momento, o login deverá ser bem-sucedido. ===================================================== 4.9 Tarefas do Administrador (user create, user delete) Devido ao modo que o comando "dcecp -c user create" faz pesquisas, ele é normalmente mais lento no LDAP do que quando realiza as etapas envolvidas separadamente. Em vez disto, recomenda-se a execução dos seguintes comandos dcecp separados: principal create group create org create group add member org add member account create A mesma recomendação é adequada para "dcecp -c user delete". Se você executar scripts que usem o comando "dcecp -c user create", consulte a discussão pe_site na seção anterior "Considerações sobre o aplicativo DCE". O uso do arquivo pe_site para "direcionar" pedidos a servidores secd existentes e fora do servidor de migração durante a migração poderá atenuar alguns atrasos de propagação. ===================================================== 5.0 CONSIDERAÇÕES SOBRE CARACTERÍSTICAS LOCAIS (LOCALE) ===================================================== 5.1 Problema do cliente Solaris LDAP com UTF-8 (somente Solaris) O cliente do IBM SecureWay Directory V3.2.1 para Solaris suporta a execução de características locais (locales) UTF-8, com a correção eletrônica 3.2.1-SWD-005 instalada. Se você tentar usar o DCE com LDAP enquanto executar uma característica local (locale) Solaris UTF-8 sem a correção eletrônica instalada, o DCE falhará com erros de codificação de LDAP semelhantes aos seguintes: 2001-07-09-15:47:53.898-05:00I----- secd ERROR sec ldap ldap_errors.c 666 0xfe8af9bc msgID=0x17122F9F ldap_simple_bind_s retornou LDAP_ENCODING_ERROR durante rgy_bind_to_ldap_server (1134). ===================================================== 5.2 Falhas de LDAP relacionadas a definições de características locais (locales) não suportados O cliente do IBM SecureWay Directory V3.2.1 não executará corretamente se as variáveis de ambiente LANG e LC_ALL das características locais (locale) do sistema operacional estiverem definidas com valores que não sejam suportados na máquina do host local. Definições incorretas causam erros de LDAP que resultam em erros DCE semelhantes aos seguintes: 2001-11-02-14:29:12.435-06:00I----- secd ERROR sec ldap ldap_errors.c 666 0xfea8f904 msgID=0x17122F9F ldap_simple_bind_s retornou LDAP_ENCODING_ERROR durante rgy_bind_to_ldap_server (1332). 2001-11-02-14:29:12.814-06:00I----- secd ERROR sec rs_ns rs_master_LDAP.c 550 0xfea8fbac msgID=0x17122084 Registro de dados inválido Como alternativa a este problema, defina os valores de LANG e LC_ALL para que sejam suportados na máquina. Para ver as definições das características locais (locale) atuais, execute o comando do sistema "locale" na sessão do DCE. No AIX, o comando "locale -a" mostra as definições válidas das características locais (locale) para a máquina local. Se as definições de características locais (locale) atual não estiverem listadas, você deverá redefinir LANG e LC_ALL com valores que estejam listados. No Solaris, você pode detectar uma definição incorreta porque o sistema operacional exibe a mensagem de aviso "não foi possível definir a característica local (locale) corretamente" durante a execução dos comandos do sistema. ===================================================== 6.0 MODIFICAÇÃO REQUERIDA DA VERSÃO DE REGISTRO ===================================================== 6.1 Verifique se todas as réplicas têm o mesmo número da versão de registro antes de migrar para o LDAP principal Antes de migrar para o LDAP principal, você deve atualizar a versão do registro de segurança do DCE para 1.3. Como isto pode exigir duas modificações de versão, verifique se todas as réplicas têm o mesmo número da versão antes de iniciar a migração para o LDAP principal. Antes de prosseguir, você deverá executar "lr -all" para verificar se a atualização ocorreu em todas as réplicas. Emita o comando "sec_admin" e digite "lr -all". Quando todas as réplicas estiverem na versão 1.3 e possuírem o mesmo número de seqüência, será seguro migrar para o LDAP principal. ===================================================== 6.2 Tentativas de modificar a versão de registro para aguardar pelos números de seqüência para correspondência Nos releases anteriores do DCE, era comum que a versão do registro fosse modificada duas vezes em um breve período de tempo. Ao migrar para usar a funcionalidade do LDAP no DCE 3.2, se a versão de registro da célula ainda não for secd.dce.1.2.2a (para Chave Pública), será necessário que a versão do registro seja modificada pelo menos duas vezes: de secd.dce.1.2.2 para secd.dce.1.2.2a e depois de secd.dce.1.2.2a para secd.dce.1.3 O DCE não suporta mudar mais de uma versão por vez e precisa de tempo para a mudança completa de uma versão antes que a mudança para uma outra versão seja iniciada. As réplicas de segurança devem processar a primeira mudança de versão através da propagação antes que a segunda seja iniciada, do contrário as réplicas de segurança retornarão erros indicando que a versão está sendo alterada por várias versões de uma vez. Antes de tentar alterar a versão do registro, use sec_admin com o subcomando lr -all para verificar se todos os números de seqüência da réplica de segurança estão atualizados. Quando todos os números de seqüência coincidirem, a versão do registro poderá ser alterada com segurança. Execute esta verificação antes de cada comando "dcecp -c registry modify -version". O comando "dcecp -c registry modify -version" tenta executar esta verificação sozinho, usando sec_rgy_wait_until_consistent. Ele tenta forçar o principal a aguardar que as réplicas tenham todas as atualizações antes de processar a atualização da versão. Se as réplicas de segurança não estiverem todas atualizadas, você verá o seguinte: Aguardando até 600 segundos para que "sec_rgy_wait_until_consistent" seja concluído. Você receberá esta mensagem se dcecp tiver que esperar mais de 15 segundos para que sec_rgy_wait_until_consistent retorne. dcecp terá um intervalo de 10 minutos se a API sec_rgy_wait_until_consistent não retornar. Se isto acontecer, a seguinte mensagem será exibida: 0x11315bbd O software atingiu o tempo limite aguardando "sec_rgy_wait_until_consistent" estar completo. versão = secd.dce.1.2.2a A versão do registro atual é exibida de modo que você possa saber se o tempo limite de dcecp em sec_rgy_wait_until_consistent esgotou-se antes ou depois da atualização da versão do registro. Se a versão exibida não for a desejada, aguarde alguns minutos e tente a modificação do registro novamente. Na maioria das vezes, o comando "dcecp -c registry modify -version" aguardará que a atualização da versão se propague a todas as réplicas de segurança. Pode ocorrer também que dcecp não consiga detectar se algumas réplicas de segurança não conseguiram todas as atualizações. Por exemplo, o servidor de Segurança Principal lançou uma atualização, mas a réplica não a processou ou uma réplica não está sendo executada atualmente. Se a versão do registro for atualizada antes que todas as réplicas de segurança sejam atualizadas, os erros de versão poderão ser informados por algumas das réplicas. Se o servidor réplica de segurança que informar o erro for de tipo existente, essa réplica não terá que ser reconfigurada. Se o servidor réplica de segurança que informar o erro estiver numa réplica de segurança de LDAP, copie o arquivo /opt/dcelocal/var/security/rgy_data/master_info de um LDAP dependente sem erro ou do dependente de migração. Certifique-se de salvar a versão original do arquivo master_info em caso de ocorrência de erros. ==================================================== 7.0 CONSIDERAÇÕES SOBRE MIGRAÇÃO E POSSÍVEIS SITUAÇÕES DE ERRO ==================================================== 7.1 A migração do registro requer alguns parâmetros para ser completada O comando "dcecp -c registry migrate" requer nomes de caminho completos para os parâmetros -dce_master_key e -keyring. Se fornecido um nome do caminho que não seja completo para um destes parâmetros, você receberá a seguinte mensagem: O valor, '', para a opção