I trying to connect RFHUTIL from my laptop to remote MQ server but its show error
09.43.47 Open for temporary reply queue failed rc=2035
Error getting queue names
Below are from Queue Manager Error Log:
2/26/2021 02:43:44 - Process(2716.35) User(MUSR_MQADMIN) Program(amqzlaa0.exe)
Host(MCP-50-50-1-5) Installation(Installation1)
VRMF(9.1.0.7) QMgr(mq)
Time(2021-02-26T01:43:44.367Z)
RemoteHost(50.50.1.2)
CommentInsert1(g525097#mcp-50-50-1-5)
CommentInsert2(SYSTEM.DEFAULT.MODEL.QUEUE)
CommentInsert3(get)
AMQ8077W: Entity 'g525097#mcp-50-50-1-5' has insufficient authority to access
object 'SYSTEM.DEFAULT.MODEL.QUEUE'.
EXPLANATION:
The specified entity is not authorized to access the required object. The
following requested permissions are unauthorized: get
ACTION:
Ensure that the correct level of authority has been set for this entity against
the required object, or ensure that the entity is a member of a privileged
group.
Are you using any SYSTEM.*.SVRCONN channels? Because CHLAUTH rules (on the queue manager) can be blocking you.
RFHUTILC uses your Windows UserId for authentication (MQ v8.0 or higher) and authorization for MQ objects (i.e. queue manager, channels, queues, etc.)
Did your MQAdmin give your UserId, or group which your UserId is in, permission to access the queue manager and the queues?
From the error message you have provided in your question, you need to run the following MQSC command (that is a command issued using the runmqsc tool). If you don't have full authority over this queue manager then I suggest you ask your MQ administrator to run this command. If you do have full authority over this queue manager then make sure you are running the runmqsc tool with the same user id that your started the queue manager with, and that you are running it on the machine where the queue manager resides.
SET AUTHREC PROFILE('SYSTEM.DEFAULT.MODEL.QUEUE') OBJTYPE(QUEUE) GROUP(the-group-that-user-id-g525097-is-in) AUTHADD(GET)
If it still fails after you do this, please post the new error message because it will likely need other permissions and the error message, while similar, will be different.
Try to run this command on queue manager and then try to access
ALTER QMGR CHLAUTH(DISABLED)
Related
I have a Spring Boot app using JMSListener + IBMConnectionFactory + CCDT for connecting an IBM MQ Cluster.
A set the following connection properties:
- url pointing to a generated ccdt file
- username (password not required, since test environment)
- queuemanager name is NOT defined - since it's the cluster's task to decide, and a few google results, including several stackoverflow ones indicate that in my case qmgr must be set to empty string.
When my Spring Boot JMSListener tries to connect to the queue, the following MQRC_UNKNOWN_ALIAS_BASE_Q error occurs:
2019-01-29 11:05:00.329 WARN [thread:DefaultMessageListenerContainer-44][class:org.springframework.jms.listener.DefaultMessageListenerContainer:892] - Setup of JMS message listener invoker failed for destination 'MY.Q.ALIAS' - trying to recover. Cause: JMSWMQ2008: Failed to open MQ queue 'MY.Q.ALIAS'.; nested exception is com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2082' ('MQRC_UNKNOWN_ALIAS_BASE_Q').
com.ibm.msg.client.jms.DetailedInvalidDestinationException: JMSWMQ2008: Failed to open MQ queue 'MY.Q.ALIAS'.
at com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.java:513)
at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:215)
In the MQ error log I see the following:
01/29/2019 03:08:05 PM - Process(27185.478) User(mqm) Program(amqrmppa)
Host(myhost) Installation(Installation1)
VRMF(9.0.0.5) QMgr(MyQMGR)
AMQ9999: Channel 'MyCHL' to host 'MyIP' ended abnormally.
EXPLANATION:
The channel program running under process ID 27185 for channel 'MyCHL'
ended abnormally. The host name is 'MyIP'; in some cases the host name
cannot be determined and so is shown as '????'.
ACTION:
Look at previous error messages for the channel program in the error logs to
determine the cause of the failure. Note that this message can be excluded
completely or suppressed by tuning the "ExcludeMessage" or "SuppressMessage"
attributes under the "QMErrorLog" stanza in qm.ini. Further information can be
found in the System Administration Guide.
----- amqrmrsa.c : 938 --------------------------------------------------------
01/29/2019 03:15:14 PM - Process(27185.498) User(mqm) Program(amqrmppa)
Host(myhost) Installation(Installation1)
VRMF(9.0.0.5) QMgr(MyQMGR)
AMQ9209: Connection to host 'MyIP' for channel 'MyCHL' closed.
EXPLANATION:
An error occurred receiving data from 'MyIP' over TCP/IP. The connection
to the remote host has unexpectedly terminated.
The channel name is 'MyCHL'; in some cases it cannot be determined and so
is shown as '????'.
ACTION:
Tell the systems administrator.
Since the MQ error log contains QMgr(MyQMGR), which MyQMGR value I did not set in the connection properties, I assume the routing seems to be fine: the MQ Cluster figured out a qmgr to use.
The alias exists and points to an existing q. Bot the target q and the alias are added to the cluster via the CLUSTER(clustname) command.
What can be wrong?
Short Answer
MQ Clustering is not used for a consumer application to find a queue to GET messages from.
MQ Clustering is used when a producer application PUTs messages to direct them to a destination.
Further reading
Clustering is used when messages are being sent to help provide load balancing to multiple instances of a clustered queue. In some cases people use this for hot/cold failover by having two instances of a queue and keeping only one PUT(ENABLED).
If an application is a producer that is putting messages to a clustered queue, it only needs to be connected to a queue manager in the cluster and have permissions to put to that clustered queue. MQ based on a number of different things will handle where to send that message.
Prior to v7.1 there was only two ways to provide access to remote clustered queues:
Using a QALIAS:
Define a local QALIAS which has a TARGET set to the clustered queue name
Note this QALIAS does not itself need to be clustered.
Grant permission to put to the local QALIAS.
Provide permissions to PUT to the SYSTEM.CLUSTER.TRANSMIT.QUEUE.
The first option allows for granting granular access to an application for specific clustered queues in the cluster. The second option allows for the application to put to any clustered queue in the cluster or any queue on any clustered queue manager in the cluster.
At 7.1 IBM added a new optional behavior, this was provided with the setting ClusterQueueAccessControl=RQMName in the Security stanza of the qm.ini. If this is enabled (it is not the default), then you can actually provide permission for the app to PUT to the remote clustered queues directly without the need for a local QALIAS.
What clustering is not for is consuming applications such as your example of a JMSListener.
An application that will consume from any QLOCAL (clustered or not) must be connected to the queue manager where the QLOCAL is defined.
If you have a situation where there are multiple instances of a clustered QLOCAL that are PUT(ENABLED), you would need to ensure you have consumers connected directly to each queue managers that an instance is hosted on.
Based on your comment you have a CCDT with an entry such as:
CHANNEL('MyCHL') CHLTYPE(CLNTCONN) QMNAME('MyQMGR') CONNAME('node1url(port1),node2url(port2)')
If there are two different queue managers with different queue manager names listening on node1url(port1) and node2url(port2), then you have different ways to accomplish this from the app side.
When you specify the QMNAME to connect to the app will expect the name to match the queue manager you connect to unless it meets one of the following:
If you specify *MyQMGR it will find the channel or channels with QMNAME('MyQMGR') and pick one and connect and will not enforce that the remote queue manager name must match.
If in your CCDT you have QNAME(''), it is set to NULL, then in your app you can specify a empty queue manager name or only a space and it will find this entry in the CCDT and will not enforce that the remote queue manager name must match.
In your app you specify the queue manager name as *, MQ will use any channel in the CCDT and will not enforce that the remote queue manager name must match.
One limitation of CCDT is that channel name must be unique in the CCDT. Even if the QMNAME is different you can't have a second entry with the same channel name.
When you connect you are hitting the entry with two CONNAME's and getting connected to the first IP(port), you would only get to the second IP(port) if at connect time the first is not available, MQ will try the second, or if you are connected and have RECONNECT enabled and then the first goes down MQ will try to connect to the first then second.
If you want to have both clustered queue PUT(ENABLED) to receive traffic then you want to be able to specifically connect to each of the two queue managers to read those queues.
I would suggest you add a new channel on each queue manager that has a different QM specific name that is also different from the existing name, something like this:
CHANNEL('MyCHL1') CHLTYPE(CLNTCONN) QMNAME('MyQMGR1') CONNAME('node1url(port1)')
CHANNEL('MyCHL2') CHLTYPE(CLNTCONN) QMNAME('MyQMGR2') CONNAME('node2url(port2)')
This would be in addition to the existing entry.
For your putting components you can continue to use the channel that can connect to either queue manager.
For your getting components you can configure at least two of them, one to connect to each queue manager using the new queue manager specific CCDT entries, this way both queues are being consumed.
I am trying to setup a MQ Cluster that has the following config
There are 3 host machines, ubuntuvm-1, ubuntuvm-2 and ubuntuvm-3
ubuntuvm-1 has one Full repository queue manager and one partial repository queue manager. QM_FR1, QM_PR1
ubuntuvm-2 is same as above. QM_FR2, QM_PR2
ubuntuvm-3 has only one partial repository queue manager, QM_PR3
Following are the steps I have taken
I have created cluster receiver channels on each queue manager that point to its own queue manager.
I have created cluster sender channels that point to at least one full repository.
I have made sure that the channels are correct, i see the tests pass when I run them through the MQ Explorer.
I get an error when using MQ Explorer, I try to add the QM_FR1 queue manger to cluster (CLUSTER1).
Following is the error.
Access not permitted. You are not authorized to perform this operation. (AMQ4036)
Severity: 10 (Warning)
Explanation: The queue manager security mechanism has indicated that the userid associated with this request is not authorized to access the object.
Why am I getting this error and how do I fix this?
Please shout if you want me to provide more details.
I am trying to put a message into Websphere MQ queue from an Orchestration which is deployed on Cast Iron Live. I have used secure connector since the orchestation is deployed on Cast Iron. When I am trying to execute the flow, it fails and the message is not placed in MQ queue. The below are the errors:
Error while trying to call remote operation execute on Secure Connector for activity
com.approuter.module.mq.activity.MqPut and Secure Connector LocalSecureConnector,
error is Unable to put message on queue null. MQ returned error code 2538.
Unable to put message on queue null. MQ returned error code 2538.
Fault Name : Mq.Put.OperationActivityId : 163
Message: Unable to put message on queue null. MQ returned error code 2538.
Activity Name:Put MessageFault Time: 2015-07-15T05:40:29.711Z
Can someone please help me resolve this. Please let me know if any further details are required.
Here are the details:
Cast Iron flow is deployed on Cast Iron Cloud i.e Cast Iron Live
MQ is running on-premise
The port I am trying to connect is 1414.
Have a secure connector running on the machine where MQ is installed.
MQ version is 8.
In Cast Iron flow, I am using an MQ connector, by giving the hostname where MQ is running, port: 1414, Channel Name : SYSTEM.DEF.SVRCONN and username as mqm. Tired using my log on username, by adding it to mqm group. But this also dosent seem to work.
The return code is instructive:
2538 0x000009ea MQRC_HOST_NOT_AVAILABLE
This indicates that Cast Iron is attempting to contact MQ using a client connection and not finding a listener at the host/port that it is using.
There are a couple of possibilities here but not enough info to say which it might be. I'll explain and provide some diagnostics you can try.
The 2538 indicates an attempt to contact the QMgr has failed. This might be that, for example, the QMgr isn't listening on the configured port (1414) or that the MQ listener is not running.
The error code says the queue name is "null". The question doesn't specify which queue name the connector is configured with but presumably it's been configured with some queue name. This error code suggests the Secure Connector on the MQ server side doesn't have its configuration installed.
The Cast Iron docs advise connecting with an ID in the mqm group but do not mention that on any MQ version 7.1 or higher this is guaranteed to fail unless special provisions are made to allow the admin connection. It may be that it's actually failing for an authorization error and the connector not reporting the correct error.
If it is as simple as the listener not running, that's easy enough to fix. Just start it and make sure it's on 1414 as expected.
Next, ensure that the Secure Connector has the configuration that was created using the Cast Iron admin panel. You need to understand why the error code says the queue name is null.
Now enable Authorization Events and Channel Events in the QMgr and try to connect again. The connector on the MQ server should connect when started and if successful you can see this by looking at the MQ channel status. However, if unsuccessful, you can tell by looking at the event messages or the MQ error logs. Both of these will show authorization failures and connection attempts, if the connection has made it that far.
The reason I'm expecting 2035 Authorization Error failures is that any QMgr from v7.1 and up will by default allow an administrative connection on any channel. This is configured in the default set of CHLAUTH rules. The intent is that the MQ admin would have to explicitly provision admin access by adding one or more new CHLAUTH rules.
For reasons of security SYSTEM.DEF.* and SYSTEM.AUTO.* channels should never be used for legitimate connections. The Best Practice is to define a new SVRCONN, for example one named CAST.IRON.SVRCONN and then define a CHLAUTH rule to allow the administrative connection.
For example:
DEFINE CHL(CAST.IRON.SVRCONN) CHLTYPE(SVRCONN) TRPTYPE(TCP) REPLACE
SET CHLAUTH('CAST.IRON.SVRCONN') TYPE(ADDRESSMAP) +
ADDRESS('127.0.0.1') +
USERSRC(MAP) MCAUSER('mqm') +
ACTION(REPLACE)
SET CHLAUTH('CAST.IRON.SVRCONN') TYPE(BLOCKUSER) +
USERLIST('*NOBODY') +
WARN(NO) ACTION(REPLACE)
The first statement defines the new channel.
The next one allows the connections from 127.0.0.1 which is where the Secure Connector lives. (Presumably you installed the internal Secure Connection on the same server as MQ, yes?) Ideally the connector would use TLS on the channel and instead of IP filtering the CHLAUTH rule would filter based on the certificate Distinguished Name. This rule is not nearly so slective and allows anyone on the local host to be an MQ administrator by using this channel.
The last statement overrides the default CHLAUTH rule which blocks *MQADMIN with a new rule that blocks *NOBODY but just for that channel.
I try to install WebSphere MQ v8 on Centos 7... I did have no problem instaling the server and test it. When I try to configure client every is OK until I try to put a message at queue with the following command: ./amqsputc queue manager. Here part of the log file.
-------------------------------------------------------------------------------
08/01/15 13:16:17 - Process(37991.4) User(mqm) Program(amqrmppa)
Host(localhost.localdomain) Installation(Installation1)
VRMF(8.0.0.0) QMgr(my.manager)
AMQ9776: Channel was blocked by userid
EXPLANATION: The inbound channel 'CANAL1' was blocked from address
'127.0.0.1' because the active values of the channel were mapped to a
userid which should be blocked. The active values of the channel were
'MCAUSER(mqm) CLNTUSER(mqm) ADDRESS(localhost)'. ACTION: Contact the
systems administrator, who should examine the channel authentication
records to ensure that the correct settings have been configured. The
ALTER QMGR CHLAUTH switch is used to control whether channel
authentication records are used. The command DISPLAY CHLAUTH can be
used to query the channel authentication records.
----- cmqxrmsa.c : 1257 -------------------------------------------------------
08/01/15 13:16:17 - Process(37991.4) User(mqm) Program(amqrmppa)
Host(localhost.localdomain) Installation(Installation1)
VRMF(8.0.0.0) QMgr(my.manager)
AMQ9999: Channel 'CANAL1' to host '127.0.0.1' ended abnormally.
EXPLANATION: The channel program running under process ID 37991 for
channel 'CANAL1' ended abnormally. The host name is '127.0.0.1'; in
some cases the host name cannot be determined and so is shown as
'????'. ACTION: Look at previous error messages for the channel
program in the error logs to determine the cause of the failure. Note
that this message can be excluded completely or suppressed by tuning
the "ExcludeMessage" or "SuppressMessage" attributes under the
"QMErrorLog" stanza in qm.ini. Further information can be found in the
System Administration Guide.
----- amqrmrsa.c : 925 --------------------------------------------------------
I appreciate all the help you can give me, thanks in advance.
It is very easy to troubleshoot the reasons why you have been blocked by a CHLAUTH rule. There is a blog post on it, I'm being blocked by CHLAUTH - how can I work out why?
However, I can tell you from here exactly which rule is blocking you, it is the default rule which bans remote privileged access, i.e. mqm access from client connections. If you want to have access without being privileged, read A non-privileged MQ administrator, and alternatively if you do want to allow the risky remote access from privileged users, read CHLAUTH - Allow some privileged admins
It's worth noting MQ v8 doesn't support CentOS at all, and hasn't declared support for RHEL 7 either.
http://www-969.ibm.com/software/reports/compatibility/clarity-reports/report/html/softwareReqsForProduct?deliverableId=1350550241693&osPlatform=Linux
At time of writing MQ v8 supports the following Linux distros:
Asianux 3.0
RHEL 6
SLES 11
Ubuntu 12.04
That said, the error 'AMQ9776: Channel was blocked by userid' you pasted above show that your client is failing the channel authentication checks.
You can check this by disabling channel authentication via the following MQSC command:
'ALTER QMGR CHLAUTH(DISABLED)'
There's a good article on developerworks that explains how to work out why your connection attempt was blocked you can look at here:
https://www.ibm.com/developerworks/community/blogs/aimsupport/entry/blocked_by_chlauth_why?lang=en
We are have a IBM websphere MQ[v5.2] on AIX platform and my machine is windows 7 pro which has MQ client v7.5.
I tried to connect to server remotely but i received a Authorization error message. This is because my local user account does have rights to connect to queue manager remotely.
So,i created a new user account in my system with some name as on server which has rights to put/get message and now i am able to connect in client mode[Websphere MQ v7.5].
I don't know whether it is actually connecting to server but it is not giving me authorization error message so i took it as success. But the issue is, when I tried to put message into queue from cmd using amqsputc Queue_name mqm the queue is opening and taking a message. But when i tried to get the message using command amqsgetc queue_name mqm it says "NO MORE MESSAGE".
What could be the issue?
Screen shot:
The fact the amqsputc doesnt give an error, and the fact the amqsgetc runs through to success implies the functionality is working. However, it finds nothing on the queue which makes me very suspicious that you have an application listening on that queue, which will consume the message as it arrives and hence before your amqsgetc. Check DISPLAY QSTATUS in runmqsc for IPPROCS on the queue - is it 0 when amqsgetc isnt running?