Jason,
Thanks very much for both, especially #2. That was a pain! :)
-Daniel
Jason Stevens wrote:
I've created a ticket for this issue:
http://dev.zenoss.org/trac/ticket/1128
In addition to correcting the bug we'll throw together a script to
avoid the pain of manually deleting the local value of zSnmpVers for
devices already modeled. Stay tuned.
-jason
On Mar 24, 2007, at 11:15 PM, Greg Davis wrote:
Sorry, typo.
New devices are set to snmp v1 by default instead of inheriting the
zProp from the parent container.
--Greg
Greg Davis wrote:
Just to chime in here...
I have had this issue for a while, new devices are set to snmp v2c
by default instead of inheriting the zProp from the parent
container. I use ONLY v2c but i always have to delete the local prop
from new devices. Furthermore some function in Zenoss (not sure but
I think it may be zenmodeler) resets the snmp version to 1. From
time to time I get a device that is working normally but generating
all kinds of events because some of the monitored OIDs are v2c only.
I go delete the local SnmpVer zProperty and everything sorts itself
out. Can we look into why this important setting is not handled
correctly?
--Gregory Davis
Erik A. Dahl wrote:
Daniel,
You actually need to delete the property using the popup all the
way at the bottom of the zProperties page called "Delete Local
Property". Blanking out the field won't do it.
-EAD
On Mar 23, 2007, at 10:47 AM, Daniel McKinney wrote:
Erik,
Ok, I went to the following link:
http://192.168.204.29:8080/zport/dmd/Devices/Server/Linux/32-bit/devices/www3/zPropertyEdit
Then i scrolled down to zSnmpVer and emptied out that field. Then
hit Save.
I was expecting it to be populated with the v2c from the parent
zSnmpVer field set at this link:
http://192.168.204.29:8080/zport/dmd/Devices/zPropertyEdit
It wasn't. It was still blank. I thought maybe it needed to have
the collection collected using the Manage tab. Still no luck.
I went so far as stopping all of Zenoss then starting it back up
and checking that page again. It's still blank.
Am i doing something wrong?
Thanks,
-Daniel
Erik A. Dahl wrote:
Daniel,
In stead of changing it on the device you need to delete its
local zProperty. This will allow the higher level one to set
the value. I think the problem is the local property overriding
the one higher up. You can delete the property at the bottom of
the zProperties page.
-EAD
On Mar 22, 2007, at 9:00 AM, Daniel McKinney wrote:
Erik,
Not sure what you mean by bad device. Do you mean the devices
that are complaining about bad OIDs? The only time i get bad
OID messages (after i researched some more) is when i move a
device from one Monitor to my new custom one. When that
occurs, the zSnmpVer field gets reset to v1 and that is when the
bad OIDs start.
Other than that, i still get the same problem Rob is having. I
go to a Class, set the zProperties' zSnmpVer to v2c and i still
have to manually go to each device beneath that Class and change
the zSnmpVer to v2c.
Thanks,
-Daniel
Erik A. Dahl wrote:
Hum,
Can you look on a bad device and see if the version has been
defined _just_ for that device? I wonder if the modeler is
messing this up. Shouldn't be.
-EAd
On Mar 21, 2007, at 7:47 AM, Daniel McKinney wrote:
Rob,
I had the same problem and i couldnt find a solution.
Actually, to make things worse, sometimes after i make the
change, it periodically reverts itself back to v1 and i cant
find out why just yet.
I originally thought it was reverting certain devices back to
v1 after i did an ./zenperfsnmp run -v10 -d <device_name>.
But i cant duplicate it. I basically do my normal tinkering
and anytime i get alot of "BAD OID" events/messages in the
zenperfsnmp.log file i check the zSnmpVer and sure enough, its
set back to v1. Very frustrating.
I think i am going to send a separate email to the zenoss dev
mailing list asking as a feature request to be able to toggle
the Snmp Version at the "Add Device" phase.
Does anyone know where the default setting is for the zSnmpVer
field? If i could set the default zSnmpVer to v2c, i would be
in business.
Before anyone says it, the very first step i did was click on
Devices/zProperties, went down to the zSnmpVer field and set
that to v2c a long time ago, so that cant be where the
"default" setting is. I know this because if i add a device,
it always adds it with v1 and i have to go in afterwards and
change it to v2c every time.
Thanks,
-Daniel
rgrijalvo wrote:
Hi All,
I'm hoping my logic is correct, but if someone could verify
Zenoss' behavior for the following, I'd really appreciate it.
I was under the impression that if I changed any of the
zProperties for a certain class, in this case,
/Device/Network/Router, the changes would apply for all
devices within the class.
The parameter I am having issues with is zSnmpVer. Under the
class router, I changed it to v2. The path for this
parameter is listed as /Network/Router. However, when I go
to the zProperties tab of a newly discovered device of class
Router, the zSnmpVer value is back to the default of v1. It
does show a new path of
/Network/Router/devices/<device_name>. The new path does not
really surprise me, but I thought it would use what I defined
at the Router class level.
Am I correct in my expectations? I modified the
zCollectorCollectPlugins parameter to exclude the RouteMap
plugin and it propagated to all devices discovered with that
class.
Thanks everyone for their feedback.
Regards,
Rob-
-
-------------------- m2f --------------------
Read this topic online here:
http://community.zenoss.com/forums/viewtopic.php?p=4839#4839
-------------------- m2f --------------------
_______________________________________________
zenoss-users mailing list
[email protected]
http://lists.zenoss.org/mailman/listinfo/zenoss-users
_______________________________________________
zenoss-users mailing list
[email protected]
http://lists.zenoss.org/mailman/listinfo/zenoss-users
_______________________________________________
zenoss-users mailing list
[email protected]
http://lists.zenoss.org/mailman/listinfo/zenoss-users
_______________________________________________
zenoss-users mailing list
[email protected]
http://lists.zenoss.org/mailman/listinfo/zenoss-users
_______________________________________________
zenoss-users mailing list
[email protected]
http://lists.zenoss.org/mailman/listinfo/zenoss-users
_______________________________________________
zenoss-users mailing list
[email protected]
http://lists.zenoss.org/mailman/listinfo/zenoss-users
_______________________________________________
zenoss-users mailing list
[email protected]
http://lists.zenoss.org/mailman/listinfo/zenoss-users
_______________________________________________
zenoss-users mailing list
[email protected]
http://lists.zenoss.org/mailman/listinfo/zenoss-users
_______________________________________________
zenoss-users mailing list
[email protected]
http://lists.zenoss.org/mailman/listinfo/zenoss-users
_______________________________________________
zenoss-users mailing list
[email protected]
http://lists.zenoss.org/mailman/listinfo/zenoss-users
_______________________________________________
zenoss-users mailing list
[email protected]
http://lists.zenoss.org/mailman/listinfo/zenoss-users