Notas da Versão do probe controller

O probe controller é um componente central do robô do canm.
uimpga-ga
controller_RN
O probe controller é um componente central do robô do
CA Unified Infrastructure Management
.
  • Os controladores programam, iniciam e interrompem os probes que o robô gerencia. Os controladores mantêm os probes configurados em execução, de acordo com as configurações do probe.
  • Os controladores mantêm o contato com os hubs pai e lidam com as operações do CA UIM, incluindo o estado do hub, os serviços de pesquisa de nome e as licenças.
  • Os controladores respondem às diretivas nos arquivos
    robot.cfg
    e
    controller.cfg
    e aos comandos emitidos por
    controller_port
    .
    Padrão
    : 48000
Agora, há dois tipos de hub e robô disponíveis — seguro (9.10S) e não seguro (9.10 e anterior). Versões 9.10 e anteriores do hub e do robô usam o modelo de segurança herdado. O hub (9.10S) e o robô (9.10S) seguros estão disponíveis a partir do CA UIM 9 SP1 e melhoram ainda mais o mecanismo de segurança no CA UIM.
Observação
: os casos de suporte podem não estar visíveis para todos os clientes.
Histórico de revisões
Versão
Description
Estado
Data
9.30
(Incluído no UIM 20.1.0)
O que há de novo:
  • (7.97 HF6) Corrigido um problema no qual o hub 7.97 ignorava os encapsulamentos e não permitia a criação de novos encapsulamentos. O hub atribui a porta à conexão de encapsulamento, fazendo uma solicitação ao controlador. O controlador sempre atribuía a nova porta e não usava as portas liberadas anteriormente, o que estava causando atraso na pesquisa da porta disponível. Otimizado para reutilizar as portas liberadas anteriormente. (Caso de suporte: 01307453)
  • (7.97 HF7 e 9.20 HF7) Corrigido um problema no qual o hub secundário interrompia o envio de QoS de todos os probes após a atualização para o 9.20. Foi adicionado o parâmetro extra como "restmon_qos" na mensagem de QoS do RESTMon e foi feito o mesmo no nível de plugin_metric para identificar a mensagem de QoS do RESTMon e resolver esse problema. (Caso de suporte: 20058295, 20040794 e 20033089)
  • (7.97 HF8 e 9.20 HF9) Corrigido um problema que causava panes, já que a ACL do BM UIM tratava as vulnerabilidades de DoS do Probe e do RCE. Foi adicionada a correção para a vulnerabilidade de execução remota de código não autenticado no nimbuscontroller Nimsoft. (Caso de suporte: 20093616, 20101721)
  • (9.10 HF1) Corrigido um problema no qual os alarmes não estavam sendo gerados de acordo com o IC selecionado na diretiva de alarme. Os alarmes não estavam sendo gerados de acordo com o ci_name selecionado na diretiva de alarme porque plugin_metric sempre era usado para obter o probe ci_name do niscache. No entanto, o probe docker_monitor envia ci_name como parte de qos_message. Para corrigir o problema, foi adicionada uma funcionalidade em plugin_metric que permite obter o ci_name da mensagem de qos caso ele não seja encontrado na pasta do niscache. (Caso de suporte: 20051916)
  • (9.20 HF2) Corrigido o problema de tolerância a falhas do robô. Foi feita a verificação para aceitar solicitações do hub principal se o robô for alternado para o hub secundário quando o modo de proxy estiver ativado no controlador. (Caso de suporte: 20051408)
  • (9.20 HF3) Corrigidos dois problemas como parte desta hot fix. Corrigido o problema de tolerância a falhas do robô. Além disso, foi corrigido um problema no qual os alarmes de diretiva de alarme não continham o marcador de usuário do robô. (Casos de suporte: 20051408 e 20063366)
  • (9.20S HF3) Corrigido um problema no qual os alarmes de diretiva de alarme não continham o marcador de usuário do robô. (Caso de suporte: 20063366)
  • (9.20 HF5 e 9.20S HF5) Corrigido um problema no qual várias instâncias do robô estavam em execução, o que estava esgotando os recursos da CPU. (Caso de suporte: 20084151)
  • (9.20 S HF4) Corrigido um problema no qual os robôs não estavam sendo tolerantes a falhas em um ambiente de robô misto seguro. O problema ocorre quando o hub envia uma solicitação de check-in a todos os seus robôs depois de serem ativados. Em um ambiente seguro, robôs não seguros enviam solicitações de ativação de robô na porta 480002, e o hub_adapter é executado na porta 48002. O hub_adapter não é incluído no componente principal, para que ele seja iniciado após algum tempo. E, antes de ele ser iniciado, a solicitação de ativação de robô é recebida e falha. Foram feitas alterações para que o processo do hub_adapter seja iniciado logo depois do hub. Isso permite que ele trate todas as solicitações de robôs não seguros. (Caso de suporte: 20069927)
  • (9.20S HF7) Corrigidos os seguintes problemas: (Casos de suporte: 20097684, 20089674, 20093286, 20075343, 20074324, 20058295, 20040794 e 20033089)
    • O controlador tinha tratamento especial para expiração de SID em robôs. O proxy não conseguia diferenciar o controlador do probe e, portanto, fornecia a SID do controlador ao probe após a expiração. Isso estava causando a permissão negada. A correção foi fornecida para fazer com que o controlador obtenha a SID por conta própria quando a SID expirar.
    • Corrigido um problema no qual o hub secundário interrompia o envio de QoS de todos os probes após a atualização para o 9.20. Foi adicionado o parâmetro extra como "restmon_qos" na mensagem de QoS do RESTMon e foi feito o mesmo no nível de plugin_metric para identificar a mensagem de QoS do RESTMon e resolver esse problema.
  • Corrigido um problema no qual as CPUs eram usadas até o limite quando um robô era executado duas vezes. (Caso de suporte: 20084151)
  • Corrigido um problema no qual o robô passivo (controlador) gerava um erro de SID inválido. (Caso de suporte: 20100511)
  • Corrigido um problema com o Evento de erro do aplicativo com o código 1000 nos robôs. (Caso de suporte: 20077272)
  • Corrigido um problema de tolerância a falhas do robô no UIM 9.1.0. (Caso de suporte: 20051408)
  • Corrigido um problema no qual os Robôs não estavam sendo tolerantes a falhas em um ambiente misto de robô seguro 9.2hf3. (Caso de suporte: 20069927)
