Wednesday, September 17, 2014

HP OM - Policy Administration




Policies determine the action to be taken as a result of events that are intercepted.
To be more clear, policies are like a set of rules based on which monitoring takes place.

Policies need to be assigned and distributed to managed nodes from the management server. This can be done either from command line or from admin GUI (version 9)[motif GUI in version 8].

opctemplate / ovpolicy are the commands used for policy management. 

Assigning a policy:

A policy needs to be assigned to the node that it will be distributed to.
Assignment can be done either from the command line using opcnode command or from the GUI options.

opcnode -assign_pol pol_name=<> pol_type=<> [version=<>] [mode=<>] node_name=<>net_type=NETWORK_IP 
OR
opcnode -assign_pol pol_name=<> pol_type=<> [version=<>] [mode=<>] group_name=<>

where pol_type can be     TEMPLATE_GROUP
                                       CONSOLE_TEMPLATE
                                       OPCMSG_TEMPLATE
                                       LOGFILE_TEMPLATE
                                       MONITOR_TEMPLATE
                                       SNMP_TEMPLATE
                                       EC_TEMPLATE
                                       SCHEDULE_TEMPLATE
Version is the version of the policy you want to assign.
mode is  the way a policy is assigned to a node. This can be  FIX (default)
                                                                                           MINOR_TO_LATEST
                                                                                           LATEST

Distributing a policy :

After assigning a policy, the policy can be distributed using the opcragt command

opcragt -distrib [ -policies ][ -templates ][ -instrum ][ -actions ][ -monitors ][ -commands ] [ -subagts ] [ -force | -purge ] [ -highprio ] [ -simulate ] 

-force => The data is transferred even if it exists already on the node.
-purge => Instrumentation is removed from the node and deployed again.
-highprio => will ignore limitations set on the number of simultaneous deployments                              and immediately trigger the deployment to the specified node.
-simulate => only a simulation, the files/policies will not be distributed to the node.

Listing policies on the managed node :


opctemplate / ovpolicy can be used to list all the policies distributed to the managed node.
# opctemplate -list
       * List installed policies for host 'localhost'.

     Version            Status
 --------------------------------------------------------------------

CONFIGSETTINGS      "OVO settings"              enabled    1
LOGFILE             "<******>log"               enabled    0001.0006
mgrconf             "OVO authorization"         enabled    1
MONITOR             "<******************>"      enabled    0001.0000
OPCMSG              "<******************>"      enabled    0001.0004
SCHEDULE            "<*********************>"   enabled    0001.0004
SNMPTRAP            "<*****************>"       enabled    0001.0013

# ovpolicy -list
       * List installed policies for host 'localhost'.

     Version            Status
 --------------------------------------------------------------------
configsettings    "OVO settings"              enabled    1
le                "<******>log"               enabled    0001.0006
mgrconf           "OVO authorization"         enabled    1
monitor           "<************>"            enabled    0001.0004
msgi              "<******************>"      enabled    0001.0004
sched             "<*********************>"   enabled    0001.0004
trapi             "<*****************>"       enabled    0001.0013


Remote listing policies on the mgd node from the management server :

# ovpolicy -list -host <******>
       * List installed policies for host '<******>'.

     Version            Status
 --------------------------------------------------------------------
  configsettings    "OVO settings"              enabled    1
  le                "<LOGFILE POLICY NAME>"     enabled    0001.0000

Removing policies on the managed node :

On the managed node :
ovpolicy -remove -all 

Describing a policy on the node :


Policies are stored on the managed node in the location  /var/opt/OV/datafiles/policies under the directories for specific type of policy.

# ls -lrt
total 28
drwxrwxr-x 2 root root 4096 Jul 16 19:06 configsettings
drwxrwxr-x 2 root root 4096 Aug 11 15:25 le
drwxrwxr-x 2 root root 4096 Sep 11 11:59 msgi
drwxrwxr-x 2 root root 4096 Sep 12 17:42 monitor
drwxrwxr-x 2 root root 4096 Sep 12 17:58 trapi
drwxrwxr-x 2 root root 4096 Sep 12 17:58 sched

drwxrwxr-x 2 root root 4096 Sep 17 12:07 mgrconf

