Re: check host syntax

[Jan-Henrik Haukeland]

In principle, I agree with your objections and your and advise to
rewrite the remote host statement. But there are a (practical) reasons
against it; I do not have time now to rewrite this now and we should
release the monit 4.0 soon. Besides, the remote host statement does
look good, and it's easy to use. Alltough this is not a good
suggestion, I suggest that we let it stand as it is now...



Martin Pala <address@hidden> writes:

> I think present syntax has drawback in port test and virtual hosts
> area. Taken from monit.pod:
>
> --SNIP--
> E.g. this is legal:
>
>  check HOST ftp.redhat.com
>    if failed port 21 then exec
>     "/usr/X11R6/bin/xmessage -display :0 RedHat is down as usual!"
>
> this is not, and will lead to a parse error:
>
>  check host ftp.redhat.com
>    if failed HOST ftp.suse.com port 21 then ...
> --SNIP--
>
> This means that:
> - you must define one check host statement for each virtual host
> running on the same node, which is more expensive then have it in one
> host statement
> - it breaks general port test syntax - it behaves different way for
> remote hosts tests (doesn't support host definition) and for local
> processes tests (supports host definition)
>
>
>
> In addition i think it could be usefull to support remote host tags as
> in process, device, file and directory tests. In the case that these
> "service names" will not be supported, it will break the convence of
> other checks. For example in the case of file check, it could be
> possible to write:
>
> 1.)  check file /bin/su
>
> instead of:
>
> 2.)  check file su with path /bin/su
>
> The first syntax (new 'check host ...' pattern) seems nice, but in the
> case of long paths (which is not su's case) it is better to use
> shortcut like 'su' then the complete path. Hosts are the same case -
> in the case that you have very long hostname IPv4 or finaly IPv6
> address, it will be better to use shortcut for service manipulation
> then host definition. Similarily we use tag for process checks instead
> of pidfile path. It affects command line, as well as
> webinterface. Example syntax (consistent with present service tags
> syntax):
>
> check host redhat with address 66.187.232.110
>
>
> => conslusion:
>
> - what about to support host option in port test for remote hosts?
> - what about to support service tags/names for remote hosts?
>
>
> I know we discussed it recently on the list and i will not to remain
> on my proposal, but about notes seems rationaly problematic for me. If
> you want to, we can keep present implementation as it is - just my
> 0.02$ :)
>
> Martin


-- 
Jan-Henrik Haukeland