| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Need pointer on how COD/CODs are generated |
« View previous topic :: View next topic » |
| Author |
Message
|
| HenriqueS |
 Posted: Thu Sep 11, 2008 2:40 pm Post subject: Need pointer on how COD/CODs are generated |
 |
|
Master
Joined: 22 Sep 2006
Posts: 235
|
Folks, I´d like some pointers on how COA/CODs are generated. Which Redbook has that?
I am facing some MQRC 2035 problems while trying to make a Linux and a Windows system to talk and exchange COAs and CODs. My searches on the net gave two differente results:
COD message ID:
| Quote: |
"The COD message is put with the authority of the original message's UserId"
|
OR
| Quote: |
"COD message is put with the authority of the process that made the MQCONN and did the GET for the original message"
|
----------------------------------
COA message ID:
| Quote: |
"The COA is put with the authority of the remote RCVR MCA, typically running under the ID of mqm or MUSR_MQADMIN (Windows)"
|
OR
| Quote: |
"COA message Ids are from the same user id that us running the qmgr".
|
----------------------
While I am receiving COAs OK (because both explanations above for COA id generation take you to the same MUSR_MQADMIN user), my generated CODs, generated from messages that came from a Linux system (mqm user) just go straight to the local DLQ with MQRC 2035.
At first glance we thought on creating a local user called mqm and include it on the mqm local group along with its 'friend' MUSR_MQADMIN. But we discovered that Windows does not allow local users and local groups with same name.
So how do I force CODs to be generated with the MUSR_MQADMIN id? Is this the way to go?
_________________
HenriqueS
Certified Websphere MQ 6.0 System Administrator |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Thu Sep 11, 2008 4:32 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The COD will be put with the ID that's in the MQMD of the message. It would help if you posted links when posting conflicting statements versus just quotes, so we can see the context.
If Server1 / QM1 sends a message to Server2 / QM2, and that message has user ID User1 in the MQMD, then Server2 needs to have User1 defined on it, AND User1 needs setmqaut rights on QM2 to connect to QM2 and to put to the XMITQ back to QM1.
I would advise against designing an app that needs COAs /CODs. What, you don't trust MQ? Then why are you using MQ?  And what are you going to do when the COA/COD doesn't arrive? You can't prove anything. Did the original message not make it? Or did the COA / COD get stuck on the way back for whatever reason? Now what? Forget using COA/COD!
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Thu Sep 18, 2008 12:14 pm Post subject: |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
I understand your point Peter. but in this scenario OTHER people from other companies do expect to receive such CODs. If I was doing something internal or a fresh system I probably would not use them.
I am leaving here in the forum the possible tricks that may be used to deal with this isse:
Note: Create an mqm user on Windows is not possible. There is a Windows limitation not allowing to create a user called 'mqm' inside of a local group that already exists called 'mqm'.
a) It may be written an exit that changes the UserIdentifider field from the MQMD of every incoming message. So the generated CODs will have an UserIdentifier field that is known to the receiver and has proper rights to access MQ objects.
b) Run the queue manager handler (runmqdlq) triggered, looking at the DLQ. As soon a new message goes into the DLQ with a MQRC 2035, write a rule to forward the message to the proper destination (just ACTION(RETRY) is fine). THIS APPROACH IS THE ONE I TOOK AND IT IS WORKING.
_________________
HenriqueS
Certified Websphere MQ 6.0 System Administrator
Last edited by HenriqueS on Fri Sep 19, 2008 9:30 am; edited 1 time in total |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Sep 19, 2008 5:29 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| You should be using an MCAUSER on whatever channels are coming in from OTHER PEOPLE at OTHER COMPANIES.... to ensure that you have completely control over YOUR security on YOUR queue managers. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Sep 19, 2008 7:20 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Good advice, and it should be done regardless, but it won't change the ID on the MQMD, which is the ID being used for COD reports.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Fri Sep 19, 2008 9:28 am Post subject: |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
You are right. At the first moment I thought that all 'retried' messages using runmqdlq gained a new UserId, probably from the user that executed the process runmqdlq. Then I stopped the return channel and looked at the XMITQ, surprise: the UserId is the same one ('mqm') which made my CODs end in the DLQ.
In my thought, after the retry, the messages would end up in the DLQ again so. I have no idea why they are sucessfully forwarded to the XMITQ. Any explanation?
Well, it is kind ugly, but is is working.
---------------------
About the MCAUSER advice, I did not get it: setting an MCAUSER makes the connection (channel connection program) to be run under that local user, right? But this has nothing to do with MQMD->UserId of the incoming message, right? So the messages will just arrive with the same UserId that was causing me the trouble. Like Peter said. Or the MQMD->UserId of the incoming message would be replaced with the MCAUser?
AFAIK, the MCAUSER is only good to use if you create a local user with same name, and set OAM attributes for some of your local MQ objects to that user. So you could restrict access to these objects for every application that connects through that channel. Also, this is clear to me when talking about SRVCONN channels. The excuse for using MCAUSER on SDR/RCVR channels is pretty unknown for me.
And about security, the advice I see on MCAUSERs is setting the default SVRCONN in your installation to a user that has no rights on MQ or even deleting the default SVRCONN channel.
| PeterPotkay wrote: |
| Good advice, and it should be done regardless, but it won't change the ID on the MQMD, which is the ID being used for COD reports. |
_________________
HenriqueS
Certified Websphere MQ 6.0 System Administrator |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Sep 19, 2008 10:26 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Set the MCAUSER of all RCVR type channels to an ID that does not have access to queues that you don't want that other company to have access to.
Why are you allowing them access to the SYSTEM.ADMIN.COMMAND.QUEUE, for example? Do you want them to admin your QM remotely via QM to QM connection? And what if 2 or more companies come to the same QM - do want them to be able to put to each other's application queues?
Any receiving type channels (RCVR, SCRCONN, CLUSRCVR, etc) with a blank MCUSER means the other side has full and complete control of your QM via that channel.
First you protect these channel types with SSL and /or an Exit to control WHO can connect.
Then you have to set MCAUSER to control WHAT they can do.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| 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
|
|
|
|
