Re: [exim] WebServer monitoring of Exim

Gordon Ross wrote:

> Are there any scripts/tools to monitor Exim via a web browser ? I can't see anything in the docs, and I've done a quick google, and all I could see was one which needed Java/Tomcat (which I'd rather not use on this server)
>
> Thanks,
>
> GTG

Gordon,

There are lots of ways - not all browser-based:

1) Exim logs where it is told to log, and chron can e-mail you periodic
reports.

2) When things are *known* to be (potentially) dodgy, an ssh with 'tail
-f /var/log/exim/mainlog' is your friend.

3) More routinely, you can Add a lightweight httpd on a port of your
choice -'thttpd' is secure and easy to configure. 'boa' is another. Then
periodically 'cp' the files: /var/log/maillog, /var/log/exim/mainlog,
/var/log/exim/paniclog to the directory you are running thppd against.
Debug leve of your choice, but suggest NOT exposing login passwords.

(You could run it against /var/log *BUT* that is giving out too much
info IMNSHO as indeed so may be the mail logs alone...)

4) Same to a page under your current httpd (Apache or AOLServer can put
it behind https - thttpd cannot do https unless 'fronted' by Squid with
https).

5) if 'chron' is too coarse-grained for you, have a look a 'monitord',
which can execute an arbitrary script at arbitrary intervals of your
choice. Either have it look for a binary known to NOT be running, in
which case it acts like a fine-grained 'chron', purely time-driven,
(minutes or seconds, not hours or days) OR have it watch the Exim
binary, and only react if/as/when exim dies (rare). It can both
re-start the service and whatever else the script calls for - such as
mailing you a report or posting to a webserver-visible area (as above).

6) See also 'checkservice', which can be told to look at the actual
functionality of a (many) service(s) on the local or (multiple) remote
machine(s), and also send you an SMS, email, or call a script to
reactivate the service. I say 'functionality' as checkservice uses
'plugins' to do more than just see if a port is open. You can write your
own or use those furnished.

7) Quick-and-dirty - chron yourself a test message at intervals, set a
filter on your MUA to move them into a subfolder, check once in a while
to see if they are coming through regularly. Said messages could be
carrying copies of logs...

8) If a non-shell or non-root person is to do the monitoring, then
either the mail OR writing messages or logs to the web-viewable area, OR
to a restricted SMB or NFS mount still works.

None of the above generate fancified html, but browsers read plaintext too!

'Nuther handy trick is to keep 'lynx-ssl' on the server. Very
liteweight means of walking the Maildir tree and viewing a message (or
lack of same since a given date/time) for troubleshooting.

- ssh in, su to root, 'lynx <mail storage root>' and text-mode-browse
whatever you must.
Respecting your clientele's privacy, of course!

BTW - FWIW - once we have sorted any config and perms errors of our own
making (and I have made many!) Exim by and large 'JFDI'. We are by no
means 'heavy' users, but I have yet to have Exim go down or get
knocked-down by anything but my own errors.

If a possible DOS attack lurks in your area, start Exim (also httpd, and
other public-facing daemons) with 'nice -20' (or whatever..)

These will run essentially as fast as usual under 'normal'
circumstances, but this insures that all the essential core services,
including logging, chron, - and most of all your critical-for-control
ssh connection - will always get priority so you can get in, take
control, and backtrack an attacker, even if the box is being driven to
the wall.

HTH

Bill Hacker