Re: [nv-l] Netview upgrades

[James Shanks <jshanks@us.ibm.com>]

Your understanding is correct, Gavin.
 
And from what you say, it sounds like
your ruleset would work in ESE.automation.
If there are no Forward, Resolve, or
Override nodes in it, and the initial Event Stream node is set to BLOCK
rather than PASS, then it will work fine.  Otherwise it has to be
re-written.

IF you do try it in ESE.automation,
there is a check you can do to tell whether things are working correctly
as far as the daemons are concerned.  First, while it is running today
and things seem OK, do a "netstat -a" and look at the Send and
Recv queues, for any socket that has nvcorrd as part of its name.  They
should be zero or very small values.   When you move to ESE.automation,
do the test again periodically.  If you see queues for nvcorrd backing
up and getting into the thousands of evens, you know you have a problem
and will need to go back to the old way until the ruleset is sorted out.

Hope this helps

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

"Gavin Newman" <NEWMANGJ@banksa.com.au>
Sent by: owner-nv-l@lists.us.ibm.com

03/26/2004 12:01 AM

Please respond to
nv-l

To	<nv-l@lists.us.ibm.com>
cc
Subject	Re: [nv-l] Netview upgrades

James

Sorry to confuse you - you are making it clearer for me.

I've looked in tecint.conf and, as you say the Tivoli host name and my
ruleset name are indeed in there. I've also looked at the ESE.automation
file and I think I now understand how that works - if I put my ruleset
name in there (and remove everything from the tecint.conf file) then my
ruleset gets loaded by the daemons and is invoked when events occur but
runs in background with no console etc. Am I correct so far?

My ruleset USED to react to events by examining the nodename of the
offending device out in userland and then running one or more scripts
and programs to send emails, send text messages to mobile phones, update
a database and various web pages. These events are never sent to Tivoli
- the flow of control within the rule ends at the "Action" block(s).

In addition to this network related event handling the ruleset used to
process traps sent to Netview by some Netware servers and then forward
those traps to Tivoli. We were doing this only so that Netview could
filter out the rubbish traps and only forward interesting traps to the
Tivoli processor (maybe this was a con so we'd have to buy the bigger
processor and protect their processor from overload). This latter
function has been removed and therefore I have no forwarding blocks in
my ruleset so I assume from what you say that it is order to have this
rule now run in background via the ESE.automation file.

I take your point re the support staff being involved in the migration
- I was thinking along thse lines myself, I'm trying to get an idea of
the direction to take before I get to that stage - hence the questions.

Cheers and thanks for the help so far - Gavin

>>> jshanks@us.ibm.com 26/03/2004 11:41:06 >>>





Well, I'm certainly confused by what you are doing and I'm not quite
certain what to say, but here goes.

To achieve TEC forwarding, a file called /usr/OV/conf/tecint.conf is
used.
That's what you are configuring when you use serversetup or smitty to
send
events to TEC.  nvserverd reads this file on start up and registers
the
rule with nvcorrd.  Events are forwarded to the TEC server listed
in
the
file with the keyword "ServerLocation".  Normally, if the
internal TEC
adapter code cannot contact the TEC server, no events are forwarded. 
So
the question naturally arises, what's in your tecint.conf file?  Is
there a
server specified?  And what exactly is in that ruleset?

 I suppose that it is possible that your ruleset only triggers actions
in
the background to do other things and that it is wholly unimportant
that
the actual TEC forwarding never takes place.  If this is true, then
you
could continue to do that I suppose, though it is quite a kludge.  But
you
will take a cpu hit in 7.1.4 because the code has been re-written by
customer request to continually re-try the TEC connection until it is
established.  What you have now tries once, and then quits, forcing
the
user to recycle the daemon or invoke the nvtecia command if the TEC
server
is down when nvserverd  starts up.

