Well, I don't suppose it would help to say, "If it works on the TEC
gateway, then do it on the TEC gateway."
You see, it is entirely possible, and even likely after some time, that the
level of the SCE, which is part of the TEC EEIF library, that ships as part
of nvserverd or tecad_nv6k will be different than that on your TEC gateway.
It all depends on whether there has been TEC maintenance applied which
updated the gateway after NetView was built, tested, and shipped. When a
new level of NetView is shipped, a stake has to be put in the ground, so to
speak, and some level of the EEIF library is included in the build. All
the testing from that point forward proceeds at that level, and the only
thing that is tested is documented NetView function. No customizations to
the nvsbcrule.xml are tested because that's not NetView function; it's TEC
function.
The testers have to certify that base NetView works as shipped, which is
what they do.
Do you follow what I'm saying? Put it another way -- there is reason why
NetView doc does not encourage you to add your own rules to the
nvsbcrule.xml, because if they don't work, all NetView can do is wait until
TEC fixes the library, and then upgrade to that library in the next
go-round of NetView maintenance.
NetView development had a choice when the TEC adapters were integrated.
They could link with a fixed version of the EEIF library and verify that it
worked well enough to do what base NetView needed it to do when it was
shipped. Or they could have chosen to use a variable version of the
library, to which you would have to periodically apply TEC maintenance as
required. Most likely, you would have to get a new copy of the TEC SDK and
move it to NetView, and either re-link nvserverd with it, or it would have
to be installed as shared. That would be much more work for the user, and
development would never be able to say that NetView Version such-and such
FixPack so-and-so worked as designed on it's ship date. As soon as the
next round of TEC maintenance was applied, who would know whether NetView
would work or not? That's why they chose the former. The downside is, of
course, that if there are unforeseen problems in the TEC library when
NetView is built, then they remain there until next development cycle which
provides enough testing resources to retest the TEC integration all over
again.
You can open your PMR of course, but patience is the order of the day, and
you already know the suggested workaround, "Do it on the TEC gateway".
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
Jane Curry
<jane.curry@skill
s-1st.co.uk> To
Sent by: tme10@lists.us.ibm.com, NetView
owner-nv-l@lists. mailing list
us.ibm.com <nv-l@lists.us.ibm.com>
cc
06/06/2005 02:50 Subject
PM [nv-l] Re: [tme10] [EC] State
C0rrelation Engine duplicate rule
doesn't suppress duplicates
Please respond to
nv-l
I have finally got around to doing more testing with this. I have tried
coding nvsbcrule.xml with both a duplicate and with a collector rule.
The only difference seems to be that the repeat count for a duplicate
rule is zero (which is reasonable - it is defined as suppressing
duplicates). A collector rule you also get an event with the msg slot
set to "Authentication Trap Summary" but the repeat count of this event
is however many occurred in the interval. However, I am still seeing
all the individual events AS WELL.
I had also been doing testing on SCE in a TEC gateway so I simply
cut-and-paste my rule from nvsbcrule.xml and paste it into my TEC
Gateway tecroot.xml. I generated wpostemsg events, filling all the
TEC_ITS_BASE events attributes as they are filled by NetView (simply by
getting them from a wtdumprl). The SCE in the gateway did the same with
repeat counts as described above for duplicate and collector rules BUT I
did NOT get the original events.
This says to me that the SCE in nvserverd is not implementing duplicate
and collector rules correctly by suppressing events. Not tested in
tecad_nv6k yet.....
Any other thoughts or inputs before I try raising a PMR?
Cheers,
Jane
Jane Curry wrote:
> I have TEC 3.9 FP2 and NetView 7.1.4 FP3 on a SuSE 9.1 Professional
> system.
> I have added 1 extra state correlation engine ( SCE ) rule to the
> provided nvsbrule.xml rules file that comes with NetView:
> <rule id="netview.dupAuthRemove">
> <eventType>TEC_ITS_BASE</eventType>
> <duplicate timeInterval="60000">
> <cloneable attributeSet="hostname"/>
> <predicate>
> <![CDATA[
> &nv_generic == "4"
> ]]>
> </predicate>
> </duplicate>
> <triggerActions>
> <action function="TECSummary" singleInstance="false">
> <parameters>
> SET:msg="Authentication Trap Summary"
> </parameters>
> </action>
> </triggerActions>
> </rule>
>
> I am generating 8 traps that match this and I am seeing an event with
> the message "Authentication Trap Summary" so the rule is obviously
> firing but I am ALSO seeing all the individual events too. They all
> come from the same hostname inside 60 seconds. The summary event has
> a repeat count of 0.
>
> I have tracing and logging turned on for the state correlation but
> can't see anything helpful in there.
>
> Anyone else seen this or can see what I have done wrong? I just have
> a vague idea I had heard of a bug with the duplicate SCE rule - mebbe
> on Linux???
>
> Cheers,
> Jane
>
--
Tivoli Certified Consultant & Instructor
Skills 1st Limited, 2 Cedar Chase, Taplow, Bucks, SL6 0EU, UK
Tel: +44 (0)1628 782565
Copyright (c) 2005 Jane Curry <jane.curry@skills-1st.co.uk>. All rights
reserved.
|