ucx$mgt_thresholds - WBEM interface

[Zeni B. Schleter]

Is anyone familiar with the WBEM interface on OpenVMS for HP Insight manager and had the problem of the thresholds not working?

We have one cluster for which all is well and another for which all is well with the exception of the thresholds. I doubt its usefulness in our situation but it annoys me that I cannot find out what is wrong the setting the thresholds.

I found a thread with Google on another site that said deleting the Ucx$mgt_thresholds.dat and the UCX$mgt_thresholds.bak will for the software to rebuild the files when the WBEM software is restarted. Now the CPQTHRESHOLD.log says it has an error linking to the ucx$mgt_thresholds.dat and .bak files but it does not create any new .dat file. There will be a new .bak file with 0(zero) blocks.

I have been revisiting the online manuals relating to this on both the HP/Compaq site and the Process software Multinet site. I am tripping over whatever it is but can not seem to see it.

I have sent a message to Process support to get the command for looking at the SNMP configuration more fully.

TIA,
-Zeni

[Volker Halle · Accepted solution]

Zeni,

I'm not too much familiar with the WBEM agents, but have been running them on some of our systems 'just for fun'.

The files SYS$SYSTEM:ucx$mgt_thresholds.* most certainly do not belong to UCX/TCPIP, but to WBEM. None of the TCPIP$*.EXE images include references to those files. It seems to only be used by cpqthresh_mib.exe.

You can manually run CPQTHRESH_MIB.EXE with trace and debug (and $ SET WATCH FILE/CLASS=MAJOR) e.g.

$ cpqt:==$SYS$SPECIFIC:CPQTHRESH_MIB.EXE
$ set watch file/class=MAJ
$ cpqt -warn -error -trace

It tries to access ucx$mgt_thresholds.dat and .bak and creates a new .bak file if it didn't find one. It then complains with the 'error linking sys$system:ucx$mgt_thresholds.dat and sys$system:ucx$mgt_thresholds.bak' message.

It does not create a new .dat file.

You can manually copy the .bak to .dat. CPQTHRESH_MIB will then delete the .dat file and create a new .dat file from the old .bak. You can edit the .DAT file and insert text, but you have to know the syntax, otherwise you'll get:

WARNING CPQTHRESHOLDMGMT_PERSIST.C line 478: badly formatted persistence record: TEST

I tried this with V82_MGMTAGENTS V3.1-5

Volker.

[Volker Halle]

Zeni,

the HP Insight Management Agents for OpenVMS Release Notes Version 3.3 (available via OpenVMS F8.3 fieldtest) include the following section:

2. Problems Corrected
...
. OpenVMS Management Agents do not allow setting of Disk/CPU/Memory thresholds
...

I'll give it a try.

Volker.

[Richard Whalen]

A few months ago I reported to HP a problem with setting thresholds from TCPware or MultiNet until I had set up TCP/IP Services for the management agents. I would expect that this would be fixed in upcoming releases.

Richard Whalen,
Process Software.

[Volker Halle]

Zeni,

I've installed V83_MGMTAGENT V3.3-1 on our OpenVMS Alpha F8.3 field test system running TCPIP T5.6, but I can't get Save Thresholds to work. I can move the threshold indicators and 'Reset to Origianl Values' works as well, but clicking on 'Save Thresholds' clears the frame in the page and then nothing happens. Refreshing the page shows the (orignally disabled) threshold indicators.

If I delete the ucx$mgt_thresholds.* files, only a new/empty ucx$mgt_thresholds.bak file will be created after WBEM$STARTUP.

Volker.

[Volker Halle]

Zeni,

if you have the WBEM thresholds working on one of your system, which version of WBEM and what does the contents of the ucx$mgt_threshold.dat look like ?

Volker.

[Zeni B. Schleter]