GA
Março de 2020
9.20
(Incluído no CA UIM 9.2.0)
O que há de novo:
  • (7.93 HF16) Correção de um problema em que o spooler do robô não estava respondendo quando o probe sysloggtw enviava grandes volumes de dados e o erro era do tipo wsaewouldblock. Para resolver esse problema, foi introduzido um novo parâmetro
    sock_write_retry_count
    . Esse parâmetro permite especificar o número de tentativas que o spooler do robô deve considerar antes de interromper o envio da mensagem. Adicione esse parâmetro ao arquivo spooler.cfg. (Caso de suporte: 01243127)
(7.97 HF1) Correção de um problema em que plugin_metric não estava coletando métricas para os probes (que têm perfis novos criados), a menos que o robô fosse reiniciado. Esse problema foi corrigido com esse hot fix.
(7.97 HF3) Esse hot fix resolve os seguintes problemas:
  • Correção de um problema em que informações de diretivas de alarme não estavam sendo adicionadas ao arquivo plugin_metric.cfg em alguns robôs. Isso estava criando problemas, pois os alarmes não estavam sendo gerados nesses dispositivos quando as métricas monitoradas excediam os limites configurados para a diretiva de alarme.
  • Correção de um problema em que foi observado alto uso de memória no processo do controlador depois que o robô era atualizado de 7.93 para 7.97.
  • Foi corrigido um problema em que, após a implantação do robô 7.97 sobre o 7.93, a versão não estava sendo atualizada na caixa de diálogo de status da UI do controlador. (Caso de suporte: 01350012)
  • Corrigido um problema no qual as entradas duplicadas de dispositivo existiam para o mesmo dispositivo no portlet UMP. (Caso de suporte: 00889072)
  • Corrigido um problema em que a atualização do UMP estava falhando. (Caso de suporte: 01369904)
  • Corrigido um problema em que o Console de administração não estava instalando o pacote dependente e a implantação falhava imediatamente. A mesma implantação era concluída com êxito se realizada por meio do IM. (Casos de suporte: 00852608 de 1261671)
  • Correção de um problema em que os alarmes TOT não estavam funcionando conforme o esperado. Por exemplo, com limites definidos em 85% para alarmes principais e 90% para críticos, os alarmes estavam sendo gerados para menos utilização de CPU. (Caso de suporte: 01269944, 01260949, 01269925, 01287039, 01290918, 01293428 e 01303742)
  • (7.93 HF10) Esse hot fix oferece suporte ao robô no Ubuntu 18.04 na plataforma x86_64. (Caso de suporte: 01242463)
  • Correção de um problema em que robô não estava iniciando nem reinicializando em um computador AIX. (Caso de suporte: 01187252)
  • Correção de um problema em que, quando um robô não conseguia encontrar um endereço IP válido em robot.cfg ou DNS, acabava usando o endereço do loopback. Isso estava interrompendo a comunicação. Esse problema foi resolvido nessa release. Para resolver esse problema, dois parâmetros configuráveis foram adicionados a robot.cfg: (caso de suporte: 01219460)
    • max_retry_IfLoopBack_attempt Especifica o número máximo de novas tentativas que o controlador pode fazer para encontrar o endereço IP do sistema. No caso do endereço IP do loopback, se robot_ip não estiver configurado em robot.cfg, o controlador tentará obter o IP do sistema. Ele tentará encontrar o endereço IP para o número de novas tentativas especificado no parâmetro. Depois de tentar a contagem especificada, o controlador começará novamente com o IP do loopback, o que resulta no mesmo comportamento inicial. O valor padrão é 10.
    • sleep_btwRetry_IfLoopBack_attempt Especifica o intervalo máximo pelo qual o controlador aguardará antes de fazer novamente a tentativa subsequente. O valor padrão é de 2 segundos.
  • Correção de um problema em que os usuários estavam tendo dificuldades com o RPM do robô do UIM e incluíam arquivos de unidade de sistema. (Caso de suporte: 00913690)
  • (7.93 HF18) Corrigido um problema em que os robôs recentemente atualizados estavam gerando problemas em computadores AIX. Quando os usuários atualizavam robôs em sistemas AIX, a maioria dos robôs funcionava, exceto aqueles que estavam se conectando a um banco de dados Oracle. Quando a atualização era realizada, o arquivo robot.cfg era atualizado e o valor LIBPATH era alterado. Esse hot fix preserva o valor existente em LIBPATH ao atualizar um robô usando robot_update. (Caso de suporte: 01185299)
  • Correção de um problema em que os usuários instalavam o robô no Windows Server 2012 R2 e aplicavam perfis do MCS para o perfil de CPU, memória e disco. Eles estavam recebendo algumas métricas de disco e CPU, mas não métricas de memória. (Caso de suporte: 01249736)
  • Corrigido um problema em que o snmpcollector não estava sendo iniciado a partir do Console de administração. Esse problema acontecia porque o controlador não estava acessível às vezes. (Caso de suporte: 01307099)
  • Corrigido um problema no qual os usuários não conseguiam instalar o robô por meio do rpm, pois ele estava usando o valor padrão (ou seja, /opt/nimsoft). O comando estava instalando o robô no local correto /opt/CA/nimsoft. No entanto, ele não estava atualizando esse arquivo com o caminho de arquivo correto /usr/lib/systemd/system/nimbus. O robô não será iniciado até que o caminho desse arquivo seja atualizado para /opt/CA/nimsoft. O arquivo tinha /opt/nimsoft. (Caso de suporte: 01347207)
  • Corrigido um problema em que, após a atualização dos robôs, o probe spooler falhava ao enviar as mensagens após a reinicialização do hub. (Caso de suporte: 01306288)
  • Corrigido um problema em que, quando os usuários tentavam instalar o robô/hub no CentOS 6.8 usando a instalação do nimldr (a partir do CA UIM 9.0.2), a instalação falhava e terminava com uma mensagem de erro. (Caso de suporte: 01332537)
