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