Commande addNode

La commande addNode incorpore une installation de serveur d'applications dans une cellule.

Suivant la taille et l'emplacement du nouveau noeud que vous incorporez à la cellule, l'exécution de cette commande peut prendre quelques minutes.

[AIX Solaris HP-UX Linux Windows][z/OS]Vous devez disposer des droits d'administrateur pour utiliser la fonction addNode.

[IBM i]Votre profil utilisateur doit disposer du droit d'accès *ALLOBJ ou des droits de lecture et d'exécution pour le script Qshell addNode.

Le serveur de l'agent de noeud est automatiquement démarré dans le cadre de la commande addNode sauf si vous indiquez l'option -noagent. Si vous recyclez le système qui héberge un noeud de serveur sans avoir configuré l'agent de noeud en tant que démon du système d'exploitation, vous devez lancer une commande startNode pour démarrer cet agent avant les serveurs d'applications.

Quand vous exécutez la commande addNode, elle arrête le serveur d'applications actif qu'elle incorpore dans une cellule. Vous pouvez également arrêter le serveur d'applications avant d'exécuter la commande addNode.

[Windows]Les services Windows existants qui ont été associés aux serveurs avant l'ajout d'un noeud à une cellule sont supprimés lorsque vous exécutez la commande addNode. Si vous supprimez le noeud de la cellule par la suite, les services Windows ne sont pas automatiquement recréés pour les serveurs de base. Pour créer un service Windows pour le produit, voir les informations relatives à la commande WASService.

Lors de l'ajout d'un noeud, le produit peut générer des ports. Les éléments suivants s'appliquent à la génération de port :
  • Les ports générés pour l'agent de noeud sont uniques pour tous les profils de l'installation. A des fins de développement, vous pouvez créer plusieurs profils sur une même installation et les ajouter à une ou plusieurs cellules sans avoir à craindre des problèmes de conflits de port.
  • Si vous souhaitez spécifier quels ports l'agent de noeud doit utiliser, précisez-les dans un fichier dont le nom est transmis avec l'option -portprops. Le fichier est composé de paires clé=valeur (une par ligne), la clé étant identique au nom de port indiqué dans le fichier serverindex.xml.
  • Si vous souhaitez affecter des numéros de port en séquence, vous pouvez utiliser l'option -startingport. Cette option empêche la détection des conflits de ports avec les autres profils.
Pratiques recommandées Pratiques recommandées: Utilisez l'option -includeapps avec la commande addNode pour garantir que l'environnement démarrera avec la même version de l'application. Si un ensemble de règles personnalisé est créé sur le serveur avant l'exécution de la commande addNode, cet ensemble de règles n'est pas copié dans la nouvelle cellule après l'exécution de la commande addNode. Par conséquent, lors de l'utilisation de l'option -installApps, une application du serveur utilisant l'ensemble de règles personnalisé ne parvient pas à charger ce dernier après l'exécution de la commande addNode. Vous pouvez exporter l'ensemble de règles personnalisé à partir du serveur autonome avant d'exécuter la commande addNode, puis l'importer dans la nouvelle cellule après l'exécution de la commande addNode.bprac

Reportez-vous à la rubrique dédiée à l'utilisation des outils de ligne de commande pour savoir si vous devez exécuter la commande à partir du profil ou du répertoire principal du serveur d'applications.

Syntaxe

Voici la syntaxe de la commande :

