Catalina,
I can't do this for you. You'd have to call Support for that kind of help.
But I can make some general observations and give you enough to get
started.
But understand that you are asking for programming assistance. That's not
something that just anyone can give you. I take it that you did not write
the original? If you did, then you should be able to get this working from
what I am about to tell you.
Your script gets passed $A and $4 from trapd. It references those
variables as $1 and $2 internally,
What you want to do is use the ruleset environment variables for the same
things in your script, in place of $1 and $2.
So in your script $1 become $NVA , the agent address, and $4 becomes
$NVATTR_4, the port number.
You need not pass it anything.
If it doesn't perform as expected, you can look in the nvaction.alog and
blog where the output from Action nodes run by actionsvr is logged. If you
need to see your script traced to debug it, then add
set -x
as the first line and it will trace to the active nvaction log.
Testing is going to be difficult, but no more difficult than it was to test
the original one. You would have to construct an snmptrap script to send a
dummy trap that looks like what you expect to get. That's the only way to
test a an automatic action being triggered from a trap or from a ruleset.
It doesn't have to be perfect. It just has to produce a trap similar
enough to what you need to trigger the action. This should be enough to
get you started.
#!/bin/ksh
# cisco_workgroup test trap
#
# The first line shows the word hostname in back ticks,
# which means to use the output of the hostname command
# as the trap destination. The hostname on the second line
# must be valid in your network or replaced by an IP address.
# The numeral 1 on the second line is the specific trap number;
# replace it if this is not correct.
# The OIDs are made up. Any set of arbitrary numbers would do.
# Since only four varbinds are needed, only four are sent.
# Except for a port number in varbind 4, their contents is fake as well.
# I am not sure about the exact format of the port number either
#
/usr/OV/bin/snmptrap `hostname` .1.3.6.1.4.1.9.5 \
'whiskey.raleigh.ibm.com' 6 1 10 \
.1.3.6.1.4.1.9.5.1.0 Integer 20 \
.1.3.6.1.4.1.9.5.2.0 Integer 4 \
.1.3.6.1.4.1.9.5.3.0 OctetStringascii "dummy test trap" \
.1.3.6.1.4.1.9.5.4.0 OctetStringascii "#10/6" \
Your original script does not put all the varbinds of the trap in the echo
windows or the e-mail message. To do that you'd have to modify it to
include the variable contents $NVATTR_1, $NVATTR_2, $NVATTR_3, and so on,
for as many variables as there are in the trap, in the echo statements in
the output.
Hope this helps,
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
"Catalina
Martinez"
<Catalina.Martine To
z@tlc.state.tx.us <nv-l@lists.us.ibm.com>
> cc
Sent by:
owner-nv-l@lists. Subject
us.ibm.com RE: [nv-l] Ruleset Question
01/12/2006 10:05
AM
Please respond to
nv-l@lists.us.ibm
.com
Thanks James,
Initially, my script was executed from within the trap customization /
command section and now I want to move the process to a ruleset.
CURRENTLY:
cisco_workgroup 1.3.6.1.4.1.9.5 "LINK_DOWN" Trap
command for automatic action:/usr/local/bin/netview_dore_down $A $4
$A == device name
$4 == port number
The script itself does an snmpget on the device to get the port name. I
took care of all the special characters and such. Generates a popup
messages which contains the device and port name. This process works
ok..
RULESET:
uses the same script. but in the ruleset, the values are not sent so the
script does not work properly. How do I export the values within a
ruleset? I've tried $NVA, $A, and then I read somewhere (cant remember
where) not to export anything in the rulesets that all values are there
but modify the script. I just need the node name and variable 4 sent to
my script.
Other questions:
How do I test a ruleset/trap? server setup?
How do I generate a popup with all the trap values? $* on the popup
notification field.
This is my script:
#!/bin/ksh
# /usr/local/bin/netview_core_down_alert
##############################################
# The script will take a device name and port number
# and produce the port name.
# If the name begins with NET a popup window and email
# are sent.
#-----------------------------------------------------
# The statement below will replace / with an . for port number#
# IN NV712 port numbers exported with _
stamp=`date +"%D-%T"`
port=`echo $2 | tr '_' '.'`
port1=`echo $2 | tr '_' '/'`
#------------------------------------------------------
# the statement below will do an snmpget to get the port name
#
portname=`/usr/OV/bin/snmpget $1 .1.3.6.1.4.1.9.5.1.4.1.1.4.$port`
#-------------------------------------------------------
# Now we take the first 3 letters of the name
name=${portname##*:}
prefix=`echo $name | cut -c 1-4`
#-------------------------------------------------------
#If the 4 letters match NET- then display window and send email
if test "$prefix" = "NET-"
then
/usr/OV/bin/ovxbeep -b 10 -display OPS:0.0 "`echo $stamp $1
reports Port $port1 link to $name is DOWN--Call NWC!| /usr/bin/fold -b
-s -w 18`"&
echo $stamp $1 $name | mail -s "CORE LINK DOWN" online lsg ops
fi
exit 0
-----Original Message-----
From: owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com]
On Behalf Of James Shanks
Sent: Wednesday, January 11, 2006 3:50 PM
To: nv-l@lists.us.ibm.com
Subject: Re: [nv-l] Ruleset Question
Since you want to query two different smartsets and take different
actions
depending on the results of those queries, it doesn't really matter
whether
you have two rules or one. The difference in processing will be tiny
because it is the smartset queries that require all the work. I'd stick
with two separate rules because that would be easier to understand and
maintain. You could alter them independently. You'd have more
complicated logic by combining them and you probably wouldn't get a
measurable change in performance in return.
If these rulesets ran in event windows, then nothing would be shown in
those windows because everything is being blocked. But I'm assuming
that
you are planning to run these in ESE.automation, correct? That's the
only
way you could have them both active at the same time. And what you
run
there has no bearing on the operator's display. When the operator opens
her event window it will be running forwardall.rs by default, or
something
else which has an explicit PASS or Forward in it, not one of these.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
"Catalina
Martinez"
<Catalina.Martine
To
z@tlc.state.tx.us <nv-l@lists.us.ibm.com>
>
cc
Sent by:
owner-nv-l@lists.
Subject
us.ibm.com [nv-l] Ruleset Question
01/11/2006 04:34
PM
Please respond to
nv-l@lists.us.ibm
.com
Hello,
AIX 5.2 Netview 7.1.4 FP3
General Ruleset question running in ESE.automation:
The rulesets listed below are working ok but wondering if there is more
efficient way of doing this:
do_down.rs -- block --> trap setting = nv60000 node-down --> query
smartset X /if contained in smartset X --> run script A
core_down.rs -- block --> trapsetting == nv6000 node-down --> query
smartset Y/if contained in smartset Y --> run script B
Questions:
1) is it better to have 1 ruleset investigating the same trap; and then
fan out with the different smartset queries /flow. So I would have 2
parallel paths within the same ruleset instead of running 2 separate
rulesets.
2) Does "block" stop the event from the displaying in Main Event window?
The Operators still need to see the event being logged.
3) I normally have "trap setting" first and then the node, can I have
origin first and then the "trap setting". does it matter? which is
better? what's the rule of thumb...
Thanks,
Catalina
|