Can client extension scripts use client-local.cfg data passed back to client? 🔗 link

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 <user-af55987f6d56@xymon.invalid> wrote:

 

Den 2014-07-11 8:49, Richard Hamilton skrev: 

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. 

See above, this should happen already. 

Having used Big
Brother for many years, the ability of Xymon to pass update

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