On Wed, May 13, 2015 1:32 pm, John Thurston wrote:
On 5/13/2015 9:20 AM, J.C. Cleaver wrote:
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
(a) would mean any new client capabilities would need to be tightly
coupled to the server so they weren't left out. It is flexible, but it
could be a hassle.
(b) would probably meet my needs nicely. I just want the status. It's
nice to have an indication of what breached the threshold, but tailing
/var/adm/messages into the HTML page for every green update seems
pointless. Maybe "IncludeRawData=color[,color]" so it could be included
with red and yellow but not with green.
Seen below for an idea for (c).
I actually probably should have clarified these as xymond_client command
line options rather than flags per se. Although it does bring up an issue
in that the command line is hard-coded for local-configuration mode users.
The only way to modify that is to edit the xymonclient.sh script.
Although an environment flag (cf. (c)) could be useful, a
"LOCALCLIENTOPTS=" variable in clientlaunch.cfg would allow arbitrary
options to be passed to xymond_client in these case.
One thing to keep in mind is that if you're doing server-side
configuration with dynamic status message . . . .
Only three of my clients are in "central" mode, and those are only in
that mode because they are running on my Xymon servers and come out of
the build-process configured that way. All of my other clients are
running older BB or BBPe clients. Which means in my case, I should
probably pursue option:
This is correct. If the BB clients are creating status messages rather
than transmitting the raw client messages, then you'd need to
edit/configure things there. It's morally equivalent to Xymon's local
mode.
(c) I suppress the columns I don't want on the three clients that
display them. I suspect that my desire to suppress this information is a
fringe-case and not worth the effort to incorporate.
On Wed, May 13, 2015 12:42 pm, Andy Smith wrote:
What about
per-host flags similar to HIDEHTTP which performs a similar function for
sensitive web page checks?
--
I think there's a use case for for both types of control here. A set of
xymond_client --options (+a generic option) for not including anything
beyond threshold evaluations in the status messages generated. This helps
the --local config use case as well as provides easy global server
control(*). Secondly, a 'HIDECLIENTDATA' flag in hosts.cfg read in by
xymond_client could give the same effect on a per-host basis for specific
exceptions.
*svcstatus.cgi could be altered to inhibit CLIENTLOG display for a host
with this setting in hosts.cfg too, but given that the data was still
present in the client channel to begin with, that's only a surface level
of security. The "best" solution will be to use --local mode and never
send that raw data to begin with.
I don't think either of these types of options are ready for 4.3.20, but
it's probably something that can be put into the next release pretty
easily.
Regards,
-jc