Some feature notes for monit, volume II

[Vlada Macek]

Hello again,

my previous post has been accepted nicely, so I'm here with the volume
II of my notes. :-)


### Doc: XML and TEXT output

Not mentioned in the documentation. I guess it's because they are new
and designed to be semi-hidden for use of m/monit. But I think such
features that are increasing interoperability of the project should be
advertised loudly! :-}


### LED blinks, speaker screams on (some?) alerts

Something like this:

    set ledalert on        # constant keyboard LED blink
    set beepalert on    # let's say three beeps each 15 seconds

The alert e-mail does not necessatily reach the target box, cellphone,
... on time. In case of nasty situation is detected, the server should
IMHO try to catch the human eye or ear as soon as and any way possible.

This alert would also be handy in case of unreachable mailserver,
network connection, in short in situations where something nasty _might_
happen but the monit knows it wont be able to inform about it.

The ongoing beep or blink state could be presented on the HTML/XML/TEXT
output too together with the HTML button and console command to shut
them off immediatelly until the next state change.


### depends on groupname

Not really sure whether such thing may be useful, but again, it would
increase the configuration freedom. This way, the action may be
triggered by any service in the dependant group.


### Password hash directly on the ALLOW line

Something like this:

    allow user:0ec8266c6fbd441ea707864855f0368a20e82c36 sha1 read-only

I don't like to reveal my password to any reader, but using external
file like htpasswd is too uphill. I consider this way a reasonable
trade-off.


### New check: i-node number change
### Symlink target change (target string checksum?)

The first check could detect a hard link target change. The second one
allows one to detect whether the symlink was tampered with. These checks
mostly fall into the security measures category and are marginal here. I
just mention it as a small ideas.


### Multiple actions after THEN

AFAIK there is possible to define only one action now. EventAction_T in
monitor.h suggests it. I imagine the *next member in EventAction_T. :-)
For example

    if loadavg(1min) > 10.0 for 8 cycles then
        { exec "/usr/local/sbin/myscript.sh", stop }


### Variables in exec action

There are situations where it can become handy to pass the addition
infomation to underlaying utilities. Variables like $ACTION, $SERVICE...
used in mail-format might be expanded in exec command line too if wished...

    if loadavg(1min) > 10.0 for 8 cycles then
        exec '/usr/local/sbin/myscript.sh "$SERVICE" "$ACTION"'


### ifhost "dilbert" or "ginger" ... endif

I think I'm not the only one who uses monit to keep an eye on several
servers, not only one. Even when using INCLUDE and CVS to manage
multiple control files, there are still many same lines remaining. Such
feature of conditional compilation would allow me to have only one
monitrc for all my servers, which could lead me to systematic unified
configuration and helps to reveal the configuration mistakes.

There is a security disadvantage in this. A cracker who gets root access
on one of my servers would know exact monitoring configuration on the
rest of them. That's bad.

Instead I'm considering now using some general preprocessor e.g. GNU M4
to produce the set of monitrc files for particular servers after the CVS
checkout. Using M4 there is possible advanced magic like parametrized
macros, etc. I'll probably use it and can contribute a tutorial or
examples if anyone interested.


And now for something completely different:

### Encryption of all mail alerts using given PGP public key

I'm proposing later in this text that monit may be able to send some
sensitive data in the mail alerts and therefore it should be possible to
hide the alert body from the unintended eyes. It is possible to keep the
public key (even multiple ones) in ASCII armored form in control file.
This feature may deploy gnupg or similar package. The fact, that the
Subject line cannot be encrypted and still alerts any recipient could be
taken as an advantage.

In case the encryption is not possible by accident, the rich body would
not be sent, of course.

I'm not sure, but I think it is possible to encrypt data by multiple
public keys and decrypt it with any of them. This feature would fit this
application. Alerts could be encrypted by admin's key together with
company's key stored somewhere safe.


### Advanced e-mail alerting

In previous e-mail, there was a proposal about the rich XML report
(_status?format=xml request), where every <service> provides exhaustive
information about the tests being applied, the currently expected and
received values (for example checksums, send/expect x received strings).

In case this proposal will be implemented, then it might be interesting,
if monit puts entire XML report (or just the systemwide part and the
failed/recoveres services) into the encrypted e-mail message body. No
special mail structure need to be invented, XML form is already the best
one for technical processing and it will contain all information.
Nevertheless it may be possible to select HTML or TXT format too to be
put into the e-mail message body.

This way we are sending the detailed historical diagnostic and forensic
information somewhere far far away for deposit (perhaps out of the
touched domain). Everything may be cracked or shut down by unknown
reason, but once the data leave the domain, we are better informed.


### Embedding a Python interpreter

I'm going slightly mad... :-]

Vlada

signature.asc
Description: OpenPGP digital signature