| Author |
Message
|
| smeunier |
 Posted: Thu Jun 13, 2013 8:00 am Post subject: CHLAUTH error messages |
 |
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
I have a question regarding what type of errors are generated when a CHLAUTH rule is violated and where they are recorded.
I have recently installed V7.5 on AIX 6.1 I have been doing basic testing to put rule in place to prevent unauthorized QMGR from being added to an existing cluster by putting a rule on the CLUSRCVR channel. The standard default CHLAUTH rules are in place and I added a rule against the CLUSRCVR channel to block all attempts.
| Code: |
SET CHLAUTH('TO.TESTCLUSTER') +
TYPE(ADDRESSMAP) +
ADDRESS('*') +
DESCR('BLOCK ALL ACCESS TO THIS CLUSRCVR CHANNEL') +
USERSRC(NOACCESS) +
WARN(NO) +
ACTION(ADD)
|
I then created a new QMGR, and added it to the Cluster using the usual steps:
- Define CLUSRCVR Channel
- Define CLUSSDR Channel to full repository where the rule is implemented
I checked the AMQERR**.LOG on the FUull Repository QMGR where the rule was implemented and found no message saying that a request had been blocked.
The QMGR is not in the Cluster, so I'm thinking it was blocked. To prove this, I undid the new cluster definitions and re-executed them. The new QMGR was then joined to the Cluster as it should have.
So my question is: with CHLAUTH settings, will blocking be recorded in the error logs? I have WARN(NO) set. |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Thu Jun 13, 2013 8:47 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Hmmm.
According to this:
https://www.ibm.com/developerworks/community/blogs/aimsupport/entry/blocking_ip_addresses_with_chlauth_which_type_to_use?lang=en
| Quote: |
Using TYPE(ADDRESSMAP)
This is the main way you should be setting up IP address rules with CHLAUTH. These rules are applied once data has been flowed so the channel name is available, although as the example above shows, you can still make rules to apply to all channels. This is the type you should use for the majority of your IP address blocking rules. When an inbound connection is blocked as a result of one of these rules, the error message that is written to your error log, and the event message that is written to the SYSTEM.ADMIN.CHANNEL.EVENT queue (if you have channel events enabled), will contain full details about the inbound connection that has been blocked. |
I think you should have sees something in the error log of the QM where the channel was blocked.
Was there anything in the channel event queue on the FR queue manager, assuming you have channel events enabled?
Was there anything in the logs of the Partial Repository QM that whose connection attempt was presumambly blocked by the FR's rule?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Jun 13, 2013 8:47 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
on Windows I see those messages both in the Windows Event Viewer AND in the AMQERR0x.LOG files...
Sorry no AIX available to test but should see the same there except for the Windows Event Viewer of course 
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| smeunier |
| Posted: Thu Jun 13, 2013 9:36 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
Well, there are some events in the Channel Event queue, but I'll have to get an event viewer to decipher them. @Peter, there were no message in the AMQERR**.LOG on either the FR or PR error queues. Just to clarify one aspect, which should not matter, but perhaps it may. The FR Qmgr is on the same server where I created a new PR QMGR to add to the cluster. I would not think this would matter, as I had blocked all ADDRESS(*).
At what point in the process of adding the PR QMGR to the CLUSTER should that error been written to the FR QMGR log, that it was being blocked? I would think when the CLUSSDR channel on the PR QMGR was created and communication tried to be established.
As a matter of fact, with the current rule in place, and the other QMGRS that are members of the CLUSTER already, I would think that they would be getting blocked as well with their sender channels and generating error msgs. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 13, 2013 11:16 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| smeunier wrote: |
| Well, there are some events in the Channel Event queue, but I'll have to get an event viewer to decipher them... |
I believe MO71 has one out of the box... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jun 13, 2013 1:59 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
| smeunier wrote: |
| Well, there are some events in the Channel Event queue, but I'll have to get an event viewer to decipher them... |
I believe MO71 has one out of the box... |
I believe the same of MS0P... .... and several other SupportPacs.... :innnocent: |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 13, 2013 7:53 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mqjeff wrote: |
| fjb_saper wrote: |
| smeunier wrote: |
| Well, there are some events in the Channel Event queue, but I'll have to get an event viewer to decipher them... |
I believe MO71 has one out of the box... |
I believe the same of MS0P... .... and several other SupportPacs.... |
I believe we need an RFE to make an easy location for uninstalling eclipse support packs. It is cumbersome to go hunt them down in the list.
And yes some upgrades require you to uninstall support packs...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jun 14, 2013 2:52 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| you mean... easier than the dropins folder or the links directory? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jun 14, 2013 5:03 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| smeunier wrote: |
| As a matter of fact, with the current rule in place, and the other QMGRS that are members of the CLUSTER already, I would think that they would be getting blocked as well with their sender channels and generating error msgs. |
I agree, although an already running channel will probably continue to run. The rule you implemented there would really prevent the cluster from operating at all. I understand you're doing it just as a test.
And I would expect the QM's error log to be full of messages saying it blocked a connection attempt, one message in the log every time a channel retried.
Sorry for the basic question, but you are checking the Queue Manager MQ error log and not the system's error log, right?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| hughson |
| Posted: Fri Jun 14, 2013 5:43 am Post subject: Re: CHLAUTH error messages |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| smeunier wrote: |
I have a question regarding what type of errors are generated when a CHLAUTH rule is violated and where they are recorded.
I checked the AMQERR**.LOG on the FUull Repository QMGR where the rule was implemented and found no message saying that a request had been blocked.
So my question is: with CHLAUTH settings, will blocking be recorded in the error logs? I have WARN(NO) set. |
CHLAUTH will write error messages to the AMQERR*.LOG as you expect. You can see an example of what you might see in I'm being blocked by CHLAUTH - how can I work out why?. It will additionally write an event message to the SYSTEM.ADMIN.CHANNEL.EVENT queue if you have CHLEV(ENABLED or EXCEPTION).
Since you are testing, one thing to try would be to implement a back-stop rule as described in CHLAUTH - the back-stop rule which you can guarantee will match whatever connection you make into the queue manager, then you can see in the error message that gets written why your other rule wasn't matching (if indeed that is the case).
I do wonder whether you might have the wrong channel name in your rule, so using the back-stop rule will show you that. You don't tell us what the channel names are other than in your example CHLAUTH rule. I do wonder whether you maybe have the name of the CLUSRCVR channel defined on your partial repository in the CHLAUTH rule on your full repository? Whereas what you want is the name of the CLUSRCVR channel on your full repository in the CHLAUTH rule on your full repository. This is just a guess thinking that the name TESTCLUSTER sounds more like a partial repository name than a full repository name!
Also double check that your queue manager has CHLAUTH(ENABLED).
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| smeunier |
| Posted: Fri Jun 14, 2013 6:13 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
| Code: |
Sorry for the basic question, but you are checking the Queue Manager MQ error log and not the system's error log, right?
|
Yes, I'm checking the AMQERRxx.LOG files and the channel event queue. No blocking errors found. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jun 14, 2013 6:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| smeunier wrote: |
| Code: |
Sorry for the basic question, but you are checking the Queue Manager MQ error log and not the system's error log, right?
|
Yes, I'm checking the AMQERRxx.LOG files and the channel event queue. No blocking errors found. |
Are you checking the system level AMQERRxx.LOG files, or the queue manager level AMQERRxx.LOG files? |
|
| Back to top |
|
|
| smeunier |
| Posted: Fri Jun 14, 2013 10:22 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
| Code: |
Since you are testing, one thing to try would be to implement a back-stop rule as described in CHLAUTH - the back-stop rule
|
EXCELLENT! This article helped so much. All is working now. Thanks! |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jun 14, 2013 11:32 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
What did you change?
Why were you not seeing messages in the error log before?
I thought about posting that link for you that Morag did, but it only seemed relevent if you had a message in the error log to begin with and you original problem was that you were not getting any messages in the log.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
