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 <waa-hobbitml at revpol.com> 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 --
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon