| Author |
Message
|
| kayou |
 Posted: Sun Aug 06, 2006 12:15 am Post subject: AMQ4036 mystery !!! Access not permitted. ... |
 |
|
Novice
Joined: 05 Aug 2006
Posts: 21
|
I'm trying Websphere MQ V6 on a home network. I installed Linux version (server) on Fedora Core 3 (192.168.2.10) and windows version (server) on Windows XP Home Edition (192.168.2.11).
All I wanted to do is to start MQ Explorer on the windows machine and to remotely administrate queue managers running on the Linux machine. Windows installation seems to be working fine (MQ Explorer is starting). Linux installation seems also to be correctly running.
But !!! If I try to connect (from MQ Explorer on Windows) to the remote queue manager, I get the following error : "Access not permitted. You are not authorized to perform this operation (AMQ4036)".
After 24 hours googling, I did the following tasks (but, so far, I still have the error and cannot administrate remote the linux WMQ).
Tasks (after server installation on Linux and Windows).
1. Adding an entry for MQSeries in /etc/services.
2. Creating the file MQSeries in /etc/xinetd.d/ (parameter user = mqm).
3. Starting queue manager (strmqm). (on Linux)
4. defining channel SYSTEM.ADMIN.SVRCONN (basic definition, without setting MCAUSER on the channel). (on Linux)
5. Setting env variable MQCCSID on windows to match the Linux CCSID. (on Windows)
6. setmqaut -m QM_TEST -t qmgr -p ... +all (on Linux)
7. I did operation 6 for user MQUSER (I created it on Windows side), for ADMINISTRATO (12 characters limitation), for MUSR_MQADMIN. I created these 3 users in Linux and added them to the mqm group on the Linux machine.
8. Queue Manager is running. Any command submitted by runmqsc is processed by the queue manager. (on Linux)
9. Command processor is running (strmqcsv). (on Linux)
10. Listener is running (runmqlsr). (on Linux)
Could someone tell me what is missing or wrong on Windows and/or Linux side ???
Thanks in advance. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Sun Aug 06, 2006 4:04 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You don't need entries in /etc/services or /etc/xinet.d.
You didn't tell us what user you are logged in as on Windows. It is this user, and this user only, that needs to be authorized on Unix.
You need to run refresh security on the qmgr after changing membership in OS groups, or restart the QM.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kayou |
| Posted: Sun Aug 06, 2006 11:58 am Post subject: |
|
|
Novice
Joined: 05 Aug 2006
Posts: 21
|
- Commented the MQSeries line in /etc/services
- Renamed the MQSeries file for oldMQSeries
- Did (on Linux) : setmqaut -m QM_TEST -t qmgr -g mqm +all
- MQUSER is the Windows user with which I run MQ Explorer, it is added in mqm on Linux
- Did (on Linux) : service xinetd restart
- Did (on Linux) : runmqlsr -m QM_TEST -t TCP -p 1414 &
- Restarted Queue manager
Result :
- A message Box "Trying to connect to queue manager" and impossiple to close it.
- After 10 minutes looping, another message box "AMQ4181 Websphere MQ is not responding". When I try to close it, I se a couple of other message boxes, among them : "AMQ4036 ... " |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sun Aug 06, 2006 1:38 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| kayou wrote: |
- Did (on Linux) : service xinetd restart
- Did (on Linux) : runmqlsr -m QM_TEST -t TCP -p 1414 & |
Don't do EITHER of those for MQ v6.
Don't use xinetd or runmqlsr to start a listener. Create a real listener object using runmqsc "DEFINE LISTENER". And "start listener". Make sure the listener's "control" property is set to "qmgr", and not "manual".
Also, if you did "runmqlsr -m QM_TEST -t TCP -p 1414&" and then logged out, the listener will go away.
Do a "ps -ef|grep mqlsr", and make sure there is a listener running.
You don't need to run setmqaut against the mqm group - it automatically and irrevocably has full authorities for everything. So your setmqaut was redundant.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kayou |
| Posted: Sun Aug 06, 2006 4:57 pm Post subject: |
|
|
Novice
Joined: 05 Aug 2006
Posts: 21
|
I created and started listener.
define listener (MQSERIES.TEST) trptype (TCP) port(1414) control (QMGR)
start listener
I verified the listener "control".
define listener (MQSERIES.TEST)
I see CONTROL(QMGR) for "control" property.
I killed all runmqlsr processes.
I tried to see the queue manager in my windows MQ Explorer. The result is the message box ("trying to connect to queue manager."). After a couple of minutes, a message box with AMQ4181 message displayed. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Aug 07, 2006 12:37 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You mean that you killled all runmqlsr processes, and then STARTED THE LISTENER, right?
Using a real listener object does end up calling runmqlsr. It's just called in a "better" and more manageable way.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kayou |
| Posted: Mon Aug 07, 2006 12:51 am Post subject: |
|
|
Novice
Joined: 05 Aug 2006
Posts: 21
|
Yeap !
I rebooted my Linux system and did only the three things below :
- Starting queue manager (strmqm)
- Creating channel SYSTEM.ADMIN.SVRCONN (under "runmsc" console)
- Creating listener and starting it (under "runmsc" console)
Still have AMQ4036 error. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Aug 07, 2006 2:06 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
So you can see an instance of runmqlsr running when you do a "ps -ef|grep mqlsr".
You can telnet to the listener port from the windows machine just fine.
You have started a command server?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Mon Aug 07, 2006 2:46 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
To begin with have a look in:
/var/mqm/errors/AMQERR01.LOG
and in /var/mqm/qmgrs/<your-qmgr>/errors/AMQERR01.LOG
you can use: tail -100 /var/mqm/errors/AMQERR01.LOG
Then check that the QMODEL(SYSTEM.MQEXPLORER.REPLY.MODEL) exists
Next you can change the MCAUSER on the SVRCONN :
ALTER CHL(SYSTEM.ADMIN.SVRCONN) CHLTYPE(SVRCONN) MCAUSER('mqm')
and add it with runmqsc. This will give you connecting user max auth.
And when you see that this works you can play with the other users....
-- Lock it or Lose it 
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| kayou |
| Posted: Mon Aug 07, 2006 9:07 am Post subject: |
|
|
Novice
Joined: 05 Aug 2006
Posts: 21
|
It works !!!
- Altered the channel with mcauser('mqm'), it works.
- Altered it again with my XP user (MQUSER), it works again.
Thanks a lot ! Thread could be closed. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Aug 07, 2006 9:48 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| kayou wrote: |
- Altered the channel with mcauser('mqm'), it works.
- Altered it again with my XP user (MQUSER), it works again. |
Then perhaps you aren't running your Explorer as "MQUSER", maybe as "DOMAIN/MQUSER" or such.
| kayou wrote: |
| Thanks a lot ! Thread could be closed. |
Edit your original message, and change the subject to add "SOLVED:" to the front.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kayou |
| Posted: Mon Aug 07, 2006 10:25 am Post subject: |
|
|
Novice
Joined: 05 Aug 2006
Posts: 21
|
Sorry, couple of questions attracted by last posts.
1) How could I know which userid MQExplorer sent to queue manager ?
2) Is it possible to run the queue manager in DEBUG mode, so as to see all requests (and parameters) sent to it by clients ?
3) Suppose the channel SYSTEM.ADMIN.SVRCONN is defined with 'mqm' user (not group, I guess). What security check the queue manager does when i recieves my Windows MQUSER against the security of the channel ? Or, does 'mqm' has another meaning than a local Linux user belonging to the 'mqm' group ?
4) Did I need to do a full installation of WMQ on windows side ? Why just a selective installation of MQExplorer would not do the job ? |
|
| Back to top |
|
|
| kayou |
| Posted: Mon Aug 07, 2006 11:15 pm Post subject: |
|
|
Novice
Joined: 05 Aug 2006
Posts: 21
|
| Got the answer for question 4 by doing a selective installation of WMQ explorer and MQclient. It works. |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Mon Aug 07, 2006 11:37 pm Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
About showing (logging) connection attempts, you could try the freeware security exit: BlockIP2.
It can tell you which user is connectiong or trying to..
It's located here BlockIP2
-- Lock it or Lose it --
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| rowles |
| Posted: Mon Aug 07, 2006 11:48 pm Post subject: |
|
|
Acolyte
Joined: 12 Oct 2005
Posts: 51
|
| kayou wrote: |
Sorry, couple of questions attracted by last posts.
1) How could I know which userid MQExplorer sent to queue manager ?
2) Is it possible to run the queue manager in DEBUG mode, so as to see all requests (and parameters) sent to it by clients ?
3) Suppose the channel SYSTEM.ADMIN.SVRCONN is defined with 'mqm' user (not group, I guess). What security check the queue manager does when i recieves my Windows MQUSER against the security of the channel ? Or, does 'mqm' has another meaning than a local Linux user belonging to the 'mqm' group ?
4) Did I need to do a full installation of WMQ on windows side ? Why just a selective installation of MQExplorer would not do the job ? |
Some Answers:
1) The user ID sent by the MQ Explorer is the logged on user that launched the Explorer.
2) There is no "debug mode" as such. But you could use an API exit that could be used to trace the calls, but that is quite an advanced topic.
3) Specifying MCAUSER on the SVRCONN channel means that any application that connects using that channel will have the authority of the user specified on the channel, not the user id sent by the client application. As you have specified mqm, which is mq's adminstration user on unix, this means any application connecting using that channel will have full authority on the queue manager.
_________________
--
Steve. |
|
| Back to top |
|
|
|
|
