Referência do bfagent.conf

O arquivo bfagent.conf armazena configurações para como o Rational Build Agent é executado. O arquivo está no mesmo diretório que o arquivo executável do bfagent.

O arquivo lista todas as configurações e padrões internos. As configurações inativas estão comentadas.

Configurações
activity_log caminho
Ativa o registro de atividades. As informações são anexadas ao arquivo especificado por caminho. O caminho deve existir e o usuário do agente deve ter permissão de gravação para ele.
Nota: O agente não reporta um erro se o caminho não existir ou se ele não puder gravar no arquivo.
Importante: Não há limite de tamanho do arquivo. O arquivo deve ser manualmente excluído. Esta configuração é destinada a ser usada temporariamente para depuração do agente. Ela não é destinada a ser um log permanente para um agente de trabalho.
allow IP-address-or-range [...]
Use esta configuração para estas condições somente para:
  • Agentes executando no Windows®
  • Agentes em execução em modo independente no UNIX® ou Linux® quando é usada a opção -s na inicialização.

Esta configuração limita as conexões com o agente. As conexões são permitidas somente a partir do endereço IP que corresponde ao IP-address-or-range. Pelo padrão, as conexões são permitidas a partir de todos os endereços.

Especifique um ou ambos os itens:
  • Endereço IP: Um endereço IPv4 ou IPv6 completamente qualificado. Por exemplo, para IPv4, 255.192.192.003. O endereço IP específico é permitido.
  • Intervalo de endereços IP: Um endereço IPv4 ou IPv6 parcialmente qualificado. Os seguintes exemplos estão corretos para IPv4: 192.168 ou 192.168.63. Todos os endereços IP que correspondem a esta qualificação são permitidos.
Nota: Se você estiver executando o agente em um superserver como inetd ou xinetd, use outro método para controlar o acesso. Você pode desejar usar um firewall, wrappers TCP (hosts.allow e hosts.deny) ou recursos de filtragem integrados de xinetd.
bind
Esta definição permite que o usuário especifique um endereço de bind explícito para o agente. Isto, junto com a definição "port", determina como o agente atenderá às conexões quando for iniciado com a opção de linha de comando -s. O valor especificado no arquivo bfagent.conf forçará o agente a se conectar ao endereço de host local IPv4; desta forma, o agente receberá somente conexões a partir de um console que esteja na mesma máquina. Exemplo: bind 255.192.192.003
Nota: Ele não tem efeito sobre agentes Windows ou Unix que são iniciados pela arquitetura de serviço do sistema como inetd, xinetd ou launchd.
ccviewroot root-path
Esta definição especifica a raiz de visualização padrão para este host. Consulte a documentação do ClearCase sobre init para obter informações adicionais. Os padrões internos são os seguintes:
  • Windows: ccviewroot M:
  • UNIX ou Linux: ccviewroot /view
command_output_cache size
Esta definição faz com que o agente armazene a saída no cache até que ela atinja o tamanho especificado em bytes. O padrão interno é não armazenar em cache. Use um cache para melhorar significativamente o desempenho do agente e reduzir a sobrecarga da rede. O tamanho do cache depende de quanta saída esses comandos produzirão.

Valor mínimo: 2048. Um valor de 2048 é usado internamente se a definição for menor do que isso.

cygwin

Esta definição é usada somente com agentes no Windows.

Esta configuração permite que o agente funcione em um host Windows usando Cygwin, um ambiente como o Linux. Ao usar Cygwin, várias ferramentas do Linux estão disponíveis para o agente.

Quando você usar esta definição, talvez seja necessário configurar cygwin_script_magic, além das definições da shell. O exemplo mostra uma forma de configurar estas definições: :
cygwin
shell C:\cygwin\bin\bash.exe --login -c "%s"
cygwin_script_magic #!/bin/bash

A definição da shell deve corresponder à sua instalação de Cygwin.

cygwin_script_magic

Esta definição é usada somente com agentes no Windows quando cygwin é configurado.

