| Author |
Message
|
| Mallik |
 Posted: Tue Jul 20, 2004 5:04 pm Post subject: 2035 with Visual Browse tool |
 |
|
Acolyte
Joined: 29 Feb 2004
Posts: 53
|
Hi everyone,
I am trying to setup permissions for my developers to use the MQBrowse tool. I know it works fine if the MCAUSER attribute of the SVRCONN channel is a member of 'mqm' group or if it is blank. But the problem with that is some developers started using MO71 support pack with the same channel, using which they can administer MQ as well, which we would like to avoid.
My question is, is it necessary for the MQ Browse tool to have a MCAUSER with mqm permissions for the SVRCONN channel?
Can we make the tool work by setting the user autorities for +allmqi? using which we can avoid 'chg' 'dsp' 'clr' & 'dlt' permissions.
I have tried the following. This is a new QMGR & dont have any queues.
setmqaut -m TESTQM -t qmgr -g grp +allmqi
setmqaut -m TESTQM -t q -n SYSTEM.*.* -g grp +allmqi
setmqaut -m TESTQM -t q -n SYSTEM.*.*.* -g grp +allmqi
I am able to test the connection to the queue manager but while listing the queues, I was getting 2035 (Not authorized). But it doesn't say which queue in particualr.
Any suggestions to resolve this would be much appreciated.
Thanks |
|
| Back to top |
|
 |
