| Author |
Message
|
| any2xml |
 Posted: Sun Oct 17, 2004 10:11 pm Post subject: MO71 - MQ GUI Tool - how to secure + remote admin |
 |
|
Apprentice
Joined: 18 May 2004
Posts: 42
|
Downloaded, installed and enjoying MO71. Thanks Paul!
1. Remote MQ administration
I had to define send/receive channel pairs at the remote qm end as well as the windows end where MO71 is running with a local MQ manager. I understand that there is an alternate way to manage remote QM using just client connection. I just could not figure out how to do it. Our remote qms are on Linux and AS/400.
2. How to secure....
A number of people share the MQ admin / monitoring responsibility. However those who just monitor (our operations people) need not and should not have admin access. Currently we are administering via a local MQ.
Help appreciated.
_________________
A Perl Hacker
http://www.goreliance.com
http://www.any2xml.com |
|
| Back to top |
|
 |
| HugoB |
| Posted: Mon Oct 18, 2004 12:04 am Post subject: |
|
|
Acolyte
Joined: 26 Jun 2001
Posts: 67
|
You should use the SYSTEM.ADMIN.SVRCONN (server connect) channel for this. You only need the MQ server software local, on de MO71 machine,
because of the API. As far as i understand.
I presume AS/400 will not work directly with MO71, i guess you need
something like an Qmgr alias. Not too sur eabout this though.
To secure you have a bit of a problem i think.
When using the server connect channel, you local username
get's parsed to the qmgr you want to modify/monitor.
So you need to define groups on the machine with the qmgr you want to reach with MO71. And make users member of those groups.
Then define with setmqaut, on the machine you want to reach with MO71,
according to you needs, ie +put +get etc.
So it is possible (i did this with the MQExplorer) but it's a bit of work. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Mon Oct 18, 2004 1:27 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
If you are going to use MQExplorer, there is a little bit more work to do.
For example:
The requirement is for userID MYUSER on a Windows machine to be able to perform remote admin on a qmgr called MYQMGR hosted on a remote UNIX machine called tenpin listening on port 1444.
Set up the listener as required.
Start the command server.
Create the SYSTEM.ADMIN.SVRCONN channel.
Auth commands for the user.
tenpin: $ setmqaut -m MYQMGR -t qmgr -p myuser +connect +inq +dsp
tenpin: $ setmqaut -m MYQMGR -t q -n SYSTEM.DEFAULT.MODEL.QUEUE -p myuser +inq +browse +get
tenpin: $ setmqaut -m MYQMGR -t q -n SYSTEM.ADMIN.COMMAND.QUEUE -p myuser +inq +put
The purpose of these commands is:
1. Grant authority to access the qmgr
2. Grant authority to the client channel to get the command server reply messages
3. Grant authority to put messages onto the command server input queue
Administration setmqaut commands, +chg +clr +dlt +dsp, will be required on each object in the qmgr to be administered remotely.
For example, to allow dsp authority on a particular queue QL1:
tenpin:/scratch/nigelg $ setmqaut -m MYQMGR -t q -n QL1 -p myuser +dsp |
|
| Back to top |
|
|
| nathanw |
| Posted: Mon Oct 18, 2004 1:47 am Post subject: |
|
|
Knight
Joined: 14 Jul 2004
Posts: 550
|
of course yu have to ensure that the q manager is set up for remote administration as if it isn't yu may have a problem
i know it is like teaching granma to suck eggs but you would be surprised how many people do not set the q managers up for this. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Oct 18, 2004 5:20 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| nathanw wrote: |
| you would be surprised how many people do not set the q managers up for this. |
There's usually a reason behind it, too. It can be very difficult to secure MQSeries in these days of Java and the blank username.
Not allowing remote administration is a somewhat simpler thing to do than properly securing a queue manager for remote administration.
Particularly if one has a management tool, like contact admin's Contact Admin. Then the management tool handles all of this for you, and again you don't want to provide the means to circumvent the tool.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| any2xml |
| Posted: Mon Oct 18, 2004 9:36 am Post subject: Thank you all for the suggestions |
|
|
Apprentice
Joined: 18 May 2004
Posts: 42
|
Thanks y'all for the guidance and suggestions. I was thinking along the lines of using setmqaut but you have provided me with the details to set up the security.
I will post my results soon. Thanks
_________________
A Perl Hacker
http://www.goreliance.com
http://www.any2xml.com |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Oct 18, 2004 6:38 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| HugoB wrote: |
You should use the SYSTEM.ADMIN.SVRCONN (server connect) channel for this. You only need the MQ server software local, on de MO71 machine,
because of the API. As far as i understand.
I presume AS/400 will not work directly with MO71, i guess you need
something like an Qmgr alias. Not too sur eabout this though. |
I would probbaly set up a dedicated SVRCONN channel for MO71 in client mode, and not use the channel that MQExploer uses, although technically it can work.
On the MO71 machine, you do not need the MQ server software, just MQClient.
AS/400 works just fine with MO71 client connecting to it. I currently have that as one of the QMs I admin with MO71.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
