|
Re: [nv-l] Solaris Agent
2003-01-24 15:34:49
On, I suspect, a similar theme, I have just had a session de-installing
and reinstalling NV 7.1.3 on Solaris 8. I DO use net-snmp but I think
the NetView installation process insists on bringing up the SEA agent
too and obviously, at this stage, uses a community name of public. If
it can't talk to this agent, it doesn't just crash the install - it
crashes the whole box! Dead Solaris - pushing up the daisies!
I've seen this a number of times before, not just with NV 7.1.3 - I'm
pretty sure I've had it with Solaris 7 too.
So, the moral of the story is to get off SEA on to net-snmp but, if you
ever need to reinstall NetView, make sure you keep an SEA agent set of
config files with a public community name, handy.
Cheers,
Jane
PS. If you want some help with the net-snmp agent, I wrote a Tivoli
Field Guide on this which you can get from the IBM Web site.
Barr, Scott wrote:
NetView v7.1.3
Solaris 2.8
Well folks, I am surprised no one else has had "the pleasure" of
discovering this problem. I just got to spend about 3 days chatting
with my good friends in support. Until about a half hour ago both
support and I were convinced we had a major netmon bug, but au
contraire, we have found a lovely little bug in the SNMP agent for
Solaris.
First, you need to understand how NETMON uses the community names file
during discovery. What was happening was that after discovery all of
our Solaris servers (which we use $ seed file entries for) would turn
red. You could ping them, but you could not demand poll them "no such
name" on the system identifier. This occured on all 150+ Solaris
servers I was monitoring. Netmon goes out and pings a device then
issues an snmpGet for the system name. If it is successful, the device
is SNMP managed and if it times out, netmon goes on to the next
community name until he finds one that works.
HOWEVER (and you can try this at home if you like)
When "snmpget -c public <nodename> system.sysName.0" is issued by the
netmon process, the results (which should be a time out) are:
Solaris:
# snmpget -c public wfx-vrz1
system.sysName.0
snmpget: This variable does not exist:
.iso.org.dod.internet.mgmt.mib-2.system..
#
AIX (or any other system)
# snmpget -c public cxp-ds002 system.sysName.0
snmpget: No response arrived before timeout.
Netmon treats these responses differently. Netmon considers the first
a successful SNMP query, and therefore (since it answered to public)
does not add an entry into ovsnmp.conf and uses public from there on
out. Next status poll - the box turns red because NETMON is busy
pounding on it with public.
Solution: Since you can't put the entries into ovsnmp.conf ahead of
time, you have to discover the boxes with pings, then add a static
entry to the SNMP configuration table, then whack the node from
discovery and rerun discovery (which will now use the correct
comminity string first try since it's in the ovsnmp.conf file).
I'm not a big fan of SEA but this just put a stake in it's heart. I am
telling our Unix folks to get net-snmp on all our servers as fast as
they can.
May this message save you many hours of headaches......
Scott Barr
CSG Systems Inc.
Network Systems Engineer
Phone: 402-431-7939
Fax: 402-431-7413
Mail: scott_barr AT csgsystems DOT com
--
Tivoli Certified Consultant & Instructor
Skills 1st Limited, 2 Cedar Chase, Taplow, Bucks, SL6 0EU, UK
Tel: +44 (0)1628 782565
Copyright (c) 2003 Jane Curry <jane.curry AT skills-1st.co DOT uk>. All rights
reserved.
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe AT lists.tivoli DOT com
For additional commands, e-mail: nv-l-help AT lists.tivoli DOT com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
|
|
|
