ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » 2035 on cluster Queue

Post new topic  Reply to topic Goto page 1, 2, 3  Next
 2035 on cluster Queue « View previous topic :: View next topic » 
Author Message
mqsidude
PostPosted: Wed Nov 14, 2007 2:56 pm    Post subject: 2035 on cluster Queue Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Wed Nov 14, 2007 3:09 pm    Post subject: Reply with quote

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
PostPosted: Wed Nov 14, 2007 7:58 pm    Post subject: Reply with quote

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
View user's profile Send private message
Michael Dag
PostPosted: Thu Nov 15, 2007 12:19 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website MSN Messenger
bruce2359
PostPosted: Thu Nov 15, 2007 7:20 am    Post subject: Reply with quote

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
PostPosted: Thu Nov 15, 2007 7:38 am    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Thu Nov 15, 2007 7:52 am    Post subject: Reply with quote

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
PostPosted: Thu Nov 15, 2007 8:31 am    Post subject: Reply with quote

Centurion

Joined: 22 Jan 2004
Posts: 148

Apologies for not being clear. The exceptions are being thrown on QM2.
Back to top
View user's profile Send private message
mqsidude
PostPosted: Thu Nov 15, 2007 8:38 am    Post subject: Reply with quote

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
View user's profile Send private message
Michael Dag
PostPosted: Thu Nov 15, 2007 8:42 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website MSN Messenger
jefflowrey
PostPosted: Thu Nov 15, 2007 8:44 am    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Thu Nov 15, 2007 8:53 am    Post subject: Reply with quote

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
PostPosted: Thu Nov 15, 2007 10:07 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
jefflowrey
PostPosted: Thu Nov 15, 2007 10:13 am    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Thu Nov 15, 2007 10:22 am    Post subject: Reply with quote

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
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2, 3  Next Page 1 of 3

MQSeries.net Forum Index » General IBM MQ Support » 2035 on cluster Queue
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.