O CA UIM 9.2.0 adotou o OpenJDK 8u212 em vez do Oracle JDK. Devido a essa mudança, o CA UIM 9 SP1 (9.1.0) que usava o Oracle JDK (JRE) 8u212 não está mais disponível e foi removido do site de suporte. Todas as funcionalidades incluídas no 9.1.0 foram lançadas agora como parte do CA UIM 9.2.0. Consequentemente, todas as referências à release 9.1.0 e à versão 9.10 do probe (lançadas com ele) também foram removidas da documentação desse probe. Recomendamos que você migre para a versão 9.20 desse probe, já que a versão anterior 9.10 não está mais disponível. Para obter mais informações sobre o uso do OpenJDK no CA UIM, consulte Adotando o OpenJDK.
GA
Agosto de 2019
7.97
  • Atualização para oferecer suporte ao Microsoft Visual C++ Redistributable for Visual Studio 2017, pacote versão 1.01 (vs2017_vcredist_x86 1.01 e vs2017_vcredist_x64 1.01). Esse suporte ajuda a garantir que a versão mínima do pacote VS 2017 seja igual ou superior a 1.01. Com essa dependência da versão 1.01, o computador não será mais reinicializado automaticamente ao instalar o pacote VS 2017. Ou seja, com a v1.01, não haverá nenhuma reinicialização automática do computador.
  • Melhor tratamento do plugin do controlador. Por exemplo, quando o controlador 7.96 (compilado com o vs2017_vcredist_x86 1.0 ou o vs2017_vcredist_x64 1.0) tenta carregar o attr_publisher (compilado com o Microsoft Visual C++ Redistributable for Visual Studio 2008), o controlador para de responder. Isso ocorre devido à incompatibilidade do compilador. Agora, com esta release do probe, que depende do vs2017_vcredist_x86 1.01 ou do vs2017_vcredist_x64 1.01, o controlador não carrega mais o plugin (attr_publisher), caso ele não seja compatível.
  • Atualizado para oferecer suporte ao Amazon Linux 2.