[AIX Solaris HP-UX Linux Windows][z/OS]
addNode dmgr_host [dmgr_port] [-conntype type] [-includeapps] [-includebuses]
[-startingport numéro de port] [-portprops nom de fichier complet]
[-nodeagentshortname nom] [-nodegroupname nom] [-registerservice]
[-serviceusername nom] [-servicepassword mot de passe] [-coregroupname nom]
[-noagent] [-statusport 1231] [-quiet] [-nowait] [-logfile nom de fichier]
[-replacelog] [-trace] [-username ID utilisateur] [-password mot de passe]
[-localusername ID utilisateur local] [-localpassword mot de passe local] [-profileName nom de profil]
[-excludesecuritydomains true | false] [-asExistingNode] [-help]
[IBM i]
addNode dmgr_host [dmgr_port] [-conntype type] [-includeapps] [-includebuses nom]
[-startingport numéro de port] [-portprops nom de fichier complet] 
[-nodeagentshortname nom] [-nodegroupname nom] [-registerservice] 
[-serviceusername nom] [-servicepassword mot de passe] [-coregroupname nom] 
[-noagent] [-statusport port] [-quiet] [-nowait] [-logfile nom de fichier] 
[-replacelog] [-trace] [-username uid] [-password mot de passe] 
[-localusername ID utilisateur local] [-localpassword mot de passe local] [-profileName nom de profil]
[-excludesecuritydomains true | false] [-asExistingNode] [-help]

L'argument dmgr_host est requis. Tous les autres arguments sont facultatifs. Le numéro de port SOAP par défaut du gestionnaire de déploiement est 8879. SOAP est le type de connecteur JMX (Java™ Management Extensions) par défaut pour la commande. Si vous disposez de plusieurs installations du produit ou de plusieurs profils, le port SOAP peut être différent de 8879. Consultez le fichier SystemOut.log du gestionnaire de déploiement pour connaître les ports en cours d'utilisation.

Remarque : Cette rubrique fait référence à un ou plusieurs des fichiers journaux de serveur d'applications. Il est recommandé de configurer le serveur de telle sorte qu'il utilise l'infrastructure de journalisation et de trace HPEL (High Performance Extensible Logging) à la place des fichiers SystemOut.log, SystemErr.log, trace.log et activity.log sur les systèmes distribués et IBM® i. Vous pouvez également utiliser HPEL conjointement avec vos fonctions de journalisation z/OS natives. Si vous utilisez l'infrastructure HPEL, vous pouvez accéder à toutes les informations de journalisation et de trace en utilisant l'outil de ligne de commande LogViewer à partir de votre répertoire bin de profil de serveur. Pour plus d'informations sur l'utilisation de HPEL, voir les informations sur l'utilisation de HPEL en vue du traitement des incidents liés aux applications.

Paramètres

Les options ci-après sont disponibles pour la commande addNode :

-conntype <type>
Spécifie le type de connecteur JMX à utiliser pour la connexion au gestionnaire de déploiement. SOAP est le type de connecteur JMX (Java Management Extensions) par défaut pour la commande. Les autres types corrects sont JSR160RMI ou Remote Method Invocation (RMI).
-includeapps
Par défaut, la commande addNode ne déplace pas les applications des serveurs autonomes du nouveau noeud vers la cellule. En règle générale, installez les applications à l'aide du gestionnaire de déploiement. L'option -includeapps indique à la commande addNode d'inclure des applications à partir d'un noeud. Si l'application existe déjà dans la cellule, un avertissement est généré et l'application ne s'installe pas dans la cellule.

Les applications sont mappées vers le serveur que vous avez fédéré à l'aide de la commande addNode. Une fois l'exécution de la commande addNode terminée, les applications s'exécutent sur le serveur lorsque celui-ci démarre. Puisque ces applications appartiennent à la cellule de déploiement réseau, vous pouvez les mapper aux autres serveurs et clusters de la cellule à partir de la console d'administration. Pour plus d'informations, voir la rubrique relative au mappage des modules vers les serveurs.

N'utilisez pas l'option -includeapps si le noeud à fédérer inclut des applications fournies avec le produit, telles que les Exemples. Sinon, le deuxième noeud à fédérer contenant ces applications est rejeté, car ces applications existent dans la cellule et la fusion des applications n'est pas prise en charge.

Si vous utilisez l'option -includeapps sur un noeud comprenant un grand nombre d'applications, vous devez allonger le délai d'expiration pour le connecteur d'administration afin de tenir compte du temps supplémentaire nécessaire au transfert de toutes les applications vers le gestionnaire de déploiement lors de l'opération addnode ainsi qu'à leur installation à distance dans la cellule. L'utilisation de l'option -includeapps n'est pas recommandée, à moins que le noeud ne comporte qu'un nombre restreint d'applications.

