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 » Clustering » Authorizing putting messages on remote cluster queues

Post new topic  Reply to topic Goto page 1, 2  Next
 Authorizing putting messages on remote cluster queues « View previous topic :: View next topic » 
Author Message
jurop
PostPosted: Mon Jun 20, 2011 3:29 am    Post subject: Authorizing putting messages on remote cluster queues Reply with quote

Novice

Joined: 17 Oct 2005
Posts: 13
Location: Slovakia

Hi,
we would like to increase our authorization settings for reply-to queue.
At present we grant interface provider applications +put authority to SYSTEM.CLUSTER.TRANSMIT.QUEUE - what is not quite secure, that such an application has authority to put messages to any cluster queue.
The WMQ documentation recommends to create a reply-to queue alias and grant +put authority to that.
This is not very usefull for us because requester applications (where are local reply queues sitting)
are usually running in more instances using 2 or more queue managers with identical queue names - and on the provider queue manager I can not create 2 reply-to queue aliases with the same name.

Scenario:
All QMGRs in 1 cluster

Requesters:
APP1-QM1-ReplyQ
APP2-QM2-ReplyQ (APP2 is the same as APP1, running in different location)

Provider:
APP3-QM3-RequestQ
With +put authority to SYSTEM.CLUSTER.TRANSMIT.QUEUE everything was working with ReplyToQueue/ReplyToQmgr pattern.
How to solve it without authority to SYSTEM.CLUSTER.TRANSMIT.QUEUE and without any application change?
Back to top
View user's profile Send private message
exerk
PostPosted: Mon Jun 20, 2011 3:38 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

The reply-to will include a queue manager name, which in conjunction with the queue name provides only one possible target when the alias is resolved.

EDIT: I'm not in favour of using clusters for request/reply routes as it pretty much 'breaks' the reason for clustering - decoupled (non-affinity) messaging and work-load balancing.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
jurop
PostPosted: Mon Jun 20, 2011 7:37 am    Post subject: Reply with quote

Novice

Joined: 17 Oct 2005
Posts: 13
Location: Slovakia

Thanks for your answer.
Did you mean to create on QM3 for example QREMOTE('QM1.ReplyQ') RQMNAME('QM1') RNAME('ReplyQ')?
Than we should change all providing applications to reply another way.
Is not there any other solution?
Back to top
View user's profile Send private message
exerk
PostPosted: Mon Jun 20, 2011 7:47 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

No. I mean share the QLOCAL in the target queue manager in the cluster, and create a QALIAS to it on the replying queue manager (with the appropriate authorities for the application set). When the replying application specifies a queue and queue manager it will be routed through to the correct queue manager.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Mon Jun 20, 2011 12:34 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

Typically in your load balancing algorythm the server application will need either +put to SCTQ or +put to a QMGR ALIAS for the destination (replyto) qmgr... and if the app is in JMS add +inq...

For the requesting app you can create a qalias for the target queue. If you leave the qmgr blank it will resolve correctly to the cluster queue. Remember to set bind not fixed...

Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
jurop
PostPosted: Tue Jun 21, 2011 3:57 am    Post subject: Reply with quote

Novice

Joined: 17 Oct 2005
Posts: 13
Location: Slovakia

If I created QALIAS on QM3 (with the appropriate authorities), it was working only if I did not use ReplyToQmgr
(and messages were load balanced over QM1 and QM2) - most of our apps need the reply to the requesting QMGR.
If I specify the remote qmgr name in the reply message I'm again not authorized (I did not define authorities to SCTQ)
I also tried on QM3 to create QMGR ALIAS for QM1 with +put authority, but it did not working. (Not authorized to put message to ReplyQ on QM1/QM1 alias)
Back to top
View user's profile Send private message
mqjeff
PostPosted: Tue Jun 21, 2011 4:09 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

If you specify both a ReplyToQueue and a ReplyToQmgr, you are instructing the server application to route the message WITHOUT using cluster load-balancing.

So you need to view this route as if it was normal and basic point-to-point messaging, because it really is.

Now, you can take steps (using a QREMOTE with a blank RQMNAME) to *cause* messages to be routed via the cluster, if you somehow really wanted to.
Back to top
View user's profile Send private message
jurop
PostPosted: Tue Jun 21, 2011 5:52 am    Post subject: Reply with quote

Novice

Joined: 17 Oct 2005
Posts: 13
Location: Slovakia

On QM3 I defined QREMOTE(ReplyQ) RNAME(ReplyQ) RQMNAME('') and set authorities.
Still not authorized to put message without authorities to SCTQ.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue Jun 21, 2011 6:01 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.

jurop wrote:

Still not authorized to put message without authorities to SCTQ.

What/who is not authorized? What username?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
jurop
PostPosted: Tue Jun 21, 2011 6:53 am    Post subject: Reply with quote

Novice

Joined: 17 Oct 2005
Posts: 13
Location: Slovakia

I created local user on QM3 host (let's say app_user) - not in mqm group.
This is the user I set the authorities to QREMOTE to and under this user I tried to put messages from QM3.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Tue Jun 21, 2011 11:08 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

jurop wrote:
I created local user on QM3 host (let's say app_user) - not in mqm group.
This is the user I set the authorities to QREMOTE to and under this user I tried to put messages from QM3.

Wrong...
Put the message from the requester as normal
On the processing box define a qmgr alias for the requester qmgr and set permissions for the GROUP of the service user used to process the messages and send them back.

Then try again.
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
jurop
PostPosted: Tue Jun 21, 2011 11:40 pm    Post subject: Reply with quote

Novice

Joined: 17 Oct 2005
Posts: 13
Location: Slovakia

As you wrote, I created alias qmgr: DEFINE QREMOTE (ALIASQMGR) RQMNAME(QM1)
and set authorities:setmqaut -m QM3 -t queue -n ALIASQMGR -g app_user_group +all
For the tests I'm using rfhutil utility, connected to QM3 over SVRCONN channel where MCAUSER=app_user
I'm trying to put message to ReplyQ and set the Remote queue manager name = QM1.
I'm getting again "2035 Not authorized (Open)"
This scenario I think is equivalent to the scenario described in the beggining od this topic.
Am I doing something wrong?
Back to top
View user's profile Send private message
exerk
PostPosted: Tue Jun 21, 2011 11:42 pm    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

As a double-blind test please try my earlier suggestion and feed back, thank you.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
jurop
PostPosted: Wed Jun 22, 2011 2:38 am    Post subject: Reply with quote

Novice

Joined: 17 Oct 2005
Posts: 13
Location: Slovakia

I tried it again - the result was as I wrote earlier:
If I created QALIAS on QM3 (with the appropriate authorities), it was working only if I did not use ReplyToQmgr
(and messages were load balanced over QM1 and QM2) -> most of our apps need the reply to the requesting QMGR, so this would not help us much.
If I specify the remote qmgr name (QM1) in the reply message I'm again not authorized (without authorities to SCTQ)
Back to top
View user's profile Send private message
exerk
PostPosted: Wed Jun 22, 2011 2:41 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

Please confirm that the userid which the REPLYING application runs under is authorised to the QA.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » Clustering » Authorizing putting messages on remote cluster queues
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.