Esta definição especifica a linha #! a ser usada na execução das etapas. O padrão é #!/bin/bash.

default_logon_domain
Especifica o domínio a ser usado quando uma solicitação de autenticação não incluir um domínio. Se não for especificado, o domínio da máquina do agente é usado.
disable_telnet
Para obter os melhores resultados, use telnet para testar a conexão do agente.
Para o agente, há algumas sobrecargas de processamento integradas associadas ao processamento e manuseio correto de sequências de controle telnet.
Use esta definição para desativar o agente de manuseio de códigos de caracteres telnet especiais que podem melhorar um pouco o desempenho. Em ambientes de produto, use esta definição para se beneficiar da melhoria de desempenho.
disable_transcode
Desativa o processamento que o agente executa para converter dados internacionais quando o sistema operacional não está usando a codificação UTF-8. Para evitar codificações mistas e distorção de dados, use UTF-8 para o sistema operacional do agente.
Se o sistema operacional não usar a codificação UTF-8, o agente deve converter os dados para a codificação correta para a configuração do código de idioma do sistema operacional.
Se o seu sistema operacional não usar UTF-8, use esta definição para obter os melhores resultados e melhorar o desempenho do agente.
enable_agent_dll
Esta definição ativa o rastreio de processo da DLL, que é uma ferramenta de depuração.
env_recursion_limit number-of-recursions
Define o limite de recursão de substituição de variável para pré-análise. Se não for configurado, o limite é 32.
extensions
Esta definição especifica os caminhos para as bibliotecas de funções externas. As funções podem ser usadas como comandos de ponto em uma etapa. Se esta definição não for especificada, as bibliotecas externas não são carregadas.

Durante a análise, o primeiro token no comando step é assumido com o nome da função. O segundo token é uma cadeia, e o terceiro é um valor de tempo limite de número inteiro (em segundos).

Requisito: Suporte ao utilitário de carga dinâmico no sistema operacional. Por exemplo, no UNIX ou Linux, você precisa de /usr/include/dlfcn.h. Estes valores padrão são usados internamente.
  • UNIX ou Linux: /usr/local/bin/bfextensions.so
  • Windows: c:\program files\ibm\build forge\agent\bfextensions.dll
getaddrinfo_using_addrconfig
Esta configuração é usada apenas para executar o agente como um serviço independente em sistemas operacionais UNIX ou Linux (bfagent -s). Esta definição faz o agente usar AI_ADDRCONFIG ao chamar getaddrinfo() para selecionar uma interface de atendimento. Pelo padrão, AI_ADDRCONFIG não é usado.

Se você usar esta definição, o agente ignora as interfaces que não possuem um endereço adequadamente configurado. Ele atende somente a interfaces que possuem um endereço adequadamente configurado.

lang lang-code

Esta definição especifica o idioma que o agente usa para escrever mensagens e saídas de comandos.

O padrão interno é en, como se ele fosse explicitamente configurado como mostrado a seguir:

lang en
leave_tmp_file

Use esta definição somente enquanto estiver resolvendo problemas.

Esta definição faz com que o arquivo temporário usado para que os comandos step sejam mantidos, em vez que serem excluídos após a execução do comando.

Nota: Não use esta definição para operações típicas.
locale locale-code.charset-code

Esta configuração é usada apenas com sistemas operacionais UNIX e Linux. O Windows manipula códigos de idioma de forma diferente.

Esta definição especifica o idioma e o conjunto de caracteres multibyte que os aplicativos localizados usam. Esta definição funciona através da definição da variável de ambiente LANG para contexto do agente.

Para configurar o agente para tratar a saída de comando como inglês dos Estados Unidos UTF-8, use o código de idioma UTF-8 para seu sistema operacional. Por exemplo, no Linux, use a seguinte representação.
locale en_US.UTF-8

Para determinar a representação correta do código de idioma UTF-8 para seu sistema operacional, execute o comando locale -a.