I left out of my original post that our systems are v7.3-2 ES47s with Multinet 4.4a. Thresholds manipulation is working on one set of clustered hosts. The thresholds are not working on the other. When you display a page that is supposed to allow manipulation there should be the boxes at the bottom for "reset originals" and "save" . I am not getting the bottom of those pages.

Whatever is supposed to go out and poll the devices to build the ucx$mgt_thresholds.dat file is not working. All I get is the null ucx$mgt_thresholds.bak file.

I tried running the cpqthresh_mib with debug as you suggested. After the initial , status successful for finding required images, there is warning about the missing .Dat file and if the .Bak is missing an warning about that but it creates the .Bak (null) file. Then there is an error about unable to link to the files. Then it talks to agentX apparently successfully. One of the early requests to the AgentX gets a "request denied" response but thereafter there are three "time to poll" message , followed by an "are you there" and a response back from AgentX that appears to confirm that it is responsive.

Sorry , I cannot attach the results. I will look at them more closely and I will try it on one of the systems where the thresholds are working for comparison.

It has been a while but I thought my co-worker (who manages the hosts where the thresholds work) could not save the settings at one time but the account was missing the WBEM administrator identifier.

the ucx$mgt_thresholds.dat on the system where it works contains SNMP information as best I can tell for communiting with the devices (?). The syntax looks like something that I saw when reading about the SNMP. eg.
1 1 4 3 30 05 03 4 1
1.3.6.1.4.1.232.11.2.4.1.1.1.5.1.
17
Insight Web Agent
8
-device
similar number strings
then 17 Insight Web Agent 8
- another device
similar number strings
- ad nauseum

I think I tried copying over the .dat file and got the error message about unable to read the syntax. All the information was wrong for that host ...

Volker,
thanks for looking. Some of the errors that you see are the ones that I see.

I tried reinstalling on one of the hosts in the hope that a minimal (but functional) ucx file would be created. That didn't happen.

I don't think I am dealing with a bug as such. It is working on a similar set of hosts with same software. There is just so many minor tweaks that have to be done when installing it, that I have missed something.

[Volker Halle]

Zeni,

in case of the missing 'Reset threshold' and 'Save threshold' buttons, I had to edit the SYS$SPECIFIC:[WBEM.WEB.IM.WEBAGENT]WEBAGENT.INI file

change IDS_SNMP_WRITE_COMMUNITY=noelmginkgo
to IDS_SNMP_WRITE_COMMUNITY=elmginkgo

AND also execute:

$ TCPIP SET CONFIGURATION SNMP/COMMUNITY="elmginkgo" -
/TYPE=(WRITE)/ADDRESS=127.0.0.1

(or the equivalent command for Multinet). Followed by a restart of SMNP and WBEM.

Volker.

[Zeni B. Schleter]

The WebAgent.Ini file has been edited. With Multinet , community settings are done with the SNMPD.CONF file and then reloading the SNMP$SERVER. I have checked security settings and locations of the added TCPIP images. I have compared the .INI and the SNMPD.CONF file with the hosts where the thresholds work.

I tried removing the READ access from the public community and found that I could get only minimal information with WBEM software.

I have considered adding Write/Traps access to the public just to see if that makes a difference. If it does, then I know that somehow my community setup is wrong.

I found the TCPIP command for checking the community configuration. I asked Process Support for a similar command. What I got was more of a dump of the MIB counters, I think; results from elmginkgo specification were the same as with public. just the counters were slightly different due to the time elapsed. This may be normal.

[Volker Halle]

Zeni,

I could finally get 'Save Thesholds' to work with the following command:

$ TCPIP SET CONFIGURATION SNMP /FLAG=SETS

and re-starting both SNMP and WBEM. The file sys$system:ucx$mgt_thresholds.dat gets created and written to.

You might need to find the equivalent command for Multinet.

Volker.

[Richard Whalen]

One thing to verify for MultiNet and TCPware is the community settings in the SNMPD.CONF file. You'll want to have the following:

community elmginkgo 127.0.0.1 write
community elmginkgo write
community public 0.0.0.0 read

And in SYS$SYSROOT:WEBAGENT.INI
you want the following:
IDS_SNMP_WRITE_COMMUNITY=elmginkgo

"elmginkgo" can be changed, just make sure that all get changed the same way.

[Richard Whalen]

I just tried on one of my systems running V3.3-1 of the management agents and I was not able to set thresholds until I had done the following commands:
$ TCPIP SET CONFIG/COMMUNITY="elmginkgo"/type=write

So, I do not believe that V3.3-1 has fixed the problem that I reported earlier this year.

[Zeni B. Schleter]

Volker, I have been going round in circles trying to fit that command for SETS to the multinet form. I did not find any references to "SETS" in the multinet manual relating to the SNMP server.

Robert, I had the loopback address for Public. I have changed it to 0.0.0.0 and have reloaded SNMP server and restarted the WBEM software. No difference.

I copied over the ucx$mgt_thresholds.dat from the other host. Restarting the WBEM gave me the graphics as if the thresholds had been set where the two system matched. But there was no response when I tried to change them. The "picture" was all I got - no substance. When I stopped and restarted, the file was replaced with a new file that contained just the first few lines.

I tried adding "SETS" in to the community settings like READ, WRITE, and TRAPS. I got the message in the SNMPSERVER.LOG that it encountered a error.

Thanks for the effort.

[Zeni B. Schleter]

FWIW The SNMPD.CONF has entries for
community public 0.0.0.0 READ
community elmginkgo 127.0.0.1 READ
community elmginkgo 127.0.0.1 WRITE
community elmginkgo 127.0.0.1 TRAPS
community public xx.xx.xx.xx READ
community elmginkgo xx.xx.xx.xx READ
community elmginkgo xx.xx.xx.xx WRITE
community elmginkgo xx.xx.xx.xx TRAPS

AGENTX_PEER 127.0.0.1
AGENTX_PEER host's ip address

I can't seem to find any reason why the UCX$MGT_THRESHold.dat is not created. It must be failing in it polling somehow. In using the cpqt setup that Volker described, I did the output changed slightly when the UCX$MGT_THRESHold.dat had a bit of a few records. That would lead me to believe that
the cpqt was using the UCX$MGT_THRESHOLDS.DAT for input.

[Volker Halle]

Richard,

the necessary command:

$ TCPIP SET CONFIG/COMMUNITY="elmginkgo"/type=(write)/ADDRESS=127.0.0.1

is described in the Installation Guide, but only in chapter 6 ( Smart Array Agent Configuration ), so it is NOT obvious, that it's also REQURIED to make 'Save Thresholds' work.

But the User Guide Chapter 2 (Enabling SNMP Traps) lists those commands:

$ TCPIP SET CONFIGURATION SNMP/FLAG=SETS

$ TCPIP SET CONFIGURATION SNMP/COMMUNITY="elmginkgo" -
_$ /TYPE=(WRITE)/ADDRESS=127.0.0.1

$ TCPIP SET CONFIGURATION SNMP/COMMUNITY="elmginkgo" -
_$ /TYPE=(WRITE)/ADDRESS=ip_address

Volker.

[Richard Whalen]

Zeni,

Your SNMPD.CONF looks good. Try doing the TCPIP SET CONFIG SNMP/COMMUNITY="elmginkgo"/type=write/address=127.0.0.1 command. There is no equivalent MultiNet command. This is the bug that I mentioned earlier. You may have to reboot the system without MultiNet running to use enough of TCP/IP services to get this to work.

Volker,

I work for Process Software, not HP, so I can't do much to improve their documentation.

Richard Whalen

[Zeni B. Schleter]

??? Both clusters are using Multinet - the one where thresholds work and the one where thresholds don't work. Why would changing something in the TCPIP$CONFIGURATION make a difference. As soon as I return to MULTINET, the change would be lost, right?

