Can client extension scripts use client-local.cfg data passed back to client?
I'm gathering that said data ends up in $XYMONCLIENTHOME/tmp/logfetch.$MACHINEDOTS.cfg.
Would it hurt anything to put (on the server) data in addition to the lines defined in the man page? Would it make it back to the above file?
And if so, can a naming convention be recommended for user-defined lines that should avoid conflict with any future official lines? (maybe names that begin with site_ or something like that?)
And if that's not all crazy...it would be cool if the library module to fetch the client-local.cfg for a host could check the timestamp on the file, and if changed, reload it (freeing all the old data structures first, so as not to leak memory, of course!)
That way, without restarting the server, one could replace the client-local.cfg file on the server and have client log, file, and extension script behavior altered accordingly.
Having used Big Brother for many years, the ability of Xymon to pass updates and _some_ client control information to the client, without one inventing one's own backchannel (using ssh or whatever), sounds like it could make life _much_ simpler in terms of centralizing the control of clients and server alike. So naturally I want to take that to its logical extreme. :-) But so far, I haven't read enough of the code to really have a good handle on just what might be possible, let alone normal enough not to be too fragile.
Richard
This is an interesting idea. Yes, you should be able to extract details from the logfetch.*.cfg file, and changes in client-local.cfg should show up there. You can put comments in client-local.cfg and they will be ignored by the Xymon client-side code, so you could define your own comment format that works for your ext scripts. For example:
###EXT:myscript.sh:VAR1=val1 VAR2=val2
Another option is to use definitions in the hosts.cfg file. You can then use: $XYMON $XYMSRV "hostinfo host=$MACHINEDOTS" and then scan the fields looking for what you're interested in. Refer to the "xymon" man page for more detail about what filtering/presentation options are available to you.
In the latter case, I follow the example of DEVMON, which prefixed its variables with "DEVMON:" like so:
10.1.2.3 example-host # noip dialup DEVMON:cid(commstring),model(hp;dl380) delayred=dns ...
Cheers Jeremy
On 11 July 2014 16:49, Richard Hamilton <rlhamil2 at gmail.com> wrote:
I'm gathering that said data ends up in $XYMONCLIENTHOME/tmp/logfetch.$MACHINEDOTS.cfg.
Would it hurt anything to put (on the server) data in addition to the lines defined in the man page? Would it make it back to the above file?
And if so, can a naming convention be recommended for user-defined lines that should avoid conflict with any future official lines? (maybe names that begin with site_ or something like that?)
And if that's not all crazy...it would be cool if the library module to fetch the client-local.cfg for a host could check the timestamp on the file, and if changed, reload it (freeing all the old data structures first, so as not to leak memory, of course!)
That way, without restarting the server, one could replace the client-local.cfg file on the server and have client log, file, and extension script behavior altered accordingly.
Having used Big Brother for many years, the ability of Xymon to pass updates and _some_ client control information to the client, without one inventing one's own backchannel (using ssh or whatever), sounds like it could make life _much_ simpler in terms of centralizing the control of clients and server alike. So naturally I want to take that to its logical extreme. :-) But so far, I haven't read enough of the code to really have a good handle on just what might be possible, let alone normal enough not to be too fragile.
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Den 2014-07-11 8:49, Richard Hamilton skrev:
I'm gathering that said data ends up in $XYMONCLIENTHOME/tmp/logfetch.$MACHINEDOTS.cfg.
Would it hurt anything to put (on the server) data in addition to the lines defined in the man page? Would it make it back to the above file?
And if so, can a naming convention be recommended for user-defined
lines that should avoid conflict with any future official lines? (maybe names that begin with site_ or something like that?)
You can add extra lines to the client-local.cfg definition for a host, and they will end up in the client logfetch.<hostname>.cfg file. It may take a bit of time
- the Xymon daemon has to reload the client-local.cfg file (by default, it checks for updates every 10 minutes - if you do a "kill -HUP" on the xymond process, it will reload the configuration immediately), and the client has to run one cycle before the new configuration is passed to the client. So it may take up to 15 minutes for a change to show up on the client.
A naming convention would be ok, I think "site_" is too long to type, but something like 'X-' (as is used in many other text protocols, e.g. http) would be fine with me.
And if that's not all crazy...it would be cool if the library module to fetch the client-local.cfg for a host could check the timestamp on the file, and if changed, reload it (freeing all the old data structures first, so as not to leak memory, of course!)
That way, without restarting the server, one could replace the client-local.cfg file on the server and have client log, file, and extension script behavior altered accordingly.
See above, this should happen already.
Having used Big Brother for many years, the ability of Xymon to pass update
or whatever), sounds like it could make life _much_ simpler in terms of centralizing the control of clients and server alike. So naturally I want to take that to its logical extreme. :-) But so far, I haven't read enough of the code to really have a good handle on just what might be possible, let alone normal enough not to be too fragile.
For larger configuration files, you can use the 'xymon IP "config FILENAME"' or 'xymon IP "download FILENAME"' commands on the client. See the xymon(1) and xymond(8) manpages. rds, Henrik
participants (3)
-
henrik＠hswn.dk
-
jlaidman＠rebel-it.com.au
-
rlhamil2＠gmail.com