| Author |
Message
|
| pintrader |
 Posted: Tue Jul 08, 2014 10:36 pm Post subject: Understanding MQ on different platforms |
 |
|
Disciple
Joined: 22 Jan 2014
Posts: 164
|
hi,
I am trying to understand how MQ on different platforms interact. So I setup a test Solaris virtual machine and setup a trial version of Solaris MQ v8 on it.
I have also installed Windows MQ v7.5 on my own laptop computer (running the Solaris VM as well) .
Then I follow the docs to setup Qmgrs and all.
These are the steps I have done:
Windows (Acting as sender to Solaris VM)
1) crtmqm WINDOWS
2) define qlocal(WINDOWS.LOCAL.Q) usage(xmitq)
3) define qr(WINDOWS.REMOTE.Q) rname(SOLARIS.LOCAL.Q) rqmname(SOLARIS) xmitq(WINDOWS.LOCAL.Q)
4) define channel(WINDOWS.SOLARIS.TCP) chltype(SDR) trptype(TCP) conname('SOLARIS_MQ(1416)') xmitq(WINDOWS.LOCAL.Q) REPLACE
Solaris VM( Acting as receiver)
1) crtmqm SOLARIS
2) define qlocal(SOLARIS.LOCAL.Q)
3) define channel(WINDOWS.SOLARIS.TCP) chltype(RCVR) trptype(TCP)
4) define LISTENER(SOLARIS.LISTENER) trptype(TCP) CONTROL(QMGR) PORT(1416)
5) start LISTENER(SOLARIS.LISTENER)
I have turned off windows firewall as well as firewall from Solaris. However the sender channel is always retrying..I couldn't seem to start it. A view at the AMQERR01.log file show this:
| Code: |
AMQ9999: Channel 'WINDOWS.SOLARIS.TCP' to host 'SOLARIS_MQ(1416)' ended
abnormally.
EXPLANATION:
The channel program running under process ID 10344(6288) for channel
'WINDOWS.SOLARIS.TCP' ended abnormally. The host name is 'SOLARIS_MQ(1416)'; in
some cases the host name cannot be determined and so is shown as '????'.
ACTION:
Look at previous error messages for the channel program in the error logs to
determine the cause of the failure. Note that this message can be excluded
completely or suppressed by tuning the "ExcludeMessage" or "SuppressMessage"
attributes under the "QMErrorLog" stanza in qm.ini. Further information can be
found in the System Administration Guide. |
Any help on this is appreciated. thanks.
Here is the next part I am confused, assuming the error above is solved. After defining the necessary channels etc, i suppose the next thing is to give permissions to use the channels or the queues right? Or there is no need to , for this testing purpose ? Is it by the default that the channel can be used straight away?
If its a server connection (SVRCONN) channel being defined on Solaris, i guess we have to create a unix user eg user1 and then give it mqm group. AFter that from the client side, use user1 to connect to solaris MQ? If so, is it something like this to be defined at the Solaris MQ:
set authrec profile(WINDOWS.SOLARIS.TCP) principal(user1) objtype(CHANNEL) authadd(ALL,ALTUSR)
thanks |
|
| Back to top |
|
 |
