Re: Some stuff....

[Martin Pala]

Jan-Henrik Haukeland wrote:

> 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 
>
>
>  
my votes:

1        0 In the event that monit will be used by more then one user (admin), 
it could be useful.
2        +1 for the SOAP protocol
3        0 I think it could be useful to have support for "roles" in monit, so there could be role 
"admin" that is allowed to start/stop processes via monit command-line and http interface and for 
example role "operator" that is allowed to only see the status of the processes (read-only - not 
start/stop them nor see passwords, etc.) It could be extensible => new roles could added (ACL based) or just 
static (a few predefined roles)

4        -1 i agree with Jan
5        +1
6        0 I think it could be useful to have support for localization directly 
in monit in the case that more people than admin shall use monit (for example 
in the case of roles support).


Conclusion: In the case of monit roles-like feature support i'm +1 for topics 
1, 3 and 6