Server configuration versus management

[Rodent of Unusual Size <co...@decus.org>]

    It seems to me that there are at least two different dimensions to
    this whole area:

     1. Server configuration: namely, managing the directives that define
        the server's operating environment
     2. Server management: starting/stopping/reloading, checking log
        files, etc. - day-to-day stuff

    The former is likely to be a major undertaking, particularly with
    the potential for a complete rework of the config grammar for Apache
    2.0.  The latter, however, ought to be reasonably do-able with what
    we have now.  It also shouldn't require a lot of Deep Thought.  As
    someone pointed out earlier, perhaps the Netscape model of a
    separate admin server to do this stuff to the main one is a good
    place to start.  For a first pass, a package of CGI scripts ought to
    get us going, which can possibly be turned into a real module later.
    Security is a significant issue.

    I'm a little concerned about the notes I've been reading about
    efforts to do GUI stuff in C++, or the latest Java workbench
    environment, or whatever.  I think we shouldn't lose sight of the
    fact that Apache is currently (though not for long ;-) UNIX-only,
    and not all of these environments are going to be available for all
    the various UNIces.  Nor will a fancy NT-GUI tool fly with someone
    who uses an X-based workstation.  Let's try and keep a fairly common
    denominator..

    #ken    :-)}

Re: Server configuration versus management

[bo...@guardian.no]

[Rodent of Unusual Size]
| 
| I'm a little concerned about the notes I've been reading about
| efforts to do GUI stuff in C++, or the latest Java workbench
| environment, or whatever.  I think we shouldn't lose sight of the
| fact that Apache is currently (though not for long ;-) UNIX-only,
| and not all of these environments are going to be available for all
| the various UNIces.  Nor will a fancy NT-GUI tool fly with someone
| who uses an X-based workstation.  Let's try and keep a fairly common
| denominator..

I definitively have to agree with you on that. we should try to write
this in a language that is portable enough to (hopefully) run the
client unmodified on most platforms.

C++ is a definitive no no.  I think the server parts should be written
in C and the client/GUI parts in some other language.  although I have
no experience with Python, from what I hear, it is supposed to be very
portable and very easy to develop user interfaces in.  (perhaps
someone who has used Python can offer some input?).

other than that I think we should try to come to some agreement on the
following.

 1) goals.  what does this system do?  does it maintain configurations
    (well, obviously :), does it analyze logs?  does it advise the
    administrator of tuning?

 2) define the parts of the system.

 3) determine what protocols are needed, then determine what sort
    of protocol we can use, should use or wether we need to design
    one ourselves.

 4) implementation specifics.  what language, what database(s),
    what libraries.

 5) implementators.  who can write the code?  who can review the
    code?


I am usually quite stressed for time and I am not sure how things will
be the next 6 months, but I will probably not have much time to write
code before august.  meanwhile I would like to dedicate some time to
following this project an offer my opinion to those who want to
listen.  perhaps even write some code if there should be the
occasional free moment.

(tomorrow my girfriend comes back from the US so I guess I will be
 indisposed for some time :-)

-Bj�rn
-- 
 Bj�rn Borud <bo...@guardian.no>       | "The Net interprets censorship 
 <URL:http://www.pvv.unit.no/~borud/>  | as damage and routes around it."
 UNIX person, one of "them"            |         - John Gilmore