Se esta definição não for especificada, o agente usa o código do idioma do sistema operacional. Esta definição é uma conveniência. Esta definição é especialmente útil se o código de idioma padrão do sistema operacional não é o código de idioma que deseja que o agente use. A definição é especialmente útil se a alteração do código de idioma do sistema para atender aos requisitos não for prática.

magic_login user:encoded-password

O agente tipicamente usa privilégios administrativos como root ou admin para efetuar logon no sistema operacional. A definição magic_login é uma alternativa à autenticação de sistema padrão. Com esta definição, o sistema pode autenticar seu login com um único nome de usuário e senha.

Se o agente estiver executando como usuário root ou admin, esta definição é ignorada e a autenticação normal é tentada.

O agente executa todos os comandos usando as permissões do usuário que iniciaram o agente, não o nome do usuário usado para efetuar login.

Esta definição é usada somente nestas situações:
  • A execução do agente com privilégios administrativos não é possível. Por exemplo, use esta configuração com sistemas UNIX que não funcionam com o PAM.
  • Quando a execução do agente com privilégios administrativos não for permitida por causa de políticas de segurança.
Para configurar um login para o agente:
  1. Para criar uma autenticação de servidor que usa um nome de usuário e uma senha.
  2. Para este exemplo, o nome de usuário é build e a senha é MySecretPassword.
  3. Crie um servidor que usa o agente. Associe a autenticação de servidor com este servidor no campo Autenticação.
  4. Gere uma senha codificada para o agente. No diretório de instalação para o agente, execute bfagent -P com a senha que você escolher.

    Uma senha codificada com hash SMD5 é devolvida, da seguinte forma:

    bfagent -P "MySecretPassword"
    eca0b7f2f4fbf110f7df570c70df844e1658744a4871934a
  5. No BFAgent.conf, configure magic_login para usar o nome de usuário e a senha codificados desejados.
    magic_login build:eca0b7f2f4fbf110f7df570c70df844e1658744a4871934a
  6. Inicie o agente.
  7. Teste a conexão do servidor. Em Servidores, selecione o servidor e. em seguida, clique em Testar Servidor.
map drive-and-user-spec[; ...]
Esta definição especifica uma unidade mapeada. Alguns sistemas podem exigir mapeamentos de unidade. Por exemplo, um mapeamento de unidade pode ser necessário porque uma shell é executada a partir de uma unidade compartilhada. Mapeamentos especificados no agente são executados antes de os mapeamentos especificados pelas variáveis de ambiente _MAP no Console de Gerenciamento. Este exemplo ilustra dois mapeamentos de unidade:
map X:=//host1/share;Z:=//host2/share(username,password)
map_drive_is_failure
Quando especificada, esta definição faz com que uma etapa falhe depois de encontrar uma especificação de unidade não mapeada, antes da execução da etapa. Se esta definição não for especificada, as etapas ignoram falhas de unidade e tentam executar a etapa. Neste caso, assegure-se de que a falha gere uma mensagem de erro compreensível.
no_preparse_command
Esta definição desativa a análise de expansão de variável que o agente tipicamente executa em um comando antes de passar o comando para a shell. Consulte também a variável de ambiente _NO_PREPARSE_COMMAND, que pode ser usada para um único projeto ou etapa.
no_pty

Esta configuração é usada apenas com agentes que estão em execução em sistemas UNIX ou Linux.

Esta definição pode ser usada para ajudar a evitar que a shell do sistema bloqueie quando a shell interagir com o pseudo-terminal do agente. Esta definição é tipicamente usada com HP/UX e z/OS . Você também pode usar dois outros métodos para ajudar a evitar este tipo de bloqueio:
  • Use uma shell alternativa.
  • Use a definição nologonshell
A definição no_pty desativa a alocação do pseudo-terminal.
Nota: O uso de no_pty afeta alguns comandos. Por exemplo, o comando ls retorna saída em uma única coluna em vez de em três colunas. Se você usar esta definição, teste completamente antes de implementar a tarefa em um ambiente de produção.
nologonshell

