Re: Some feature notes for monit

[Jan-Henrik Haukeland]

First, thanks for a well presented and constructive email. We need new 
ideas to continue evolve monit. However we are all non-paid volunteers 
and work on monit in our spare time so development tends to be 
interest-based and not always what (others think) are important for 
monit. Suggestions are welcome and suggestions backed up by code 
(patches) are even more welcome and more likely to make it into monit 
:)

Others have comment on your mail and I just thought I should mark those 
suggestions I would like to put on our TODO list 
(http://www.tildeslash.com/monit/next.html) where 1=ok, 0=no opinion 
-1=no. If the other commiters could be so kind and do the same we may 
have a consensus on what to add.


On Jul 7, 2004, at 5:40 PM, Vlada Macek wrote:

> ### MiB, GiB, KiB... units

-1

> ### Usability: Hashes on the monit command line

+1 Good idea, most unixes has this functionality already, but not all. 
For example my OS X does not. Another pluss is that this cost little 
since we have the functions in monit. I also like your suggestion for 
output:

> An example:
>
>     $ monit -H < /etc/passwd
>     MD5 (stdin) = 5676cffe1b85f738ad53bc8fcf4075f5
>     SHA1(stdin) = a9e98b7aa950d5cca495f9c83c357360005516b2
>     $
>
>
> ### Syntax inconsistence: CERTMD5

+1 It's a documentation issue, openssl handles both.

> ### Syntax inconsistence: start/stop methods
>
> Wouldn't it be cleaner to write `set start "/etc/init.d/foo"' instead
> of `start="/etc/init.d/foo"'?

-1 besides, "set" is a keyword used for global statements

> ### Static binary linking

See Christian's response

> ### Mailserver must listen on port 25

+1 for flexibility but not very important in my book. Although 
server:port is a good format I agree with you that we should be 
consistent and use:

>     set mailserver first.mail.srv port 8025
>     set mailserver second.mail.srv            # usual port 25


> ### Access time changed by checks
>
> Does monit leave atime of checked fs objects intact?

0 Is atime changed by monit?

> ### Missing check: TIMESTAMP checks mtime only

0

> ### Missing check: general lstat(2) variable check

0

> ### Untight permission check

0

> ### Ability to run an arbitrary command and check:
>     - its return code in the expression (if retcode != 1 then alert)
>     - constant and variable checksum of its stdout
>     - send to stdin/expect from the stdout (like in the host check)
>     - send to stdin/checksum of the stdout

+1 I see your point and it's a good point, however this can be much 
work, touching on main parts of monit. I think you can do much of the 
functionality today by calling a shell-script in exec and do the stuff 
there. But yes it's cleaner to incorporate this in monit, so I'm in 
favor of the suggestion. The work involved means it will not be high on 
the priority list, but it should be on the todo list as something 
someone can do sometime. (Do you volunteer :)

> ### Missing check: ext2/ext3 attributes (e.g. whether the file is
> still immutable)

0

> ### Global resource (load avg, memory usage) check

1 Very good idea. It's Christians domain so lets hope he agree :)

> ### Join CHECK FILE and CHECK DIRECTORY together

0 Hmm, although everything is a file on unix there is a conceptual 
difference between file and directory that can be good to separate(?). 
But having a size and checksum test for a directory is a good idea.

> ### XML output
> - As I noticed, currently only one kind of monit status page is in
> XML. More would be great!

more may come when we continue work on m/monit

> - Minor bug: As Content-Type, _status?format=xml returns text/plain,
> should be text/xml.

Yep, Thanks

> - I propose to print all XML values in the most technical form for
> possible later processing <uptime>43m</uptime> is directly
> displayable, but <uptime>2585</uptime> would be much better!

+1 Good point

> - It may be nice to return instant systemwide resource values
> mentioned once above (uptime since boot, load averages, memory usage,
> IO, VM...) in XML and perhaps in HTML too.

Exactly, +1. (HTML though will be the output to monit's web 
interface.). If you would like to propose (write) a suggestion for a 
XML schema it would be interesting. I'm currently stuck with what we 
have.

> ### Multiple group membership

+1

> Here it is. I've some more notes prepared, but it is enough for now.

If you have more stuff it's very welcome.


--
Jan-Henrik Haukeland