[AIX Solaris HP-UX Linux Windows][z/OS]Par défaut, lors de l'installation d'une application, les fichiers binaires sont extraits dans le répertoire racine_serveur_app/installedApps/nomCellule. Une fois la commande addNode exécutée, le nom de cellule de la configuration du nouveau noeud change : le nom de cellule de base initial est remplacé par le nom de cellule du gestionnaire de déploiement. Les fichiers binaires de l'application sont situés dans l'emplacement dans lequel ils se trouvaient avant l'exécution de la commande addNode. Par exemple, racine_serveur_app/installedApps/ancien_nomCellule.

[IBM i]Par défaut, lors de l'installation d'une application, les fichiers binaires sont extraits dans le répertoire racine_profil/installedApps/nomCellule. Une fois la commande addNode exécutée, le nom de cellule de la configuration du nouveau noeud change : le nom de cellule de base initial est remplacé par le nom de cellule du gestionnaire de déploiement. Les fichiers binaires de l'application sont situés dans l'emplacement dans lequel ils se trouvaient avant l'exécution de la commande addNode. Par exemple, racine_profil/installedApps/ancien_nomCellule.

Dans l'exemple suivant, l'emplacement des fichiers binaires a été indiqué explicitement lors de l'installation de l'application :
${APP_INSTALL_ROOT}/${CELL}
La variable ${CELL} indique le nom de cellule en cours. Ensuite, lors de l'exécution de la commande addNode, les fichiers binaires sont transférés dans le répertoire racine_profil/installedApps/nomCelluleEncours.

La fédération du noeud dans une cellule à l'aide de la commande addNode n'entraîne pas la fusion des configurations au niveau de la cellule (y compris les informations sur les hôtes virtuels). Si l'hôte virtuel et les alias de la nouvelle cellule ne correspondent pas au produit, vous ne pouvez pas accéder aux applications exécutées sur les serveurs. Vous devez ajouter manuellement tous les alias hôte et les hôtes virtuels à la nouvelle cellule, à l'aide de la console d'administration exécutée sur le gestionnaire de déploiement.

Eviter les incidents Eviter les incidents: Lorsque le paramètre -includeapps est spécifié, une erreur OutOfMemoryError peut se produire si la taille du segment de la machine virtuelle Java est insuffisante. Dans ce cas, le message d'erreur suivant est émis :
ADMU0111E : Fin du programme avec l'erreur : java.lang.OutOfMemoryError

Cette erreur peut se produire en cas de traitement de grosses applications ou quand un grand nombre d'applications réside sur le serveur d'applications de base.

Pour corriger cette erreur et fédérer avec succès le serveur d'applications, procédez comme suit :

  1. Exécutez la commande cleanupNode sur le serveur du gestionnaire de déploiement. Pour plus d'informations sur la commande cleanupNode, voir la rubrique correspondante.
  2. Augmentez la taille du segment de la JVM pour le script addNode. Quand vous émettez la commande addNode, la taille du segment de la JVM est réglée sur -Xms128m -Xmx512m. Pour augmenter ces valeurs, utilisez le paramètre -javaoption. Par exemple, indiquez ce qui suit (sur la même ligne) :[Windows]
    addNode localhost 8879 -javaoption java_option "-Xmx512m"
    [Linux][AIX]
    addNode.sh localhost 8879 -javaoption java_option "-Xmx512m"
  3. Exécutez de nouveau la commande addNode.
