Le fichier bfagent.conf stocke les paramètres d'exécution de Rational Build
Agent. Il se trouve dans le même répertoire que le fichier exécutable bfagent.
Ce fichier répertorie tous les paramètres et valeurs par défaut internes. Les
paramètres inactifs sont placés en commentaire.
- Paramètres
- activity_log chemin
- Active la consignation des activités. Les informations sont ajoutées à la fin du
fichier spécifié par chemin. Ce chemin doit exister et l'utilisateur de l'agent
doit y avoir accès en écriture.
Remarque : L'agent ne signale pas d'erreur si le chemin
n'existe pas ou qu'il ne peut pas écrire dans ce fichier.
Important : La taille de ce fichier n'est pas limitée. Ce fichier doit être supprimé manuellement. Ce
paramètre doit être utilisé de manière temporaire pour le débogage de l'agent. Il ne
s'agit pas d'un journal permanent pour un agent actif.
- allow IP-address-or-range [...]
N'utilisez ce paramètre que dans les cas suivants :
- Agents fonctionnant sous Windows
- Agents fonctionnant en mode autonome sous UNIX ou Linux lorsque l'option -s est
utilisée au démarrage.
Ce paramètre limite le nombre de connexions à
l'agent. Les connexions ne sont autorisées qu'à partir des adresses IP qui correspondent
à l'adresse IP ou à la plage d'adresses IP.
Par défaut, les connexions sont autorisées à partir de toutes les adresses.
Spécifiez l'un des éléments ou les deux :
- Adresse IP : Adresse IPv4 ou IPv6 complète. Par exemple, pour IPv4,
255.192.192.003. L'adresse IP spécifique est autorisée.
- Plage d'adresses IP : Adresse IPv4 ou IPv6 partiellement qualifiée.
Ces exemples sont corrects pour IPv4 : 192.168 ou 192.168.63. Toutes les adresses IP
correspondant à cette qualification sont autorisées.
Remarque : Si vous exécutez
l'agent sur un super serveur tel qu'inetd ou xinetd,
utilisez une autre méthode pour contrôler les accès. Vous pouvez utiliser un pare-feu, des encapsuleurs TCP (hosts.allow
et hosts.deny) ou la fonctionnalité de filtrage intégrée de xinetd.
- bind
- Ce paramètre permet de spécifier une adresse de liaison explicite
pour l'agent. Ce paramètre, avec le paramètre "port", détermine comment l'agent écoutera les
connexions lorsqu'il est démarré avec l'option de ligne de commande -s. La valeur
indiquée dans le fichier bfagent.conf force l'agent à se lier à l'adresse IPv4 ; ainsi,
l'agent ne recevra que les connexions d'une console qui se trouve sur la même machine.
Exemple : bind 255.192.192.003
Remarque : Il n'a aucun effet sur les agents
démarrés par l'architecture des services du système, telle
qu'inetd, xinetd ou
launchd.
- ccviewroot root-path
- Ce paramètre spécifie la racine de la vue par défaut de cet hôte. Pour plus
d'informations, reportez-vous à la documentation ClearCase sur init. Les valeurs par
défaut internes sont les suivantes :
- command_output_cache size
- Lorsque ce paramètre est spécifié, l'agent place la sortie en mémoire cache jusqu'à
ce qu'elle atteigne la taille spécifiée en octets. Par défaut la sortie n'est pas placée
en mémoire cache.
L'utilisation d'une mémoire cache peut considérablement améliorer les performances de
l'agent et réduire le temps système du réseau. La taille de la mémoire cache dépend du
nombre de sorties générées par les commandes.
Valeur minimale : 2048. La valeur 2048
est utilisée en interne si le paramètre est inférieur à cette valeur.
- cygwin
Ce paramètre n'est utilisé qu'avec les agents sous Windows.
Ce paramètre
permet à l'agent de fonctionner sur un hôte Windows à l'aide de cygwin, un environnement
similaire à Linux. Si cygwin est utilisé, un certain nombre d'outils Linux sont
disponibles pour l'agent.
Lorsque vous utilisez ce paramètre, il se peut que
vous deviez également définir les paramètres cygwin_script_magic et shell. L'exemple
illustre l'une des manières de configurer ces paramètres :
cygwin
shell C:\cygwin\bin\bash.exe --login -c "%s"
cygwin_script_magic #!/bin/bash
Le paramètre de shell doit correspondre
à celui de votre installation de Cygwin.
- cygwin_script_magic
Ce paramètre n'est utilisé qu'avec les agents sous Windows si cygwin est
défini.
Ce paramètre spécifie la ligne #! à utiliser lors de
l'exécution des étapes. La valeur par défaut est #!/bin/bash.
- default_logon_domain
- Spécifie le domaine à utiliser lorsqu'une demande d'authentification n'inclut pas de
domaine. S'il n'est pas spécifié, le domaine de la machine de l'agent est utilisé.
- disable_telnet
- Pour de meilleurs résultats, utilisez telnet pour tester la connexion de l'agent.
- Pour l'agent, un temps système de traitement intégré est associé au traitement
approprié des séquences de contrôle telnet.
- Utilisez ce paramètre pour empêcher l'agent de traiter les codes de caractère telnet
spéciaux et améliorer ainsi légèrement les performances. Dans les environnements de
produit, utilisez ce paramètre pour bénéficier de performances améliorées.
- disable_transcode
- Désactive le traitement effectué par l'agent pour convertir les données
internationales lorsque le système d'exploitation n'utilise pas le codage UTF-8. Pour
éviter les codages mixtes et l'altération de données, utilisez UTF-8 pour le système
d'exploitation de l'agent.
- Si le système d'exploitation n'utilise pas le codage UTF-8, l'agent doit convertir
les données au codage approprié pour les paramètres d'environnement local du système
d'exploitation.
- Si votre système d'exploitation n'utilise pas UTF-8, utilisez ce paramètre pour de
meilleurs résultats et des performances de l'agent améliorées.
- enable_agent_dll
- Ce paramètre permet le traçage du processus DLL, qui est un outil de débogage.
- env_recursion_limit number-of-recursions
- Définit la limite de récursivité des remplacements de variable pour la pré-analyse
syntaxique.
S'il n'est pas défini, la limite est 32.
- extensions
- Ce paramètre spécifie les chemins d'accès aux bibliothèques de fonctions externes.
Les fonctions peuvent être utilisées comme commandes précédées d'un point dans une étape. Si ce paramètre n'est pas spécifié, les bibliothèques externes ne sont pas chargées.
Lors de l'analyse syntaxique, le premier symbole de la commande d'avance pas à pas est
interprétée comme le nom de la fonction.
Le deuxième symbole correspond à une chaîne et le troisième, à un délai d'expiration
(nombre entier de secondes).
Condition requise : Prise en charge du
chargeur dynamique dans le système d'exploitation. Par exemple, dans UNIX ou Linux, vous
avez besoin du fichier /usr/include/dlfcn.h. Ces valeurs par défaut sont utilisées en
interne.
- UNIX ou Linux : /usr/local/bin/bfextensions.so
- Windows : c:\program files\ibm\build forge\agent\bfextensions.dll
- getaddrinfo_using_addrconfig
- Ce paramètre n'est utilisé que pour exécuter l'agent comme service autonome sur les
systèmes d'exploitation UNIX ou Linux (bfagent -s). Ce paramètre spécifie à l'agent
d'utiliser AI_ADDRCONFIG lors de l'appel de getaddrinfo() pour sélectionner une interface
d'écoute. Par défaut, AI_ADDRCONFIG n'est pas utilisé.
Si vous utilisez ce paramètre,
l'agent ignore les interfaces qui ne possède pas d'adresse correctement configurée. Il
n'écoute que les interfaces possédant une adresse correctement configurée.
- jcl_submit_user user:encoded-password
- Le moniteur de travaux requiert des données d'identification valides pour soumettre
un travail. Pour spécifier le nom d'utilisateur et le mot de passe de l'utilisateur qui
soumettra le travail à JES, vous devez utiliser le paramètre jcl_submit_user.
Pour générer un mot de passe codé, exécutez bfagent -e [Password]
à partir d'un shell z/OS et collez la valeur affichée par l'agent, avec l'ID utilisateur,
dans ce paramètre.
- job_monitor_port
- Job Monitor communique via le port 6715 par défaut. Rational Build Agent utilise
cette valeur comme valeur par défaut, sauf si vous spécifiez un autre numéro de port.
- lang code-lang
N'utilisez ce paramètre que si la console de gestion ne fournit pas de
langue valide.
Ce paramètre spécifie la langue utilisée par l'agent
pour écrire des messages et la sortie de la commande. En général, il n'est pas
défini de manière explicite car l'agent utilise la langue spécifiée par la console de
gestion. Toutefois, il peut être utile de définir la langue si l'environnement
local souhaité n'est pas disponible sur l'ordinateur.
Ce paramètre est également utile comme paramètre de secours au cas ou la console de
gestion ne parvient pas à communiquer une langue ou qu'elle en communique une non valide.
La valeur par
défaut interne est en, comme si ce paramètre était explicitement défini
de la sorte :
- leave_tmp_file
N'utilisez ce paramètre que pour l'identification et la résolution des incidents.
Si ce paramètre est utilisé, le fichier temporaire utilisé conserve les commandes
d'avance pas à pas à conserver au lieu de les supprimer après leur exécution. Lors de
l'identification et de la résolution d'incidents, ce fichier peut être comparé aux étapes
à mesure qu'elles sont affichées dans la console de gestion.
Remarque : N'utilisez pas ce paramètre pour des opérations standard.
- locale locale-code.charset-code
Ce paramètre n'est utilisé qu'avec les systèmes d'exploitation UNIX et Linux.
Windows gère les paramètres nationaux différemment.
Ce paramètre spécifie la
langue et le jeu de caractères multi-octets utilisés par les applications localisées. Ce
paramètre fonctionne en définissant la variable d'environnement LANG pour le contexte de
l'agent.
Pour configurer l'agent afin qu'il traite la sortie de la commande au
format UTF-8 anglais (Etats-Unis), utilisez les paramètres régionaux UTF-8 de votre
système d'exploitation. Par exemple, sous Linux, utilisez la représentation ci-après.
locale en_US.UTF-8
Pour déterminer la représentation appropriée des paramètres régionaux UTF-8 pour votre
système d'exploitation, exécutez la commande locale -a.
Si ce paramètre
n'est pas spécifié, l'agent utilise les paramètres régionaux du système d'exploitation. Ce paramètre est fourni par souci de commodité. Ce paramètre est particulièrement utile
si les paramètres régionaux du système d'exploitation ne correspondent pas à ceux que
vous souhaitez être utilisés par l'agent. Ce paramètre est particulièrement utile s'il
n'est pas pratique de modifier les paramètres régionaux du système pour répondre aux
exigences de l'agent.
- magic_login user:encoded-password
L'agent utilise généralement des droits d'administration tels que root ou admin
pour se connecter au système d'exploitation. Le paramètre magic_login permet de remplacer
l'authentification système standard. Avec de ce paramètre, le système peut authentifier
votre connexion à l'aide des seuls nom d'utilisateur et mot de passe.
Si l'agent
est exécuté en tant qu'utilisateur root ou admin, ce paramètre est ignoré et une
authentification normale est tentée.
L'agent exécute toutes les commandes à l'aide
des droits de l'utilisateur qui a démarré l'agent et non du nom d'utilisateur utilisé
pour se connecter.
Ce paramètre n'est utilisé que dans les cas suivants :
- Si l'exécution de l'agent avec les droits d'administration n'est pas possible.
Par exemple, utilisez ce paramètre avec les systèmes UNIX qui ne fonctionnent pas avec
PAM.
- Si l'exécution de l'agent avec les droits d'administration n'est pas autorisée en
raison de règles de sécurité.
Pour configurer une connexion pour l'agent :
- Créez une authentification serveur qui utilise un nom d'utilisateur et un mot de
passe.
Dans la console de gestion, cliquez sur .
- Pour cet exemple, le nom d'utilisateur est build et le mot de passe
est MySecretPassword.
- Créez un serveur qui utilise l'agent. Associez l'authentification du serveur à ce
serveur dans la zone Authentification.
- Générez un mot de passe chiffré pour l'agent. Dans le répertoire d'installation de
l'agent, exécutez bfagent -P avec le mot de passe de votre choix.
Un mot de passe en code haché SMD5 est renvoyé, comme suit :
bfagent -P
"MySecretPassword"
eca0b7f2f4fbf110f7df570c70df844e1658744a4871934a
- Dans bfagent.conf, définissez magic_login pour utiliser le nom
d'utilisateur et le mot de passe chiffré.
magic_login
build:eca0b7f2f4fbf110f7df570c70df844e1658744a4871934a
- Démarrez l'agent.
- Testez la connexion du serveur. Dans Serveurs, sélectionnez le
serveur, puis cliquez sur Test Server.
- map spéc-unité-et-utilisateur[; ...]
- Ce paramètre spécifie une unité mappée. Certains systèmes peuvent nécessiter de
mapper des unités. Par exemple, un mappage d'unités peut être requis car un shell est
exécuté à partir d'une unité partagée. Les mappages spécifiés sur l'agent sont effectués
avant ceux spécifiés par les variables d'environnement _MAP environment dans la console
de gestion. Cet exemple illustre deux mappages d'unités :
map
X:=//host1/share;Z:=//host2/share(username,password)
- map_drive_is_failure
- Si ce paramètre est spécifié, une étape échoue lorsqu'elle rencontre une
spécification d'unité non mappée avant d'être exécutée. Si ce paramètre n'est pas
spécifié, les étapes ignorent les incidents d'unité et tentent d'exécuter l'étape. Dans
ce cas, vérifiez que l'incident génère un message d'erreur significatif.
- no_preparse_command
- Ce paramètre désactive l'analyse syntaxique des extensions de variable que l'agent
effectue généralement sur une commande avant de transmettre cette dernière au shell. Voir
aussi la variable d'environnement _NO_PREPARSE_COMMAND, qui peut être utilisée pour un
seul projet ou une seule étape.
- no_pty
Ce paramètre n'est utilisé qu'avec les agents fonctionnant sur des systèmes UNIX
ou Linux.
Il peut être utilisé pour empêcher le shell du système de se verrouiller
lorsqu'il interagit avec le pseudo-terminal de l'agent. Ce paramètre est généralement
utilisé avec HP/UX et z/OS.
Vous pouvez également utiliser deux autres méthodes pour empêcher ce type de verrouillage
:
- Utilisez un autre shell.
- Utilisez le paramètre nologonshell
Le paramètre
no_pty
désactive l'allocation du pseudo-terminal.
Remarque : L'utilisation de no_pty affecte
certaines commandes. Par exemple, la commande ls renvoie la sortie dans une seule
colonne au lieu de trois. Si vous utilisez ce paramètre, effectuez des tests approfondis
avant de déployer le travail dans un environnement de production.
- nologonshell
N'utilisez ce paramètre qu'avec les agents fonctionnant sous UNIX ou Linux.
Si ce paramètre est spécifié, le shell exécuté par l'agent est un shell normal et non un
shell de connexion. Ce paramètre est souvent utilisé dans les cas suivants :
- Les shells de connexion offrent une sortie en mode prolixe.
- Les shells de connexion modifie les paramètres de l'environnement de manière non
souhaitable.
- Les shells de connexion tentent de communiquer de manière interactive avec
l'utilisateur.
Lorsque ce paramètre est défini, des méthodes standard
permettant de demander que le shell corresponde à un shell normal et non à un shell de
connexion sont utilisées. Cela risque de ne pas fonctionner sur toutes les plateformes et
dans de tels cas, le paramètre shellflag peut être utilisé pour transmettre des
indicateurs au shell afin de modifier son comportement.
Ces
comportements ne sont pas souhaitables pour l'agent, car ce dernier est exécuté en tant
qu'utilisateur non interactif.
Remarques : - Le système Mac OS X 10.5 utilise /bin/bash, qui ne
répond pas à nologonshell. Utilisez shellflag -l.
- Le système d'exploitation z/OS utilise toujours le script /etc/profile pour les
shells de connexion et les autres shells. Il se peut que vous deviez modifier le contenu du script
ou utiliser un autre shell si son comportement ne convient pas bien à l'agent.
Voir également le paramètre shellflag. Des indicateurs peuvent être utilisés pour
modifier le comportement du script de connexion.
- password_encrypt_module chemin_dll;chemin_conf
- Requis pour activer SSL sur l'agent. Spécifie les chemins d'accès à un DLL et un
fichier de configuration.
- chemin_dll correspond au chemin d'accès de bfcrypt.dll
(généralement ./bfcyrpt.dll).
- chemin_conf correspond au chemin d'accès de bfpwcrypt.conf
(généralement ./bfcrypt.conf).
- port numéro-port-ou-plage [...]
Ce paramètre n'est utilisé qu'avec les agents fonctionnant en mode autonome sous
UNIX ou Linux, lorsque vous utilisez l'option -s au démarrage.
Ce paramètre
spécifie le port utilisé par l'agent pour écouter les connexions à l'aide de la console
de gestion.
- Les agents fonctionnant en mode autonome sous UNIX ou Linux (option -s au démarrage).
Spécifie le port utilisé par l'agent pour écouter les connexions à l'aide de la console
de gestion.
Remarque : Le port est défini sur 5555 par défaut.
Pour UNIX ou Linux, ce paramètre se trouve dans /etc/services.
- shell nom_shell [options]
- Ce paramètre spécifie le shell par défaut. Les valeurs par défaut internes sont les
suivantes :
- Windows : shell cmd.exe /q /c "%s" sauf si les paramètres suivants
sont utilisés :
- Si le paramètre cygwin est utilisé, la valeur par défaut est
shell C:\cygwin\bin\bash.exe --login -c "%s"
- Si le paramètre cygwin n'est pas utilisé, la valeur par défaut est shell cmd.exe /u /q /c "%s"
- UNIX ou Linux : Shell défini pour le compte utilisateur ou /bin/sh
si le shell de l'utilisateur ne peut pas être déterminé. Notez que vous ne pouvez pas
spécifier des paramètres ici, mais que vous pouvez utiliser shellflag
pour les transmettre. L'agent force automatiquement l'utilisation par défaut d'un shell
de connexion en insérant un trait d'union. Par exemple, /bin/ksh est
envoyé en tant que -ksh.
Si shell est défini de manière
explicite, nologonshell est défini de manière implicite. Voir
nologonshell.
- System i : Spécifiez /bin/sh comme valeur de shell
Vous pouvez
remplacer ce paramètre dans une étape. Une étape commençant par une ligne contenant
#! remplace les paramètres de shell et le paramètre
nologonshell est utilisé pour exécuter les commandes d'avance pas à pas.
- shell_compatible_undef_vars
- Ce paramètre force la représentation des variables non définies par une chaîne vide. S'il n'est pas défini, la représentation correspond au nom de variable des variables au
format $VAR, ${VAR} ou %VAR% et à la chaîne vide de $[VAR].
- shellarg
Ce paramètre n'est utilisé qu'avec les agents fonctionnant sous UNIX
ou Linux.
Utilisez-le si les commandes semblent brouillées. Certains shells sous
Red Hat Linux Enterprise requièrent ce paramètre.
Ce paramètre modifie la manière
dont un script de commande est transmis au shell. Normalement, le script est transmis via
une entrée standard :
/bin/sh < /tmp/bfshellscript.sh
Ce paramètre entraîne l'exécution des scripts en les transmettant comme paramètres :
/bin/sh /tmp/bfshellscript.sh
- shellflag indicateur
Ce paramètre n'est utilisé qu'avec les agents fonctionnant sous UNIX ou Linux.
Ce paramètre ajoute un indicateur lorsqu'un shell est en cours
d'exécution. Vous ne pouvez spécifier qu'un seul indicateur. Il est généralement utilisé pour
désactiver le traitement du script rc afin de réduire la sortie ou les traitements
non souhaités.
Exemples :- csh et dérivés : Utilisez shellflag -f pour désactiver le traitement
du script rc.
- bash : Utilisez shellflag –-noprofile pour désactiver le traitement
du script de profil.
- ssl_ca_location chemin
- Spécifie le fichier de clés qui contient l'autorité de certification.
Si l'agent est exécuté comme service, utilisez un chemin d'accès absolu.
- ssl_cert_location chemin
- Spécifie le fichier de clés qui contient le certificat privé.
Si l'agent est exécuté comme service, utilisez un chemin d'accès absolu.
- ssl_client_authentication [true | false]
- Spécifiez true pour demander l'authentification du client lorsqu'une connexion est
établie avec l'agent. Si la valeur est true, le certificat du moteur Rational Build Agent doit
être ajouté au fichier de clés de l'autorité de certification de l'agent.
- ssl_cipher_group [listegroupes | ALL]
- Spécifie les groupes de chiffrement individuels à utiliser. Accepte la valeur ALL.
- ssl_cipher_override chiffrements
- Remplace le groupe de chiffrements. Spécifiez les chiffrements à utiliser.
- ssl_key_location chemin
- Spécifie le fichier de clés qui contient la clé. Si l'agent est exécuté comme
service, utilisez un chemin d'accès absolu.
- ssl_key_password motdepasse
- Mot de passe de la clé. Cette propriété est stockée en texte en clair par défaut.
Vous pouvez permettre à l'agent de chiffrer ce mot de passe à l'aide de sa propre clé ou
de la clé du serveur Rational Build Agent.
- ssl_protocol protocole
- Protocole d'établissement de liaison SSL à utiliser (SSL, SSLv2, SSLv3, SSL_TLS, TLS,
TLSv1). Le protocole doit correspondre au protocole utilisé par le serveur Rational Build Agent.
- update_path chemin
Ce paramètre identifie le chemin d'accès complet de l'exécutable de Rational Build
Agent. Ce paramètre est établi automatiquement lors de l'installation. Le répertoire est un répertoire par défaut pour le système d'exploitation ou le
répertoire d'installation que vous spécifiez.
Remarque : Ce paramètre est ignoré sur les agents
Windows. Le chemin de mise à jour est extrait des clés de registre. Les clés sont
définies lors de l'installation de l'agent.