| Author |
Message
|
| dilep |
 Posted: Tue Sep 02, 2008 6:50 am Post subject: SSL in the MQ cluster |
 |
|
Apprentice
Joined: 27 Nov 2006
Posts: 40
|
Hi,
I am using MQ Cluster. In that two full repository queue mangers and one partial repository queue manger. When I am using , SSLCIPH as TRIPLE_DES_SHA_US for SSL enabling the cluster channels. The cluster channels are working fine.
When I change to SSLCIPH as NULL_SHA in the cluster receiver channel of one of the cluster receiver channel of full repository queue manger and the SSLCIPH as TRIPLE_DES_SHA_US in the partial repository queue manger cluster sender channel.
Normally the channel didn’t start. Because of wrong SSLCIPH in the other side. But when I start the channel, the channel is up.
I have applied refresh security and refresh cluster after changing the SSLCIPH.
Please anyone know ,Is there anything more i want to do for the SSL in cluster setup
Thanks |
|
| Back to top |
|
 |
| zhanghz |
| Posted: Wed Sep 03, 2008 3:00 am Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
this reminds me of a problem that i encountered that couldn't be resolved when we tried to activate SSL in a cluster of 3 QGMRs.. The problem was something like, although SSLCIPH is changed, no SSLCIPH is shown in some channels when displaying CLUSQMGR; and, after SSLCIPH is removed (we decided to revert to no ssl), displaying CLUSQMGR still shows non-blank values in SSLCIPH for some channels.
I remember we tried refresh cluster on both FR and PR qmgrs. Would like to know the resolution to this too..
(monitoring this thread...) |
|
| Back to top |
|
|
| David.Partridge |
| Posted: Wed Sep 03, 2008 5:04 am Post subject: |
|
|
Master
Joined: 28 Jun 2001
Posts: 249
|
You need to remember that a CLUSSDR channel definition that is manually defined is only used as it is defined on two occasions:
1. When the queue manager is initially joining the cluster
2. When a "REFRESH CLUSTER(name) REPOS(YES) command is issued.
The rest of the time the queue manager will use a dynamically created channel definition for the cluster sender channel based upon the CLUSRCVR definition for the other end of the channel that it has been sent from a full repository queue manager.
So changing the SSLCIPH setting on the CLUSSDR will (most of the time) have absolutely no effect.
HTH
_________________
Cheers,
David C. Partridge |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Sep 03, 2008 6:01 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| David.Partridge wrote: |
You need to remember that a CLUSSDR channel definition that is manually defined is only used as it is defined on two occasions:
1. When the queue manager is initially joining the cluster
2. When a "REFRESH CLUSTER(name) REPOS(YES) command is issued.
|
Only in the case of PR's I believe...
_________________
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 |
|
|
| David.Partridge |
| Posted: Wed Sep 03, 2008 6:29 am Post subject: |
|
|
Master
Joined: 28 Jun 2001
Posts: 249
|
No, this happens even on a Full Repository QM. The MCA will always override any manually defined CLUSSDR definition with the information from the cluster repository for the associated CLUSRCVR except for the occasion where the FR is joining the cluster for the first time.
Obviously you can make further overrides to the MQCD before the channel actually starts using a CHAD exit, but that's not strictly relevant to the discussion at hand.
The "refresh cluster(name) repos(yes)" case doesn't apply for an FR QM of course because that can only be issued from a PR QM.
_________________
Cheers,
David C. Partridge |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Sep 03, 2008 6:49 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Hit the button before checking that I'd chopped all that I needed 
Question: Why then do the explicit FR CLUSSDR's stay lit up in 'normal' operation if they are not used?
_________________
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 |
|
|
| David.Partridge |
| Posted: Wed Sep 03, 2008 7:09 am Post subject: |
|
|
Master
Joined: 28 Jun 2001
Posts: 249
|
Not sure what you mean by saying "stay lit up".
Yes, there's a definition there with a particular name such as TO.QMB.
Yes, you can do a dis chs('TO.QMB') and it will tell you its running.
But that's got nothing to do with how the MCA builds the MQCD control block that is used for the channel instance as it starts up under normal conditions. That is (mostly) taken from the information for the CLUSRCVR at the other end of the channel.
ISTR there may be one or two things that are still inherited from the manual CLUSSDR definition, but which they are I can't remember (its been a long while since I worried about that).
If you really need that level of detail you'd need to apply a suitable libation of beer (or maybe thumbscrews  ) to Paul (or whoever currently owns the MCA code). Morag may also know that stuff ...
_________________
Cheers,
David C. Partridge |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Sep 03, 2008 11:51 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Thank you. Every day I realise how little I know about WMQ, how much more I have to learn, and how many misconceptions have crept in in the short time I've been doing this!
It's the status that had me fooled, especially when using WMQExplorer (and even z/OS showed the channels 'lighting up' in the panels on a recent test [yesterday]).
_________________
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 |
|
|
| zhanghz |
| Posted: Wed Sep 03, 2008 6:32 pm Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
ah, well, i don't quite get this.. OK, i know now that the spot light is on CLUSRCVR, but when we enable SSL on the channels, of course we alter all cluster channels on all the 3 QMGRs in the cluster, including CLUSRCVR channels obviously. But why we got this blank SSLCIPH value for some channels when displaying clusqmgr?
What should be correct steps of enabling SSL in a cluster then?
ps: i know there is an article on this which involves creating a new set of cluster channels with SSLCIPH specified on all QGMRs in a cluster etc. Any other easy way of doing this? by simply altering existing cluster channels SSLCIPH value?
Thanks. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Sep 03, 2008 7:15 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Sep 03, 2008 7:19 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| zhanghz wrote: |
What should be correct steps of enabling SSL in a cluster then?
ps: i know there is an article on this which involves creating a new set of cluster channels with SSLCIPH specified on all QGMRs in a cluster etc. Any other easy way of doing this? by simply altering existing cluster channels SSLCIPH value?
Thanks. |
IBM didn't come up with 2 ways to add SSL to a cluster and then publish an article on the more difficult way, keeping the easier way secret. While you might get it to work temporarily skipping steps, you're best bet is follow the documentation in that Developerworks article every step of the way. That's good advice for anything MQ cluster related - follow the doc.
If you can incur outages while you implement SSL, you can do it over the existing channels. Doing it over new channels affors you the luxury of taking as long as you want to do it with no pressure as you work the kinks out.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zhanghz |
| Posted: Wed Sep 03, 2008 8:41 pm Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
| PeterPotkay wrote: |
IBM didn't come up with 2 ways to add SSL to a cluster and then publish an article on the more difficult way, keeping the easier way secret. While you might get it to work temporarily skipping steps, you're best bet is follow the documentation in that Developerworks article every step of the way. That's good advice for anything MQ cluster related - follow the doc.
If you can incur outages while you implement SSL, you can do it over the existing channels. Doing it over new channels affors you the luxury of taking as long as you want to do it with no pressure as you work the kinks out. |
Thanks. Suggest IBM put this in the manuals or redbook. Not every one will google or search in ibm.com..
I looked throught that article, there is one step we can't do, not sure how you guys handle that. The step is "check that the new SSL channels can transmit messages successfully". This steps involves sending test messages into cluster queue which we can't do as the queues all have triggering.
Can I bypass this step and go directly stop existing non-SSL cluster channels and delete them later after making sure SSL cluster channels are in RUNNING status? |
|
| Back to top |
|
|
| zhanghz |
| Posted: Wed Sep 03, 2008 8:44 pm Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
well, ok, guess we can remove triggering during testing... sorry for posting the question without thinking through first.. 
guess we are too conservative.. unwilling to do anything that might be unnecessary or that might cause problems... |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Sep 04, 2008 3:10 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
You should a have set of your own MQ Admin test queues defined in the cluster that allow you to put and get messages without using application queues. Anytime we make any changes to our cluster we run thousands of messages via script thru our test queues to insure every QM can successfully send and receive messages from any other QM.
There is no need to remove triggering on application queues. You can implement and test SSL in the cluster without any application impact.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zhanghz |
| Posted: Thu Sep 04, 2008 8:08 am Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
| thanks peter. right, i didn't think of creating test cluster queues in production environment and forgot that clusters use the default (so no need to define any new transmission queue) cluster transmission queue for sending messages... Will see whether this can be done in my environment. |
|
| Back to top |
|
|
|
|
