[Top][All Lists]

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

Re: Plans for the next release

From: Jan-Henrik Haukeland
Subject: Re: Plans for the next release
Date: 01 Jul 2002 22:28:08 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service)

Martin Pala <address@hidden> writes:

> Maybe it will be useful to use similar categories as on (for example)


> I think it it will be useful to show the status
> (Planned/InProgress/Done) and maybe developer, that actualy tries to
> do it.

Agree. Lets see, is this right:

1. Configure monit from different sources; like LDAP. - Martin
2. Using monit as an init replacement - 2. Rory or hauk?
3. Implement dependencies between program entries - Rory
4. Add support for managing program groups in the web-interface - hauk
5. Extend the port check to understand URLs - Martin and hauk will help :)
6. Provide functionality for checking program CPU usage - hauk

> Maybe next hints:
> - rewrite parser of start/stop programs is needed (actualy it supports
> only following patterns:
> 1. program -x -y
> 2. program -x parametr
> 3. program parametr

Absolutely, this needs to be fixed. I'll look into it.

> - testing modules for LDAP and MySQL, etc. This maybe will require
> redesign the protocol module schema. It allows now only network
> oriented services to be monitored and the socket is opened before the
> module is called. It isn't possible to write service test module by
> using service API (as LDAP, MySQL, etc.), where the connection (and
> its resources -
> socket, etc.) is initialized under the controle of service library. It
> could be possible to use "low-level" programming instead of API
> functions, but i think that isn't the best way in that case. In the
> case that the monitored service uses for example unix-socket or
> something similar, it isn't possible to use present schema. I realy
> like the effectivity and simplicity of present schema, but maybe it is
> to closed for testing hundreds of services and protocols.

Maybe, but using sockets and sub-implementing a protocol is a lot
easier than to link in a thirdparty API. But I'm open for suggestions
to change the protocol implementation.

> - SSL support for monit httpd (as you mentioned in the past)

Yes, but I think that will have to be in a later version.

> - support for tcp-wrapper in monit httpd

I'm not sure what you mean, please explain

> I'm working currently on virtual host support for http testing
> module. I will also modify the protocol schema to be more general -
> support more types of testing modules and to allow to do some extended
> testing specific to protocol (such as URL request, etc.) I will
> prepare the LDAP testing module too, so it can demonstrate the argues
> why change is needed (i think). I hope that i will have it ready to
> the end of this week, so maybe we can then discuss the (draft) code :)

Great stuff.

Jan-Henrik Haukeland

reply via email to

[Prev in Thread] Current Thread [Next in Thread]