GA
Dezembro de 2018
7.96
Incluído no CA UIM 9.0.2
O que há de novo:
  • Adicionado suporte ao monitoramento do Ubuntu 18.04. Aplique o robô 7.93HF10 para esse suporte.
    Caso de suporte: 01184423
  • Alterada a configuração padrão de reuse_async_session na seção do controlador de robot.cfg to 1 = ON.
  • Adicionado suporte ao PowerPC 64 Little-endian (ppc64le).
  • Remoção do suporte para as seguintes plataformas:
    • HP-UX OS 11.2 (IA64) e 11.2 (PA-RISC)
    • Linux CentOS 5 (32 bit e 64 bit), Debian 5 e 6
  • (Fevereiro de 2019) Adicionado suporte para monitorar o Windows 2019.
GA
Outubro de 2018
7.93
O que há de novo:
  • (7.92HF5) Se você criar uma nova zona do Solaris, um robô instalado na zona global não será implantado automaticamente na nova zona. Para instalar um robô em uma nova zona não global, instale o robô na zona não global usando as mesmas etapas seguidas para instalar o robô na zona global. (Caso de suporte 746015)
  • (7.92) Além dos sistemas operacionais listados abaixo, foi adicionado suporte aos robôs e hubs secundários do Suse 11 ou posterior:
    • Se você estiver instalando o hub ou o robô em um dos seguintes sistemas operacionais:
      • CentOS 7 ou posterior
      • Red Hat 7 ou posterior
      • Suse 11 ou posterior
      • openSUSE 13 ou posterior
      • Debian 8 ou posterior
    • Você deve ativar o serviço nimbus após a conclusão da instalação do nimldr. Para ativar o serviço nimbus, execute:
    • systemctl enable nimbus.service
  • (7.92HF3) Corrigido um problema em que os modelos VMware não eram criados corretamente no Windows quando
    audit=on
    estava definido. (Caso de suporte 00425378)
  • (7.92HF3) Corrigido o problema em que as seções de um arquivo de configuração do probe podiam ser perdidas durante a edição quando
    AUDIT_DETAIL
    estava ativado, fazendo com que o probe travasse.
  • (7.92HF3) Corrigido um problema em que probes programados eram mostrados como inativos quando estavam ativos. (Caso de suporte 00633989)
  • (7.92HF3) Corrigido um problema em que probes com vários segmentos podiam bloquear o arquivo de configuração no Windows desnecessariamente.
  • (7.92HF10) Aprimoramentos de desempenho do controlador.
  • (7.92HF11) O probe snmpcollector agora pode ser implantado com êxito por meio do Gerenciador de infraestrutura. Agora, o controlador distribui os arquivos de certificação de fornecedor do probe snmpcollector. (Casos de suporte 00819546, 00824491, 00683844, 00825054, 00835227, 00818146 e 00821694)
