The "--merge-clientlocal" option is almost what I'm looking for, but not
quite. It would be perfect if the host-specific variables would override
matching variables in the generic OS entry. What I want to do is something
like this in client-local.cfg:
[linux]
file:/some/important/file
file:/another/important/file
xrate:28k
[server1]
xrate:512k
The file names are read by a script that just sends a report with the file
sizes and timestamps. The xrate value is used by a different script, for
rate-limiting the transfer of an antivirus database file. Some servers are
on gigabit network, others are a lot slower, so it would be nice to be able
to override the os-level xrate entry with a faster setting where the
network can handle it
So, ideally, when server1 checks in, it would be handed the file names and
xrate:512k. When server2 checks in, it gets handed the file names and
xrate:28k. If server1 is handed both xrate:28k and xrate:512k, can I be
sure that they will always show up in that order??
If it would work that way, I could eliminate over 1000 client-local
entries. Unfortunately, I'm working with xymon-4.3.12, which doesn't have
the --merge-clientlocal option.
Ralph Mitchell
On Wed, Oct 29, 2014 at 5:44 PM, Bill Arlofski <user-0b8af203a56e@xymon.invalid>
wrote:
On 10/29/14 14:48, Ralph Mitchell wrote:
In xymon-4.3.12 it sends the client-local block for the hostname, if it
is defined OR the block for the OS, correct?? Not a blend of the two,
with host-specific entries overriding the generic entries, right??
Does that change in a later release? I need a better way to manage it...
Ralph Mitchell
Hi Ralph
You can get a blend (merge) of the two:
from /help/manpages/man5/client-local.cfg.5.html
"If xymond is started with the "--merge-clientlocal" option, then xymond
will instead merge all of the matching sections into one, and return all
of this data to the client"
It appears to be global of course, and that may not be what you want.
I only knew about this because I have been working with alerting, and
other settings recently and have been in and out of the docs quite a bit.
:)
Hope that helps!
Bill
--
Bill Arlofski
Reverse Polarity, LLC
http://www.revpol.com/
-- Not responsible for anything below this line --