The normal way to do what you are doing would be to put the ruleset in
/usr/OV/conf/ESE.automation and let actionsvr handle the background
actions, and forget about TEC .  But I could not advise you to
undertake
that migration without understanding how your "TEC" ruleset is
constructed,
because the processing requirements of the internal TEC adapter and
actionsvr are quite different.  Having  "Forward" nodes
in your TEC
ruleset
is a requirement if you want something sent to TEC; but they are
forbidden
in an actionsvr ruleset, because he has no where to send them, and
more
importantly, if they are included, they will cause the entire trio of
nvcorrd, nvserverd, and actionsvr to eventually hang, and you'll get
no
more events.

You might very well want to bring IBM Support in on this as you
migrate.
It is even something you could work on now, because there is no benefit
to
doing this the way that you are, and no harm in switching to the
"right
way" in advance of your migration, provided your ruleset is written
correctly.

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


                    
                     
                     
     

             "Gavin Newman"  
                     
                  

             <NEWMANGJ@banksa.  
                     
               

             com.au>      
                     
                     
To
             Sent by:      
                     
                    

             owner-nv-l@lists.    
    <nv-l@lists.us.ibm.com>        

             us.ibm.com      
                     
                   
cc
                    
                     
                     
     

                    
                     
                     
     

             03/25/04 05:42 PM    
                     
             

                    
                     
                     
     

                    
                     
                     
     

             Please respond to    
                     
         
Subject
                   nv-l  
             Re: [nv-l] Netview upgrades
   

                    
                     
                     
     

                    
                     
                     
     

                    
                     
                     
     

                    
                     
                     
     

                    
                     
                     
     

                    
                     
                     
     





James

Thanks for your help. I may misunderstand the role of the rules but
its
worked for me so far.

I have a ruleset which handles my events and calles external scripts
in
response to node down, interface down, node up events and traps
received
from various devices. - I set this ruleset in the "forward to TEC"
setting in Tivoli even though I no longer forward anything to Tivoli
and
the ruleset then operates in the background and processes my events.

I'm presuming this ruleset is different to the one that defines what
events I see on my Events window on the GUI.

What I want to be able to do is continue to use my primary ruleset to
handle all incoming events even when I no longer have Tivoli "bundled"
in with Netview and even if the GUI is not running.

Am I on the wrong track here or am I hopelessly confused (not for the
first time)?

Cheers - Gavin

>>> jshanks@us.ibm.com 26/03/2004 02:36:41 >>>
There is no direct migration from NetView 5.1 to 7.1, and that is one
of
the very big pitfalls you face in a highly-customized environment when
you
do not stay current.  The migration effort increases exponentially.

For example, if you have a highly customized trapd.conf, with many new

traps, you can merge it with the updated trapd.conf  shipped in 7.13
or

7.1.4  using  nvaddtrapd (/usr/OV/bin/nvaddtrap <old.trapd.conf>
) 
but

you will not get the  changes you made to existing NetView traps and
others which are also included.  So you will likely have to do a lot
of

manual editing.  Br sure to keep backup copies of your old and new
until
you are satisfied with the result.

It sounds to me as though your best bet for a map migration is to make
use
of location.conf.  I don't believe that is a part of NetView 5.1 and
even
if it is, it would not have the same functionality that it has today.
What
you need is a utility to take your existing database and map and
create
a
location.conf file from it.  That would preserve most, if not all,
of
your
map customization.  NetView itself does not offer such a utility but
others do.  It will soon be available on the NetView user's group
website,
http://www.nv-l.org/ 

So my advice  is to become an active member of the NetView User's
Group.
They could help you with the migration using their experience and
advise
you on learning how to utilize the new features of NetView 7.1.  
To
join,
visit http://www.tivoli-ug.org/groups.php?groupid=151 

As for Forwarding to TEC, that's entirely optional, so if you don't
need
to do it anymore, you need not.  It is controlled by the file
/usr/OV/conf/tecint.conf.
Just rename that file and restart nvserverd and TEC forwarding ceases.
But
you'll have to explain what you mean about using a different ruleset
to

