Remplacement des informations sur l'hôte de serveur Liberty

La fonction collectiveMember-1.0 permet à un serveur d'être géré par le contrôleur de collectivité. La plupart des informations sur l'hôte du serveur peuvent être détectées automatiquement. Dans certains cas toutefois, vous devez fournir des informations supplémentaires sur l'hôte pour que le contrôleur de collectivité puisse établir une connexion au serveur.

Pour plateformes répartiesPour plateformes IBM iRemarque : La fonction collectiveController-1.0 et ses capacités sont disponibles dans WebSphere Application Server Liberty Network Deployment et WebSphere Application Server Liberty pour z/OS seulement. Cette fonction n'est pas disponible dans WebSphere Application Server Liberty ou WebSphere Application Server Liberty Core. Si vous disposez d'une installation WebSphere Application Server Liberty Network Deployment, vous pouvez utiliser sa fonction collectiveController-1.0 pour opérer avec des membres de la collectivité depuis des installations WebSphere Application Server Liberty ou WebSphere Application Server Liberty Core.
Pour permettre le remplacement des informations sur l'hôte, ajoutez l'élément suivant au fichier server.xml :
<hostAuthInfo rpcPort="ssh_port"
          rpcUser="user_ID"
          rpcUserPassword="password"
          rpcUserHome="user_home"
          rpcHost="host_name"
          sudoUser="sudo_user"
          sudoPassword="sudo_user_password"
          sshPublicKeyPath="public_key_path"
          sshPrivateKeyPath="private_key_path"
          sshPrivateKeyPassword="private_key_password"
          useHostCredentials="true_or_false"/>
rpcPort
Ce paramètre indique le port du mécanisme RPC, qui est le port SSH 22 par défaut. Si votre système utilise un port non standard, définissez cette valeur en conséquence. Si cette valeur n'est pas spécifiée, la valeur par défaut est 22.
rpcUser
Ce paramètre spécifie l'ID utilisateur que le contrôleur de collectivité doit utiliser pour se connecter au serveur. Si l'hôte ne prend pas en charge SSH ou si l'utilisation de clés SSH n'est pas souhaitée, vous pouvez utiliser ce paramètre pour spécifier un utilisateur de connexion au système d'exploitation. Par exemple, si vous vous connectez à l'hôte avec l'utilisateur myID, vous indiquez rpcUser="myID". Si cette valeur n'est pas spécifiée, la valeur par défaut est System.getProperty("user.name").
rpcUserPassword
Ce paramètre spécifie le mot de passe associé à l'ID utilisateur spécifié. Par exemple, si vous vous connectez à l'hôte avec l'utilisateur myID et le mot de passe myPwd, vous indiquez rpcUser="myID" et rpcUserPassword="myPwd". Si cette valeur n'est pas spécifiée, le serveur génère une paire de clés SSH ou utilise la paire de clés SSH pour la connexion qui est spécifiée avec les paramètres privateKeyPath et publicKeyPath. Si SSH n'est pas installé sur le serveur (par exemple sur un système d'exploitation Windows ou OS/400), le mot de passe est requis.
rpcUserHome
Ce paramètre spécifie le répertoire de base de l'utilisateur. Si cette valeur n'est pas spécifiée, la valeur par défaut est System.getProperty("user.home"). Si rpcUser est spécifié, spécifiez rpcUserHome.
rpcHost
Ce paramètre indique l'hôte sur lequel le mécanisme RPC est configuré pour l'écoute. Si cette valeur n'est pas spécifiée, la valeur par défaut est la valeur de la variable defaultHostName. Si votre système utilise un hôte autre que defaultHostName, définissez cette valeur en conséquence.
sudoUser
Si cette valeur est spécifiée, elle permet au contrôleur de collectivité d'exécuter des commandes en tant qu'autre utilisateur, ou utilisateur "sudo", à la place de l'ID utilisateur indiqué pour la connexion. Il est applicable uniquement aux serveurs pour lesquels un serveur SSH est installé. Il ne possède pas de valeur par défaut.
sudoPassword
Ce paramètre spécifie le mot de passe de l'utilisateur sudo spécifié par le paramètre sudoUser. Il est applicable uniquement aux serveurs pour lesquels un serveur SSH est installé. Il ne possède pas de valeur par défaut.
sshPublicKeyPath
Ce paramètre spécifie le chemin et le nom d'un fichier de clé publique spécifié par l'utilisateur. Si cette valeur n'est pas spécifiée, la valeur par défaut est ${server.output.dir}/resources/security/ssh/id_rsa.pub. Si le fichier spécifié (ou le fichier par défaut) n'existe pas, un nouveau fichier de clé publique est généré.
sshPrivateKeyPath
Ce paramètre spécifie le chemin et le nom d'un fichier de clé privée spécifié par l'utilisateur. Si cette valeur n'est pas spécifiée, la valeur par défaut est ${server.output.dir}/resources/security/ssh/id_rsa. Si le fichier spécifié (ou le fichier par défaut) n'existe pas, un nouveau fichier de clé privée est généré.
sshPrivateKeyPassword
Ce paramètre spécifie le mot de passe pour la clé privée. Il ne possède pas de valeur par défaut.
useHostCredentials
Ce paramètre indique si les commandes du serveur de membre de collectivité héritent des données d'identification de l'hôte. La valeur par défaut est false, ce qui signifie que l'utilisateur doit indiquer les données d'identification RPC pour le contrôleur afin de démarrer ou d'arrêter à distance le membre. Lorsque ce paramètre est défini sur true, les commandes du serveur de membre de collectivité héritent des données d'identification RPC d'enregistrement de l'hôte et elles ignorent toutes les autres données d'identification RPC dans l'élément de configuration hostAuthInfo.

