Je souhaite accéder au gestionnaire de files d'attente via l'explorateur mq mais j'obtiens une erreur:
J'ai suivi toutes les instructions de https: // www-01 .ibm.com / support / docview.wss? uid = swg21623113 afin de permettre à mq explorer d'accéder au serveur mq mais toujours pas de chance.
Détails du serveur IBM MQ:
Détails de MQ Explorer:
Je m'attendais à recevoir un message d'erreur sur mon serveur MQ pour comprendre le problème, mais étonnamment, il n'y a aucun message d'erreur ...
3 Réponses :
Vous ne dites pas sous quelle version d'IBM MQ votre gestionnaire de files d'attente s'exécute. c'est-à-dire v7.5, v8.0, v9.0 ou v9.1.
Vous êtes-vous donné à CHLAUTH l'autorisation d'utiliser le canal SYSTEM.ADMIN.SVRCONN? Il est fort probable que vous soyez bloqué par la règle du backstop.
De plus, si vous utilisez IBM MQ v8.0 ou supérieur, alors CONNAUTH pourrait vous bloquer.
Voici deux bons liens pour vous guider à travers votre problème.
https : //www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.mig.doc/q001110_.htm
La version MQ est 8.0.0.4. Dans le lien que j'ai partagé ( www-01.ibm.com/support /docview.wss?uid=swg21623113 ), il recommande: * c. Pour MQ 7.1 et versions ultérieures, et si vous devez autoriser les connexions à distance par un administrateur MQ. * ré. Pour MQ 8.0 et versions ultérieures, et si vous souhaitez que le mot de passe soit facultatif pour un administrateur MQ. * J'ai fait les deux donc CONNAUTH n'est pas un problème pour moi mais je vais jeter un œil à votre lien au cas où je pourrais attraper quelque chose. Merci beaucoup pour la réponse
Je viens de lire les liens mais ils sont tous liés si CHLAUTH (ENABLED) ce n'est pas le cas pour moi.
Vous avez tenté de connecter votre MQ Explorer à votre gestionnaire de files d'attente à l'aide des détails de connexion suivants: -
et vous avez reçu le code retour MQRC_HOST_NOT_AVAILABLE (2358) qui indique que l'adresse réseau n'est pas joignable.
Les raisons courantes de cette erreur incluent le fait de ne pas avoir d'écouteur TCP.IP en cours d'exécution sur ce port, mais vous nous avez dit que vous avez un écouteur en cours d'exécution.
L'adresse IP que vous avez utilisée est le problème. Remplacez l'adresse IP de votre configuration MQ Explorer par l'adresse IP réelle sur laquelle le gestionnaire de files d'attente est exécuté. Si MQ Explorer et Queue Manager sont sur la même machine (dans le même conteneur), vous pouvez utiliser le nom d'hôte localhost ou l'adresse IP 127.0.0.1, sinon, veuillez utiliser l'adresse IP attribuée pour la machine. D'après votre capture d'écran, il semble qu'il s'agisse d'une adresse 192.168. *.
0.0.0.0 semble être une référence docker à l'adresse IP réelle de l'hôte d'après ce que j'ai lu. À moins que vous ne disiez à docker de router un port hôte vers l'IP du docker, ce n'est pas le cas.
Sur un hôte Linux normal, 0.0.0.0 est passé à 127.0.0.1 pour moi.
Sous Windows, il ne semble pas être configuré par défaut.
Vous ne savez pas si vous pensez que c'est le problème ou non?
Je pense que cela a peut-être à voir avec les ports de conteneurs qui sont exposés ou non.
Vous avez indiqué que vos gestionnaires de files d'attente s'exécutent dans un conteneur et que votre MQ Explorer s'exécute dans un autre conteneur. J'ai remarqué que vous avez fourni 0.0.0.0 comme nom d'hôte, mais le conteneur dans lequel MQ Explorer est exécuté ne comporte aucun gestionnaire de files d'attente!
Si vous exécutez la commande suivante (en remplaçant par l'ID du conteneur exécutant votre file d'attente managers), vous devez obtenir l'adresse IP du conteneur sur le sous-réseau docker. Essayez d'utiliser cette adresse IP dans MQ Explorer au lieu de 0.0.0.0:
docker run -d -e LICENSE=accept --publish-all --publish 1417 ibmcom/mq
Si votre conteneur est sur un autre réseau docker, vous devrez exécuter le remplacement suivant par le nom vous avez donné au réseau docker:
docker inspect --format "{{ .NetworkSettings.Networks.<Network Name>.IPAddress }}" <QM container>
De plus, lorsque vous avez créé votre conteneur de gestionnaire de files d'attente, vous êtes-vous souvenu d'exposer le port 1417 que vous essayez d'utiliser? Par défaut, l'exemple mq-container expose uniquement les ports suivants: 1414, 9157 et 9443. Lorsque vous exécutez le conteneur, vous devez exposer les ports mais en fournissant --publish-all - -publier 1417 lorsque vous avez exécuté le conteneur. Par exemple:
docker inspect --format "{{ .NetworkSettings.IPAddress }}" <QM container>
Merci beaucoup Rob! Cela a résolu mon problème. Pour être clair, j'ai déjà publié le port 1417 sur mon hôte mais j'utilisais 0.0.0.0 au lieu de 172.17.0.2
Heureux de l'entendre résolu votre problème. Ce document de débordement de slack détaille ce qu'il faut faire lorsque quelqu'un répond à une question et comment marquer le problème comme résolu: stackoverflow.com/help/someone- réponses Dans ce cas, vous devez "accepter" cette réponse pour montrer qu'elle a résolu votre problème.
Quelle version de MQ v8 utilisez-vous pour le gestionnaire de files d'attente (par exemple 8.0.0.3 ou 8.0.0.11)? Vérifiez que
DIS QMGR CHLEVest réglé surENABLEDsi ce n'est pas le cas, puis activez-le avecALTER QMGR CHLEV (ENABLED). Reproduisez l'échec et vérifiez que tous les messages sont générés dans la file d'attenteSYSTEM.ADMIN.CHANNEL.EVENT. Si vous voyez des messages, exécutez ceci:/ opt / mqm / samp / bin / amqsevt -m QMGRNAME -q SYSTEM.ADMIN.CHANNEL.EVENT. Regardez les derniers messages pour voir s'ils correspondent à votre MQ Explorer et expliquez pourquoi vous constatez un échec.Le commentaire de @JoshMc et la réponse de Roger suggèrent que vous rencontrez des problèmes de sécurité, mais le code anomalie 2358 est MQRC_HOST_NOT_AVAILABLE, vous devriez donc vérifier votre connectivité. Vous avez suggéré que vous n'aviez pas de problèmes de connectivité parce que vous pouvez telnet vers le QMgr - ce telnet provient-il du même conteneur de machine / docker que celui dans lequel s'exécute MQ Explorer? Vous ne nous montrez pas une capture d'écran de vos paramètres de connexion MQ Explorer - nous pouvons seulement supposer que vous avez entré le bon port là-bas?
@JoshMc, merci beaucoup pour les conseils! J'ai suivi vos recommandations et comme vous l'avez mentionné, un enregistrement est apparu dans la file d'attente
SYSTEM.ADMIN.CHANNEL.EVENT. Malheureusement, je n'ai pas de scriptamqsevt. J'ai un dossier/ opt / mqm / sampmais pas de dossierbin. Je vérifie également le dossier/ opt / mqm / binmais pas de chance. J'essaierai de trouveramqsevt. Merci beaucoup pour la pointe!@JoshMc, je devrais vous dire mes étapes car j'ai le sentiment que le message dans la file d'attente n'est peut-être pas lié à mon problème. J'ai changé la valeur de
CHLEVdans mon gestionnaire de files d'attente et j'ai essayé de me connecter à nouveau depuis mq explorer. Rien ne s'est passé. Ensuite, j'ai pensé que je devais redémarrer mon gestionnaire de files d'attente, ce que j'ai fait. Ensuite, j'ai démarré mon auditeur et j'ai pensé que je devrais également démarrer ma chaîne car c'était nécessaire pour la file d'attente distante, alors j'ai pensé que cela pourrait également être une exigence pour mq explorer. Quoi qu'il en soit, je pense que le message dansSYSTEM .ADMIN.CHANNEL.EVENTprovient probablement de ma commande de canal de démarrage :(@JoshMc, je viens d'arrêter / démarrer ma chaîne et le nombre de messages devient 3
@MoragHughson, je viens d'ajouter une capture d'écran. En haut à droite: Xterm, j'ai fait du telnet à partir de cette fenêtre vers 0.0.0.0 1417 | En bas à droite: connexion au serveur MQ | Gauche: fenêtre MQ Explorer qui s'ouvre grâce à XQuartz
Que faites-vous pour vous assurer que le conteneur de l'explorateur peut accéder au conteneur du gestionnaire de files d'attente sur le port 1417?
Et vous avez raison, toute commande de démarrage ou d'arrêt contre un canal entraînera la génération d'un message d'événement de canal. Généralement, un canal SVRCONN est dans un état INACTIF ce qui signifie qu'il est prêt à recevoir une connexion, le seul moment où vous auriez besoin pour démarrer un SVRCONN est s'il était dans un état STOPPED parce que vous l'avez précédemment arrêté.
Si vous parvenez à démarrer une bash à la fois dans le gestionnaire de files d'attente et dans le conteneur de l'explorateur MQ, un meilleur test consiste à effectuer le telnet sur l'explorateur MQ en ciblant la même adresse IP et le même port que vous spécifiez dans MQ Explorer, en supposant que cela se connecte correctement, alors allez dans le gestionnaire de files d'attente bash et exécutez
netstat -an | grep 1417et recherchez une connexionESTABLISHED, si vous n'en voyez pas, votre connexion depuis le conteneur de l'explorateur MQ est ne pas accéder au conteneur du gestionnaire de files d'attente.Qu'est-ce que l'adresse IP 0.0.0.0? Êtes-vous sûr que c'est la bonne adresse IP que vous devriez utiliser?
Vous ne verrez aucune erreur enregistrée dans le gestionnaire de files d'attente pour ce cas d'erreur particulier, car le client (MQ Explorer) n'atteint pas votre gestionnaire de files d'attente comme indiqué par le code de retour MQRC_HOST_NOT_AVAILABLE (2358).