Highlighted
Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..
155 views

Message Action Signature error messages for automatic actions

Jump to solution

Hi,

OBM 2019.05 Classic on Windows with OA 12.05 on RHEL-nodes. OBM comprises a primary and a backup DPS and two active GWS' (with a load balancer in front of them).

In this environment, on one of the monitored RHEL-nodes we have deployed a set of policies where one of the (Logfile Entry) policies reads a log and upon a match runs opcmon as an automatic command to return a value to a second (Measurement Threshold) policy. It all works like a charm, BUT after each such execution of opcmon we receive a pair of error messages from one of the GW's (sometimes GW1, sometimes GW2):

MessageActionSignatureChecker.checkOk(121) - Resulting from previous checks, this Action is not trusted
MessageActionSignatureChecker.checkOk(117) - The action signature check finally failed fro action call: 'opcmon myReceivingPolicyNameHere=1'

These two events always appear in pairs, and I can see that they are actually fetched from the opr-gateway.log file on the GW-servers.

Furthermore if we look into the events created by the first LE-policy (these events are sent directly to the closed state), I can see that they automatic commands are not at all visible there. They have i.e. been removed, although like mentioned above they are indeed executed.

One more comment; If we run the same opcmon command either locally on the monitored node, but even from the command line on one of the GW-servers towards/on the node in question by means of the "ovdeploy" command, we do NOT receive such error messages in the event browser. And the opcmon command (even then) works fine.

BR,
Frank Mortensen
Managon AB

Labels (1)
0 Likes
1 Solution

Accepted Solutions
Highlighted
Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..

Hi again,

I have now found the cause of this problem, and I assume it relates to a bug.

When using policy parameters as part of the automatic command (it probably even applies to operator commands), this problem occurs. I used such a parameter to represent the other policy name that opcmon should return its value to.

When having this problem, the action per se is actually executed as it should, but all traces of the action is removed from the event that is being generated, and you get the two previously mentioned error events alternately from the GWS's.

When I replaced the policy parameter in the action with a hardcoded value, the error events ceased to arrive and we can now see the action details in the events. Fortunately, we can live with this alternative for the policy in question.

It should also be mentioned that I have previously tried to upgraded the OA in question to v12.11, removed the cert and obtained a new one (ovcert -certreq) and redeploying all policies, but none of this helped.

BR,
Frank Mortensen

View solution in original post

0 Likes
3 Replies
Highlighted
Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..

@FrankMortensen have you migrated this machine from one OBM to another? or any recent Change with your certificates? if it is MOM Setup, it could be that mgrconf policy is missing. there could be several such reasons.

i faced similar Problem for first time when we migrated from OMW to OMi and then recently when we replaced self signed certificate with Company signed certificate.

-KAKA-

0 Likes
Highlighted
Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..

Thanks, Kaka. No we have not carried out any changes like that lately.

But I reckon I should try to reinstall the agent on the node in question, or even upgrade it while I am at it.

Cheers,
Frank

0 Likes
Highlighted
Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..

Hi again,

I have now found the cause of this problem, and I assume it relates to a bug.

When using policy parameters as part of the automatic command (it probably even applies to operator commands), this problem occurs. I used such a parameter to represent the other policy name that opcmon should return its value to.

When having this problem, the action per se is actually executed as it should, but all traces of the action is removed from the event that is being generated, and you get the two previously mentioned error events alternately from the GWS's.

When I replaced the policy parameter in the action with a hardcoded value, the error events ceased to arrive and we can now see the action details in the events. Fortunately, we can live with this alternative for the policy in question.

It should also be mentioned that I have previously tried to upgraded the OA in question to v12.11, removed the cert and obtained a new one (ovcert -certreq) and redeploying all policies, but none of this helped.

BR,
Frank Mortensen

View solution in original post

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.