GA
Outubro de 2017
7.91
O que há de novo:
  • O robô Ubuntu 16 x64 agora é suportado.
    • Execute uma instalação nativa conforme descrito em Implantar robôs em massa com uma ferramenta de terceiros e instaladores nativos.
      Observação: a implantação com automated_deployment_engine não é suportada para o Ubuntu 16.
      • Quando a instalação estiver concluída, execute 
        /opt/nimsoft/install/service-ctrl.sh enable
         para ativar os serviços do robô no Ubuntu 16. Esta etapa não é necessária para o Ubuntu 14.
      • Inicie o robô com 
        /opt/nimsoft/bin/niminit start
    • Para desinstalar completamente o robô do Ubuntu 16, desinstale o serviço executando o comando 
      systemctl disable nimbus.service
       e exclua o arquivo
      /lib/systemd/system/nimbus.service
      .
  • Agora, o Microsoft Cluster é suportado.
  • Agora, o robô do Windows Server 2016 é suportado.
  • O suporte ao robô do Debian 6 foi descontinuado.
  • O utilitário do probe (pu) é distribuído como um pacote separado. Use o pacote pu para atualizar o utilitário do probe para v7.90.
  • A determinação automática do endereço IPv4 do robô foi aprimorada. O valor de robotip não precisa ser definido manualmente no arquivo 
    robot.cfg
    para que um robô seja iniciado.
  • A detecção de tolerância a falhas do robô impede a ocorrência de uma tolerância a falhas desnecessária quando o hub deixar de responder a uma única solicitação do robô (_status, alive, robotup ou probelist). O robô é mais tolerante a solicitações _status incompletas. Duas novas propriedades podem ser especificadas no arquivo 
    robot.cfg
    .
    • robot_status_check_interval
      controla a frequência com que o robô sonda o hub com uma solicitação _status
      . Anteriormente, isso não era configurável e a sondagem ocorria em um tempo limite médio, aproximadamente a cada 11 segundos. Use essa propriedade para especificar de forma aproximada o novo intervalo de sondagem. O intervalo é aproximado porque a verificação de status ocorre no tempo limite médio que excede o intervalo solicitado. Por exemplo, se 
      robot_status_check_interval
      estiver definido como 30 segundos, a sondagem ocorrerá a cada 33 segundos (tempo limite médio de 3 x 11 segundos). O valor padrão é 60 segundos, que equivale a uma verificação de status a cada 66 segundos.
    • robot_failover_count
       melhora a resiliência do robô. Anteriormente, o mecanismo de tolerância a falhas do robô era chamado quando uma solicitação _status para o hub falhava. Use essa propriedade para especificar o número de falhas consecutivas de _status que devem ocorrer para que seja iniciada a tolerância a falhas do robô em um hub secundário. O padrão é 2.
