| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| DEFCLXQ set to CHANNEL, but MQ Name Resolution issue? |
« View previous topic :: View next topic » |
| Author |
Message
|
| PeterPotkay |
 Posted: Mon Aug 24, 2020 10:46 am Post subject: DEFCLXQ set to CHANNEL, but MQ Name Resolution issue? |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
MQ 9.1.0.5 on RHEL
New install, new queue manager, queue manager was altered to DEFCLXQ = CHANNEL before its added to the existing MQ cluster.
QM1 is the queue manager the client app is connected to.
QM2 is the destination queue manager that houses the local queue.
Use Cases
A. Client app connects to QM1, MQOPENs a locally defined Remote Queue definition aimed at the local queue on QM2. No issues, I can see name resolution takes the MQOPEN call to SYSTEM.CLUSTER.TRANSMIT.TO.QM2.MYCLUSTERNAME.
B. Client app connects to QM1, MQOPENs a locally defined Alias Queue definition that resolves to a clustered local queue on QM2. No issues, I can see name resolution takes the MQOPEN call to SYSTEM.CLUSTER.TRANSMIT.TO.QM2.MYCLUSTERNAME.
C. Client app connects to QM1, MQOPENs supplying the Destination Queue Name as well as the Destination Queue Manager Name (QM2). ISSUES! I can see name resolution takes the MQOPEN call to SYSTEM.CLUSTER.TRANSMIT.QUEUE. Since I purposely did not grant the app access to SYSTEM.CLUSTER.TRANSMIT.QUEUE, they get MQRC 2035. I did grant them access to SYSTEM.CLUSTER.TRANSMIT.TO.QM2.MYCLUSTERNAME because that is the queue I expected name resolution to resolve to.
If I temporarily grant access to SYSTEM.CLUSTER.TRANSMIT.QUEUE, it works and I can see the app connection to SYSTEM.CLUSTER.TRANSMIT.QUEUE.
When the app puts the message, I then see the Cluster channel from QM1 to QM2 open SYSTEM.CLUSTER.TRANSMIT.TO.QM2.MYCLUSTERNAME, not SYSTEM.CLUSTER.TRANSMIT.QUEUE.
For use case C:
the app has the SYSTEM.CLUSTER.TRANSMIT.QUEUE open for output (but not SYSTEM.CLUSTER.TRANSMIT.TO.QM2.MYCLUSTERNAME)
the cluster sender channel has SYSTEM.CLUSTER.TRANSMIT.TO.QM2.MYCLUSTERNAME open for input and output (but has no (visible) connection to SYSTEM.CLUSTER.TRANSMIT.QUEUE)
The put and get counts increase on SYSTEM.CLUSTER.TRANSMIT.TO.QM2.MYCLUSTERNAME, they do not increase on SYSTEM.CLUSTER.TRANSMIT.QUEUE
With DEFCLXQ set to CHANNEL, I expected all 3 uses cases to only use the QM specific cluster transmit queues, and no dependency on the classic SYSTEM.CLUSTER.TRANSMIT.QUEUE.
Use Cases A and B I only had to grant access to the locally defined Remote or Alias definition.
Use Case C I expected to need to grant access to the transmission queue, but Im surprised MQ Name Resolution takes the apps MQOPEN call to SYSTEM.CLUSTER.TRANSMIT.QUEUE.
So, is this a defect in my understanding of how this should work, a defect in my configuration (where?) or a defect in MQ 9.1.0.5 with name resolution as it relates to DEFCLXQ = CHANNEL?
Is it expected that with DEFCLXQ set to CHANNEL, an app the MQOPENs a queue while supplying the destination QM name actually has a dependency on SYSTEM.CLUSTER.TRANSMIT.QUEUE?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Mon Aug 24, 2020 4:18 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Jamie Squibb from IBM directed my attention to the following documentation.
https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.2.0/com.ibm.mq.pla.doc/q017170_.htm
| Quote: |
| If an application opens a cluster queue that is not on the local queue manager, there is no local object to check. The access control checks are made against the cluster transmission queue, SYSTEM.CLUSTER.TRANSMIT.QUEUE. Even with multiple cluster transmission queues, from Version 7.5, local access control checks for remote cluster queues are made against SYSTEM.CLUSTER.TRANSMIT.QUEUE. |
This covers my scenario exactly.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Aug 25, 2020 12:47 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
Jamie Squibb from IBM directed my attention to the following documentation.
https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.2.0/com.ibm.mq.pla.doc/q017170_.htm
| Quote: |
| If an application opens a cluster queue that is not on the local queue manager, there is no local object to check. The access control checks are made against the cluster transmission queue, SYSTEM.CLUSTER.TRANSMIT.QUEUE. Even with multiple cluster transmission queues, from Version 7.5, local access control checks for remote cluster queues are made against SYSTEM.CLUSTER.TRANSMIT.QUEUE. |
This covers my scenario exactly. |
To avoid authorizing the SCTQ you can also add a Security Stanza to the qm.ini where you choose to authorize via RQMNAME.... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hughson |
| Posted: Tue Aug 25, 2020 9:06 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| fjb_saper wrote: |
| PeterPotkay wrote: |
Jamie Squibb from IBM directed my attention to the following documentation.
https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.2.0/com.ibm.mq.pla.doc/q017170_.htm
| Quote: |
| If an application opens a cluster queue that is not on the local queue manager, there is no local object to check. The access control checks are made against the cluster transmission queue, SYSTEM.CLUSTER.TRANSMIT.QUEUE. Even with multiple cluster transmission queues, from Version 7.5, local access control checks for remote cluster queues are made against SYSTEM.CLUSTER.TRANSMIT.QUEUE. |
This covers my scenario exactly. |
To avoid authorizing the SCTQ you can also add a Security Stanza to the qm.ini where you choose to authorize via RQMNAME.... |
You should work for the Readers Digest ....
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Aug 25, 2020 9:35 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| hughson wrote: |
| fjb_saper wrote: |
| PeterPotkay wrote: |
Jamie Squibb from IBM directed my attention to the following documentation.
https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.2.0/com.ibm.mq.pla.doc/q017170_.htm
| Quote: |
| If an application opens a cluster queue that is not on the local queue manager, there is no local object to check. The access control checks are made against the cluster transmission queue, SYSTEM.CLUSTER.TRANSMIT.QUEUE. Even with multiple cluster transmission queues, from Version 7.5, local access control checks for remote cluster queues are made against SYSTEM.CLUSTER.TRANSMIT.QUEUE. |
This covers my scenario exactly. |
To avoid authorizing the SCTQ you can also add a Security Stanza to the qm.ini where you choose to authorize via RQMNAME.... |
You should work for the Readers Digest .... |
To my defense the infocenter is exceptionally obtuse in the matter as it nowhere states that it is a Security Stanza that needs to be changed... On the other hand I should have followed the link instead of assuming it just said that the system was going to use the SCTQ for authorizations...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