Each policy will have a data file and a header xml file. The data file is the one that is the policy.
[>>:/var/opt/OV/datafiles/policies/trapi]
# ls -lrt
total 88
-r--r----- 1 root root  9171 Jul 16 19:06 0<***>0_data
-r--r----- 1 root root 11051 Jul 16 19:06 7<***>0_data
-r--r----- 1 root root 29541 Jul 16 19:06 b<***>0_data
-r--r----- 1 root root  1281 Aug 11 15:25 c<***>0_data
-r--r----- 1 root root  3333 Aug 11 18:12 7<***>0_header.xml
-r--r----- 1 root root  3331 Aug 11 18:13 b<***>0_header.xml
-r--r----- 1 root root  3326 Aug 11 18:13 c<***>0_header.xml
-r--r----- 1 root root  3302 Aug 11 18:13 0<***>0_header.xml
-r--r----- 1 root root  3271 Sep 12 17:58 8<***>0_header.xml
-r--r----- 1 root root  4450 Sep 12 17:58 8<***>0_data

Doing a grep on the files for the policy name would yield the file name for that particular policy.
# grep "<NAME OF POLICY>" *
c<***>0_data:SNMP "<NAME OF POLICY>"

c<***>0_header.xml:   <name><NAME OF POLICY></name>


Thursday, January 19, 2012

Reset CoreID of Management Server - OMU v8



Lets jump a few step ahead. I wanted to share something that I learnt today.
Suppose the CoreID of the management server got reset or deleted by some reason, we would need to reset it to the value that was there previously.

To get the previous CoreID, we can run the following command either on the management server or on the management node. 
On the management server :


[root@management_server:/root]
# ovcert -list
+---------------------------------------------------------+
| Keystore Content                                        |
+---------------------------------------------------------+
| Certificates:                                           |
|     0e86<******>5 (*)                                   |
|     9109<******>d (*)                                   |
+---------------------------------------------------------+
| Trusted Certificates:                                   |
|     CA_0e86<******>5                                    |
|     CA_543b<******>a                                    |
|     CA_7ac7<******>5                                    |
|     CA_d385<******>e                                    |
+---------------------------------------------------------+

+---------------------------------------------------------+
| Keystore Content (OVRG: server)                         |
+---------------------------------------------------------+
| Certificates:                                           |
|     0e86<******>5 (*)                                   |
+---------------------------------------------------------+
| Trusted Certificates:                                   |
|     CA_0e86<******>5 (*)                                |
|     CA_543b<******>a                                    |
|     CA_7ac7<******>5                                    |
|     CA_d385<******>e                                    |
+---------------------------------------------------------+

On the Managed node 


[root@managed_node:/root]
# ovcert -list
+---------------------------------------------------------+
| Keystore Content                                        |
+---------------------------------------------------------+
| Certificates:                                           |
|     beb5<******>1 (*)                                   |
+---------------------------------------------------------+
| Trusted Certificates:                                   |
|     CA_0e86<******>5                                    |
|     CA_543b<******>a                                    |
|     CA_7ac7<******>5                                    |
|     CA_d385<******>e                                    |
+---------------------------------------------------------+

Usually, if there is one management server in the environment, there would be only certificate listed under the  'Trusted Certificates' list. 
Note : On the management server, under 'Trusted Certificates' the certificate listed with (*) at the end is the CoreID of that particular server.
Similarly on the managed node, the certificate marked with (*) is the CoreID of that particular managed node.

Since I have got multiple management server in my environment, there are a whole lot listed here.

So, lets proceed with the output from the managed node.
"0e86<******>5" is the CoreId of this managed node's primary management server.

To reset your management server's CoreID, go to the management server and

[root@management_server:/root]

#ovcoreid -set < Certificate ID > -force


[root@management_server:/root]

#ovcoreid -set 0e86<******>5 -force

Another Procedure would be to use the config file to set the CoreID.

[root@management_server:/root]

#ovconfchg -ns sec.core -set CORE_ID 0e86<******>5






Friday, January 13, 2012

Remote administration of HPOM managed agent processes


The HPOM managed nodes can be remotely administered from the management server.  

opcragt -<options> <node_name>
Using the above command without any options will return the status of all the agent processes on the managed node. There is a long list of options that can be used with this command. We shall see the most commonly used ones.

On the managed node, ovcd and ovbbccb should be running for the management server to access the agent process information remotely.

The commonly used options are :

# opcragt [ -help | -start | -stop | -status | -primmgr | -distrib | -agent_version | -cleanstart ] <-all | -managed_node | -managed_node_group>

-help : Displays the usage message.
-start / -stop / -status : As we have seen in earlier posts ( and as the name suggests), these are to start the agent, stop the agent and check the status of the agent.
C:\Documents and Settings\lawrence>opcragt <managed node>
Node: <managed node>
OVO Managed Node status :
-------------------------

OV Control ovcd (2092) is running
OV Performance Core coda (3252) is running
OV Communication Broker ovbbccb (2528) is running
OV Config and Deploy ovconfd (2760) is running

