Author |
Message
|
ivanachukapawn |
Posted: Wed Mar 22, 2006 9:05 am Post subject: |
|
|
 Knight
Joined: 27 Oct 2003 Posts: 561
|
oddly, I just tried starting some Cluster Channels. they are in retry mode. the error logs do not show any errors for this. |
|
Back to top |
|
 |
HubertKleinmanns |
Posted: Wed Mar 22, 2006 9:08 am Post subject: |
|
|
 Shaman
Joined: 24 Feb 2004 Posts: 732 Location: Germany
|
Try a PING CHANNEL(<channel name>). Maybe you see some SSL error message. _________________ Regards
Hubert |
|
Back to top |
|
 |
ivanachukapawn |
Posted: Wed Mar 22, 2006 9:22 am Post subject: |
|
|
 Knight
Joined: 27 Oct 2003 Posts: 561
|
tried a ping. got
'TO.E':Unexpected error. Reason(536909377)
I may have to page down to find this code, it may take a while.
JD |
|
Back to top |
|
 |
HubertKleinmanns |
Posted: Wed Mar 22, 2006 9:42 am Post subject: |
|
|
 Shaman
Joined: 24 Feb 2004 Posts: 732 Location: Germany
|
Did you insert all the self-signed certificates of the QMgrs to all other QMgrs? Otherwise you should get responses like:
- AMQ9641: Remote CipherSpec error for channel '<your channel>'.
- AMQ9636: SSL distinguished name does not match peer name, channel '<your channel>'. _________________ Regards
Hubert |
|
Back to top |
|
 |
ivanachukapawn |
Posted: Wed Mar 22, 2006 9:53 am Post subject: |
|
|
 Knight
Joined: 27 Oct 2003 Posts: 561
|
Yes, each clustered Queue Managers Keystore contains 3 certificates (actually, a lot more public, but the 3 local self-signed are there. I listed them in each Keystore to make sure).
We don't get the error messages you noted. Instead, we just end up with Cluster Sender/Receivers in retry mode. Also, the ping error code I posted a while ago. |
|
Back to top |
|
 |
HubertKleinmanns |
Posted: Wed Mar 22, 2006 12:19 pm Post subject: |
|
|
 Shaman
Joined: 24 Feb 2004 Posts: 732 Location: Germany
|
Please post the contents of your error log files AMQERRnn.LOG. You may also start a trace using the command
Code: |
strmqtrc -m <your_qmgr> -t ssl |
stop the trace using
Code: |
endmqmtrc -m <your_qmgr> -a |
and format the output using
Post the output to us.
By the way, the command
Code: |
REFRESH SECURITY TYPE(SSL) |
you mentioned before, is only valid on z/OS. _________________ Regards
Hubert |
|
Back to top |
|
 |
ivanachukapawn |
Posted: Wed Mar 22, 2006 12:25 pm Post subject: |
|
|
 Knight
Joined: 27 Oct 2003 Posts: 561
|
I'll work on the error logs and traces.
REFRESH SECURITY TYPE(SSL) runs (inside runmqsc) for Solaris Queue Managers and delivers the message - Security has been Refreshed |
|
Back to top |
|
 |
Ivans |
Posted: Wed Mar 22, 2006 10:51 pm Post subject: |
|
|
Apprentice
Joined: 03 Jan 2006 Posts: 48 Location: Hursley
|
Reason(536909377) = x20009641 = AMQ9641...
-------
Remote CipherSpec error for channel <insert_3>.
Severity:
30 : Severe error
Explanation:
The remote end of channel <insert_3> has had a CipherSpec error. The channel did not start.
Response:
Review the error logs on the remote system to discover the problem with the CipherSpec.
-------
So I think that the remote cipherspec either does not match, is blank or is invalid. Can you post the remote error and the local and remote cipherspec info using both DIS CHANNEL and DIS CLUSQMGR?
Cheers,
Ian
WebSphere MQ |
|
Back to top |
|
 |
ayhz2002 |
Posted: Thu Mar 23, 2006 9:46 am Post subject: |
|
|
Newbie
Joined: 30 Jan 2006 Posts: 5
|
|
Back to top |
|
 |
ivanachukapawn |
Posted: Thu Mar 23, 2006 10:36 am Post subject: |
|
|
 Knight
Joined: 27 Oct 2003 Posts: 561
|
Dear AYHZ
This is beautiful! Thanks very much for this article link. It goes against the other advice which I have received which hasn't been working. I will give it a try and let you know.
JD |
|
Back to top |
|
 |
bbburson |
Posted: Thu Mar 23, 2006 11:56 am Post subject: |
|
|
Partisan
Joined: 06 Jan 2004 Posts: 378 Location: Nowhere near a queue manager
|
HubertKleinmanns wrote: |
By the way, the command
Code: |
REFRESH SECURITY TYPE(SSL) |
you mentioned before, is only valid on z/OS. |
It is included for distributed queue managers in v6. |
|
Back to top |
|
 |
Ivans |
Posted: Fri Mar 24, 2006 12:09 am Post subject: |
|
|
Apprentice
Joined: 03 Jan 2006 Posts: 48 Location: Hursley
|
Hi ivanachukapawn,
The article (http://www-128.ibm.com/developerworks/ibm/library/i-supply1j/) has a lot of really useful advice, but may not solve your WMQ clustering problem.
The article instructs to set the SSLCIPH attribute on...
* the full repository cluster receiver channels
* the full repository cluster sender channels
* the partial repository cluster sender channels
But not on the partial repository cluster receiver channels.
This enables SSL on channels....
* From partial repositories to full repositories
* From full repositories to full repositories
But does not enable SSL on channels...
* From full repositories to partial repositories
* From partial repositories to partial repositories
This means the cluster is not fully secure.
Do you have any application traffic being sent to partial repositories that you would like secure? If so, I suggest you put SSL on all your cluster channels. One stumbling block to doing that is that if you alter the channels in the incorrect order, you could get SSLCIPH mismatches, which lead to channel errors (for example, AMQ9641).
Ian
WebSphere MQ |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Mar 24, 2006 1:40 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
D..n cluster channel changes....
They don't take right away... You may have to make your full repository a partial and go back to full again.
You can really only see the attributes being used on the channel when running the dis chs(*) command.
What you see being used on the currently running channel may no longer match what the channel definition looks like (the running version has not caught up to the changes yet).
You may have to stop and restart the channel manually.
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
HubertKleinmanns |
Posted: Sat Mar 25, 2006 6:43 am Post subject: |
|
|
 Shaman
Joined: 24 Feb 2004 Posts: 732 Location: Germany
|
bbburson wrote: |
HubertKleinmanns wrote: |
By the way, the command
Code: |
REFRESH SECURITY TYPE(SSL) |
you mentioned before, is only valid on z/OS. |
It is included for distributed queue managers in v6. |
You are right, I only read the V5.3 docs.
But as far as I know, some of the refresh commands are also callable on V5.3 QMgrs (for compatibility reasons), but will be ignored. _________________ Regards
Hubert |
|
Back to top |
|
 |
|