nv-l

Re: Keeping NV fields up-to-date

2000-04-07 12:24:22
Subject: Re: Keeping NV fields up-to-date
From: Jeff Fitzwater <jfitz AT Princeton DOT EDU>
To: nv-l AT lists.tivoli DOT com
Date: Fri, 07 Apr 2000 12:24:22 -0400
Here is a fix that works.

I use the "nvdbimport" command.   See man page in Admin Ref pg107.  It
has example of HTTP.   I don't see how the oid_to_type with W attribute
would get pluged in if you never do a discovery.  I load all host with
"loadhosts" so I control what gets maped.

This procedure did the trick to make devices that support WEB browser
work via menu pull down or executable icon if needed.

Jeff F.

Jeff Fitzwater wrote:
> 
> NV 6 on sol 2.6
> 
> I have a similar problem with the oid-to-type field .  If I change field 4
> to have a (BW) indicating it is a bridge and has a web interface, I can't
> seam to make the devices learn the new field attribute.      I have shut
> down netview and executed (ovw -fields) and also tried (ovtopofix -a) and
> still the devices do not understand they are web capable.   They work fine
> if I set the object info for HTTP manually from the device pull-down menu.
> I have even deleted an object and rediscoveered it via (loadhosts) and still
> no entry to the device object field for HTTP.
> 
> Jeff Fitzwater
> CIT Systems & Networking
> Princeton University
> 
> ----- Original Message -----
> From: <lclark AT us.ibm DOT com>
> To: <NV-L AT tkg DOT com>
> Sent: Friday, April 07, 2000 9:10 AM
> Subject: Re:[NV-L] Keeping NV fields up-to-date
> 
> >
> >
> > Joe, most of my work is with new installs, so I don't often see the
> > kinds of administrative problems long-running installations have.
> > But here's my two cents' worth anyway.
> >
> > I believe that the vendor and agent fields do not get updated on a
> > config poll, only at initial discovery. Those are the only ones that
> > have bothered me, anyway.
> >
> > I always make sure that the oid_to_type file is backed up by the
> > vendor list (ovw_fields) and agent list (snmp_fields). This is not
> > always done if third-party products are added. If they don't match
> > exactly, the agent and vendor fields in the oid_to_type file won't
> > be added to the object info for a newly discovered node.
> >
> > Then I always set up a collection (smartset) with the criteria of the
> > vendor field being unset, but which is snmp-capable. This gives me
> > a group to watch. Anything that shows up in here is probably not drawn
> > properly, since I know there is no entry in the oid_to_type file for it,
> > or it was discovered before I updated the configuration files. It flags
> > new types of devices based on oid. If something shows up, I know
> > that I have to update the vendor and agent lists, the oid_to_type, and
> > maybe the oid_to_sym files, and then I delete and rediscover those
> > nodes, primarily because I want the vendor field to be set, because it
> > is the criteria for my 'to-do' collection.
> >
> > Can  you point out other fields that are bothering you?  This discussion,
> > like the recent discussion of long-term administration of seedfiles, is
> > one that is best held between customers who see the real-life issues
> > over the long haul.
> >
> > Cordially,
> >
> > Leslie A. Clark
> > IBM Global Services - Systems Mgmt & Networking
> > Detroit
> >
> > ---------------------- Forwarded by Leslie Clark/Southfield/IBM on
> > 04/07/2000 08:54 AM ---------------------------
> >
> > "Prokott, Joe" <Joe.Prokott AT westgroup DOT com>@tkg.com on 04/06/2000 
> > 06:23:27
> > PM
> >
> > Please respond to IBM NetView Discussion <nv-l AT tkg DOT com>
> >
> > Sent by:  owner-nv-l AT tkg DOT com
> >
> >
> > To:   "'NV Forum'" <nv-l AT tkg DOT com>
> > cc:
> > Subject:  [NV-L] Keeping NV fields up-to-date
> >
> >
> >
> > We have a never ending and growing NetView environment and sometimes
> > struggle keeping all the NV fields for objects up-to-date.
> >
> > Does anyone know of a good way to verify that all NetView fields are
> > up-to-date?  I know there are some NV fields that only get defined upon
> > initial discovery and will not change unless rediscovered, even if the
> > fields files themselves have been updated.  Is there a list of these type
> > of
> > fields that do not change once initially defined?  Better yet, is there
> > some
> > way I can run a script that will either (1) let me know what nodes need to
> > be re-discovered because there is a conflict with what is defined in the
> NV
> > database and what is defined in the fields/oid_to_sym/oid_to_type/etc...
> > files, or (2) dynamically update these differences to match what is
> > defined.
> >
> >
> > There are always new fields added to new versions of NetView and I am
> never
> > quite sure if these will automatically be added or if I will need to
> > rediscover the node so the new fields get added.  It would be nice if
> > NetView could tell me what the differences were so we could keep things
> > up-to-date.  It is not practical for us to rediscover our entire network
> on
> > some regular basis because we do not know if there are NV object field
> > changes or not.
> >
> > I assume many others have this same problem.  I would like as close to an
> > automated solution to this problem as possible.
> >
> >
> > Joe Prokott
> > Network Architect
> > West Group
> > phone:  651-687-4536
> > e-mail: joe.prokott AT westgroup DOT com
> >
> >
> >
> > _________________________________________________________________________
> >
> > NV-L List information (unsubscribing, policies, posting, digest version,
> > searchable archives): http://www.tkg.com/nv-l
> >
> >
> >
> > _________________________________________________________________________
> >
> > NV-L List information (unsubscribing, policies, posting, digest version,
> > searchable archives): http://www.tkg.com/nv-l
> >
> 
> _________________________________________________________________________
> 
> NV-L List information (unsubscribing, policies, posting, digest version,
> searchable archives): http://www.tkg.com/nv-l