Problemas conhecidos:
  • Instale o pacote robot_update v7.90 antes de atualizar o probe do hub para v7.90. Quando o pacote do hub é instalado primeiro, o hub é exibido como offline no Console de administração e no Gerenciador de infraestrutura. Um erro de comunicação é relatado, mas a atualização do hub é concluída com êxito, mesmo quando ocorre o erro.
  • Atualizar robotip manualmente na plataforma Debian
    • Por padrão, o Debian usa 127.0.1.1 como o endereço de resolução de nome. Quando um robô for implantado em um sistema Debian com automated_deployment_engine e o sistema for reiniciado, o robô tentará vincular ao endereço 127.0.1.1. Para evitar a contenção do endereço 127.0.1.1 nos sistemas Debian, execute as seguintes ações:
      • Depois de instalar o robô manualmente ou com automated_deployment_engine, adicione ou atualize a chave a seguir no arquivo robot.cfg para garantir que o robô faça a vinculação ao endereço IP correto:
        • robotip =
          endereço_IP_debian
      • Ao preparar um arquivo XML para a implantação em massa nos sistemas Debian, defina robotip explicitamente no arquivo XML da seguinte maneira:
        • <robotip>
          endereço_IP_debian
          </robotip>
      • Sendo que 
        endereço_IP_debian
         é o endereço IP ao qual o robô deve se vincular no sistema de destino.
Defeitos corrigidos:
  • Falha de implantação de pacotes de distsrv no hub principal.
  • Falha do robô quando a auditoria é ativada em conjunto com o MCS. (Caso de suporte 00425278)
  • Geração de log incorreta quando request.cfg não estava disponível, o que fazia os usuários acreditarem que havia um problema que foi corrigido.
  • A instalação com o Nimldr falha com uma falha de segmentação em sistemas com mais de 10 endereços IP.
  • O utilitário do probe (pu) falha no Windows ao chamar o retorno get_status do probe automated_deployment_engine. Erro: tipo de PDS desconhecido. O tratamento de tipos desconhecidos de PDS foi aprimorado. (Caso de suporte 70004053)
  • O servidor de detecção não consegue detectar alterações na origem do robô após uma reinicialização suave do controlador.
  • O comando pré-instalação na plataforma Linux impede o downgrade ou a reinstalação do arquivo robot_update.zip v7.80.
    • Antes da correção, um downgrade de uma versão mais recente ou uma reinstalação do robot_update v7.80 fazia com que a instalação do robô falhasse.
  • Solicitações soap longas do webservicemon não conseguem retornar dados. (Caso de suporte 70000840)
    • Foi removido o limite de tamanho do buffer de 5000 caracteres para um valor de chave. Antes da correção, os dados eram truncados em 5000 caracteres.
  • Erro do spooler: 
    buffer pequeno demais
     ao iniciar um robô com mais de 200 IPs virtuais. (Caso de suporte 00170426)
  • As PIDs não são validadas até que seja emitido um comando para encerrar o processo mediante reinicialização do controlador. (Caso de suporte 246869)
    • Por padrão, serão interrompidos os processos existentes do probe que tiverem o mesmo nome que um probe que está em vias de ser iniciado.
    • Por padrão, quando um probe for interrompido por algum motivo, o controlador tentará interromper o probe com o retorno _stop. Se o retorno _stop não for aceito, o controlador encerrará o processo do probe.
  • O probe do ADE não está adicionando corretamente a Origem no HP-UX. (Caso de suporte 00289464)
  • Uma condição de corrida faz com que o hub falhe.
  • Os alarmes enviados pelo spooler não têm uma instrução Sem gravidade correspondente que os remova da lista de alarmes ativos.
  • A exceção ServerErrorException do utilitário de probe ocorre durante a execução do retorno list_subscribers em um sistema operacional Windows que esteja em um idioma diferente do inglês.
  • Os descritores de arquivos e soquetes armazenados em cache por muito tempo no controlador fazem com que o controlador fique travado. (Caso de suporte 379016)
  • Implantar um robô no Windows faz com que o Windows seja reinicializado automaticamente. O problema é observado com mais frequência ao usar o instalador nativo do Windows ou o ADE.
  • O retorno probe_config_get sempre falha. Para implementar a correção, adicione a nova chave reuse_async_session = 1 à seção
    controller
    do arquivo robot.cfg. O padrão é 0, desativado. (Caso de suporte 521488)
