[Xymon] suppress log contents from 'msgs' column ?

[Andy Smith]

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