John,
How much of a duplicate do you want?
It is rather difficult to explain this, because the installation process for
NetView assumes that you have made the decision either to start afresh or to
migrate all your old stuff, and it proceeds from there. There is no middle
ground unless you are very experienced with the product and know something
about how the old system works.
Sounds to me like you should have done a migration install. Let me explain how
you could do that still, if you are willing to de-install the NetView 5.1 you
have and re-install it. The procedure would be to go to the V3 box and create a
backup for
migration. You do that with a script provided on the 5.1 installation CD. It
creates a directory structure called usr/OV/ALL.USER . Then you tar up that
directory structure and ftp it to the box where you have you removed 5.1. Untar
it. When you re-install 5.1, it will find that directory structure on the
"new" box and merge everything you have for V3 which can be migrated into V5.1.
But follow the directions in the 5.1 Release Notes on page 17 and following:
"4.2 Migration and Deinstallation" to make sure you don't leave out any crucial
steps. One in particular for trapd is to run the chktrapd.conf script in the
/MUSTSEE directory of the CD. You run this against your V3 trapd.conf so that
it will identify any entries there that won't migrate without modification.
The point of all this is that when you are done, not only have we taken and
merged all the new things in trapd.conf with what was in the V3, but we have
merged your old databases as well, and your customizations in /usr/OV/conf.
Now if there is some reason you don't want to do that, then we can just
concentrate on manually manipulating your new trapd.conf file. But it won't be
as clean as the migration install. Go to /usr/OV/conf/C on the new box and
make a backup of trapd.conf. If you screw up the syntax inside of trapd.conf,
it won't load and trapd won't start, so it is important to have a good backup,
and to make a new one every time you manipulate this file without using xnmtrap
(the GUI editor). Then ftp /usr/OV/conf/C/trapd.conf from your old box to your
new box and give it a new name.
Then run nvaddtrapdconf -h against it (you can use the -r flag too, if you want
to also change what it says in the header) and it will attempt to add all the
traps from the V3 file that are not in the V5.1 file, and change the syntax as
required to match what V5.1 requires. But this may fail because of the formats
and those will not have been modified, because we aren't doing a complete
migration. In that case, we will have to the edit the trapd.conf that was
produced and try to manually clean up the errors. Now you see why a backup is
necessary.
So as you can see this is not a simple undertaking if you want to just move
parts of the old system without knowing anything about it. Can you use your
operators as a resource and find out from them what is different about the new
that they want to work like the old?
James Shanks
Tivoli (NetView for UNIX) L3 Support
John Mayeur <jmayeur@FRUIT.COM> on 12/08/99 11:36:36 AM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on NetView
<NV-L@UCSBVM.UCSB.EDU>
To: NV-L@UCSBVM.UCSB.EDU
cc: (bcc: James Shanks/Tivoli Systems)
Subject: Re: Filters / Rulesets
James -
I did not migrate the existing trapd.conf. The new install was on a separate
box,
so nothing was actually "migrated". I am trying to build a duplicate of the old
one. Is there a way to use the old (V3) trapd.conf or manually convert it for
the
new (V5) install?
James Shanks wrote:
> John -
>
> Most people want their paging and emails to be independent of whether or not
the
> GUI is up. So they tend to have those things done either by rulesets designed
> just for that purpose and run in the background, or else have them run in
> scripts kicked off from automatic actions in trapd.conf. Either way, what
the
> operators are doing with the GUI does not matter. As long as the proper
daemons
> are up, the actions happen.
>
> To run a ruleset in the background you put its name in the
> /usr/OV/conf/ESE.automation file, which is then read by actionsvr on start
up.
> He registers them with nvcorrd, just as users register rulesets when they
open
> a dynamic workspace. The only thing to be careful of that the rulesets need
to
> be designed to be run by a daemon, which does not have a console. Since he
> cannot display events, the ruleset should not contain elements which require a
> display such as the Forward, Resolve, or Override nodes, and the Initial Event
> Stream node should be set to "Block" the sending of events to the display,
> otherwise the event subsystem will slow and eventually hang.
>
> Any filters used in V3 (and that was the only way to keep things off the
display
> in V3 unless the trap were configured to be "Log Only") will still work in
V5.1
> and later. And any scripts run as automatic actions should still work too if
> you have some of those. Did you migrate your trapd.conf or start with a fresh
> one?
>
> James Shanks
> Tivoli (NetView for UNIX) L3 Support
>
> John Mayeur <jmayeur@FRUIT.COM> on 12/07/99 03:37:42 PM
>
> Please respond to Discussion of IBM NetView and POLYCENTER Manager on NetView
> <NV-L@UCSBVM.UCSB.EDU>
>
> To: NV-L@UCSBVM.UCSB.EDU
> cc: (bcc: James Shanks/Tivoli Systems)
> Subject: Re: Filters / Rulesets
>
> James -
>
> The Netview V3 that is in production here was installed and maintained by
> persons no
> longer with the company. The hardware and the O/S are not Y2K compliant,
hence
> the
> need for the install. I inherited this system and its replacement. I have
> little
> knowledge on how it was setup and that is why I am trying to understand
rulesets
> and
> filters.
>
> I did use a seedfile to discover the network (loopbacks for routers) and
NetView
> did
> a good job of discovering. As I said earlier we use this only for UP/DOWN
> notification (currently). So at the ethernet and token-ring segment level I
have
> changed the symbol type so their status does not propagate. I don't mind
having
> all
> the objects (2000 nodes/250 networks/75 gateways) in the database because the
> box
> running NetView has plenty of resources and NetView is all that runs on it.
> This
> box sits in our data center and the computer operators monitor the networks
for
> failure. I was trying to configure the Events app so that all the operators
see
> is
> the events for the nodes we care about. Additionally I would like to add the
> features such as the pop-up window, email, paging etc.
>
> So if I understand your explanation:
>
> netmon polls
> sends updates to ovwdb & ovtopmd
> ipmap updates maps and color of the icons
> forwards trap (from netmon poll or trap sent from host) to trapd
> trapd logs and then sends to event correlation daemon
>
> In my case since I have the Events app open at start-up, it is the only
dynamic
> workspace open:
>
> correlation then processes it through the ruleset used for Events
> filter would pass or block events to the display
>
> Question:
> Is it ok to use the ruleset for Events to page, pop-up window, email or what
> ever
> you need?
> It seems this would keep things simple if it is ok to channel everything
through
> this one ruleset.
>
> James Shanks wrote:
>
> > John -
> >
> > Steve's right about this, I think.
> >
> > And basically, nothing has changed in the fundamentals since NetView Version
3
> > -- those traps you see are generated by netmon. All that has changed is
that
> > you can do more (a lot more) with the traps than before. But if you never,
> > ever want to see them, don't want them logged, and don't want to waste cpu
and
> > memory processing them, then you want to exclude them, by not having those
> > objects in your database at all. Read up on seed files and determine how
best
> > to exclude what you don't want in the database. And post your questions
here
> > for help.
> >
> > But my question to you is -- How were you handling this in V3? That method
> > should still work in 5.1
> >
> > Other than that the answers to your events questions are fairly
> straightforward.
> >
> > All events go through some ruleset or other before showing up in the event
> > window. You can use the Create pull-down to create a new window and use a
> > different ruleset in each one. You can control what ruleset is the default
> and which workspaces (windows) are started by editing
> /usr/OV/app-defaults/Nvevents.
> > Each user can have his own defaults by copying this file to his or her $HOME
> > directory and editing that.
> >
> > ESE.automation has no connection with the event windows you see. That file
is
> a
> > mechanism to have the actionsvr start some rulesets running in the
background
> > for things like paging and other notifications independently of whether the
> > event windows are open. Rulesets used there should not have any reference
to
> > the display (no Forward, no Resolve, no Override function) as this will only
> > cause performance problems.
> >
> > A filter is the last thing that happens before the window displays the
events.
> > You cannot filter the input to a ruleset, only the output. If you don't
want
> to
> > see events from DHCP addresses and you can create a filter to do that, then
do
> > it.
> > You won't see them, but they will still be generated and logged in
trapd.log.
> >
> > What we have been talking about here is the event window display. Nothing
you
> > do for this lightens NetView's load (hence Steve's response). netmon still
> > monitors (pings and issues snmpget) all nodes, ovwdb and ovtopmd put them in
> the
> > database, ipmap draws them and updates their colors on the map, and traps
> still
> > gets all the traps, logs them, and passes them on to the correlation daemon,
> > nvcorrd, for ruleset processing. So there is still all this overhead, no
> matter
> > what you display in the window. That's not a bad thing. It is just
important
> > that you know what you are doing so you can make wise choices.
> >
> > James Shanks
> > Tivoli (NetView for UNIX) L3 Support
> >
> > Steve Francis <steve.francis@COMMSERV.UCSB.EDU> on 12/06/99 05:54:32 PM
> >
> > Please respond to Discussion of IBM NetView and POLYCENTER Manager on
NetView
> > <NV-L@UCSBVM.UCSB.EDU>
> >
> > To: NV-L@UCSBVM.UCSB.EDU
> > cc: (bcc: James Shanks/Tivoli Systems)
> > Subject: Re: Filters / Rulesets
> >
> > Usually the best way to handle this is to:
> > - only discover things that you want managed (put in a discovery filter so
> > that only SNMP devices are discovered, assuimng your end user PCs are not
> > SNMP capable, or filter discovery by the SNMP OID if they are)
> > - or discover PCs as unmanaged (based on lack of SNMP support or OID).
> > Then they will not be polled by Netview, and it will not generate events
> > for them.
> >
> > Saves you lots in Netview CPU, memory, etc.
> >
> > John Mayeur wrote:
> >
> > > AIX 4.3.2
> > > Netview 5.1
> > > Framework 3.6.1
> > >
> > > I am replacing a Netview 3.x server with a new one ases described above.
> > > My company basically uses the product for up/down status notification
> > > only. It monitors routers, RS/6000's, AS/400's, file/print servers,
> > > hubs and switches. None of these hosts are configured to send traps to
> > > the new installation. I have all the components installed and working
> > > and I have a map built with all the submaps needed.
> > >
> > > My questions are concerning filters and rulesets. When Netview is
> > > started the Events app is running in the Control Desk. It is constantly
> > > scrolling messages for Node Up/Down, Interface Up/Down for hosts I don't
> > > need to monitor (end user PCs). Since there are no hosts configured
> > > (yet) to send traps, I assume these are being generated by the polling
> > > process? My goal is to show only events/traps for the nodes needed. I
> > > have noticed that the Events app starts with the forwardall.rs ruleset.
> > > Should I modify this ruleset or create a new one? How do you start the
> > > Events app with a different ruleset by default? Can you have multiple
> > > rulesets active for the Events app (ESE.automation)? Or should a filter
> > > block all of the unwanted events first. Which comes first the filter or
> > > the ruleset? I would like to start by filtering (exclude) all events
> > > that come from hosts that have an IP address issued from DHCP if
> > > possible (because I know the ranges). Would there be a better selection
> > > criteria? I have read the docs on this but it is still unclear to me.
> > > Could someone please explain the "flow" of events and traps as well as
> > > tips to efficiently handle them.
> > >
> > > John Mayeur
> > > Network Engineer
|