Subagent EA:
Message Agent opcmsga (3312) is running
Message Interceptor opcmsgi (3352) is running
Action Agent opcacta (3408) is running


Remote administration completed successfully on all nodes. 
-cleanstart : Removes all the files in the temp directory of the managed node. Start or Restart the agent on the specified managed node.
-distrib : Used to distribute templates, monitors, commands, actions, instrumentation to the managed node. This command can be used with specific options -templates / -actions / -monitors / -commands. -force or -purge can also be used with this command.
-agent_version : Returns the version number of the HPOM agent software that is currently installed on the managed node.
-version : Returns the version of the opcragt tool.
-primmgr : Updates the primary management server of the managed nodes to the this server. This can run for all nodes, specific node or for a node group.
/opt/OV/bin/OpC/opcragt -primmgr [-all | [-nodegrp <group>…] <node>…]

>> Refer the man page of opcragt for more detailed explanation.

Discovering the Network in NNM v7.5x




After we have NNM installed and running, we need to add devices to NNM for monitoring. In this post we shall see the basics of the discovery process in NNM.

Discovering the network in NNM can be done automatically or in a controlled manner, i.e. > Automatic Discovery 
> Manual Discovery
Automatic discovery is not advised unless the environment is very small. 'netmon' process is responsible for discovery of the network devices.

Manual Discovery in NNM is done via  

1)      Seed File
2)     loadhosts  program

Seed File Procedure

The various steps involved in this procedure are :

Step 1:- Create an ASCII file which will contain the IP Address / Hostname of the devices, that are to be included in the map.