Use esta configuração apenas com agentes que estão em execução em sistemas UNIX ou Linux.

Esta configuração faz com que a shell na qual o agente executa seja uma shell normal, não uma shell de logon. Esta definição ocorre frequentemente nestes casos:
  • As shells de logon fornecem saída detalhada.
  • As shells de logon mudam as configurações de ambiente de formas indesejadas.
  • As shells de logon tentam se comunicar interativamente com o usuário.

Quando definida, são usados métodos padrão de solicitação de que a shell seja uma shell normal em vez de uma shell de logon. Isto pode não funcionar em todas as plataformas e, nestes casos, a definição shellflag pode ser usada para passar sinalizadores à shell para modificar seu comportamento.

Tais comportamentos não são desejáveis para o agente, pois ele executa como um usuário sem ser um usuário interativo.
Nota: O sistema Mac OS X 10.5 usa /bin/bash, que não responde ao nologonshell. Use shellflag -l.
Nota: O sistema operacional z/OS sempre usa o script /etc/profile tanto para shells de logon quanto para shells que não são de logon. Você pode precisar alterar o conteúdo do script ou usar outra shell se o seu comportamento não funcionar bem com o agente.

Consulte também a definição shellflag. Os sinalizadores podem ser usados para alterar o comportamento do script de logon.

password_encrypt_module dll_path;conf_path
Necessário para ativar o SSL no agente. Ele especifica caminhos para uma DLL e um arquivo de configuração.
  • dll_path é o caminho para bfcrypt.dll (tipicamente é ./bfcyrpt.dll).
  • conf_path é o caminho para bfpwcrypt.conf (tipicamente é ./bfcrypt.conf).
port port-number-or-range [...]

Esta configuração é usada apenas com agentes que estão em execução em modo independente no UNIX ou Linux durante a emissão da opção -s na inicialização.

Esta definição especifica a porta que o agente usa para atender às conexões com o Console de Gerenciamento.
  • Agentes em execução em modo independente no UNIX ou Linux (opção -s na inicialização).
Especifica a porta que o agente usa para atender às conexões com o Console de Gerenciamento.
Nota: A porta é configurada como 5555 pelo padrão. Para UNIX ou Linux, a configuração está em /etc/services.
shell shell_name [opções]
Esta definição especifica a shell padrão. Os padrões internos são os seguintes:
  • Windows: shell cmd.exe /q /c "%s" a menos que as seguintes definições sejam usadas:
    • Se a configuração cygwin for usada, o padrão será shell C:\cygwin\bin\bash.exe --login -c "%s"
    • Se a definição cygwin não for usada, o padrão será shell cmd.exe /u /q /c "%s"
  • UNIX ou Linux: O shell configurado para a conta do usuário ou /bin/sh, se o shell do usuário não puder ser determinado. Observe que você não pode especificar os parâmetros nesta definição, mas é possível usar a definição shellflag para passá-los. A shell do agente automaticamente força o padrão para ser uma shell de logon através da inserção de um hífen. Por exemplo, /bin/ksh é enviado como -ksh. Se shell for explicitamente definida, então nologonshell é implicitamente definida. Consulte nologonshell.
  • System i: Configure o valor da shell como /bin/sh

Você pode substituir esta configuração de dentro de uma etapa. Uma etapa que inicia com uma linha contendo #! substitui a definição da shell e a definição nologonshell é usada para executar os comandos step.

shell_compatible_undef_vars
Esta definição força que a representação de variáveis indefinidas seja uma cadeia vazia. Se não for definida, a representação é o nome da variável para variáveis de formato $VAR, ${VAR}, ou %VAR% e a cadeia vazia para $[VAR].
shellarg

Esta configuração é usada apenas com agentes que estão em execução em sistemas UNIX ou Linux.

Use esta definição se parecer que os comandos estão misturados. Algumas shells no Red Hat Linux Enterprise exigem esta definição.