GA
Abril de 2017
7.80
O que há de novo
:
  • Suporte a pacotes de codificação TLS do OpenSSL
    • Ao usar pacotes de criptografia TLS 1.1 ou 1.2, inclua um fallback alternativo para SSLv3. Fallback para compatibilidade entre robôs mais antigos e novos hubs ou com probes conectados a um robô usando SSL. Exemplo: AES128-SHA256:RC4-SHA, em que AES128-SHA256 é TLS v1.2 e RC4-SHA é SSLv3.0
  • OpenSSL 1.0.1m implementado
  • O Windows IA64 não é mais suportado
Defeitos corrigidos
:
  • O probe do spooler é reiniciado
    • Quando um probe controller configurado no modo proxy for reiniciado, o probe spooler também será reiniciado.
  • A SID do controlador será automaticamente renovada após ter passado o tempo de expiração de logon do hub
    .
    • A SID do controlador do hub expirava após transcorrido o
      Login Expiration Time
      . A expiração impedia o controlador de adquirir uma nova licença para um probe de um
      distsrv
      em um hub remoto. Uma nova licença é necessária quando um probe com uma licença expirada é reiniciado. Agora, o controlador remoto é automaticamente conectado ao hub e adquire uma nova SID quando a SID expira.
  • O controlador inicia os probes java no AIX.
    • Em sistemas AIX, o controlador falhava ao iniciar os probes java. Agora, a chamada do sistema AIX para iniciar os probes java permite que eles sejam iniciados. Agora, o nome do processo é exibido nos sistemas AIX como
      full_command_to_start_java_probe
      em vez de
      nimbus(probename)
      .
  • O código de saída de pré-instalação do controlador é interpretado corretamente.
    • Os códigos de saída de pré-instalação são:
      • 0 – OK
      • 1 - avisar, mas continuar
      • 2 - avisar e cancelar esta seção
      • 3 - avisar e cancelar o restante da instalação
  • O controlador lida com o reinício do probe sem travar.
    • O robô v7.70 travava quando todas as condições a seguir eram verdadeiras:
      • Um probe estava em execução.
      • O robô tinha probes
        start_after
        que não foram instalados.
      • O controlador reiniciava seus probes devido a alterações nas configurações da origem ou de
        marketplace
        .
GA
Junho de 2015
7.70
Importante
: as opções do modo de comunicação SSL se tornaram mais efetivas com o lançamento do controlador v7.70. O controlador cria o arquivo de certificado 
robot.pem
 durante a inicialização. O arquivo permite a comunicação criptografada pela camada de transporte do OpenSSL. O tratamento do arquivo de certificado 
robot.pem
 foi alterado. Alterações no tratamento causam impacto na comunicação para:
  • Hubs definidos com o modo 0 (sem criptografia)
  • Hubs definidos com o modo 2 (apenas SSL)
  • Componentes gerenciados pelo hub