A Sample seedfile could look like
############################################################
192.24.25.26
192.34.25.26       #Gateway 1*
Railey.johs.com
Sydney1.johs.com   # Sydney router
###########################################################
(#) anything after this is interpreted by netmon as comments included by the administrator.
(*) Include gateways in seeds to get the maximum devices discovered, as gateways maintain largest ARP Tables

Step 2:- Modify the netmon.lrf file 
/etc/opt/OV/share/lrf/netmon.lrf
(Ensure a backup of netmon.lrf is taken before doing this modification)
Search for this text

netmon:netmon:
OVs_YES_START:ovtopmd,pmd,ovwdb:-P:OVs_WELL_BEHAVED: 15:
            
After –P insert –s (location where seedfile is actually stored)
Assume seed file is stored in /usr/john/seed.txt  ( "C:\NNMfiles\seedone" in Windows )

netmon:netmon:
OVs_YES_START:ovtopmd,pmd,ovwdb:-P -s \usr\john\seed.txt":OVs_WELL_BEHAVED:15:
OR
netmon:netmon:
OVs_YES_START:ovtopmd,pmd,ovwdb:-P -s "C\:\NNMfiles\seedone":OVs_WELL_BEHAVED:15:
           
Step 3:- Save the netmon.lrf and stop the netmon service using  command  
ovstop netmon 

Step 4:- To update the ovsuf with netmon configuration change use ovaddobj command
ovaddobj $OV_LRF/netmon.lrf               # UNIX
ovaddobj install_dir\lrf\netmon.lrf       # WINDOWS

Step 5:- Restart the netmon service using ovstart
ovstart netmon

NNM will then use the seedfile and will discover the devices mentioned .

loadhosts Procedure
               
loadhosts procedure is used to place the devices directly in the topology map and to reduce the network traffic of discovering the devices, devices in this procedure are immediately added in the database and placed in the map.

The steps involved are

Step 1:- Create a ASCII file containing the IP address or hostname of the devices to be added, each device is to be specified in separate line

A sample loadhosts file
##################################################################
192.3.4.89
192.5.3.4
routerone.johns.com
 ##############################################################################

Step 2:- On the command prompt type
#>      loadhosts –m <subnet mask> <filename>
#> loadhosts -m 255.255.248.0 /usr/john/hosts.txt

OVOU Server and Agent v8.x Services - Start and Stop



To continue with the basics of OMU - Server and Agent

To start the OMU services
#> opcsv -start

To stop the OMU services
#> opcsv -stop

To check for the status of OMU services
#> opcsv -status
OVO Management Server status:
-----------------------------
Control Manager           opcctlm     (9638) is running
Action Manager            opcactm     (9662) is running
Message Manager           opcmsgm     (9663) is running
TT & Notify Mgr           opcttnsm    (9664) is running
Forward Manager           opcforwm    (9665) is running
Service Engine            opcsvcm     (9670) is running
Cert. Srv Adapter         opccsad     (9668) is running
BBC config adapter        opcbbcdist  (9669) is running
Display Manager           opcdispm    (9666) is running
Distrib. Manager          opcdistm    (9667) is running

Open Agent Management status:
-----------------------------
Request Sender            ovoareqsdr  (9417) is running
Request Handler           ovoareqhdlr (9639) is running
Message Receiver (HTTPS)  opcmsgrb    (9640) is running
Message Receiver (DCE)    opcmsgrd    (9641) is running

OV Control Core components status:
----------------------------------
OV Control                ovcd        (8737) is running
OV Communication Broker   ovbbccb     (8738) is running
OV Certificate Server     ovcs        (8761) is running



The OMU services can also be stopped using
#> /opt/OV/bin/ovstop opc ovoacomm ovctrl

ovoacomm is the agent communication service
ovctrl is the control broker service

Start HPOM integrated services by entering:
#> /opt/OV/bin/ovc -start

Start the HPOM agent on the management server:
#> /opt/OV/bin/ovc -start

Stop the HPOM agents on your management server by entering:
#> /opt/OV/bin/ovc -kill

Check the status of the HPOM agents on your management server by entering:
#> /opt/OV/bin/ovc -status
ovcd        OV Control                          CORE         (8737)   Running
ovbbccb     OV Communication Broker             CORE         (8738)   Running
coda        OV Performance Core                 COREXT       (12643)  Running
ovconfd     OV Config and Deploy                COREXT       (12644)  Running
ovcs        OV Certificate Server               SERVER       (8761)   Running
opcmsga     OVO Message Agent                   AGENT,EA     (2556)   Running
opcacta     OVO Action Agent                    AGENT,EA     (2561)   Running
opcmsgi     OVO Message Interceptor             AGENT,EA     (2569)   Running
opcle       OVO Logfile Encapsulator            AGENT,EA     (2570)   Running
opcmona     OVO Monitor Agent                   AGENT,EA     (2571)   Running
opctrapi    OVO SNMP Trap Interceptor           AGENT,EA     (2585)   Running

Also, the command 'opcagt' can be used to check for the status, start and stop the agent. This command will also tell us if the agent is buffering or not.
This command is effective only for the Event/Action agent and CODA.

#> opcagt -status
coda        OV Performance Core                 COREXT       (12643)  Running
opcmsga     OVO Message Agent                   AGENT,EA     (2556)   Running
opcacta     OVO Action Agent                    AGENT,EA     (2561)   Running
opcmsgi     OVO Message Interceptor             AGENT,EA     (2569)   Running
opcle       OVO Logfile Encapsulator            AGENT,EA     (2570)   Running
opcmona     OVO Monitor Agent                   AGENT,EA     (2571)   Running
opctrapi    OVO SNMP Trap Interceptor           AGENT,EA     (2585)   Running
Message Agent is not buffering.

#> opcagt -cleanstart  
This will restart Event/Action Agent doing a cleanup of temporary files.





Thursday, January 12, 2012

NNM v7.5x services - Start and Stop


First post, lets start off with the basics :)

To start NNM services 
#> ovstart -c

To stop NNM services
#> ovstop -c

To check for the status of NNM services
#> ovstatus -c
 Name              PID  State          Last Message(s)
 OVsPMD           8677  RUNNING        -
 esf             10617  RUNNING        Initialization complete.
 ovsessionmgr    10618  RUNNING        Initialization complete.
 ovwdb            8715  RUNNING        Initialization complete.
 ovuispmd         9416  RUNNING        Initialized. 3 ovw clients registered.
 ovtrapd         10619  RUNNING        Initialization complete.
 ovactiond       10620  RUNNING        Initialization complete.
 ovalarmsrv      10621  RUNNING        Initialization complete.
 pmd              8716  RUNNING        Initialization complete.
 genannosrvr         -  unknown        (Does not communicate with ovspmd.)
 httpd               -  unknown        (Does not communicate with ovspmd.)
 ovtopmd          9406  RUNNING        Connected to native database "openview".
 snmpCollect     10624  RUNNING        Initialization complete.
 ovas            10805  RUNNING        Initialization complete.
 ovrequestd      10626  RUNNING        Initialization complete.
 ovdbcheck       10625  RUNNING        Connected to embedded database.
 ovctrl              -  unknown        (Does not communicate with ovspmd.)
 ovoacomm         9417  RUNNING        Open Agent Service Server Initialization Complete.                       For details about Open Agent Service use 'opcsv'.
 opc              9638  RUNNING        OVO Server Initialization Complete.                       For details about OVO Manager Processes use 'opcsv'.
 netmon          23652  RUNNING        Initialization complete.