If you're going to do dependency rules, it may be a good idea to keep them
optional; I like having them all go into alarm b/c not all of our shift
engineers know how severe a particular server name...by showing
'named-status', 'www-port', and 'radiusd-status', they know it's severe,
and who to call as well.
one other idea; how about an option allowing you to lengthen one column,
and shorten another. The 'wide' option doesn't lengthen the 'site' field
for example which would be nic.
On Thu, 3 Sep 1998, Vikas Aggarwal wrote:
> >From the positive and negative feed back that I have recieved so far, I
> was going to add the following features to 'netconsole':
>
> 1. read the updates file (similar to the web interface) and hide the
> event or display the status line. This is doable fairly easily.
> The only problem is the real-estate on the 80 char screen.
>
> I dont want to add authentication etc. into the curses interface and
> make it overly complicated, hence editing the 'updates' file will still
> have to be using an external editor or else from the Web interface.
>
> 2. A lot of folks like the web interface, so I dont see a need to replace
> it with a X or tcl interface and achieve the same 'gui' look.
>
> 3. I was going to add a 'dependency' filter to netconsole:
>
> List all the variables at the various layers i.e.
>
> NewsPort, SMTPport, etc. depend on ICMP
>
> so if ICMP goes down, then the other variables are expected to go down
> and need not display them.
>
> Similarly, build a device dependency:
>
> NewsServer depends on RouterA depends on RouterB
>
> Hence, if routerB goes dead, the other devices behind it are expected
> to go down also so DONT display them if they also go down.
>
> A sort of a 'root-cause' filter.
>
> Note that this is for *display* purposes only- all noclogd logging will
> still continue as is.
>
> The problem is finding a good way to write all these dependency rules
> without expecting everyone to be a C programmer ?
>
>
> -vikas
>
>
> > The easiest way to do something like this would be to split the objects up
> > into two layers; the event layer which reads the events and reports them
> > to whatever higher layers request it, and the output layer which all of
> >
> > It may also be a nice idea to implement them all into one binary, towhich
> > you could type 'netconsole -t vt100' and get a vt100 output, or
> > 'netconsole -t x' and get an x window, etc. This goes along with my other
> > >
> > > However..... having hacked curses full time for a number of
> > > months I can relate to Vikas's attitude!
> > >
> > > What about replacing "netconsole" with two interfaces which
> > > don't involve curses:
>
Thank you,
Jonathan A. Zdziarski
Senior Systems Administrator
Netrail, Inc.
888.NET.RAIL x242
|