Monitoring servers

John Evans evansj at kilnar.com
Mon Aug 13 16:47:15 CDT 2001


On Mon, 13 Aug 2001, Robert L. Harris wrote:

> I'm looking at a script that'll be run once a day or so, connect to
> them and get uptime, users, etc.

The method that I've seen that works well is an entry in /etc/inetd.conf
that looks like this:
monitor stream tcp nowait nobody /usr/local/bin/monitor.pl

In /etc/services:
monitor 12345  # Or some other port.

Then a master server connects to each server in its monitor list at port
12345 (or whatever.) When the monitor.pl on the client gets hit, it fires
up, reads a config file that tells it what to look at, spits the results
back out the server that connected to it and dies. It accepts zero input
from the outside connection so no risk of buffer overruns or other hacks.
However, with each connection, it fires off a seperate copy of the script.
This can lead to someone downing a server by opening numerous connections
to the server. There are ways around this, though.

The server then takes the output of the client and builds a webpage (could
be done as a logfile or email as well) that you can view to see if a
particular system is going haywire.

To make releasing new copies of the software and config files easier, you
can put them on an NFS mount that all clients mount at boot and then run
the script from there.

As far as any modules that are out there to help with all of this... I
know of none.


-- 
John Evans
http://evansj.kilnar.com/

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS d- s++:- a- C+++>++++ ULSB++++$ P+++$ L++++$
E--- W++ N+ o? K? w O- M V PS+ !PE Y+ PGP t(--) 5-- X++(+++)
R+++ tv+ b+++(++++) DI+++ D++>+++ G+ e h--- r+++ y+++
------END GEEK CODE BLOCK------





More information about the Pikes-peak-pm mailing list