| Author |
Message
|
| mqsidude |
 Posted: Wed Nov 14, 2007 2:56 pm Post subject: 2035 on cluster Queue |
 |
|
Centurion
Joined: 22 Jan 2004
Posts: 148
|
OS - AIX
WMQ - 6.0.2.0
I have two Queue Managers QM1 and QM2 on two different servers, clustered. A local queue Q1 is defined on QM1 and shared in the cluster. There is a WAS application hosted on same machine as QM2, running under userid 'wasuser' trying to put messages on Q1. 'wasprime' is the primary group of 'wasuser'. We granted connect and inq for 'wasprime' on QM2. Now the applicaton gets 2035, not authorised error. Any thoughts on this?
Do we need to issue any permissions on the queue Q1? Please note that there are no 'wasuser' and 'wasprime' on QM1 host.
Any help is appreciated.
Thanks |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed Nov 14, 2007 3:09 pm Post subject: |
|
|
Guest
|
| Quote: |
| trying to put messages on Q1 |
You must grant put authority if you want to put messages to a queue. |
|
| Back to top |
|
|
| mqsidude |
| Posted: Wed Nov 14, 2007 7:58 pm Post subject: |
|
|
Centurion
Joined: 22 Jan 2004
Posts: 148
|
True..but as I mentioned in my initial post, the userid (and its prime group) are not available on the machine where the queue Q1 and its Queue Manager QM1 are hosted. So I cannot issue any authorities on that box as the command will surely throw "no such group or user " exception.
One possible way I can think of is to create 'wasuser' and 'wasprime' on the same machine where QM1 is hosted and grant sufficient permissions for the queue.
Any thoughts? |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Nov 15, 2007 12:19 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
either create an alias on QM2 pointing to the clustered Queue on QM1 and grant put authority on the alias OR
grant put authority to the system.cluster.transmit.queue on QM2... in general this is a bad idea as now you can put to any queue in the cluster...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Nov 15, 2007 7:20 am Post subject: |
|
|
Guest
|
| Quote: |
| Now the applicaton gets 2035 |
| Quote: |
| Do we need to issue any permissions on the queue Q1? Please note that there are no 'wasuser' and 'wasprime' on QM1 host. |
I'm just a little confused...
Do you mean that that the WAS app on QM2 gets the 2035 authorization failure? Or, is the 2035 occuring on QM1?
For MQOPEN and MQPUT1, the authority check is made on the name of the object being opened - thus, the Q1 queue opened by the WAS app on QM2.
| Quote: |
| we granted connect and inq for 'wasprime' on QM2. |
Why did you grant only connect and inq? What happens if you undo the grants? Or grant +all? |
|
| Back to top |
|
|
| mqsidude |
| Posted: Thu Nov 15, 2007 7:38 am Post subject: |
|
|
Centurion
Joined: 22 Jan 2004
Posts: 148
|
Michael - Thanks for the suggestions. Alias queue solution seems to be more granular. But what is the standard or rather popular option?
Bruce -
| Quote: |
| Do you mean that that the WAS app on QM2 gets the 2035 authorization failure? Or, is the 2035 occuring on QM1? |
The WAS app is hosted on same box as QM2, the app connects to QM2 and puts mesasges on clustered queue Q1 (owned by QM1) and this is were we see the 2035 errors.
| Quote: |
| Why did you grant only connect and inq? What happens if you undo the grants? Or grant +all? |
Because those are the only permissions required for the app to connect to QM2? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Nov 15, 2007 7:52 am Post subject: |
|
|
Guest
|
| Quote: |
| Because those are the only permissions required for the app to connect to QM2? |
If you only grant inq and connect, you cannot expect the app to successfully MQOPEN or MQPUT a message.
In a distributed queue manager environment, there are two places where authorization will be checked:
1) on the sending side, where the application MQCONNects to the local queue manager; AND where the Queue Remote definition is MQOPENed; AND where the app MQPUTs the message to the transmission queue; and
2) the receiving side where the MCA MQOPENs the destination queue; and MQPUTs the message to the destination queue.
Authorization must be granted at both ends.
| Quote: |
| The WAS app is hosted on same box as QM2, the app connects to QM2 and puts mesasges on clustered queue Q1 (owned by QM1) and this is were we see the 2035 errors. |
I'm just a little lost. Which qmgr do you mean by "this"? |
|
| Back to top |
|
|
| mqsidude |
| Posted: Thu Nov 15, 2007 8:31 am Post subject: |
|
|
Centurion
Joined: 22 Jan 2004
Posts: 148
|
| Apologies for not being clear. The exceptions are being thrown on QM2. |
|
| Back to top |
|
|
| mqsidude |
| Posted: Thu Nov 15, 2007 8:38 am Post subject: |
|
|
Centurion
Joined: 22 Jan 2004
Posts: 148
|
| Quote: |
| If you only grant inq and connect, you cannot expect the app to successfully MQOPEN or MQPUT a message |
I agree, but how can we grant PUT or GET on Q1 when we don't have 'wasuser' or 'wasgrp' on box where QM1 is hosted? Reemeber Q1 is owned by QM1 and shared in the cluster so that apps on QM2 can access it. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Nov 15, 2007 8:42 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| mqsidude wrote: |
| Quote: |
| If you only grant inq and connect, you cannot expect the app to successfully MQOPEN or MQPUT a message |
I agree, but how can we grant PUT or GET on Q1 when we don't have 'wasuser' or 'wasgrp' on box where QM1 is hosted? Reemeber Q1 is owned by QM1 and shared in the cluster so that apps on QM2 can access it. |
... Q1 is accessed from QM2 through the 'cluster'='access to the SCTQ' on QM2 !!!
as said...
you can grant access through an alias or directly to the SCTQ...
popular is probably +put on SCTQ
proper should be +put on the Alias...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Nov 15, 2007 8:44 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You don't grant any access to anything on QM1.
You grant access to stuff on QM2.
In this case, the most secure option is to create a QALIAS to the queue on QM1, and grant PUT authority to that ALIAS.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Nov 15, 2007 8:53 am Post subject: |
|
|
Guest
|
| Quote: |
| I agree, but how can we grant PUT or GET on Q1 when we don't have 'wasuser' or 'wasgrp' on box where QM1 is hosted? Reemeber Q1 is owned by QM1 and shared in the cluster so that apps on QM2 can access it. |
Let's stick with QM2 where the exception is being thrown. This means that the username that the application is running under doesn't have authorization to open the remote queue definition (QM1) on QM2. This makes sense if you only granted connect (to QM2) and inq (to Q1). |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Nov 15, 2007 10:07 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jefflowrey wrote: |
You don't grant any access to anything on QM1.
You grant access to stuff on QM2.
In this case, the most secure option is to create a QALIAS to the queue on QM1, and grant PUT authority to that ALIAS. |
Jeff correct me please if I am wrong. I would have thought that granting put on QM2 to the qname or generic qname even if the queue resides on QM1 is sufficient as the qmgr would treat the cluster queue as a remote queue if it doesn't host it.
So
a) no granting to the SCTQ,
b) granting put to the qname even though no queue with this name resides on the qm doing the put operation.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Nov 15, 2007 10:13 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Does it succeed to issue setmqaut for an object that doesn't exist on the qmgr you're connected to?
I didn't think it did.
But yes, DO NOT give privileges to S.C.T.Q.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Nov 15, 2007 10:22 am Post subject: |
|
|
Guest
|
Authority is granted on objects.
Queue objects come in four flavors: QLocal, QModel, QAlias, QRemote.
The only queue object that can hold messages is a QLocal. The other queue object types must resolve to a local queue.
MQOPENs are always to local object definitions - on the queue manager your application is connected to (QM2, in your case).
A QRemote object is a local object definition of a local queue owned by a queue manager that is NOT the one your application is connected to. The QRemote definition must resolve to a transmission queue.
For a clustered QLocal queue owned by another queue manager, the transmission queue will be the SCTQ.
Last edited by bruce2359 on Thu Nov 15, 2007 10:27 am; edited 2 times in total |
|
| Back to top |
|
|
|
|