gotcha
-includebuses
Copie les bus du noeud à fédérer vers la cellule. Ce paramètre tente également de copier la configuration du bus d'intégration de services du noeud distant dans la cellule. Si un bus de la cellule de destination porte le même nom qu'un des bus du noeud distant, l'ajout de noeud échoue. Pour éviter cet échec, vous pouvez effectuer certaines actions avant d'utiliser la commande addNode. Vous pouvez supprimer le bus concerné de la cellule de destination, renommer le bus à ajouter à la cellule ou bien configurer manuellement le bus déjà présent dans la cellule.
-startingport <numéro_port>
Prend en charge la spécification d'un numéro de port à utiliser en tant que numéro de port de base pour tous les agents de noeud et ports de serveurs JMS (Java Messaging Service) créés lors de l'exécution de la commande addNode. Cette prise en charge permet de déterminer les ports définis pour ces serveurs au lieu d'utiliser les valeurs de port par défaut. Le numéro de port de départ est incrémenté d'une unité pour calculer le numéro de chaque port d'agent de noeud et le numéro du port du serveur JMS configuré à l'aide de la commande addNode.

[AIX Solaris HP-UX Linux Windows]Pour obtenir de plus amples informations sur les paramètres de port par défaut et éviter d'éventuels conflits, voir la rubrique sur les paramètres de numéro de port .

Si un même serveur physique comporte plusieurs agents de noeud, vous pouvez définir le numéro de port de base à affecter à chacun d'eux soit en utilisant le paramètre -startingport avant de lancer la fédération, soit en modifiant les ports consignés dans la section d'agent de noeud du fichier serverindex.xml.

-portprops <nom_fichier>
Transmet le nom du fichier contenant les paires clé-valeur des ports explicites du nouvel agent de noeud. Par exemple, pour attribuer à vos ports SOAP et RMI les valeurs 3000 et 3001, créez un fichier avec les deux lignes suivantes et transmettez-le en tant que paramètre :
SOAP_CONNECTOR_ADDRESS=3000
BOOTSTRAP_ADDRESS=3001
-nodeagentshortname <nom>
Le nom abrégé à utiliser pour le nouvel agent de noeud.
-nodegroupname <nom>
Nom du groupe de noeuds auquel ce noeud est ajouté. Si vous ne précisez pas cette option, le noeud est ajouté au groupe DefaultNodeGroup.
[Windows]-registerservice
Enregistre l'agent de noeud en tant que service Windows.

Vous avez également la possibilité de définir un nom d'utilisateur et un mot de passe pour le service Windows à l'aide des paramètres -serviceusername et -servicepassword. Si vous définissez un nom d'utilisateur, vous devez fournir à l'utilisateur le droit Ouvrir une session en tant que service pour que le service fonctionne correctement.

Si vous ne spécifiez aucun nom d'utilisateur ou mot de passe, le service s'exécute sous le compte du système local.

