Dear all, I am now using mon.cgi I can successfully login with mon but the error follow still occur: ---------- Could not successfully execute command "monitor" test service "http" on hostgroup "wwwservers" on server "pc185.icon-info.com.hk": 520 command could not be executed (perhaps you don't have permissions in auth.cf?) ---------
Why? What is a normal auth.cf? I have modified my auth.cf and put into /etc/mon/auth.cf Can anyone help? Thanks. Alex Li My auth.cf: ----------- # # command section # command section ack: AUTH_ANY checkauth: all clear: AUTH_ANY disable: AUTH_ANY dump: AUTH_ANY enable: AUTH_ANY get: AUTH_ANY list: all loadstate: AUTH_ANY protid: all quit: all reload: AUTH_ANY reset: AUTH_ANY savestate: AUTH_ANY servertime: all set: AUTH_ANY start: AUTH_ANY stop: AUTH_ANY term: AUTH_ANY test: AUTH_ANY version: all # # trap section # # if no source hosts or users are defined, then do not # accept traps # trap section #source_host user password # # allow from user "mon" from any host # * mon alex12 # # allow from host 127.0.0.1 without requiring # a valid username and password # # 127.0.0.1 * * # ----- Original Message ----- From: "Andrew Ryan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, November 22, 2001 2:06 AM Subject: Re: upalerts and "exit=n" > At 09:42 AM 11/21/01 -0500, [EMAIL PROTECTED] wrote: > > I > >guess the right way to handle this would be to keep a list within mon of > >current failure states that haven't gone back to zero, and send upalerts to > >all of them? > > > >I realize it would probably be a lot of work to hack this into mon, but it > >would be a really useful feature. > > It's the right direction, but it's still not a complete solution without > host awareness. For example, to extend your example, not only is it > possible for exit statuses to change each time a monitor is run, but it's > also possible for the failed hosts to change, and for different hosts to > have different exit statuses. So not only would you need to match up exit > codes but also hosts. > > Doing this in the current 0.99 codebase would be possible, but probably a > huge and ugly hack. I think we'll have to wait for the 1.1 development > branch when Jim revamps some of the protocols to allow for more > fine-grained alerting, to leverage the scalability of the hostgroup concept > and still allow for very fine-grained state tracking at the per-host and > per-service level. > >
