note
Rhys
Okay, I've got good news and bad news.
<p>
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.
</p>
<p>
The bad news is I have to add new code to any module that needs to load MIBs. The new code is as follows:
</p>
<code>
@DIRS = `ls -1d /usr/local/share/snmp/mibs/TEMP/*`;
foreach $dir ( @DIRS ) {
chomp $dir;
&SNMP::addMibDirs("$dir");
}
</code>
Anyway, some more detail on the advantages:
<p>
<ol>
<li>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.</li>
<li>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.</li>
<li>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.</li>
<li>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).</li>
</ol>
I may even write a separate script just to detect duplicates, since the user has a nasty tendency to do that. :-)
<p>
Anyway, I want to thank all those who offered suggestions. Hopefully this will be the last time I have to worry about this. :-D
<p>
--Rhys
296312
296629