Xymon Mailing List Archive search

suppress log contents from 'msgs' column ?

list Andy Smith
Wed, 13 May 2015 20:42:57 +0100
Message-Id: <user-7b8fa9c618e9@xymon.invalid>

J.C. Cleaver wrote:
On Wed, May 13, 2015 10:07 am, John Thurston wrote:
On 5/13/2015 8:48 AM, Mark Felder wrote:
On Wed, May 13, 2015, at 11:43, John Thurston wrote:
In testing 4.3.20, I've noticed that the 'msgs' column (for hosts
running the xymon solaris client) contain lines from my logs even when
they are reporting 'green'. I don't really want the contents of
/var/adm/messages leaked to every viewer of my Xymon web interface.
- snip -
Is your Xymon server open to the public internet? :-)
No, but my xymon server is available to anyone on my network and handles
messages from clients in several departments. I don't see any reason or
value in publishing my /var/adm/messages (or spilling my process list)
for everyone to read.
cpu: I think it's useful to capture those moments in time especially
when you want to see what changed between green and red.
Where is the value is continually spilling the process list when it is
green? When there is an alarm, I can begin to see the value. But not on
a day-to-day, always-green, basis.

The client normally only reports on a 5-minute interval. When it reports
'red' on 'cpu', is there really any value in knowing what it was idling
on five minutes earlier? At best I'm going to care what is sucking the
resources right now. In most cases, though, I don't even care about
that. In the event of a 'red' notice, I go directly to the host and use
my system tools to determine what is wrong.
logs: I agree; it's a waste to capture/display the contents if you're
not matching anything
Are you aware of any way to suppress this display? I'd like to stop it.

I can switch to a different client, or suppress more columns, but I'd
like to find a more elegant way to reach the goal.

I think it really comes down to your audience. xymon/hobbit/Big Brother
were all designed around making life easier for sysadmins, so it tends to
default showing more technical data and placing it within easy reach.


For precedence, we do have the following options to xymond_client currently:


--no-ps-listing
  Normally  the  "procs"  status  message  includes the full
process-listing received from the client. If you prefer to just have the
monitored processes shown, this option will turn off the full
ps-listing.

--no-port-listing
  Normally the "ports" status message includes the full netstat-listing
received from the client. If you prefer to just have the monitored 
ports  shown, this option will turn off the full netstat-listing.


I could see one of two paths here:

a) adding individual flags for each of the remaining test results
xymond_client generates, controlling the raw data on the status page, or

b) a single master "raw data on status" flag used for all at once

They're not mutually exclusive, of course (most restrictive flag would
win), but I'm not sure on the various use cases out there.


One thing to keep in mind is that if you're doing server-side
configuration with dynamic status message (I'd have to check on the static
HTML output, since I haven't used it in quite a while), anyone who can
read the status message will also be able to read the Client Data link,
which contains the raw data anyway. So if this is to hide data, I feel
like it really only makes sense when clients are in --local evaluation
mode.


OTOH, there are other reasons besides security to not display data in the
status message: it's more legible, and it's less data to re-transmit
internally (like netstat output on huge servers).

And finally, there are middle ground options that could be patched in.
xymongen and svcstatus.cgi still see everything in the message output as a
blob to stick into a <PRE> tag, but there's no reason a small disclosure
triange widget couldn't be used to hide the things below the '&color'
lines, which serve as de-facto sub-statuses.


Thoughts?

-jc
We find the listings of both procs and ports incredibly useful for post 
incident forensics, we would not want to be without it.  What about 
per-host flags similar to HIDEHTTP which performs a similar function for 
  sensitive web page checks?
-- 
Andy