3101 is getting fixed for 2.2.
Thanks,
Matt Ray
Zenoss Community Manager
community.zenoss.com
[EMAIL PROTECTED]
On May 5, 2008, at 12:29 AM, kpg123 wrote:
askbill wrote:
Ok, I've done all of this now. The only difference is the MIBs
directory. I think the difference is that I'm using the VM and
there's no /opt/zenoss/ directory. Instead the files are in /usr/
share/mibs/ which looked more obvious to me.
If you're using the VMWare appliance you should put the MIBs into a
directory that doesn't exist (ie you need to create it with a
command like mkdir -p /home/zenoss/share/mibs)
/home/zenoss/share/mibs
I've opened a ticket to add the directory: 3101
If you're unsure about the directory location, you can verify by
adding a print statement into Products/ZenModel/zenmib.py after
smimibdir is defined and running
zenmib run --nocommit mymibfile
Realistically, this should be a part of the info that comes up
from the help on zenmib. I'll add the option to set a new default
MIB directory which will cause it to come up in the help section.
It's probably something that should also be a part of the
documentation if it's not there already (I'm too lazy to check :).
Hopefully the option should make it into the next point release
after 2.2.
In some cases now I'm receiving a textual description of what an
OID or trap means, but not in most. In one case, there are 2
traps, link up and link down for an IPSEC tunnel, that provide no
description. The specific MIB for those objects was loaded
successfully, although with some dependency errors.
Some OIDs don't have descriptions, so it's possible that it might be
an OID that someone considered "self-documenting". :) Check it out
in with a MIB viewer or inside of Zenoss in the "Mibs" section of
the navigation bar.
If the OID does have a description, then you might want to run
zenmib with the --debug and --nocommit options which will show you
the command-line which is used to generate the python code which
would be imported.
To be more precise,
zenmib run --nocommit -v10 --debug mymibname
Run that command-line and save the output to a file which will be
something like:
smidump -fpython mymibname >mymib_to_python.py
(The above mini-example has no dependencies, otherwise there will be
-p options and the filename of the MIB to include)
Then look at the generated python to verify that the description
made it into the file. This will see if it's a problem with smidump
or if it's a Zenoss error. If it's a Zenoss issue, then you'll
need to pursue it more deeply by looking at rules and then Zenoss
code.
Do you think the dependency errors have something to do with this?
In general, I really think I'm seeing significantly less
descriptions then I should be. Maybe I've missed something bigger.
They might be affecting it, but you'd need to follow the above
steps to see the smidump output to see.
kells
-------------------- m2f --------------------
Read this topic online here:
http://community.zenoss.com/forums/viewtopic.php?p=19340#19340
-------------------- 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
