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

Reply via email to