[Windows]-serviceusername <utilisateur>
[Windows]Utilise le nom d'utilisateur donné comme utilisateur de service de Windows.
[Windows]-servicepassword <mot_passe>
[Windows]Utilise le mot de passe Windows donné en tant que mot de passe de service Windows.
-coregroupname <nom>
Nom du groupe central auquel ce noeud est ajouté. Si vous ne précisez pas cette option, le noeud est ajouté au groupe DefaultCoreGroup.
-noagent
Indique à la commande addNode de ne pas lancer le processus d'agent de noeud du nouveau noeud.
-statusport
Paramètre facultatif autorisant un administrateur à définir le numéro de port pour le rappel de l'état de l'agent de noeud. Cet outil ouvre le port et attend le rappel d'état émis par l'agent de noeud, indiquant que celui-ci a démarré. Si ce paramètre n'est pas défini, un port inutilisé est automatiquement attribué.
-quiet
Supprime les informations de progression que la commande addNode imprime en mode normal.
-nowait
Indique à la commande addNode de ne pas attendre que l'initialisation du processus d'agent de noeud lancé aboutisse.
-logfile <nom de fichier>
Spécifie l'emplacement du fichier journal dans lequel sont consignées les informations de trace. Par défaut, le fichier journal est appelé addNode.log et créé dans le répertoire logs du profil du noeud ajouté.
-replacelog
Remplace le fichier journal au lieu d'ajouter les données au fichier en cours. Par défaut, la commande addNode ajoute les entrées au fichier de trace existant. Cette option indique à la commande addNode de remplacer le fichier de trace.
-trace
Génère des informations de trace supplémentaires dans le fichier journal à des fins de débogage.
-user <nom> ou -username <nom>
Indique le nom d'utilisateur pour l'authentification si la sécurité est activée. Fonctionne comme l'option -user. Le nom d'utilisateur doit exister.
-password <mot de passe>
Indique le mot de passe pour l'authentification si la sécurité est activée. Le mot de passe utilisé doit être celui de l'utilisateur existant.
-localusername <nom>
Indique le nom d'utilisateur pour l'authentification par les serveurs d'applications présents sur le noeud que vous souhaitez fédérer. Ce paramètre ne s'applique que si la sécurité est activée pour le serveur d'applications.
-localpassword <mot_passe>
Indique le mot de passe pour l'authentification par les serveurs d'applications présents sur le noeud que vous souhaitez fédérer. Le mot de passe utilisé doit être celui de l'utilisateur existant. Ce paramètre ne s'applique que si la sécurité est activée pour le serveur d'applications.
-profileName
Définit le profil d'un processus Application Server dans une installation multiprofil. L'option -profileName n'est pas nécessaire à l'exécution dans un environnement de profil unique. La valeur par défaut pour cette option correspond au profil par défaut. Ce paramètre est requis pour ajouter à la cellule du gestionnaire de déploiement un profil autre que celui par défaut.
-excludesecuritydomains true | false
Attribuez la valeur true au paramètre -excludesecuritydomains si vous ne souhaitez pas de domaines de sécurité configurés sur le noeud du serveur d'applications fédéré dans la cellule. Quand le paramètre a la valeur true, la configuration de sécurité de la cellule est utilisée. Ce paramètre s'applique uniquement quand des domaines de sécurité sont configurés dans le serveur d'applications non fédéré. Par défaut, s'il existe un domaine de sécurité associé à un serveur d'applications, le domaine de sécurité est fédéré à la cellule afin que le serveur utilise les mêmes informations de domaine de sécurité une fois qu'il est fédéré.
-asExistingNode
Indique de récupérer nn noeud géré existant d'une cellule de gestionnaire de déploiement.
Utilisez le paramètre -asExistingNode de la commande addNode pour récupérer rapidement un noeud endommagé. Par exemple, si un noeud devient indisponible suite à une défaillance de machine, mais que les informations du noeud sont conservées sur le gestionnaire de déploiement, vous pouvez utiliser l'option addNode -asExistingNode pour recréer le noeud non disponible en exécutant les opérations suivantes :
  1. Créez un nouveau profil avec les mêmes noms de noeud et de profil que ceux du noeud devenu indisponible. Vous pouvez créer le profil sur une machine différente du noeud d'origine.
  2. Pour le nouveau profil, exécutez la commande addNode avec l'option -asExistingNode.

Vous pouvez également utiliser l'option -asExistingNode de la commande addNode pour déplacer un noeud vers une installation du produit se trouvant sur un autre ordinateur, mais dans le même chemin, pour déplacer un noeud vers une installation du produit se trouvant dans un autre système d'exploitation ou dans un autre chemin, ou encore pour créer des cellules à partir d'une cellule de modèle. Voir la rubrique relative à la récupération ou au déplacement de noeuds à l'aide de la commande addNode -asExistingNode.

Eviter les incidents Eviter les incidents: Les autres options de la commande addNode pour la configuration de noeud sont incompatibles avec l'option -asExistingNode. N'utilisez pas -asExistingNode avec les options incompatibles suivantes : -includeapps, -includebuses, -startingport, -portprops, -nodeagentshortname, -nodegroupname, -registerservice, -serviceusername, -servicepassword, -coregroupname et -excludesecuritydomains.gotcha
-help
Imprime une syntaxe.
-?
Imprime une syntaxe.

Scénario d'utilisation