| w33f |
| Posted: Tue Jul 08, 2014 10:59 pm Post subject: |
|
|
Novice
Joined: 07 Nov 2013
Posts: 17
|
Is that the logs on your windows box? What do the ones on your solaris ones say? Can you telnet from the windows box to the solaris hostname/port successfully?
Also why do you want to give a user mqm access connecting through a SVRCONN channel? Is this for your client/Application? If so I'd strongly recommend NOT granting that access! |
|
| Back to top |
|
|
| MQsysprog |
| Posted: Tue Jul 08, 2014 11:14 pm Post subject: |
|
|
Centurion
Joined: 24 Feb 2014
Posts: 116
|
I would add also a ping done on the sender channel side ,a browse on the windows logs ,and qmanager logs as said before by w33f searching for a return code and a good inspection on the tcp/ip status of the solaris machine .
Good Luck |
|
| Back to top |
|
|
| pintrader |
| Posted: Tue Jul 08, 2014 11:19 pm Post subject: |
|
|
Disciple
Joined: 22 Jan 2014
Posts: 164
|
| w33f wrote: |
Is that the logs on your windows box? What do the ones on your solaris ones say? Can you telnet from the windows box to the solaris hostname/port successfully?
|
yes that's from windows AMQErr01 log. The solaris's amqerr01 log doesn't have much information. Yes I can use SSH (using plink) from windows to Solaris successfully. But plink gives fatal error : FATAL ERROR: Server unexpectedly closed network connection
Also, I followed the doc and edited the inetd.conf
MQSeries stream tcp nowait mqm /opt/mqm/bin/amqcrsta -m SOLARIS
I am not sure if this is needed at all or not since I have already created a listener?
| w33f wrote: |
Also why do you want to give a user mqm access connecting through a SVRCONN channel? Is this for your client/Application? If so I'd strongly recommend NOT granting that access! |
hi, that's why i am confused. Say If my client application wants to connect directly to Qmgr, i should define the channel as type SVRCONN right? then at the client app, they will specify a user id to connect to. In this case, the user id should be a Solaris user id right? And should I place this user id into the mqm group? or is it not necessary to give this user id any group.
thanks |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jul 09, 2014 5:01 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
MQ, even at v8, makes no use at all of the OS user/group registry on the client end. So it doesn't make any difference at all what you set up on any client server in terms of users or groups.
Before MQ v8, MQ does not authenticate users at all, it merely authorizes them. It can authenticate *certificates*, but not *users*.
Before MQ v8, all authorization happens relative to the OS user/group registry on the queue manager machine.
At MQ v8 or later, you can *optionally* use a separate LDAP that is *not* the OS level user/group registry to authenticate users and then authorize them. |
|
| Back to top |
|
|
| pintrader |
| Posted: Wed Jul 09, 2014 5:17 am Post subject: |
|
|
Disciple
Joined: 22 Jan 2014
Posts: 164
|
| mqjeff wrote: |
Before MQ v8, MQ does not authenticate users at all, it merely authorizes them. It can authenticate *certificates*, but not *users*.
Before MQ v8, all authorization happens relative to the OS user/group registry on the queue manager machine.
|
thanks. can i then say that, in order to let some client connect and use my MQ server resources, i first have to create a Solaris user, eg user1, grant it to some group (not necessary the mqm group) defined by business requirement, and then ask the application team to use user1 to connect to my MQ server. ?
At the MQ server, i can give just permissions to a group instead of a user , as I may have more users coming in the future. right?
thanks |
|
| Back to top |
|
|
| pintrader |
| Posted: Wed Jul 09, 2014 5:19 am Post subject: |
|
|
Disciple
Joined: 22 Jan 2014
Posts: 164
|
| w33f wrote: |
Is that the logs on your windows box? What do the ones on your solaris ones say? Can you telnet from the windows box to the solaris hostname/port successfully?
! |
thanks all. I manage to solve the first network connection problem. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jul 09, 2014 6:09 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| pintrader wrote: |
| thanks all. I manage to solve the first network connection problem. |
By doing what exactly?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jul 09, 2014 6:12 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| pintrader wrote: |
| mqjeff wrote: |
Before MQ v8, MQ does not authenticate users at all, it merely authorizes them. It can authenticate *certificates*, but not *users*.
Before MQ v8, all authorization happens relative to the OS user/group registry on the queue manager machine.
|
thanks. can i then say that, in order to let some client connect and use my MQ server resources, i first have to create a Solaris user, eg user1, grant it to some group (not necessary the mqm group) defined by business requirement, and then ask the application team to use user1 to connect to my MQ server. ? |
No. You tell them what channel to use and put MCAUSER(user1) on that channel. |
|
| Back to top |
|
|
| pintrader |
| Posted: Wed Jul 09, 2014 6:39 am Post subject: |
|
|
Disciple
Joined: 22 Jan 2014
Posts: 164
|
| bruce2359 wrote: |
| pintrader wrote: |
| thanks all. I manage to solve the first network connection problem. |
By doing what exactly? |
hi
instead of using my laptop to communicate with one VM, i use 2 VMs instead. both running on virtualbox and host only adapter. I am not a trained VM person so i do not know how to configure my laptop to talk to VM. Anyways, using 2 vm with same product works for me.
thanks |
|
| Back to top |
|
|
| pintrader |
| Posted: Wed Jul 09, 2014 6:41 am Post subject: |
|
|
Disciple
Joined: 22 Jan 2014
Posts: 164
|
| mqjeff wrote: |
No. You tell them what channel to use and put MCAUSER(user1) on that channel. |
ok thanks. but this "user1" id would still need to be created using useradd on Solaris right? does it need to be mqm group as well ?
Also, i read in the docs, if I don't put an userid in MCAUSER (ie leave blank), then the client can connect using whatever id . Isn't this a better method? because in the future there would be many more clients connecting to the MQ server.
thanks |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jul 09, 2014 7:07 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| pintrader wrote: |
| Also, i read in the docs, if I don't put an userid in MCAUSER (ie leave blank), then the client can connect using whatever id . Isn't this a better method? |
No, because they can use any id including mqm. They then have full administravtive control over the queue manager.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| pintrader |
| Posted: Wed Jul 09, 2014 6:00 pm Post subject: |
|
|
Disciple
Joined: 22 Jan 2014
Posts: 164
|
| Vitor wrote: |
| pintrader wrote: |
| Also, i read in the docs, if I don't put an userid in MCAUSER (ie leave blank), then the client can connect using whatever id . Isn't this a better method? |
No, because they can use any id including mqm. They then have full administravtive control over the queue manager. |
Hi if that's the case, how does one in the industry do it.?
for example, many clients will be authenticating through the application, they cannot be using the same Solaris userid to log in. They would have logged in using their own id, which is what I meant by creating these userid in Solaris.
Is the "user" specified in MCAUSER field ie (MCAUSER('user') ) specific to MQ internally? Or it should be a user account in a Windows or Unix environment..?
thanks |
|
| Back to top |
|
|
| w33f |
| Posted: Wed Jul 09, 2014 6:16 pm Post subject: |
|
|
Novice
Joined: 07 Nov 2013
Posts: 17
|
| pintrader wrote: |
| Vitor wrote: |
| pintrader wrote: |
| Also, i read in the docs, if I don't put an userid in MCAUSER (ie leave blank), then the client can connect using whatever id . Isn't this a better method? |
No, because they can use any id including mqm. They then have full administravtive control over the queue manager. |
Hi if that's the case, how does one in the industry do it.?
for example, many clients will be authenticating through the application, they cannot be using the same Solaris userid to log in. They would have logged in using their own id, which is what I meant by creating these userid in Solaris.
Is the "user" specified in MCAUSER field ie (MCAUSER('user') ) specific to MQ internally? Or it should be a user account in a Windows or Unix environment..?
thanks |
Vitor's comment was the reason I said not to give their MCA user membership of the mqm group. Doing this gives them full control over the qmgr to create/delete anything they want.
Assuming all clients connecting through the SVRCONN channel require the same access, you should create a separate group for them (either using local groups or through the domain) and give them permission only on what they need.. e.g. +connect access to the qmgr, +put and +get access on only the relevant queues etc. |
|
| Back to top |
|
|
| pintrader |
| Posted: Wed Jul 09, 2014 8:05 pm Post subject: |
|
|
Disciple
Joined: 22 Jan 2014
Posts: 164
|
| w33f wrote: |
Vitor's comment was the reason I said not to give their MCA user membership of the mqm group. Doing this gives them full control over the qmgr to create/delete anything they want.
Assuming all clients connecting through the SVRCONN channel require the same access, you should create a separate group for them (either using local groups or through the domain) and give them permission only on what they need.. e.g. +connect access to the qmgr, +put and +get access on only the relevant queues etc. |
thanks. clearer now on this part.
I tried using the amqsbcg to view the message from Solaris.
-bash-4.1$ amqsbcg SOLARIS.LOCAL.Q SOLARIS
AMQSBCG0 - starts here
**********************
MQOPEN - 'SOLARIS.LOCAL.Q'
MQGET of message number 1, CompCode:0 Reason:0
****Message descriptor****
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 546 CodedCharSetId : 1208
Format : 'MQSTR '
Priority : 0 Persistence : 0
MsgId : X'414D5120544553542E57494E444F57537937BD5320012A02'
CorrelId : X'000000000000000000000000000000000000000000000000'
BackoutCount : 0
ReplyToQ : ' '
ReplyToQMgr : 'TEST.WINDOWS.QMGR '
** Identity Context
UserIdentifier : 'administrato'
AccountingToken :
X'160105150000007FADE5DDE1C60FD082D9E166F401000000000000000000000B'
ApplIdentityData : ' '
** Origin Context
PutApplType : '11'
PutApplName : 'Sphere MQ\bin\MQExplorer.exe'
PutDate : '20140710' PutTime : '04171098'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'
**** Message ****
length - 17 of 17 bytes
00000000: 7465 7374 3132 3331 3233 3132 3331 3233 'test123123123123'
00000010: 31 '1 '
I have a question on UserIdentifier : 'administrato. I am logged in as Administrator on the windows VM. So when I put a message across to the Solaris VM, 'administrato' is not defined in Solaris as a user. So shouldn't MQ reject this message? I did not put any userid in MCAuser field of the sender channel properties, hence I guess this is what is meant by any user can connect.
So i can conclude that MQ by default allows anyone to connect and put message even though there is no such user account defined. The next crucial step we should do is to use SET AUTHREC/CHLAUTH or setmqaut to give permissions. Is my understanding correct? thanks |
|
| Back to top |
|
|
|
|
