| Author |
Message
|
| sclarke |
 Posted: Thu Jan 22, 2015 9:17 am Post subject: Tracking broker administrative changes |
 |
|
Apprentice
Joined: 05 Jan 2002
Posts: 39
|
WMB8 - is there a way in WMB to track that mqsichangeproperty, mqchangeconfigurableservice etc has been run and what the value was changed to? I don't see a way to generate an event from running those commands. What best practices do other admins use to keep track of broker configuration changes on a asset by asset basis... For example - if I changed the maxheapsize on an Execution group, when and potentially the value. I realize you can run mqsireportproperties etc but would like to be more proactive on capturing/auditing changes
thanks. Any differences with IIB9/10? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Jan 22, 2015 9:24 am Post subject: Re: Tracking broker administrative changes |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sclarke wrote: |
| What best practices do other admins use to keep track of broker configuration changes on a asset by asset basis... |
We script such changes and embed them in a change control process, and protect the WMB service id (which is the only id allowed to make such changes) with sudo. AFAIK there's no way to obtain any auditing from WMB itself.
| sclarke wrote: |
| Any differences with IIB9/10? |
Not that I'm aware of.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sclarke |
| Posted: Fri Jan 23, 2015 3:44 am Post subject: |
|
|
Apprentice
Joined: 05 Jan 2002
Posts: 39
|
Does your change control process include source control of the commands that you ran or the scripts output the commands into non-controlled files which can be viewed later?
Thanks! Curious what other companies do? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jan 23, 2015 5:09 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
One can have the world's best change control process, but it still good to be able to independently get notified of changes (think Configuration Events in MQ) or be able to easily audit the environment and compare settings and configurations across multiple Brokers that are supposed to be the same.
A robust tool that can gather configuration settings and store them could also be used to identify what changed when. I think there is a gap in the marketplace in this space. I surprised there is nothing in this space yet. DataPower has the same gap.
Yes, I know WMB/IIB exposes an interface (CMP API) to be able to do this all yourself, but to do that right and make it pretty and user friendly is a big effort, at the bottom of a looooong To Do list for me.
My RFE to have IBM beef up MBX or Web Management Interface to allow us to compare Brokers:
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=55244
Please vote if you think its a good idea.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Jan 23, 2015 5:10 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
When you look at the "admin queue" from message broker explorer - you can see the recent admin commands. Where does that info come from?
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 23, 2015 6:20 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sclarke wrote: |
| Does your change control process include source control of the commands that you ran or the scripts output the commands into non-controlled files which can be viewed later? |
Yes to both. We've modified the deployment process (which deploys bar files to IIB and EAR files to the Java magic) to run the scripts so to get them working they have to be added to source control (which is where the deployment process expects everything to be) and the results are logged in the same way the results of a deployment are logged.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sclarke |
| Posted: Fri Jan 23, 2015 6:29 am Post subject: |
|
|
Apprentice
Joined: 05 Jan 2002
Posts: 39
|
We have a pretty good deployment process. My question/issue is tracking the physical changes made to the broker properties
mqsichangeproperties
mqsicreateconfigurableservice
etc
I just voted on Peter's request. Any other best practices out there?
Good discussion.... |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 23, 2015 6:52 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sclarke wrote: |
We have a pretty good deployment process. My question/issue is tracking the physical changes made to the broker properties
mqsichangeproperties
mqsicreateconfigurableservice
etc |
I know that, and it's exactly those changes I was talking about. Mostly new configurable services for flows with nodes that require them.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