| RogerLacroix |
| Posted: Tue Jul 20, 2004 9:50 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
Thanks for trying out MQ Visual Browse.
To allow a group to connect to a queue manager do the following command:
| Code: |
| setmqaut -m TESTQM -t qmgr -g grp +connect +inq |
When the user clicks the List button, a PCF message is sent to the 'SYSTEM.ADMIN.COMMAND.QUEUE'. A temporary dynamic queue is created for the reply (i.e. AMQ***).
Therefore, the group will need access to the command queue and anything that begins with AMQ. i.e.
| Code: |
setmqaut -m TESTQM -t queue -g grp -n SYSTEM.** +allmqi
setmqaut -m TESTQM -t queue -g grp -n AMQ.** +allmqi |
It is better to use the double asterisk (**) rather than your method.
Finally, the group will need access its own queues. i.e.
| Code: |
| setmqaut -m TESTQM -t queue -g grp -n MYSTUFF.** +allmqi |
I haven't tried this yet but if you don't care what queue the user is accessing (you just want to block chg, dlt, etc..) then you could try:
| Code: |
| setmqaut -m TESTQM -t queue -g grp -n ** +allmqi |
Also, it is a good idea to issue the REFRESH SECURITY command via runmqsc after executing the setmqaut commands.
Hope that helps.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| Mallik |
| Posted: Wed Jul 21, 2004 10:34 am Post subject: |
|
|
Acolyte
Joined: 29 Feb 2004
Posts: 53
|
Thanks for the response Roger.
I am getting the same 2035 error. Here are the steps that I did. My SVRCONN channel has MCAUSER attribute as 'mqmon'
$setmqaut -m TESTQM -t qmgr -g mqmon +allmqi
$ dspmqaut -m TESTQM -t qmgr -p mqmon
Entity mqmon has the following authorizations for object TESTQM:
inq
set
connect
altusr
setid
setall
$setmqaut -m TESTQM -t q -n SYSTEM.** -g mqmon +allmqi
$dspmqaut -m TESTQM -t q -n SYSTEM.ADMIN.COMMAND.QUEUE -p mqmon
Entity mqmon has the following authorizations for object SYSTEM.ADMIN.COMMAND.QUEUE:
get
browse
put
inq
set
passid
passall
setid
setall
$setmqaut -m TESTQM -t q -n AMQ.** -g mqmon +allmqi
I did issue the REFRESH SECURITY command after doing all these steps.
The following command didn't work but it doesn't matter as I have only system queues in the QMGR.
$setmqaut -m TESTQM -t q -n ** -g mqmon +allmqi
AMQ7096: An authorization specification is required but you did not provide
one.
Usage: setmqaut -m QMgrName [-n ObjName] -t ObjType [-p Principal | -g Group]
[-s ServiceName] Authorizations |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Jul 21, 2004 11:13 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Ok,
I'm going to need more information:
- What version of MQ are you using including CSD?
- What OS is the queue manager running on? Solaris, AIX, Windows? and what version?
So you are using client mode to connect to the queue manager. Are you sure that the SVRCONN channel specified inside MQVB, is the same as the SVRCONN channel on the queue manager (where you added the MCA UserID) ?
Did you stop then restart the SVRCONN channel after you made the changes?
Also, please make sure that you don't have a typo in the MCA UserID field. i.e. mqmon - it is EXACTLY mqmon (5 lower-case characters)
Lets do some very specific tests. But first do the following 3 commands:
- STOP the SVRCONN with mode FORCE.
- Issue the REFRESH SECURITY command
- START the SVRCONN
Now start MQVB and do the following:
Test #1:
- Click File->Open Queue
- Select the Queue Manager and then click the Edit button
- Verify the Remote Parameter values are correct
- Click the Test button
What is the message you get? If you get Successfully connected to the queue manager. then go to test #2.
Test #2:
- Return to the Open Queue Window (press the Cancel button on the previous window)
- In the Queue Name field, input a known valid queue i.e. SYSTEM.DEFAULT.LOCAL.QUEUE and then click the Open button.
What happened? Did you get an error message or did it open the queue? If it opened the queue then go to test #3.
Test #3:
- Click File->Open Queue
- Select the Queue Manager
- Make sure the Mask has the asterisk (*) value
- Click the List button
What happened? Did you get an error message or did it display the List of Queues window?
Please answer the questions at the top and provide as much detail as possible about the test cases.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| Mallik |
| Posted: Wed Jul 21, 2004 12:28 pm Post subject: |
|
|
Acolyte
Joined: 29 Feb 2004
Posts: 53
|
MQVersion: 5.3.0
OS: Solaris 8
I am using the same SVRCONN channel and the MCA user is mqmon lower case.
I stopped the chl, refreshed the security & stareted the chl.
Test#1 Success(earlier also)
Test#2 Success (Didn't test earlier)
Test#3 Failure with 2035
Regarding the stopping the channel and refreshing the security:
1.Created a test queue
2. Tried test #2 got 2035
3. set +allmqi for the test q
4. Tried again the Test #2 and succeed.
5. 2035 when tried Test #3.
So from this test, I am sure the test #1, #2 are fine and using the right MCAUSER & channel. I didn't even issues Refresh security or restart the channel and used the same VB window. But while listing the queues with * and 'Local' I am getting 2035. Not quite sure for which queue its complaining about. One more thing is while the VB is running I just changed the MCAUSER attribute to 'mqm' and it worked fine.
thanks |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Jul 21, 2004 12:49 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Good, tests 1 & 2 work and just the list function is the problem. Give me a little time to test a solution because I think I know what permission is missing.
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| Mallik |
| Posted: Wed Jul 21, 2004 1:54 pm Post subject: |
|
|
Acolyte
Joined: 29 Feb 2004
Posts: 53
|
I have noticed some thing. When I issue dspmqaut against SYSTEM.AUTH.DATA.QUEUE, it gives nothing. I did specifically setmqaut but didn't display anything.
$setmqaut -m TESTQM -t q -n SYSTEM.AUTH.DATA.QUEUE -p mqmon +allmqi
The setmqaut command completed successfully.
$dspmqaut -m TESTQM -t q -n SYSTEM.AUTH.DATA.QUEUE -p mqmon
Entity mqmon has the following authorizations for object SYSTEM.AUTH.DATA.QUEUE:
I understand that this queue holds all authority info. http://www.mqseries.net/phpBB2/viewtopic.php?t=8917&highlight=system+auth+data+queue+setmqaut
Is it some thing thats causing the 2035 error? |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Jul 21, 2004 2:42 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Wow, talk about being on the same page.
That's exactly what I am scratching my head over. I did the same thing as you and got the same results. I tried a bunch of variation and I could not get a non mqm account to have any authority to SYSTEM.AUTH.DATA.QUEUE.
Also, here are the commands for you to partially list queues (with a mask).
| Code: |
setmqaut -m TESTQM -t qmgr -g mqmon +dsp +allmqi
setmqaut -m TESTQM -t q -n SYSTEM.** -g mqmon +dsp +allmqi |
You need the +dsp (display) authority. I have found that you don't need to give access to AMQ** queues. It is because of +allmqi and the fact that it is a temporary dynamic queue.
I will need to update the 'List of Queues' function to skip over the SYSTEM.AUTH.DATA.QUEUE queue. What a pain. 
One other interesting anomaly I noticed, on Windows 2000 with WMQ 5.3 CSD05, this command does work:
| Code: |
| setmqaut -m TESTQM -t q -n ** -g mqmon +dsp +allmqi |
Does anyone from IBM (Jason, Ron, Charlie, etc..) want to comment on these items? Hummmmmmmmm....
Give me a day to update the code, test and post the new version to my web site.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| Mallik |
| Posted: Wed Jul 21, 2004 10:22 pm Post subject: |
|
|
Acolyte
Joined: 29 Feb 2004
Posts: 53
|
I did try the +dsp option in addition to +allmqi before I post here. I didn't get any 2035 error but couldn't see any queues (with mask) as you said. Hope we can make the tool work with +allmqi option.
Thanks again for your help. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Thu Jul 22, 2004 1:06 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Thu Jul 22, 2004 6:33 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
I have added code to work-around the MS0B bug and added code to skip-over SYSTEM.AUTH.DATA.QUEUE queue for non mqm users.
Both MQ Visual Edit and MQ Visual Browse have been updated to v1.2.2C.
Give it a try and let me know if you have any problems.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| Mallik |
| Posted: Sun Jul 25, 2004 10:39 am Post subject: |
|
|
Acolyte
Joined: 29 Feb 2004
Posts: 53
|
Cool its working now. I had to use both +allmqi and +dsp. Need to test and make sure that MO71 doesn't work with these settings.
Thanks Roger.
Madhu. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Sun Jul 25, 2004 2:56 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
Yes, +dsp is required for the List of Queues function because it queries each queue (depending on mask) for the queue's CurrentDepth and QueueType.
Basically, +dsp authority allows the particular group or user to query MQ object's attributes.
My guess is part of MO71 will work like listing queues or displaying attributes but creating, altering and deleting of MQ objects will not work.
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| Seeker |
| Posted: Wed Nov 10, 2004 10:26 am Post subject: Error 2035 on Solaris |
|
|
Newbie
Joined: 07 Oct 2004
Posts: 8
|
Hello Everyone,
I 'am trying to use mqbt.sh on a SUN SPARC machine and I run into error 2035. When I tried to set permissions on the system queues using
setmqaut -m QMRNAME -t queue -n SYSTEM.* -g GROUP +allmqi,
runmqsc reports that the name SYSTEM.* as invalid. Any suggestions of how to issue the command will be greatly appreciated.
I 'am a complete newbie to MQSeries, so please make your suggestions as explicit as possible.
Thanks,
Seeker |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Nov 10, 2004 10:42 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
What version of WMQ are you running?
If you are running WMQ v5.3, then you should read the WMQ System Administration manual, because there is a big difference between using the wildcard of '*' and '**'.
Higher up in this posting chain, my comment was to use (changed name to your style)
| Code: |
setmqaut -m QMRNAME -t qmgr -g GROUP +dsp +allmqi
setmqaut -m QMRNAME -t q -n SYSTEM.** -g GROUP +dsp +allmqi |
The first command allows the program to connect to the queue manager, where as the second command allows the GROUP users to access the queues. (Please pay attention to the double '**' asterisks.) You MUST do BOTH commands, otherwise you will get 2035 (Not Authorized).
Also, make sure you issue the REFRESH SECURITY command after doing the setmqaut commands (or bounce the queue manager).
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
|
|