O que há de novo:
  • Os marcadores de usuário são propagados pelo hub e pelo controlador.
    Os alarmes e mensagens do hub e do controlador agora contêm marcadores de usuário. Anteriormente, o hub e o controlador liam os marcadores de usuário
    os_user1
    e
    os_user2
    do arquivo 
    robot.cfg
    . Agora, o hub lê os marcadores de usuário do arquivo 
    hub.cfg
    . A seção
    Configuração geral
    na UI de configuração do hub do Console de administração permite que os usuários especifiquem
    os_user1
    e
    os_user2
    . Em um sistema de hub, o spooler do hub para o probe adiciona os marcadores de usuário aos alarmes e mensagens do probe. Em um sistema de robô, o spooler do robô adiciona os marcadores de usuário.
A opção
os_user_include
, que permitia que o hub lesse os marcadores de usuário do arquivo
robot.cfg
, foi removida do hub v7.70. Os hubs e robôs na v7.70 não leem os marcadores de usuário do arquivo 
robot.cfg
. Se o robô do hub tinha marcadores de usuário definidos, eles permanecerão no arquivo
robot.cfg
 após a atualização, mas são ignorados. Para adicionar os marcadores de usuário aos alarmes e mensagens do probe do hub, especifique os marcadores de usuário no arquivo 
hub.cfg
.
  • Pacote incluído na distribuição do CA UIM 8.2.
Defeitos corrigidos:
  • As perdas de memória existentes foram resolvidas
  • Tentativas de salvar as alterações na configuração do robô quando o sistema de arquivos está cheio mantêm a configuração original.
  • O controlador não atribui probes às portas usadas pelos encapsulamentos de hub. As portas são atribuídas às interfaces corretas com base no modo de vinculação rígida.
  • O robô instala corretamente os arquivos do pacote no zLinux.
  • O robô para todos os processos filho ao encerrar.
  • Os robôs configurados para
    proxy_mode
    retornam ao seu hub pai designado após tolerância a falhas.
  • Se uma porta disponível não pudesse ser encontrada, o robô poderia consumir 100% da CPU.
  • O probe hdb poderia travar no Windows devido a problemas com a configuração do logmon.
  • Problemas quando o modo do robô era alterado de passivo para ativo.
GA
Março de 2015
7.63
  • OpenSSL 1.0.0m
  • Removida uma condição potencial de falha durante o encerramento.
  • Melhorias nas verificações de portas livres em várias circunstâncias.
  • Pacote incluído na distribuição do CA UIM 8.1.
GA
Dezembro de 2014
7.62
  • O retorno de chamada
    get_info
    inclui informações de endereço MAC para AIX, Solaris e HP-UX (além do Linux e Windows).
  • Resolvido o problema de despejo de memória ao desligar o controlador
  • Corrigido um defeito que fazia o robô sempre remover o registro do hub no desligamento.
  • Resolvido uma falha de soquete no retorno de chamada de
    get_info
    no Linux.
  • Pacote incluído na distribuição do CA UIM 8.0
GA
Novembro de 2014
7.60
  • Novos instaladores do robô nativo e suporte de
    ADE
    para AIX e zLinux.
  • Robô 7.60 para zLinux
  • A primeira porta do probe do robô assume 48000 como padrão
  • Pacote incluído na distribuição do NMS 7.60
GA
Junho de 2014
7.05
  • Pacote incluído na distribuição do NMS 7.50
GA
Março de 2014
7.10
  • Adicionado suporte para o Microsoft Windows Server 2012 e Microsoft Windows 8.
  • Removida a dependência do .NET framework 2.0
  • Integrada a instalação do Visual C++ 2008
  • Pacote incluído nas distribuições do NMS 7.00 e 7.10
GA
Dezembro de 2013
Considerações
  • Quando um robô é atualizado, é recomendável atualizar também os plugins do controlador, como o attr_publisher. Ele é obrigatório no caso de uma atualização de robô de uma versão mais antiga para a 7.97. Caso contrário, attr_publisher não funcionará.