On Thu, Sep 04, 2008 at 10:11:39AM +0200, Morten Brekkevold wrote:
On Thu, 28 Aug 2008 15:18:12 +0100 Tim Chown tjc@ecs.soton.ac.uk wrote:
b1-l1-cat1 may have indexed one of its temperature sensors as 1 during the initial import into NAV, and then changed its mind at a later time. That would account for the problem you're having.
Thanks for the explanation. What then is the recommended way to suppress errors related to this OID? NAV kindly generates email alerts for errors when querying devices, we just have a few too many related to this OID :)
There is no recommended way, really. Cricket is a noisy fellow, complaining about every little thing that annoys it, and since it normally runs every five minutes, it annoys the heck out of many a sysadmin during the course of a day.
Now I realise why it is called cricket. Nothing to do with the game :)
Most installations I've run into either direct cron-mail from Cricket into /dev/null, or put it into a mailbox they check less often than their inbox. It's output is not all terribly useful.
OK, so a suggestion is that in nav.conf you currently have (for example):
# The e-mail address of the NAV system administrator. All cron error # messages will be sent to this address. ADMIN_MAIL=systjc@ecs.soton.ac.uk
I suggest you add another option
CRON_MAIL=....
so you can still have an admin contact on the NAV system/web view, but direct cron stuff easily to nowhere. Or maybe a variable for just the Cricket cron outputs if NAV cron output is useful :)
Is there a recommended way to configure NAV to not poll our 3750 stacks for temp data?
You could re-profile them and see whether NAV notices that they don't support that OID anymore.
Thanks for the explanation, it does help a lot to understand it, though reprofiling had no effect :/
A week ago I knew far less about OIDs and I think I was better for it :)
Welcome to the wonderful world of SNMP ;)
We've just started looking at our 1230 series Cisco APs and including them in NAV. Fun with OIDs there too. I think that will be for a separate mail later ;)
Thanks again for the excellent support/explanations.
On Thu, 4 Sep 2008 16:59:28 +0100 Tim Chown tjc@ecs.soton.ac.uk wrote:
Now I realise why it is called cricket. Nothing to do with the game :)
And it makes is so much harder to google for information about the software :)
OK, so a suggestion is that in nav.conf you currently have (for example):
# The e-mail address of the NAV system administrator. All cron error # messages will be sent to this address. ADMIN_MAIL=systjc@ecs.soton.ac.uk
I suggest you add another option
CRON_MAIL=....
so you can still have an admin contact on the NAV system/web view, but direct cron stuff easily to nowhere. Or maybe a variable for just the Cricket cron outputs if NAV cron output is useful :)
The ADMIN_MAIL setting has no relation to what is displayed as a contact anywhere on the NAV web; that's just regular HTML configured by the administrators in the webfront config/template files.
The point of ADMIN_MAIL is to have something to fall back to if all other methods of getting attention fail.
One thing you can do is edit /etc/nav/cron.d/cricket and redirect everything from the collect-subtrees cricket command to /dev/null and then run "nav restart cricket" to reinstall the cron snippet into navcron's crontab.
If you do that, you can still find cricket's messages in its log files. It's default loglevel is more verbose than just error messages, so you'd either have to grep the logs for errors or adjust the loglevel in cricket-conf.pl.
Is there a recommended way to configure NAV to not poll our 3750 stacks for temp data?
You could re-profile them and see whether NAV notices that they don't support that OID anymore.
Thanks for the explanation, it does help a lot to understand it, though reprofiling had no effect :/
Hmm, that's strange. Do the OID profiles of your 3750's still include the tempInlet oidkey? Or is it just that cricket hasn't been reconfigured yet (which happens nightly)?
We've just started looking at our 1230 series Cisco APs and including them in NAV. Fun with OIDs there too. I think that will be for a separate mail later ;)
ooh, wireless...
Thanks again for the excellent support/explanations.
You deserve thanks as well, your above-average informative/useful feedback makes it possible :)
-
Morten Brekkevold -
Tim Chown