Can't send message by opcmsg to Openview 8 on vms v8.3.-1h1 without vms privileges

[Eitan Ram]

Hi to all.

Openvms v8.3.1h1 on itanuim server.

HP OpenVMS Operations Manager HTTPS Agents Version 8.6.

When my process have all vms privileges enabled - I can send message to OVO console by opcmsg.

But if I disabled all vms privileges :

$ set proc/priv=(noall,tmpmbx,netmbx)

and try to send message by opcmsg:

$ opcmsg severity=WARNING application=Folder object=TEST -
         msg_text="test message from eitan - ovo8"
The OVO Message Command is not configured on this system.
Contact your OVO Administrator to configure it. (OpC30-913)

The symbol opcmsg is set to:

$ show symbol opcmsg

OPCMSG == "$$1$DGA390:[OVO$COMMON_IA64.OVO.OPT.OV.BIN]OPCMSG.EXE"

It's seems to be a privelege problem of protection on ovo directories.

Any idea?

Thanks, Eitan.

[abrsvc]

I am not familiar with the particular software here, but in generic terms, this is likely to be a priv problem.  Typically, you would not want "normal" users to have elevated privs.  In order to access software like this, the images are usually installed with the appropriate privs.  This will allow the non-priv'd user access to the function without granting privs.  Check the installation guide for OpenView for guidance.  Any required privs or installation instructions should be spelled out there.

Dan

[Eitan Ram]

Hi Dan.

Thank you for your reply.

I tried to install the image with sysprv privilege - but the install failed because this images is linked with /traceback.

Eitan.

[Hoff]

Start with a call to HP support to sort this out, and see if there's a patch or an update for this.  

Or if not, a request logged for a way to generate these messages without requiring privileges.

You could patch the image to remove the traceback flags, or set up a privileged front-end tool or a privileged process to send the messages.  For instance, an installed privileged image that then spawns this one to send the HP OpenView Operations (OVO) messages.  

But before building these tools, a call to HP support will be the lowest-effort approach.  

For whatever reason, the folks that built this tool clearly didn't expect it to be installed.  Which means (barring changes from HP or some coding to work around this), you'll need privileges for this tool.  

And just brute-force installing an image with privileges might well open up security issues, particularly if the tool isn't expecting to operate this environment.  As is apparently the case here.

[H.Becker]

>>> You could patch the image to remove the traceback flags, ...

_IF_  you want to go this route,  have a look at HELP SET IMAGE /FLAGS. NOTBK_IN_IMG is what you are looking for. From the effort point of view, this is competitive with the lowest-effort approach.