Exemples

Scénario 1 : le serveur se trouve sur un système d'exploitation Windows et SSH n'est pas installé
<hostAuthInfo rpcUserPassword="myPassword"/>
Scénario 2 : SSH est installé sur le serveur et s'exécute sur le port 2222
<hostAuthInfo rpcPort="2222"/>
Scénario 3 : Exécution des commandes en tant qu'autre utilisateur
<hostAuthInfo sudoUser="anotherUser" sudoPassword="anotherPassword"/>
Scénario 4 : le serveur est situé sur un système d'exploitation Windows et un service SSH tel que Cygwin est installé. Sous la configuration serveur suivante, le contrôleur connecte le serveur membre via SSH. Dans ce cas, le besoin de désactiver Windows User Account Control (UAC) ne s'applique pas. Le paramètre <répertoire utilisateur> est le répertoire par défaut de l'utilisateur. Par exemple, C:\cygwin\home\bob:
<hostAuthInfo rpcUserHome="<user's home directory>" />
Scénario 5 : le contrôleur de collectivité et le membre se trouvent sur des hôtes distincts et non sur le même hôte. Pour indiquer que le membre hérite des données d'identification RPC de l'hôte, définissez useHostCredentials sur true dans le fichier server.xml du membre. Suivez les étapes ci-après pour configurer le membre qui doit hériter des données d'identification RPC de l'hôte en spécifiant --useHostCredentials dans la commande join qui permet de rejoindre un serveur en tant que membre de la collectivité.
  1. Créez, configurez et démarrez i, contrôleur de collectivité nommé myController comme indiqué à l'étape 1 de la section tagt_wlp_configure_collective.html.
  2. Enregistrez l'hôte comme membre auprès de la collectivité. Le membre et le contrôleur de collectivité se trouvent sur des hôtes différents.

    Dans ce scénario, la commande registerHost utilise l'hôte de contrôleur de collectivité hostA.ibm.com avec le numéro de port 9443, l'utilisateur admin et me mot de passe adminpwd. La commande enregistre l'hôte membre hostB.ibm.com auprès de la collectivité, puis il définit rpcUser par un ID utilisateur de connexion au système d'exploitation pour l'hôte membre osUser1, et rpcUserPassword comme mot de passe de connexion au système d'exploitation pour l'ID utilisateur de l'hôte membre osUser1Pwd. Exécutez la commande registerHost sur l'hôte de contrôleur de collectivité.

    wlp/bin/collective registerHost hostB.ibm.com --host=hostA.ibm.com --port=9443 --user=admin --password=adminpwd --rpcUser=osUser1 --rpcUserPassword=osUser1Pwd

    Entrez y (oui) lorsque vous êtes invité à accepter la chaîne de certificats. A l'issue de l'enregistrement, le message Host hostB.ibm.com successfully registered. s'affiche. L'hôte de contrôleur de collectivité possède désormais l'ID utilisateur et le mot de passe de système d'exploitation du membre hôte.

  3. Sur l'hôte membre, créer un serveur nommé myMember à utiliser comme membre de collectivité.
    wlp/bin/server create myMember
  4. Ajoutez le serveur myMember au contrôleur de collectivité, en indiquant l'utilisation des données d'identification de l'hôte. Dans la commande join, qui s'exécute sur l'hôte membre, indiquez --useHostCredentials afin que le membre hérite des données d'identification RPC de l'enregistrement de l'hôte.
    wlp/bin/collective join myMember --host=hostA.ibm.com --port=9443 --user=admin --password=adminpwd --keystorePassword=memberKSPassword --useHostCredentials
  5. Mettez à jour le fichier server.xml du membre comme indiqué à l'étape 2 de la section tagt_wlp_configure_collective.html.

    Etant donné que vous avez indiqué --useHostCredentials dans la commande join, la configuration générée pour le membre server.xml file définit useHostCredentials sur true:

    <!-- Remote host authentication configuration -->
    <hostAuthInfo useHostCredentials="true" />
Avec l'option --useHostCredentials, vous n'avez pas besoin d'indiquer l'ID utilisateur et le mot de passe du système d'exploitation dans le fichier server.xml du membre car celui-ci hérite des données d'identification de l'hôte. Ultérieurement, si l'ID utilisateur ou le mot de passe de système d'exploitation du serveur membre change, exécutez la commande updateHost pour modifier cet ID utilisateur et ce mot de passe. Pour plus d'informations sur les commandes registerHost et updateHost, voir Enregistrement des ordinateurs hôte auprès d'une collectivité Liberty.

Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: Tuesday, 6 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=ragt_wlp_server_host
Nom du fichier : ragt_wlp_server_host.html