Les exemples suivants montrent la syntaxe correcte :
addNode testhost 8879 (ajoute un serveur d'applications au gestionnaire de déploiement)

addNode deploymgr 8879 -trace (génère le fichier addNode.log)

addNode host25 8879 -nowait (n'attend pas un processus de l'agent de noeud)
La valeur 8879 est le port par défaut.
[IBM i]
addNode mydmgr 11383 -profileName mynode (ajoute le profil, mynode, à la cellule gérée par le profil mydmgr, qui écoute le port SOAP 11383)

Remarques sur la sécurité à prendre en compte lors de l'ajout d'un noeud de serveur d'applications à une cellule WebSphere Application Server, Network Deployment

[IBM i][AIX Solaris HP-UX Linux Windows]Lorsque vous ajoutez un noeud à la cellule, vous héritez automatiquement du registre d'utilisateurs et du mécanisme d'authentification de la cellule.

[z/OS]Lorsque vous ajoutez un noeud à une cellule, le noeud que vous venez de fédérer hérite automatiquement du registre d'utilisateurs (système d'exploitation local, LDAP ou personnalisé), du mécanisme d'authentification (LTPA) et du paramètre d'autorisation (liaisons WebSphere ou profils EJBROLES SAF) de la cellule WebSphere Application Server, Network Deployment existante.

Dans le cadre d'une sécurité distribuée, tous les serveurs de la cellule doivent utiliser les mêmes registre d'utilisateurs et mécanisme d'authentification. Après une modification du registre d'utilisateurs, vous devez modifier vos applications pour que les mappages d'utilisateurs et de groupes à des rôles soient corrects dans le nouveau registre d'utilisateurs. Voir l'article sur l'affectation d'utilisateurs et de groupes à des rôles.

L'infrastructure de clé publique SSL (Secure Sockets Layer) est un autre facteur important à prendre en compte. Avant d'exécuter la commande addNode avec le gestionnaire de déploiement, vérifiez que la commande addNode peut communiquer en tant que client SSL avec le gestionnaire de déploiement. Cette communication requiert que le magasin des tiers dignes de confiance de la commande addNode configuré dans le fichier sas.client.props contienne le certificat signataire du certificat personnel du gestionnaire de déploiement, tel qu'il apparaît dans le fichier de clés spécifié dans la console d'administration.

