[Date Prev]   [Date Next] [Thread Prev]   [Thread Next] [Date Index]   [Thread Index]


     Re: outage note//scheduled outage

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