Re: Some stuff....

[Jan-Henrik Haukeland]

Christian Hopp <address@hidden> writes:

> I have again some ideas for discussion...
> 
> 1) [Feature]
> 
>    An optional "DESC[RIPTION] STRING" entry for every check.  It might
>    be useful in cases that more then one admin uses monit.  It should
>    display in the web interface, maybe in the status and in the alert
>    emails too.

Aside from the web interface you could simply use comments in the
monitrc file to document each entry. But I'm sort of indifferent to this.

> 2) [Feature]
> 
>    A possibility to run Monit as "CGI" => Monit's status in html
>    format additionally to the normal status.

But the staus is already right there on the front page, in HTML and
easily parsable by e.g. Perl.  But I'm open for outputting various
information from the web server, for instance support for the SOAP
protocol.

> 3) [Security]
> 
>    A "dumb" mode for the httpd server => for the paranoid admin.  In
>    case you want to have the status in the httpd but no interaction.

I'm not sure, if you're really paranoide simply do not run the web
server, okay, you will miss out on some function but monit will work
fine without. Besides with ACL, Basic Auth and thanks to you SSL the
web server should be pretty save to run.
 
> 4) [Security]
> 
>    Monit server <-> monit client communication via "file socket"
>    instead of network => for the paranoid admin.  Why?  You can give a
>    "file socket" a more refined permissions then a network socket.
>    Even if the socket is just directed to localhost, everyone on that
>    computer can send data to it.  For the "file socket" you still need
>    the permission on the system".
> 
>    e.g.
>         USE ADDRESS /var/run/monit.sock root root 0600

This is a feature that looks good at first sight but on second sight
does only add micro-optimizing security to the server. The current
socket communication is fine, and you can use Basic Auth to only
access the Server with a password found in monitrc. And if someone can
hack the monitrc file and read the password thay can certainly change
the permissions on the unix socket file.


> 5) [Feature]
> 
>    Additional process resources:
> 
>         - number of child processes
>         - then also possible... total memory of all child processes


Sounds good (it should be put in the process detail page I think).

> 6) [Feature] But I don't like but it might be necessary...
> 
>    I18N... central string tables... etc.

English is fine isn't it for this kind of program? If and when we
create a GUI program to display the status on many monit instances
I18N could be something to consider.

To summarize

proposal my vote
1        0
2        pending +1
3        -1
4        -1
5        +1
6        -1 


-- 
Jan-Henrik Haukeland