| Author |
Message
|
| aditya.aggarwal |
 Posted: Fri Jun 12, 2009 12:44 am Post subject: MQRC 2035 with SYSTEM.CLUSTER.TRANSMIT.QUEUE |
 |
|
Master
Joined: 13 Jan 2009
Posts: 252
|
HI CHAPS,
We have added the 'oracle' user in the mqm group. application running is with this user id and not able to put the message in a Cluster queue physically present on the Remote queue manager. it was throwing the MQRC 2035 error continiously.
Also there was no authorization shown for oracle user after executing the the dspmqaut -m qmgrname-t q -n SYSTEM.CLUSTER.TRANSMIT.QUEUE -p oracle
For temporary fix we had executed the setmqaut command for oracle user to connect with SYSTEM.TRANSMISSION.QUEUE.
After this application starts putting the message in to the Cluster queue physically present on the remote queue manager.
We are surprised that why we need to grant the setmqaut specifically even the 'oracle' user was part of mqm group.
is it a bug with mq or o/s? or is there any fix pack available for his problem?
We are using MQ V6.0.2.2 , Solaris10 [Spark] under Sun Cluster.
Cheers,
Aditya |
|
| Back to top |
|
 |
| aditya.aggarwal |
| Posted: Fri Jun 12, 2009 12:59 am Post subject: |
|
|
Master
Joined: 13 Jan 2009
Posts: 252
|
| Quote: |
For temporary fix we had executed the setmqaut command for oracle user to connect with SYSTEM.TRANSMISSION.QUEUE.
|
Please read it as
For temporary fix we had executed the setmqaut command for oracle user to connect with SYSTEM.CLUSTER.TRANSMIT.QUEUE
request you all to avoid any discussion on why we are adding 'oracle' user in to mqm group.
Cheers,
Aditya |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jun 12, 2009 1:23 am Post subject: Re: MQRC 2035 with SYSTEM.CLUSTER.TRANSMIT.QUEUE |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| aditya.aggarwal wrote: |
Also there was no authorization shown for oracle user after executing the the dspmqaut -m qmgrname-t q -n SYSTEM.CLUSTER.TRANSMIT.QUEUE -p oracle
|
Note that Unix authorisation runs at group level not principle, hence the above effect.
Are you sure your cluster is working properly? I refer to the fact messages seem to be flowing (security issues notwithstanding) over the non-cluster transmission queue.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jun 12, 2009 1:26 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| aditya.aggarwal wrote: |
| request you all to avoid any discussion on why we are adding 'oracle' user in to mqm group. |
I can almost hear the tone in your voice..... 
But this is me, saying nothing on the subject. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Fri Jun 12, 2009 1:29 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
We generally keep ids outside the mqm group and give authorizations to those ids which are not the part of mqm group because mqm is admin level of access on mq objects.
In a cluster env. , SCTQ is important when comes to authorizations.
The following concept works even in cluster env. "If you are connected to qmgr A and your instance of the cluster queue is in qmgr B you cannot GET a message from that clustered queue. You NEED to be connected to qmgr B to GET a message from said cluster queue.However you will be able to PUT a message to the cluster queue while connected to qmgr A"
If you were trying to give all admin access to oracle id by putting it in mqm group., it would get those.
As vitor said, check the messages are going through the SCTQ or SDTQ. (Precedence !!) 
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Jun 12, 2009 1:45 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| shashivarungupta wrote: |
| We generally keep ids outside the mqm group and give authorizations to those ids which are not the part of mqm group because mqm is admin level of access on mq objects... |
You didn't read this bit then?
| Quote: |
| ...request you all to avoid any discussion on why we are adding 'oracle' user in to mqm group... |
_________________
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 |
|
|
| shashivarungupta |
| Posted: Fri Jun 12, 2009 1:54 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| exerk wrote: |
| shashivarungupta wrote: |
| We generally keep ids outside the mqm group and give authorizations to those ids which are not the part of mqm group because mqm is admin level of access on mq objects... |
You didn't read this bit then?
| Quote: |
| ...request you all to avoid any discussion on why we are adding 'oracle' user in to mqm group... |
|
Thats a tragedy. when I was preparing for the post, it (that attention note) appeared just after I posted my comments.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| aditya.aggarwal |
| Posted: Fri Jun 12, 2009 2:24 am Post subject: |
|
|
Master
Joined: 13 Jan 2009
Posts: 252
|
Vitor Wrote
| Quote: |
| Note that Unix authorisation runs at group level not principle, hence the above effect. |
Thanks. so we need to add the group of 'oracle' user in to mqm group?
Vitor Wrote
Are you sure your cluster is working properly? I refer to the fact messages seem to be flowing (security issues notwithstanding) over the non-cluster transmission queue.
Yes Mq Cluster is working properly. Message are flowing over the SYSTEM.CLUSTER.TRANSMIT.QUEUE. it was a typing mistake.
Cheers,
Aditya |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jun 12, 2009 2:30 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| aditya.aggarwal wrote: |
| Thanks. so we need to add the group of 'oracle' user in to mqm group? |
No, I was pointing out you were trying to display the mq authorities of the user (principle) oracle and the reason it was displaying nothing was that the principle has no autoritites.
What you might want to look at is group membership for this user? Something in my head is saying mqm has to be the user's principle group for this to work, but that could just be the cafffine poisoning talking. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Jun 12, 2009 3:37 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
With unix, from what I can remember (and these days, that's not much), if you grant access to a principle, ALL members of that principles primary group inherit the same access rights, hence why authorisations should be set at group level.
_________________
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 |
|
|
| Vitor |
| Posted: Fri Jun 12, 2009 3:46 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| With unix, from what I can remember (and these days, that's not much), if you grant access to a principle, ALL members of that principles primary group inherit the same access rights, hence why authorisations should be set at group level. |
That might well be what I'm mis-remembering.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Fri Jun 12, 2009 4:20 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
Principal :
Is a UNIX system user ID, or an ID associated with an application program running on behalf of a user.
Group :
Is a UNIX system-defined collection of principals.
Authorizations can be granted or revoked at the group level only. A request to grant or revoke a user’s authority updates the primary group for that user.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jun 12, 2009 4:46 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The simplest answer is usually the correct one. Did you run REFRESH SECURITY after changing a group's membership after the QM was already running? If not, how would the QM know the oracle user was now part of the mqm group?
This is me also not saying anything about the logic of adding that ID to the mqm group. I wonder what that ID's primary group is, and what other IDs are in that primary group.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Fri Jun 12, 2009 5:18 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| PeterPotkay wrote: |
The simplest answer is usually the correct one. Did you run REFRESH SECURITY after changing a group's membership after the QM was already running? If not, how would the QM know the oracle user was now part of the mqm group?
This is me also not saying anything about the logic of adding that ID to the mqm group. I wonder what that ID's primary group is, and what other IDs are in that primary group. |
Note: When you change authorizations with the setmqaut command, the OAM implements such changes immediately. Queue managers store authorization data on a local queue called SYSTEM.AUTH.DATA.QUEUE. This data is managed by amqzfuma.exe.
I think REFRESH SECURITY is required when changes are being done related to SSL. Its not mandate to shoot this command when it comes to OAM.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| aditya.aggarwal |
| Posted: Fri Jun 12, 2009 5:20 am Post subject: |
|
|
Master
Joined: 13 Jan 2009
Posts: 252
|
Hi Peter ,
Yes we run the REFRESH SECURITY command.
'oracle' user primary group is 'dba' and there is only one more user in 'dba' group.
All,
Still i am wondering why i need to run 'setmqaut' specially even after adding the 'oracle' user in to 'mqm' group?
And also how can i enable the authorization errors, user access control in the queue manager error logs?
Cheers,
Aditya |
|
| Back to top |
|
|
|
|