Les points suivants doivent être pris en compte lors de l'exécution de la commande addNode alors que la sécurité est activée :
  • Lorsque vous tentez d'exécuter des commandes de gestion du système telles que la commande addNode, indiquez les données d'identification permettant d'effectuer l'opération. La commande addNode accepte les paramètres -username et -password pour l'indication de l'ID utilisateur et du mot de passe. Indiquez l'ID utilisateur et le mot de passe d'un administrateur. Par exemple, indiquez un membre des utilisateurs de la console d'administration possédant des droits d'administrateur, ou l'ID administrateur configuré dans le registre d'utilisateurs. Voir l'exemple de commande addNode suivant :
    addNode CELL_HOST 8879 -includeapps -username utilisateur -password motdepasse

    Le paramètre -includeapps est facultatif. Cette option tente d'inclure les applications du serveur dans le gestionnaire de déploiement. La commande addNode risque d'échouer si les registres d'utilisateurs employés par le serveur d'applications et le gestionnaire de déploiement ne sont pas les mêmes. Pour y remédier, vous pouvez soit rendre identiques les registres d'utilisateurs, soit désactiver la sécurité. Si vous modifiez les registres d'utilisateurs, veillez à vérifier que les mappages utilisateurs à rôles et groupes à rôles sont corrects. Pour plus de détails sur la syntaxe de la commande addNode, lisez les informations sur la commande addNode.

    [z/OS]Si vous émettez la commande addNode avec la sécurité activée, vous devez utiliser un ID utilisateur doté des droits requis, et spécifier les options -user et -password.

  • L'ajout d'un noeud distant sécurisé via la console d'administration n'est pas pris en charge. Vous pouvez soit désactiver la sécurité sur le noeud distant avant d'effectuer l'opération, soit effectuer l'opération à partir de l'invite de commande en utilisant le script addNode.
  • [z/OS]Avant d'exécuter la commande addNode, vous devez vérifier que les fichiers de clés certifiées installés sur les noeuds communiquent avec les fichiers de clés et les fichiers de clés SAF (System Authorization Facility) appartenant au gestionnaire de déploiement, et vice versa. Cette opération aboutit si vous générez des certificats pour le gestionnaire de déploiement utilisant la même autorité de certification que celle utilisée par les processus d'agent de noeud. Les configurations SSL ci-dessous doivent contenir des magasins de clés et des magasins des tiers dignes de confiance entre lesquels des interactions sont possibles.
    • Répertoire SSL système indiqué dans la console d'administration. Sélectionnez Administration du système > Gestionnaire de déploiement > Transports HTTP > numéro_port_ssl > SSL.
    • Répertoire SSL correspondant au connecteur JMX approprié si SOAP est indiqué. Cliquez sur Administration du système > Gestionnaire de déploiement > Services d'administration > Connecteurs JMX > Connecteur SOAP > Propriétés personnalisées > sslConfig.
    • Répertoire SSL défini dans NodeAgent. Cliquez sur Administration du système > Agents de noeud > Serveur de l'agent de noeud > Services d'administration > Connecteurs JMX > Connecteur SOAP > Propriétés personnalisées > sslConfig.

    [z/OS]Soyez vigilant lorsque vous ajoutez un noeud dans une configuration de gestionnaire de déploiement, qui définit un domaine de sécurité différent.

  • [IBM i][AIX Solaris HP-UX Linux Windows]Avant d'exécuter la commande addNode, vous devez vérifier que les fichiers de clés certifiées installés sur les noeuds peuvent communiquer avec les fichiers de clés du gestionnaire de déploiement, et vice versa. Si vous utilisez les fichiers DummyServerKeyFile et DummyServerTrustFile par défaut, aucune erreur de communication ne doit survenir car ces fichiers peuvent déjà communiquer. Toutefois, n'utilisez jamais ces fichiers fictifs (dummy) dans un environnement de production ou lorsque vous transmettez des données sensibles.
  • Si la sécurité est activée pour le gestionnaire de déploiement versions 7 et 8, alors le gestionnaire de déploiement ne peut pas utiliser l'ID serveur interne autogénéré pour fédérer un noeud Version 6.x. L'ID serveur interne autogénéré est utilisé par défaut lorsque la sécurité est activée.
  • Lorsqu'un client d'une édition antérieure essaie d'utiliser la commande addNode pour se fédérer dans un gestionnaire de déploiement version 7 ou 8, il doit d'abord obtenir les signataires pour que la liaison puisse être établie. Pour plus d'informations sur les modifications requises avant d'exécuter la commande addNode dans le scénario, consultez la rubrique relative à l'obtention des signataires d'une version antérieure dans la rubrique Installation sécurisée pour l'extraction des signataires client, en particulier la section Obtention de signataires pour les clients et serveurs d'une édition antérieure. Le registre utilisateur peut être modifié de l'une des manières suivantes :
    • Dans la console d'administration, cliquez sur Sécurité globale. Sous Définitions de domaine disponibles, cliquez sur Configurer > identité du serveur stockée dans un référentiel. Entrez le nom d'utilisateur et le mot de passe, puis cliquez sur Appliquer.
    • Exécutez une commande wsadmin :
      AdminTask.configureAdminWIMUserRegistry('[-autoGenerateServerId false -serverId testuser -serverIdPassword testuserpwd -primaryAdminId testuser -ignoreCase true ]')
    Le serveur doit être redémarré pour que ces modifications soient prises en compte.
  • Une fois la commande addNode exécutée, le serveur d'applications se trouve dans un nouveau domaine SSL. Il peut contenir des configurations SSL pointant vers des fichiers de clés et des fichiers de clés certifiées non préparés pour interagir avec d'autres serveurs du même domaine. Déterminez les serveurs qui communiquent entre eux et vérifiez que ces serveurs sont dignes de confiance dans vos fichiers de clés certifiées.

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



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