handle your events.  Rulesets are active only in a particular context.

Some are used for event windows, one is specified in the tecint.conf
to

handle TEC forwarding, and others may be specified in
/usr/OV/conf/ESE.automation to perform various background tasks.  But
there is no general ruleset which handles all your events.

HTH

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



"Gavin Newman" <NEWMANGJ@banksa.com.au>
Sent by: owner-nv-l@lists.us.ibm.com 
03/24/2004 07:57 PM
Please respond to
nv-l


To
<nv-l@lists.us.ibm.com>
cc

Subject
[nv-l] Netview upgrades






I'm currently running Netview 5.1 on AIX 4.3.3. We need to move to AIX
5.x and will need to upgrade to Netview 7.1.x.
We will be installing the new version on a new platform so it need not
be an upgrade over the top of 5.x (which I understand needs an
intermediate 6.x step).

Given that we would have a fresh 7.x install how can we transfer our
existing rules, configurations, maps etc to the new installation so as
not to have to redraw our very complicated maps etc.

Secondly - we used to forward events to Tivoli using a complicated
rule
set. Over time the rules changed such that 99% of our events now
trigger
scripts which do various things and we are now dropping the forward to
Tivoli altogether.
We currently define the rule to be used by Netview by starting Tivoli
and setting the "Forwarding to Tivoli" config option. If we no
longer
have Tivoli involved in our Netview installtion how do we tell Netview
which ruleset we want to handle our incoming events?

Cheers - Gavin Newman



**********************************************************************
*****   IMPORTANT INFORMATION    *****
This document should be read only by those persons to whom it is
addressed and its content is not intended for use by any other
persons.  If you have received this message in error, please notify
us immediately.  Please also destroy and delete the message from
your computer.  Any unauthorised form of reproduction of this message
is strictly prohibited.

St George Bank Limited AFSL 240997 or its subsidiaries ASSIRT Pty Ltd
AFSL 240979, Advance Asset Management Limited AFSL 240902, PACT
Accountants Investment Group Pty Limited AFSL 240693, St George Life
Limited AFSL 240900, ASGARD Capital Management Limited AFSL 240695
and Securitor Financial Group Limited AFSL 240687 is not liable for
the proper and complete transmission of the information contained in
this communication, nor for any delay in its receipt.
**********************************************************************




**********************************************************************
*****   IMPORTANT INFORMATION    *****
This document should be read only by those persons to whom it is
addressed and its content is not intended for use by any other
persons.  If you have received this message in error, please notify
us immediately.  Please also destroy and delete the message from
your computer.  Any unauthorised form of reproduction of this message
is strictly prohibited.

St George Bank Limited AFSL 240997 or its subsidiaries ASSIRT Pty Ltd
AFSL 240979, Advance Asset Management Limited AFSL 240902, PACT
Accountants Investment Group Pty Limited AFSL 240693, St George Life
Limited AFSL 240900, ASGARD Capital Management Limited AFSL 240695
and Securitor Financial Group Limited AFSL 240687 is not liable for
the proper and complete transmission of the information contained in
this communication, nor for any delay in its receipt.
**********************************************************************




**********************************************************************
*****   IMPORTANT INFORMATION    *****
This document should be read only by those persons to whom it is 
addressed and its content is not intended for use by any other 
persons.  If you have received this message in error, please notify
us immediately.  Please also destroy and delete the message from 
your computer.  Any unauthorised form of reproduction of this message
is strictly prohibited.

St George Bank Limited AFSL 240997 or its subsidiaries ASSIRT Pty Ltd 
AFSL 240979, Advance Asset Management Limited AFSL 240902, PACT 
Accountants Investment Group Pty Limited AFSL 240693, St George Life 
Limited AFSL 240900, ASGARD Capital Management Limited AFSL 240695 
and Securitor Financial Group Limited AFSL 240687 is not liable for 
the proper and complete transmission of the information contained in 
this communication, nor for any delay in its receipt.
**********************************************************************