O arquivo bfagent.conf armazena as configurações de 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 apenas para estas condições:
- Agentes executando no Windows®
- Agentes executando em modo independente no UNIX® ou Linux® quando a opção -s na inicialização for usada.
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.
Por 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 completo. 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 superservidor, como inetd ou xinetd, use outro método para controlar o acesso. É possível desejar usar um firewall, wrappers TCP (hosts.allow e hosts.deny) ou recursos de filtragem integrados de xinetd.
- bind
- Esta configuração permite especificar um endereço de ligação explícito para o agente. Isto, junto com a configuraçã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 em agentes que são iniciados pela arquitetura de serviço do
sistema, como inetd, xinetd ou launchd.
- ccviewroot root-path
- Esta configuração especifica a raiz de visualização padrão para este host. Consulte a documentação do ClearCase sobre init para obter mais informações.
Os padrões internos são os seguintes:
- command_output_cache size
- Esta configuraçã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 quantas
saídas 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 configuração é usada somente com agentes no Windows.
Esta configuração permite que o agente funcione em um host Windows usando o cygwin, um ambiente semelhante ao Linux. Ao
usar o cygwin, uma série de ferramentas do Linux fica disponível para o agente.
Quando você usa esta configuração, é possível configurar cygwin_script_magic e também as configurações shell. O exemplo mostra uma forma de definir estas configurações:
cygwin
shell C:\cygwin\bin\bash.exe --login -c "%s"
cygwin_script_magic #!/bin/bash
A configuração da shell deve corresponder à sua instalação de Cygwin.
- cygwin_script_magic
Esta configuração é usada somente com agentes no Windows quando o cygwin estiver
configurado.
Esta configuraçã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 será 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 manipular 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 deverá converter os dados para a codificação correta das
configurações 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 configuraçã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 configuraçã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, em
UNIX ou Linux é necessário /usr/include/dlfcn.h. Esses
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 somente para a execução do agente como um serviço independente nos sistemas operacionais UNIX ou Linux (bfagent
-s). Esta configuração faz o agente usar AI_ADDRCONFIG ao chamar getaddrinfo() para selecionar uma interface de atendimento. Por padrão, AI_ADDRCONFIG não é usado.
Se você usar esta configuraçã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.
- jcl_submit_user user:encoded-password
- O Monitor de Tarefas requer credenciais válidas para submeter uma tarefa. Para especificar o nome de usuário e a senha para o usuário que
submeterá a tarefa ao JES, é necessário o parâmetro jcl_submit_user.
Para gerar uma senha codificada, execute o bfagent -e [Senha]
a partir de um shell do z/OS e cole o valor que o agente exibir, juntamente com o ID do usuário
nesta configuração.
- job_monitor_port
- O Monitor de Tarefas se comunica pela porta 6715 por padrão. O Rational Build Agent usará
este valor como padrão a menos que seja especificado um número de porta diferente.
- lang lang-code
Use essa configuração apenas quando o Console de Gerenciamento não
fornecer um idioma válido.
Esta definição especifica o idioma que o agente usa para escrever mensagens e saídas de comandos. Normalmente isso não é configurado explicitamente porque
o agente usa o idioma que o Console de Gerenciamento especifica. Entretanto, configurar o idioma pode ser útil se o código do idioma
desejado não estiver disponível no computador.
Essa configuração é útil também como backup, caso o Console de Gerenciamento falhe ao
se comunicar em um idioma ou se comunicar em um idioma inválido.
O padrão interno é en, como se ele fosse explicitamente configurado como mostrado a seguir:
- 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. Na resolução de problemas, o arquivo pode ser comparado com as etapas
conforme elas são exibidas no Console de Gerenciamento.
Nota: Não use esta definição para operações típicas.
- locale locale-code.charset-code
Esta configuração é usada somente com sistemas operacionais UNIX e
Linux. O Windows trata códigos de idiomas de forma
diferente.
Esta definição especifica o idioma e o conjunto de caracteres multibyte que os aplicativos localizados usam. Esta configuração funciona através da configuraçã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, em 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 configuração é uma conveniência. Esta configuraçã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 configuraçã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 atente, não o nome do usuário usado para efetuar login.
Esta configuraçã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 os sistemas UNIX que não funcionam com PAM.
- Quando a execução do agente com privilégios administrativos não por permitida por causa de políticas de segurança.
Para configurar um login para o agente:
- Para criar uma autenticação de servidor que usa um nome de usuário e uma senha.
No Console de Gerenciamento, clique em.
- Para este exemplo, o nome de usuário é build e a senha é MySecretPassword.
- Crie um servidor que usa o agente. Associe a autenticação de servidor com este servidor no campo Autenticação.
- 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
- No bfagent.conf, configure magic_login para usar o nome de usuário e a senha codificados desejados.
magic_login build:eca0b7f2f4fbf110f7df570c70df844e1658744a4871934a
- Inicie o agente.
- 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 configuraçã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 significativa.
- 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 somente com agentes em execução nos sistemas UNIX e
Linux.
Esta configuraçã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 configuração é tipicamente usada com HP/UX e
z/OS. É possível também usar dois outros métodos para ajudar a evitar este tipo de bloqueio:
- Use uma shell alternativa.
- Use a configuração nologonshell
A configuraçã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 configuração, teste completamente antes de implementar a tarefa em um ambiente de produção.
- nologonshell
Use esta configuração somente com agentes em execução no UNIX ou no
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 configuração é frequente 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, os métodos padrão de solicitação de que a shell usada seja uma shell normal em vez de uma shell de logon. Isto pode não funcionar em todas as plataformas e, nestes casos, a configuração shellflag pode ser usada para passar sinalizadores ao shell para modificar o comportamento.
Tais comportamentos não são desejáveis para o agente, pois ele executar como um usuário sem ser um usuário interativo.
Notas: - O sistema Mac OS X 10.5 usa /bin/bash, que não responde ao nologonshell. Use shellflag
-l.
- O sistema operacional z/OS sempre usa o script /etc/profile para as shells de logon e para as
shells que não são de logon.
Pode ser possível 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 somente com agentes em execução no modo independente em UNIX ou Linux quando você emite a opção -s na inicialização.
Esta definição especifica a porta que o agente usar para atender às conexões com o Console de Gerenciamento.
- Agentes executando em modo independente em 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 configurações seguintes sejam usadas:
- Se a configuração cygwin for usada, o padrão será shell
C:\cygwin\bin\bash.exe --login -c "%s"
- Se a configuração cygwin não for usada, o padrão será shell cmd.exe /u /q /c "%s"
- UNIX ou Linux: A configuração da shell para a conta do
usuário ou /bin/sh se a shell do usuário não puder ser determinada.
Observe que você não pode especificar os parâmetros nesta configuração, mas é possível usar a configuraçã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
É possível substituir esta configuração de dentro de uma etapa. Uma etapa que inicia com uma linha contendo #! substitui a configuração da shell e a configuração nologonshell é usada para executar os comandos step.
- shell_compatible_undef_vars
- Esta configuração força que a representação de variáveis indefinidas seja uma cadeia vazia. Se não for configurada, 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 somente com agentes em execução em UNIX e
Linux.
Use esta configuração se parecer que os comandos estão misturados. Algumas shells no Red
Hat Enterprise Linux exigem esta configuração.
A configuraçã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 somente com agentes em execução em UNIX e
Linux.
Esta configuraçã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]
- Configure como true para exigir a autenticação de cliente quando uma conexão é feita para o agente. Se for verdadeiro, o certificado de mecanismo do Rational Build Agent deve 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 executar com 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. É possível ativar o agente para criptografar esta senha usando sua própria chave ou a chave do servidor do Rational Build Agent.
- 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 Rational Build Agent.
- update_path caminho
Esta configuração identifica o caminho completo para o executável do Rational Build Agent. A configuraçã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 configuração é ignorada nos agentes do Windows. O caminho de atualização é assumido a partir das chaves de registro. As chaves são configuradas durante a instalação do agente.