A definição muda a forma como o script de comando é passado para a shell. Normalmente o script é passado através da entrada padrão:
   /bin/sh < /tmp/bfshellscript.sh
Esta configuração faz com que os scripts sejam executados passando-os como parâmetros:
/bin/sh /tmp/bfshellscript.sh
shellflag sinalizador

Esta configuração é usada apenas com agentes que estão em execução em sistemas UNIX ou Linux.

Esta definição inclui um sinalizador quando uma shell está em execução. Somente um sinalizador pode ser especificado. Ela é tipicamente usada para desativar o processamento do script rc para reduzir a saída ou processamento indesejado.

Exemplos:
  • csh e derivativas: use shellflag -f para desativar o processamento do script rc.
  • bash: use shellflag –-noprofile para desativar o processamento do script de perfil.
ssl_ca_location caminho
Especifica o arquivo keystore que contém a autoridade de certificação. Se o agente executar com um serviço, use um caminho absoluto.
ssl_cert_location caminho
Especifica o keystore que contém o certificado privado. Se o agente executar com um serviço, use um caminho absoluto.
ssl_client_authentication [true | false]
Defina como true para exigir a autenticação de cliente quando uma conexão é feita para o agente. Se true, o certificado do mecanismo Build Forge deverá ser incluído no keystore da autoridade de certificação do agente.
ssl_cipher_group [grouplist | ALL]
Especifica grupos de códigos individuais a serem usados. Pode ser definido como ALL.
ssl_cipher_override cyphers
Substitui o grupo de códigos. Especifica os códigos a serem usados.
ssl_key_location caminho
Especifica o arquivo keystore que contém a chave. Se o agente for executado como um serviço, use um caminho absoluto.
ssl_key_password password
Senha para a chave. Esta propriedade é armazenada em texto não-criptografado por padrão. Você pode manusear o agente para criptografar esta senha usando sua própria chave ou chave do servidor do Build Forge .
ssl_protocol protocolo
O protocolo de handshake SSL a ser usado: SSL, SSLv2, SSLv3, SSL_TLS, TLS ou TLSv1. O protocolo deve corresponder ao protocolo usado pelo servidor do Build Forge .
update_path caminho
Esta definição identifica o caminho completo para o agente executável do Build Forge . A definição é estabelecida automaticamente durante a instalação. O diretório é um diretório padrão para o sistema operacional ou o diretório de instalação que você especifica.
Nota: Esta definição é ignorada nos agentes do Windows. O caminho de atualização é assumido a partir das chaves de registro. As chaves são definidas durante a instalação do agente.
win_reexec_after_auth
Inclua esta definição se precisar executar os comandos do agente em um sistema de arquivos de compartilhamento de rede usando credenciais de autenticação do servidor do Build Forge . Por exemplo, para modificar arquivos em uma visualização dinâmica do ClearCase, o agente deve acessar arquivos do ClearCase em um sistema de arquivo compartilhado em rede.
O agente Build Forge é inicializado primeiramente com credenciais de conta do sistema Windows. Para executar comandos, o agente autentica-se posteriormente no Windows usando credenciais de autenticação de servidor Build Forge.
Sem esta definição, o compartilhamento de rede reconhece somente as credenciais iniciais da conta de sistema do Windows e ignora as credenciais de autenticação do servidor subsequentes, que são necessárias para acessar e gravar em arquivos no sistema de arquivos de compartilhamento de rede.
O win_reexec_after_auth inicia um novo processo depois de a autenticação com Windows novamente usando as credenciais de autenticação de servidor e força o sistema de arquivos compartilhado a reconhecer as credenciais modificadas.
Quando você usa a definição win_reexec_after_auth, o agente é executado como um serviço e não distingue entre comandos que acessam os arquivos de compartilhamento da rede e aqueles que não, para que seja possível observar um impacto no desempenho.

Feedback

Isto ajudou? Você pode fornecer feedback em Jazz.net (registro necessário): Comment in the forums ou submit a bug