Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

Re: SNMP MIB files...

by zengargoyle (Deacon)
on Oct 03, 2003 at 19:30 UTC ( #296368=note: print w/replies, xml ) Need Help??

in reply to SNMP MIB files...

i would just keep my MIB files installed with the package and add the directory to the (front or end... i forget which) of the $ENV[MIBDIRS] variable. if you craft your own .index file in the directory you don't have to worry about the filenames.

be warned, there used to be a bug in the .index code that would ignore the freshness of the .index file and re-create it every time.

Replies are listed 'Best First'.
Re: Re: SNMP MIB files...
by Rhys (Pilgrim) on Oct 05, 2003 at 02:35 UTC
    I thought about modifying the $ENV{MIBDIRS}, but I wouldn't be able to make it either global or permanent without (probably) a lot of extra work *and* making mor eintrusive changes to the system.

    Besides, adding eight or nine directories with names like '/usr/local/share/snmp/mibs/JScan/BayStack' to that variable would make it gigantic. Enormous variables have always annoyed me, and I kind of figured it annoyed others as well.

    I'm not married to the opinion, though. If I should be modifying $ENV{MIBDIRS}, what's the best way to do it? Add a script to /etc/profile.d?


      (Rhys -- I see you've fleshed it out quite a bit since we chatted in the CB.)

      How 'bout having your perl app read the dir list from a config file? This not only lets you change you mind about the MIBDIR layout, but keeps the changes confined to the app's process tree and lets your end users choose different MIBs than yours, should they wish to extend your app.

      In fact, with that, you could even keep your MIBs completely out of the common hierarchy.

      Remember, when you stare long into the abyss, you could have been home eating ice cream.
        Okay, I've got good news and bad news.

        The good news is that this will mostly work, and I can add several things to the list of stuff I no longer have to worry about.

        The bad news is I have to add new code to any module that needs to load MIBs. The new code is as follows:

        @DIRS = `ls -1d /usr/local/share/snmp/mibs/TEMP/*`; foreach $dir ( @DIRS ) { chomp $dir; &SNMP::addMibDirs("$dir"); }
        Anyway, some more detail on the advantages:

        1. I don't have to modify environment variables. This is good because if $ENV{MIBDIRS} is previously unset, you have to find out where the site-wide MIBs are stored. While this is usually predictable, I'd rather not worry about it at all.
        2. I don't have to modify environment variables. By adding the package's own base MIB directory to the config file, the change can be made effective site-wide (using the config file in /etc) without worrying about users' various shells, changing their environments, etc.
        3. I can actually eliminate a config item I used to have in the code that kept track of the location of the site-wide MIBs that come with Net-SNMP. Again, less to worry about.
        4. In the course of investigating this, I've discovered the proper use of the &SNMP::loadModules() function AND I've learned enough about duplicate MIB detection that the package's own code will be a lot leaner and the post-install script can do a lot more to detect duplicates (thus avoiding several really annoying MIB problems I've had before).
        I may even write a separate script just to detect duplicates, since the user has a nasty tendency to do that. :-)

        Anyway, I want to thank all those who offered suggestions. Hopefully this will be the last time I have to worry about this. :-D


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://296368]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (5)
As of 2021-01-28 12:47 GMT
Find Nodes?
    Voting Booth?