[Richard Whalen]

Zeni,

I understand the idea that the change would be lost when you return to MultiNet after making the TCP/IP Services change, but that is not the case. The TCPIP SET CONFIG command modifies something in TCPIP$CONFIGURATION.DAT. One of the processes involved in setting thresholds reads this file, even though it shouldn't (when it isn't running under TCP/IP Services).

Richard

[Zeni B. Schleter]

Very Interesting. This could be the key but I would never have guessed it. The hosts where the thresholds are working never had TCPIP installed on them. We had just extracted the necessary TCPIP images from the distribution. The hosts where it is not working did have TCPIP installed. I had tried using in briefly but removed it from the startup files. Information in any of the TCPIP*.dat files would be erroneous.

On one of the hosts, I tried renamimg the .DAT files to something else and tried restarting SNMP and WBEM. That did not make any difference. Later today I will try a reboot. If that doesn't work, I will try the turning-off of Multinet (reboot) and modify TCPIP (with the .DAT files back to original) and then reboot again.

I will definitely post if this resolves my mystery.

[Volker Halle]

Richard,

I have been informed (via PTR), that the Management Agents V3.4 Installation Guide has been updated with references to the User's Guide for enabling the SETS and SNMP traps with TCPIP.

Volker.

[Zeni B. Schleter]

Without rebooting, I put the tcpip*.dat files back to original names. I executed Sys$startup:tcpip$startup.com. I got a message about no license. I invoked TCPIP and made the following changes.
SET CONFIG SNMP/FLAG=(SETS,AUTHEN_TRAP)
SET CONFIG SNMP/COMMUNITY="elmginkgo"/TYPE=(read,write,trap)/ADDR=127.0.0.1
SHOW CONFIG SNMP/FULL

I added in the ip-address of the host for the elmginkgo but that may be unnecessary.

I stopped and restarted the WBEM tool. Everything starts but WBEM$SERVER dies quickly. Looking at the WEBSERVER.LOG the following is given:
Enter CpqHmmoConfigureHTTPServer...
......past config active disc, error = 9
......past clear reconnect flag, error = 9
Leave CpqHmmoConfigureHTTPServer...
Leave HMMOStartupHTTPServer, error= 9
HTTP Server did not start
:
WBEM$Server proceeds to exit handler

I feel like I am closer but the results don't bear it out. Rebooting may take care of some inconsistency that I have added by changing the TCPIP configuration the way I did.

[Volker Halle]

Richard,


The TCPIP SET CONFIG command modifies something in TCPIP$CONFIGURATION.DAT. One of the processes involved in setting thresholds reads this file, even though it shouldn't (when it isn't running under TCP/IP Services).


I tested this theory by setting an ALARM ACE on TCPIP$CONFIGURATION.DAT and yes, TCPIP SET CONF SNMP accesses this file, but none of the WBEM$* processes seem to access this file during startup or when saving thresholds (at least when running TCPIP).

Volker.

[Zeni B. Schleter]

Though the TCPIP issue seems compelling, after setting the SNMP in the configuration file and rebooting with Multinet, I still do not have ucx$mgt_thresholds.dat file and the threshold functions still are not displayed at the bottom of the pages that are supposed to have those options.

I could go back and rename the tcpip*.dat files and reboot. Maybe their presence is a problem.

[Zeni B. Schleter]

Rename all TCPIP*.dat files in Sys$Startup and Sys$syste to .DAT_OLD . Rebooted. No change.

I have compared the results of the cpqt trace on the system with thresholds to one that doesn't and the initial sequence is very similar.

[Richard Whalen]

I put an alarm ACE on SYS$SYSTEM:TCPIP$CONFIGURATION.DAT and did not get any alarms while starting the agents or setting thresholds under TCPware. (The test system is running TCPware at the moment; TCPware and MultiNet's SNMP Agent are build from common sources.)

Richard