I did not author the document, I just saved it and passed it on. I suspect
that you have
a problem with the thing you created. Check the status source, for
instance, and make
sure the selection name matches exactly. I've used it with 'Software' type
objects. There
are attributes that come with objects of certain types. When you created
this one, you
probably did not go into ipmap attributes, which you would have if the
thing had an IP
address. Did you go into the xxmap attributes? Maybe you need to. Maybe it
needs
more fields than it has now.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Leslie,
I opted to use the command line snmptrap and it works fine over
real
nodes, but I made manualy a new object and doesn´t work on it, here is the
description:
OBJECT: 63654
FIELD ID FIELD NAME FIELD VALUE
10 Selection Name "sapserv4"
14 OVW Maps Exists 1
15 OVW Maps Managed 2
71 isNode TRUE
73 isComputer TRUE
81 isMini TRUE
which is the parameter I have to change (and how) in orther to snmptrap
script works fine?
Thanks . . .
> -----Original Message-----
> From: PUB:Leslie Clark [SMTP:lclark@US.IBM.COM]
> Sent: Monday, April 05, 1999 1:07 PM
> To: NV-L@UCSBVM.ucsb.edu
> Subject: Re: Changing status... The Word from Support
>
> Here's something I keep handy on this subject.. Warning. long append.
> File for future reference.
>
> ------------------------------------------------------------------
>
> One of the most common, and yet most complicated, things that NetView
>
> users ask about is how to alter the status (color) of an icon on the
>
> map using a trap, effectively overriding what netmon has done. This
>
> can be accomplished in one of three ways, (1) using a ruleset with the
>
> override node in it, (2) issuing the 58916871 NetView trap, or (3) by
>
> configuring a non-NetView trap.
>
> This document is an attempt to explain how these processes work.
>
> Types of status
>
> There are three (3) sources of status for objects on a NetView map:
>
> 1. Object source -- status of a single object is kept in the
>
> database entry for that object
>
> 2. Compound Propagated source -- object has no status of its own, but
>
> it is derived from status of its constituent objects.
>
> Network symbols and collection objects have status source of
>
> 'Compound Propagated'
>
> 3. Symbol source -- an ipmap status not part of the object host nodes
>
> in the map have this status source
>
> You can determine the status source for any map object by selecting
>
> it with the rightmost mouse button and clicking on Edit ==> Modify /
>
> Describe ==> Symbol.
>
> General requirements
>
> 1. In order for an event, no matter how it is processed, to override
>
> status and change the color of an object on the map(s), the Event
>
> process (called nvevents) must be running in dynamic workspace in a
>
> control desk on the read-write map, and the control desk must have
>
> been started by ovw (the map process) initially. This is the default
>
> NetView End User Interface configuration.
>
> The reason for this is that the APIs for the status override function
>
> are in nvevents and ovw, and they can only be used effectively when
>
> both are connected to the same read-write map.
>
> 2. The API can easily override the status of objects which have a
>
> status source of 'Object' or 'Symbol', but a status source of
>
> 'Compound Propagated' is more difficult. Since this is a derived
>
> status it cannot be changed directly. What nvevents can do in this
>
> case, is to change the status source of the object to 'Symbol' first,
>
> and then override it. But as this means that from that time on, the
>
> map object will no longer reflect the combined status of the objects
>
> "below" it (unless you later change the status source back to
>
> 'Compound Propagated again via Edit with the right mouse button) you
>
> must set the application defaults for nvevents to permit this to
>
> happen. You must edit app-defaults/Nvevents to say
>
> nvevents.overrideCompoundStatus : True
>
> When your event requests a status override, the object's status source
>
> will be changed from compound to symbol, and then overridden. But now
>
> you must take responsibility to change the status again when the
>
> condition which caused you to change it in the first place has passed,
>
> as it will never again reflect the status derived from its components.
>
> Failure to have nvevents.overrideCompoundStatus : True set in your
>
> Nvevents file is the most common reason why users report that overrides
>
> do not work. Be aware that each user could have his or her own
>
> copy of Nvevents in his or her $HOME directory or could have
>
> incorporated the Nvevents entries into a .Xdefaults file. And be aware
>
> that X is not forgiving about user defaults. The value here must be
>
> "True" and not "True " with any extra spaces trailing the 'e'.
>
> Note that if a host node is in a Collection, it has status source of
>
> 'Compound Propagated', while on the IP Segment map it will have a
>
> status source of 'Symbol'. If you do not have
>
> nvevents.overrideCompoundStatus : True
>
> set in the Nvevents app-defaults, then the status you set will not be
>
> reflected in the Collection. This is another common problem which
>
> users report.
>
> Note that the host node on a Segment map typically has status source
>
> of 'Symbol'. It is set when netmon issues a Node Up/Node Down trap.
>
> Note that interfaces have a status source of 'Object'. Their status
>
> is set when netmon issues an Interface Up/Interface Down trap. At
>
> higher levels, networks and segments have a status source of 'Compound
>
> Propagated', so both the host node AND its "down" interfaces must
>
> have their status set to User1 or User2 to avoid having them alter the
>
> status of the network. Failure to set both of them is another common
>
> user problem.
>
> 3. Condsider how you will change the status back again. If you are
>
> changing status of nodes and interfaces that netmon pings, remember
>
> that it will change them back again, so you might delay the netmon
>
> polling cycle for them. If you are overriding the status source of an
>
> object that was 'Compound Propagated' and are changing it to 'Symbol',
>
> you must find a way to change the status again with so other "cleared
>
> condition" event, since it will not change on its own now.
>
> Override status with ruleset
>
> In order for a ruleset to override status and change the color of an
>
> object on the map(s), the ruleset must be running in dynamic workspace
>
> in a control desk on the read-write map. This is general requirement
>
> #1.
>
>
> And for the ruleset to override the status of an object which has a
>
> status source of 'Compound Propagated', you must edit
>
> app-defaults/Nvevents to say
>
> nvevents.overrideCompoundStatus : True
>
> This is general requirement #2.
>
> But ruleset override will only override the status of the host node,
>
> the "origin" of the trap, and not the interface (unless the interface
>
> does not have a hostname associated with it in the NetView database).
>
> This can be inconvenient, especially if what you want to do is
>
> override the status of both the host node and the interface (to
>
> something like User1 or User2) so that they do not figure in status
>
> propagation to higher-level nodes.
>
> Note that the host node on a Segment map typically has status source
>
> of 'Symbol'. It is set when netmon issues a Node Up/Node Down trap.
>
> Note that interfaces have a status source of 'Object'. Their status
>
> is set when netmon issues an Interface Up/Interface Down trap. At
>
> higher levels, networks and segments have a status source of 'Compound
>
> Propa- gated', so both the host node AND its "down" interfaces must
>
> have their status set to User1 or User2 to avoid having them alter the
>
> status of the network.
>
> So NetView also provides another way that status can be overridden.
>
> Override status using the 58916871 trap.
>
> If you look at the description of this trap in Event Configuration,
>
> you will see that this trap is not issued by netmon but is in fact
>
> designed for customer use to change status (and therefore color) on a
>
> map. It doesn't affect true status in the object database. Below is
>
> a shell script which will issue this trap via the snmptrap command.
>
> You pass it two variables -- (1) the name of the object from object
>
> database, and (2) the status you want this changed to on the map(s).
>
> Here's the script:
>
> #!/bin/ksh
>
> set -x
>
> NAME=$1
>
> STATE=$2
>
> /usr/OV/bin/snmptrap `hostname` .1.3.6.1.4.1.2.6.3.1 \
>
> `hostname` 6 58916871 1 \
>
> .1.3.6.1.4.1.2.6.3.1.1.2.0 Integer 14 \
>
> .1.3.6.1.4.1.2.6.3.1.1.3.0 OctetString $NAME \
>
> .1.3.6.1.4.1.2.6.3.1.1.4.0 OctetString "Object status is" \
>
> .1.3.6.1.4.1.2.6.3.1.1.5.0 OctetString $STATE
>
> Obviously you can make this script more elaborate if you like.
>
> The permissable status values are Unknown, Normal, Marginal, Critical,
>
> Up, Down, User1, and User2.
>
> You can obtain the name of the object by highlighting the icon on the
>
> map and clicking with the RIGHT mouse button to get to Edit ==>
>
> Modify/Describe ==> Object and the name is in the Set Selection Name
>
> Typically, a host is known by its hostname and an interface by
>
> hostname:interfacename, where the interface name is the IFdescription
>
> from the MIB (such as "nv6ktst5.raleigh.ibm.com:tr0" for example).
>
> You can always verify you have a correct object name by doing
>
> ovobjprint -s <name>. If the object is not found, then you have a bad
>
> name.
>
> Since this is being done using the nvevents API to ovw, the same
>
> restrictions apply. The snmptrap must be received by some NetView with
>
> nvevents running in a control desk attached to an ovw running the
>
> read-write map. This is general requirement #1.
>
> And the Nvevents app-defaults file must have the same value set:
>
> nvevents.overrideCompoundStatus : True if what you are setting has a
>
> status source of Compound Propagated. This is general requirement #2.
>
> Override with a trap setting
>
> As in all other cases, general requirements #1 and #2 apply here as
>
> well.
>
> In addition, you cannot alter the status set by netmon traps, so you
>
> have to use a trap from another agent. Here you can also use snmptrap
>
> to create your own traps and issue those by script or automatic action
>
> from Event Configuration.
>
>
--------------------------------------------------------------------------
> -
> ------------------------------------------------
>
> Cordially,
>
> Leslie A. Clark
> IBM Global Services - Systems Mgmt & Networking
>
>
>
> Hi everybody!
> Does anybody know which is the command line to change the color
> (status) of an objetct.
> Many thanks.
>
> Ing. Miguel Bandieramonte
> TECSIS ACE Siderca Siderar
> ARGENTINA
> tcsbte@tecsis.com
> 54-3489-4-3-3979
|