
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
I've been working on an action connector following this guide, but I've run into two major problems. Does anyone have any advice for solving either problem?
The first problem is that I can't get the action to show up in the "CounterACT" section of the "Send Command" menu. I have created a winaction.counteract.properties file that rests in the $ARCSIGHT_HOME\user\agent\flexagent folder. The agent.properties file specifies agents[0].configfile=winaction. Even after restarting the connector service and refreshing the connector on the ESM (via right-click menu), the command doesn't show up.
Pasted below is my winaction.counteract.properties file.
command.count=1
command[0].name=urllookup
command[0].displayname=URL-lookup
command[0].parameter.count=1
command[0].parameter[0].name=hex
command[0].parameter[0].displayname=Hex
command[0].action=C:\\...\\python.exe C:\\...\\urlLookup.py ${hex}
As an alternative, I configured an "Execute Command" in an ESM rule with action type "Run on Connector(s)". I configured my script the same way with the same parameters, and it appears to run properly, but times out (see below).
[2013-08-26 16:32:18,780][ERROR][default.com.arcsight.tools.process.c][run] Killed process: java.lang.ProcessImpl@134c0a6 (C:\...\python.exe C:\...\urlLookup.py <param> -- null) after 30002 (timeout was: 30000)
[2013-08-26 16:32:18,785][ERROR][default.com.arcsight.common.ib.a][executeCommand]
java.lang.Exception: Command [] did not finish in time [30000]
In the agent.properties file, there is a 'script timeout' line:
agents[0].scripttimeout=30000
I changed the value to '500000', but the error above still appears for me. My script's logs confirm that the timeout is interrupting the script before it finishes executing. Is there any way to extend this timeout?
Accepted Solutions

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Michael,
I ended up addressing this issue another way. One option that I considered (somewhat hacky) would be to create a new script that simply calls your real script. If your new script doesn't wait for the real script to finish, the real script could theoretically run as long as necessary. Of course, you'll have to develop a separate method for logging script status and the like (could even write a CEF log file/syslog stream and read that back into ArcSight).
So the logical flow would be:
1) ESM calls script1.sh.
$ cat script1.sh
script2.sh <param1> <param2>
2) script1.sh calls script2.sh
$ cat script2.sh
<real actions you want to take>
Let us know if that solves the problem ...
Jordan

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Jordan,
Did you ever get this solved? I am having the same issue.
Thanks,
-George

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Michael,
I ended up addressing this issue another way. One option that I considered (somewhat hacky) would be to create a new script that simply calls your real script. If your new script doesn't wait for the real script to finish, the real script could theoretically run as long as necessary. Of course, you'll have to develop a separate method for logging script status and the like (could even write a CEF log file/syslog stream and read that back into ArcSight).
So the logical flow would be:
1) ESM calls script1.sh.
$ cat script1.sh
script2.sh <param1> <param2>
2) script1.sh calls script2.sh
$ cat script2.sh
<real actions you want to take>
Let us know if that solves the problem ...
Jordan

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Thanks Jordan.
I ended up using your recommended method. I also checked with HP directly (via Service Request) and the rep acknowledged that this is the proper workaround (i.e., there's no config item to extend the timeout for the 'ESM execute command' action). I appreciate your help.
Mike