Jane -
My colleague has confirmed that IY14241 (using default "public" community
name when it is not defined) is in NT for 6.0.2 as well as UNIX, though
the fix was actually added as part of some general code restructuring and
not as a result of the APAR so that number dose not show in the defect
list. Another relevant fix involves snmpcollect using public when he
should not, PJ27435. I will post a complete defect list as soon as I
have time. NetView 6.0.2 will be generally available March 2, 2001, so I
was not planning on doing this o soon. Ken threw me a curve when he
published that tome-raider version of the Release Notes here yesterday,
since at this point, only hot list customers (those who have made special
arrangements to get an early copy) have seen the code or the Release Notes.
But anyone can publish anything they want to this thing. Just be a bit
patient. The official copies from manufacturing are being minted right
now.
We are still distributing it internally. I just received our official
copies by Fed EX yesterday morning.
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
Jane Curry <jane.curry AT skills-1st.co DOT uk>@tkg.com on 02/05/2001 04:40:05
PM
Please respond to IBM NetView Discussion <nv-l AT tkg DOT com>
Sent by: owner-nv-l AT tkg DOT com
To: NetView mailing list <nv-l AT tkg DOT com>
cc:
Subject: [NV-L] Using public as community name in spite of...
We are struggling with NetView 6.0.1 on NT to prevent it using public as
a community name. ovsnmp.conf has a few specific node/community names
(none using public) and a default that is NOT public. We have entirely
removed communityNames.conf. In spite of this, we find nodes being
sent SNMP packets with public - and when the SNMP GET is successful, the
node is automatically added to ovsnmp.conf with public.
WE DON'T HAVE CONTROL OVER THESE DEVICES SO SUGGESTING CHANGING THE
AGENT CUSTOMISATION IS NOT VALID, but we really, really, don't want to
get SNMP answers out of them.
An earlier append suggested that following this process, including the
complete removal of communityNames.conf, solved the problem - but
perhaps that scenario was Unix rather than NT??
2 questions:
1) Does anyone else see this problem and have a solution? We are
working on using the "I" flag in oid_to_type - not sure yet whether it
is going to suffice
2) Does anyone know if this is fixed in 6.0.2 which James said had gone
to manufacturing last week (Hint - James - if you have time, I'd love a
list of bug fixes in 6.0.2.....)
Thanks for any input,
Jane
--
Tivoli Certified Enterprise Consultant & Instructor
Skills 1st Limited, 2 Cedar Chase, Taplow, Bucks, SL6 0EU, UK
Tel: +44 (0)1628 782565
Copyright (c) 2001 Jane Curry <jane.curry AT skills-1st.co DOT uk>. All rights
reserved.
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
|
