| Author |
Message
|
| JohnSmith |
 Posted: Tue Jun 01, 2010 1:50 am Post subject: Tracking the BAR file to a particular Host/System |
 |
|
Voyager
Joined: 17 Mar 2010
Posts: 86
|
we are having a team of developers who all are having a common server (DEV, OS is AIX) where the Message broker is running, after developing the flow and testing them into their local server, they release it to our DEV server which is done by each of them individually. everyone is using a common user ID which has permission on that server.
Right now we are facing problem when someone tamper with some of the common flows (i.e. by mistake someone deploy something which is not a working version and replace the already existing common flows), it ends up being all other flows throwing errors.
When we try to look for the source of that common flow Bar file, there are only 2 places we have to look for the same'
1. In the message broker toolkit Domain perspective, look for flow properties, which only show the BAR file with directory location and the deployment time.
2. Go to SYSLOG at AIX system and browse the logs, it shows as something like this -
| Quote: |
un 1 17:30:21 barb020c WebSphere Broker v6105[1122380]: (BROKER1.EG11.EG1)[19535]BIP2152I: Configuration message received from broker. : BROKER1.918bed1d-2701-0000-0080-fbbfe61bb34a: /build/S610_P/src/DataFlowEngine/ImbConfigurationNode.cpp: 275: ImbConfigurationNode::evaluate: :
Jun 1 17:30:21 barb020c WebSphere Broker v6105[1122380]: (BROKER1.EG1)[19535]BIP2153I: About to 'change' an execution group. : BROKER1.918bed1d-2701-0000-0080-fbbfe61bb34a: /build/S610_P/src/DataFlowEngine/ImbConfigurationNode.cpp: 278: ImbConfigurationNode::evaluate: :
Jun 1 17:30:23 barb020c WebSphere Broker v6105[1122380]: (BROKER1.EG1)[19535]BIP2154I: Execution group finished with Configuration message. : BROKER1.918bed1d-2701-0000-0080-fbbfe61bb34a: /build/S610_P/src/DataFlowEngine/ImbConfigurationNode.cpp: 493: ImbConfigurationNode::evaluate: : |
[/color][/color]
it doesn't show as anything about the IPaddress/HostName of the server where the request has come from.
Is there any way we can log or track the Hostname who has deployed a particular BAR file.
Our Message Broker environment details - OS - AIX, Message Broker V6.1 |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Jun 01, 2010 2:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You appear to be using v6.1 - you might find something in the logs on the ConfigMgr machine.
If you're using v7... there is no ConfigMgr.
Regardless, if you need to identify specific actions to specific users, you should stop using a generic user for all actions. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 01, 2010 2:41 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Also, since it is a DEV environment and you're not using it for more structured testing, you might consider giving every developer their own EG. Then they can deploy and test things without impacting the common flows that someone else has running. |
|
| Back to top |
|
|
| vmcgloin |
| Posted: Tue Jun 01, 2010 4:01 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
We use a similar setup - deploys are through Hudson but we log in to that with our own username - so deploys can be tracked there.
Also, we can see the BAR file name (including path) in the toolkit. So if people are deploying bar's from their own workstations then you could insist that they use identifiable paths or bar file names.
Even better use the Version number at the flow level along with your source control system and track changes that way. |
|
| Back to top |
|
|
| JohnSmith |
| Posted: Tue Jun 01, 2010 4:04 am Post subject: |
|
|
Voyager
Joined: 17 Mar 2010
Posts: 86
|
| Quote: |
You appear to be using v6.1 - you might find something in the logs on the ConfigMgr machine.
If you're using v7... there is no ConfigMgr.
Regardless, if you need to identify specific actions to specific users, you should stop using a generic user for all actions.
|
Jeff, both configMgr and Broker is running on the same system, well I understand that in case of AIX system there is only one place where we can look for broker logs which is syslog, and it is not showing me the HOSTNAME of the system.
| Quote: |
| Also, since it is a DEV environment and you're not using it for more structured testing, you might consider giving every developer their own EG. Then they can deploy and test things without impacting the common flows that someone else has running. |
Well, it is although a developer environment but we do have some restrictions on execution group distributement (we have distributed them based on the back end apps), now if the back end app is same, then each and every interface to that back end goes to same execution group which is also having common flows related to that back end. Now, we do not want developers to play around out of curiousity or unknowingly on that server(they each have their own local system with all the software installed on it).
well I am quite surprised that a sophisticated tool like Broker doesnt have the logging facility to record hostname/IPaddress of the system who is messing around with it. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 01, 2010 4:11 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| JohnSmith wrote: |
| well I am quite surprised that a sophisticated tool like Broker doesnt have the logging facility to record hostname/IPaddress of the system who is messing around with it. |
It has sophisticated interfaces with source code control tools like CVS & (as my worthy associate points out) Hudson.
It also has the tracking features the same poster correctly pointed out.
It also has a rich & granular security system to control access.
If you've chosen not to use some or all of that (like using a generic id) the tool can't be blamed.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| JohnSmith |
| Posted: Tue Jun 01, 2010 4:20 am Post subject: |
|
|
Voyager
Joined: 17 Mar 2010
Posts: 86
|
sorry vitor, I think the reply from vmcgloin came at the same time when I posted my post, so I probably skipped the part.
vmcgloin wrote:
| Quote: |
We use a similar setup - deploys are through Hudson but we log in to that with our own username - so deploys can be tracked there.
Also, we can see the BAR file name (including path) in the toolkit. So if people are deploying bar's from their own workstations then you could insist that they use identifiable paths or bar file names.
Even better use the Version number at the flow level along with your source control system and track changes that way. |
vmcgloin, I can only say that your infrastructure is very good, we are also planning to use Hudson in the higher environment where we will handover the server to infrastrucutre team but for for our developer level we do not have such tools with us.
Clear case versioning is also a good approach and to some extent using the "identifiable paths" can also help us but it is not a fool proof solution.
well, these are things we have to take care in the future but here the dispute is going on regarding a past deployment done yesterday. well, it created some internal politics issue so I thought if we have any way of finding out the IP address, we would have the better control. It would just help in our team in the long run. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 01, 2010 4:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| JohnSmith wrote: |
| well, these are things we have to take care in the future but here the dispute is going on regarding a past deployment done yesterday. well, it created some internal politics issue so I thought if we have any way of finding out the IP address, we would have the better control. It would just help in our team in the long run. |
Moving away from a generic ID for all deployments is the better solution and will help give you better control and will be better help to your team in the long run.
They will *know*, then, that they can't hide from fault and will be more careful. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jun 01, 2010 4:38 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Yes, avoid shared ids (and therefore shared passwords).
Set up the WMQ and WMB access control lists based on groups, not userids.
(These are new groups in addition to the use of mqm or mqbrkrs group).
Add the appropriate users to the group(s) that will give them the required access. Don't add them to mqm or mqbrkrs unless they need full admin access.
That way you have low maintenance and individual accountability and no more risky shared passwords. |
|
| Back to top |
|
|
| mqmatt |
| Posted: Tue Jun 01, 2010 6:20 am Post subject: |
|
|
Grand Master
Joined: 04 Aug 2004
Posts: 1213
Location: Hursley, UK
|
For V6.1, you'll need to look in the event log, like you suggest. The CM didn't really do audit information.
V7 is a lot more powerful in this regard, as you have the Administration Log which says who attempted what and when. |
|
| Back to top |
|
|
|
|
