Re: [nv-l] Ruleset editor for Windows?

[CMazon@commercebankfl.com]

I have tried the built in rule set and
it has not worked.  The reason for using the Cisco trap is because
these traps are actually created by the devices and not Netview itself.
 I have come accross some situations where if for some chance the
device was too busy to respond to the SNMP poll, Netview will generate
a trap of Node down when in actuality the node is up.  The Cisco traps
are more trust worthy in this fashion because the device will send a trap
only on a change on its interface. Not just timing out on a response.  I
have already tried modifying the timing of the polls but I still have some
cisco devices (with Bad OIDs) that Netview at times will say are completely
down but are really up.


Carlos Mazon

James Shanks <jshanks@us.ibm.com> Sent by: owner-nv-l@lists.us.ibm.com 12/22/2003 05:08 PM Please respond to nv-l

To:        nv-l@lists.us.ibm.com         cc:                 Subject:        Re: [nv-l] Ruleset editor for Windows?

Have you tried the NetView ruleset you spoke of?  That's
downandnotupinten.rs isn't it?.  I didn't think even that one was
constructed so that it would work.

That's another problem on Windows. Some of the samples don't work, and
some that do, don't work correctly.  Never have.  They were things
that 
the original developer was playing with and never should have shipped,
in 
my opinion.  But if you can get downandnotupinten.rs to work for NetView
events, then you should be able to edit it with Wordpad and replace the
NetView OID with the Cisco OID and the NetView trap numbers with the Cisco
ones (for what, LinkUp, Link Down?) and then it should work, but that's
a 
very big "if".

What I don't quite follow is why you would do this at all,  since
NetView 
will tell you the same thing that the Cisco traps would tell you, wouldn't
it?

James Shanks
Level 3 Support  for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group




CMazon@commercebankfl.com
Sent by: owner-nv-l@lists.us.ibm.com
12/19/2003 05:16 PM
Please respond to nv-l

 
        To:     nv-l@lists.us.ibm.com
        cc: 
        Subject:        Re: [nv-l]
Ruleset editor for Windows?




Thanks for the info James.  What I wanted to do is create a similar
ruleset to what is already there for the Node down for 10 minutes, however
instead of using Netview's traps, we wanted to use Cisco's traps with the
same general idea. Wait 10 or 5 minutes and then generate and event/trap
if the interface did not come back up so that an alert (email) can be 
sent. We are not using TEC which I know can probably do this for us so
I 
was hoping to use the builtin features of Netview. But if I understand
what you are stating with the first apar mentioned below, this ruleset
is 
not functional because it keeps detecting the same agent as coming up or
down so If I have a 2 down node events, and one comes up, it automaticly
stops the rule since it detected the same agent as up.  (Correct me
if I 
am wrong.)   

I can see now why almost everyone uses Netview for AIX or Solaris but it
is hard me to justify a Unix box just for one product when we are a totaly
Windows environment.  Are there any similar limits to using Netview
for 
Linux.  I know in the previous versions there was no data store house
(DB) 
for Linux but not sure for the new version?  Would I get similar 
functionality (if not complete) in Linux as compared to Unix? What about
using a Windows client with a Linux server (I believe this not possible)?

Thanks again 

Carlos 



James Shanks <jshanks@us.ibm.com> 
Sent by: owner-nv-l@lists.us.ibm.com 
12/19/2003 04:50 PM 
Please respond to nv-l 
        
        To:        nv-l@lists.us.ibm.com
        cc:         
        Subject:        Re: [nv-l]
Ruleset editor for Windows?




There is no ruleset editor for Windows and there is not likely to be one,
because the usefulness of ruleset on Windows is nothing like what it is
on 
UNIX. 

There is no actionsvr, no way to remove events from the event display,
and 
some ruleset nodes like the pager and the (off-line) action node, do not
work at all on Windows.  These limitations can be overcome, if you
are 
clever and dedicated, but even then, the results may not be what you 
expect. 

Yes, NetView Linux does have a ruleset editor.  But even after you
port 
your UNIX rule to Windows, it may have to be modified in order to work
correctly. 
There are some guidelines in the Windows Programmer's Guide,  concerning
how to edit an rs file, but it is not much.  Just be sure to use WordPad,
and not NotePad, or you will corrupt the file and nvcord will fail trying
to load it. 

So you must be very, very careful about what you are trying to accomplish
with rulesets on Windows.   The original design saw them only as providing
additional filtering capabilities for the Event Browser, which is why the
samples are so lame,  but beyond that the implementation leaves a
lot to 
be desired.  To understand why, remember that on Windows, all events
are 
stored directly in the ODBC database by trapd.  And the Event Browser
reads events from the ODBC database.  There is no event flow on Windows
like there is on UNIX with nvcorrd in the middle.  So every thing
that 
nvcord (notice the spelling difference on Windows) does with an event on
Windows is after the fact.  This results in some rather strange design
issues. 

First, every successful ruleset on Windows will create a new, near 
duplicate event of the original event and store this near duplicate back
in the ODBC database.  That's because the original one is already
in there 
and cannot be modified.  So when you use the "ALL Events"
filter instead 
of the ruleset custom filter, you will see both the original event and
the 
duplicates too.  This may seem very confusing and most people don't
care 
for it.  When you use the ruleset as a custom filter, you will see
only 
the events which it created.   

Second, each near duplicate event gets a new first varbind inserted, an
integer which tells the Event Browser what ruleset was used to create the
near duplicate.  That's how the Event Browser knows which ones to
display 
for each ruleset.   But because there is a new first varbind, all
the 
original varbinds are "pushed down" one position; old varbind
one becomes 
new varbind two, varbind two becomes three, and so on, which can mess up
how the event is displayed, depending on how it is formatted in 
trapd.conf.  As I said, the implementation leaves a lot to be desired.
But 
that's how it works.  For simple cases, it is reliable enough, but
not 
very useful in my opinion. 

However, there are two open APARs on this function as I write this.  One
is for the fact that the agent address is corrupted in the near duplicate
events.  No matter what agent sent them, the new event has the NetView
box 
itself as the agent.  And the other is that a ruleset which wishes
to 
override the status or severity of an event, such as the 
setstatusseverity.rs which ships with the product, will cause severe 
problems because that function is broken.     Eventually both
of these 
problems will be fixed, but they are not now.   

Thus, as a general rule, rulesets on Windows should be avoided, except
in 
special circumstances. 
Just what did you want to do with them?

James Shanks
Level 3 Support  for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group 


CMazon@commercebankfl.com 
Sent by: owner-nv-l@lists.us.ibm.com 
12/19/2003 03:52 PM 
Please respond to nv-l 
        
       To:        nv-l@lists.us.ibm.com
       cc:         
       Subject:        [nv-l] Ruleset
editor for Windows? 





Netview 7.1.4 Windows 2000 

Is there a guide to manually write a ruleset for windows? I know there
is 
no rule set editor for windows and we do not have the resources to set
up 
a Unix flavor of the product.  I would like to understand the variables
in 
the file and how they are set in the file itself so that I may be able
to 
create some simple rulesets for our needs. 


Is the ruleset editor available in Netview for Linux, I may be able to
run 
a virtual PC with Linux and set that up just for that purpose. 

Thanks. 

Carlos.