Re: Features for a monitoring tool

From: Felinux (
Date: 02/16/03

From: Felinux <>
Date: Sun, 16 Feb 2003 15:45:10 GMT

Juha Laiho wrote:

> Felinux <> said:
> [SNIP]
> No, it's the other way around. Clients on the monitored machine(s) and
> server somewhere else. Then possibly a user interface for the server
> somewhere. Some monitoring is best done so that the server polls the
> client, but there are also cases where you want to have notifications
> originated by the client, without the server polling for the info.

Sorry, but I don't get it. Why should the server be the one on the monitored
machine? What I thought I would do was a monitoring client that asked the
monitored server "Is everything ok?" every n seconds and logged the

> Ok, and then (using your terminology on server and client here) the
> server will still need to present the password in clear to the client,
> so the server will need means to decrypt the password. And thus, the
> means to decrypt the password will reside on the server, so you're
> not gaining much by encrypting the password and leaving the tools to
> decrypt the password just next to it.

I guess you are right... but I thought I would use something like this: the
client (i.e. the monitoring host) would scramble the password with a
one-way algorithm (like DES, right?) and send it encrypted. The server
would compare this scrambled pass with the string obtained by scrambling
with the same algorithm the password saved in its config file (readable
only by root). Thus, no decryption would be needed, and the pass would be
stored clear-text on a root-only readable file. It's about the same thing
login does, right?

> - configurable monitoring, because I probably am running things that you
> didn't know about
Great idea. I think it's a little over my ability, but I'll give it a try =)

> - good user interface, to be able to gather summary of the current
> situation at a glance, but also to be able to drill down to a number
> of different details whenever needed
Well... I thought it mostly as a non-interactive log generator, but I could
add an option to make a single query and exit and a way to select exactly
WICH details to show...

> Examples for very basic monitoring ("these on all hosts"):
> ... and on top of these the monitoring of the actual function of the host.
> But this (the monitoring targets) is the easy part. Not losing messages
> and getting the UI right are the hard part. Security isn't easy, either.

Thank you a lot for your answer: you gave me a lot of stuff to work on and
that's more than I could ask for. I think I will learn a lot by
implementing all of this "data collection".


< felinux at supereva dot it >