| Author |
Message
|
| brian_r |
 Posted: Wed Apr 08, 2009 2:06 am Post subject: MQSSL SVRCONN channels |
 |
|
Apprentice
Joined: 28 Jan 2008
Posts: 31
Location: Dublin
|
Hi All,
Had a look through all documentation regarding SSL on SVRCONN channels. Am I right in saying that in order for this to be set up, you need a CLNTCONN channel created on the same QM, which will exchange client connection tables to the client machine?
Thanks in advance |
|
| Back to top |
|
 |
| exerk |
| Posted: Wed Apr 08, 2009 2:11 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
The CLNTCONN can be defined on any queue manager, and the CCDT file exported to the client machine. If the client application is utilising MQCONNX you do not need a CCDT.
_________________
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: Wed Apr 08, 2009 2:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
But you're correct in saying that to use SSL you need a CCDT - you can't use the MQSERVER environment variable.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| brian_r |
| Posted: Wed Apr 08, 2009 2:25 am Post subject: |
|
|
Apprentice
Joined: 28 Jan 2008
Posts: 31
Location: Dublin
|
Great thanks,
So when I configure the parameters to use SSL through the SVRCONN channel the messages will still use the SVRCONN channel as opposed to the CLNTCONN channel with the same name? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Apr 08, 2009 2:32 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| brian_r wrote: |
Great thanks,
So when I configure the parameters to use SSL through the SVRCONN channel the messages will still use the SVRCONN channel as opposed to the CLNTCONN channel with the same name? |
No.
The client side of a client connection is *always* using a CLNTCONN. The server side is *always* using a SVRCONN. The two *always* have the same name.
The only choice you have is in how you define the CLNTCONN. the MQSERVER environment variable defines it for you. The Client Channel Table lets your MQ Administrator define it. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 08, 2009 2:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| brian_r wrote: |
| So when I configure the parameters to use SSL through the SVRCONN channel the messages will still use the SVRCONN channel as opposed to the CLNTCONN channel with the same name? |
CLNTCONN and SVRCONN are 2 ends of the same connection; much like (but not the same as!) a sender and receiver are 2 ends of the same channel.
All the MQSERVER environment variable does is create a CLNTCONN for you.
The Clients manual explains all of this much better than I do. With diagrams.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Apr 08, 2009 2:36 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| brian_r wrote: |
Great thanks,
So when I configure the parameters to use SSL through the SVRCONN channel the messages will still use the SVRCONN channel as opposed to the CLNTCONN channel with the same name? |
The CLNTCONN is not a channel as such, but as a list of attributes populated into a file, that can be 'read'. I'm not sure of the best way to describe it; I tend to think of it as a means to provide an abstracted MQCONNX facility to an application, without the application having to do the hard work.
I'm sure my master will be along in a moment to beat me about the head for such a woolly (or possibly drivelling) statement.
EDIT: And as if by magic, two of them pop up! Awaiting the wrath...
_________________
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: Wed Apr 08, 2009 2:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| I'm sure my master will be along in a moment to beat me about the head for such a woolly (or possibly drivelling) statement. |
I know what you're trying to say and even I didn't understand that...
| exerk wrote: |
| EDIT: And as if by magic, two of them pop up! Awaiting the wrath... |
Just pointing out you need to be faster.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Apr 08, 2009 2:44 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Mea culpa...
_________________
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 |
|
|
| mqjeff |
| Posted: Wed Apr 08, 2009 3:01 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| I know what you're trying to say and even I didn't understand that... |
| Vitor wrote: |
| Just pointing out you need to be faster. |
|
|
| Back to top |
|
|
| brian_r |
| Posted: Wed Apr 08, 2009 3:34 am Post subject: |
|
|
Apprentice
Joined: 28 Jan 2008
Posts: 31
Location: Dublin
|
| exerk wrote: |
| brian_r wrote: |
Great thanks,
So when I configure the parameters to use SSL through the SVRCONN channel the messages will still use the SVRCONN channel as opposed to the CLNTCONN channel with the same name? |
The CLNTCONN is not a channel as such, but as a list of attributes populated into a file, that can be 'read'. I'm not sure of the best way to describe it; I tend to think of it as a means to provide an abstracted MQCONNX facility to an application, without the application having to do the hard work.
I'm sure my master will be along in a moment to beat me about the head for such a woolly (or possibly drivelling) statement.
EDIT: And as if by magic, two of them pop up! Awaiting the wrath... |
Thanks for the response, not hazey at all
So, to clarify, in theory I create a CLNTCONN channel on the same QM as the SVRCONN channel. However its never actually references its only used to create the channel table file, which can then be transferred to the client, when MQSERVER is not an option.
Thanks to all!! |
|
| Back to top |
|
|
| brian_r |
| Posted: Wed Apr 08, 2009 3:37 am Post subject: |
|
|
Apprentice
Joined: 28 Jan 2008
Posts: 31
Location: Dublin
|
| My previous post is assuming Client and server are on different servers btw |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 08, 2009 3:38 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| brian_r wrote: |
| Thanks for the response, not hazey at all |
Don't encourage him.... 
| brian_r wrote: |
| So, to clarify, in theory I create a CLNTCONN channel on the same QM as the SVRCONN channel. However its never actually references its only used to create the channel table file, which can then be transferred to the client, when MQSERVER is not an option. |
Almost - as my inarticulate apprentice managed to say clearly, there's no requirement to create the CLNTCONN on the same qmgr. You can and it'll work fine, but you can define the CLNTCONN on any queue manager and transfer it as you indicate.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Apr 08, 2009 3:45 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Vitor wrote: |
| brian_r wrote: |
| Thanks for the response, not hazey at all |
Don't encourage him.... |
You make me spend too much time in the dark... 
_________________
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: Wed Apr 08, 2009 3:57 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| You make me spend too much time in the dark... |
Or not enough. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
