[Announce] monit 4.3-beta3

[Martin Pala]

The monit 4.3-beta3 is available:

Download from:  http://www.tildeslash.com/monit/beta/
Checksum:       21518469bea7b254e00232d07edb8034  monit-4.3-beta3.tar.gz
Change log:     http://www.tildeslash.com/monit/beta/CHANGES.txt

We ask that as many as possible will help us in testing this beta. The
release has been tested on Linux.

CHANGES since version 4.2:

Version 4.3-beta3

*  This release patch the following security vulnerability and error,
   reported by "Matthew Murphy" <mattmurphy at kc.rr!com>:
      Error: Possible off-By-One write when handling HTTP POST body
      Vulnerability: Possible buffer overflow in Basic Auth. handling
   The vulnerability exist in previous monit releases down to the 1.4
   release. This issue affect previous monit releases if monit is
   started with http server support.

*  Fix wait_start thread race condition on monit exit too (it was caused
   by the same problem which was fixed in beta1 for monit reload
   already).

Version 4.3-beta2

*  Purge EVENT_FAILED - it was helper event, no longer in use.
   It was fully replaced by new event engine scheme.

*  Evaluate particular service tests only in the case that
   appropriate conditions are defined.


Version 4.3-beta1

NEW FEATURES AND FUNCTIONS:
*  Event engine was refactored. Monit now supports events of
   FAILED and PASSED types, thus it is able to handle any state
   change. Monit will send alert on recovery by default for
   all event types, except the case, when the monitored service
   doesn't exist or the type of service is invalid - in such case
   will monit involve service restart by default. Alerts are sent
   once (on state change only). It is possible to optionaly select
   the action on recovery. General syntax:
     IF rule THEN action [ELSE IF RECOVERED THEN action]

*  Monit now supports variable and constant tests. Constant
   tests are related to failed/passed state. Variable tests beggins
   with 'IF CHANGED' statement and serves for monitoring of object
   changes. You can use it just for alert or to involve some automatic
   action, as for example to reload monitored process after its
   configuration file was changed. Variable tests are supported for
   'checksum', 'size' and 'timestamp' tests only, if you consider
   that other tests can be useful in variable form too, please let
   us know.

*  Events generated in the case of error condition changed. Events
   CHANGED, NONEXIST, DATA, EXEC and INVALID were added and it is
   possible to register them in alert statement in addition to
   present alert selectors as usual. Syntax example:
     ALERT address@hidden ON {
       CHANGED, DATA, EXEC, INVALID, NONEXIST, CHECKSUM, ...
     }
   For example in the case that monitored process is not running,
   monit will generate NONEXIST event. In the case that it is not
   possible to access process' data, monit will generate DATA event.
   In the case that the execution of start or stop program failed,
   monit will generate EXEC event. In the case that monitored file
   is not regular file, monit will generate INVALID event. CHANGED
   event is generated in the case that monit is configured to watch
   variable object changes (for example configuration file timestamp).

*  Monit now reports action in addition to the event description in
   default alert message format. The action description is accessible
   in mail-format statement via $ACTION token.

*  Monit now reports default actions for failed and recovery states
   of all constant testing rules.

*  Monit now supports START action in addition to previous ALERT,
   RESTART, STOP, EXEC, and UNMONITOR actions.

*  START, STOP, RESTART and UNMONITOR events are deprecated and future
   releases may remove them. They were replaced by new event scheme.
   Usage of these words in 'alert ... on { ...}' statement is possible but
   not recommended anymore. In the case that you need to register just
   subset of alerts for delivery, you need to choose event which is
   corresponding to real cause of the problem (for example event NONEXIST
   for crashed process). START, STOP, RESTART and UNMONITOR are just 
actions,
   i.e. consequence - not the problem's cause.

BACKWARD INCOMPATIBLE CHANGES:
*  Syntax and behavior of 'checksum' test changed.
   Monit supports two classes of these tests now: either constant or 
variable.
   Old syntax:
    IF FAILED [hashtype] CHECKSUM [EXPECT STRING] THEN action
   New constant test syntax (behavior backward incompatible):
    IF FAILED [hashtype] CHECKSUM [EXPECT STRING] THEN action
    [ELSE IF RECOVERED THEN action]
   New variable rule syntax:
    IF CHANGED [hashtype] CHECKSUM THEN action
   It affects following construct:
    CHECK FILE httpd.conf WITH PATH /usr/local/apache/conf/httpd.conf
      IF FAILED CHECKSUM THEN EXEC "/usr/local/apache/bin/apachectl 
graceful"
   In previous monit version this configuration caused the apache reload
   on monitored configuration file change. Then the value was reseted so
   the test passed next cycles until the file was changed again. Refactored
   event engine monitors for checksum value recovery, i.e whether it 
changed
   to the original value - in such case it will evaluate recovery action,
   otherwise the test keeps failed state. Because the value in this
   usage context will not correspond to the original, monit will evaluate
   action (reload apache) each cycle until the checksum will recover
   (which is unlikely for configuration file).
   New syntax have to be used for the same result:
    CHECK FILE httpd.conf WITH PATH /usr/local/apache/conf/httpd.conf
      IF CHANGED CHECKSUM THEN EXEC "/usr/local/apache/bin/apachectl 
graceful"

*  Syntax of one 'size' test form changed. It was unified with new variable
   tests form.
   Deprecated syntax:
    IF SIZE CHANGED THEN action
   New variable rule syntax:
    IF CHANGED SIZE THEN action

*  Syntax of one 'timestamp' test form changed. It was unified with new 
variable
   tests form.
   Deprecated syntax:
    IF TIMESTAMP CHANGED THEN action
   New variable rule syntax:
    IF CHANGED TIMESTAMP THEN action

BUGFIXES:
*  Race condition in wait_start thread fixed. Thanks to Peter Holdaway
   <pholdaway!technocom-wireless com> for discovering the problem.

*  There was a deadlock possibility caused by race condition in old event
   engine - it was solved within the scope of refactorization.