On Fri, February 12, 2016 3:36 pm, John Thurston wrote:
On 2/12/2016 1:44 PM, J.C. Cleaver wrote:
On Fri, February 12, 2016 1:47 pm, John Thurston wrote:
I'm having difficulty with xymongrep, and it isn't related to 4.3.25
because I see the same behavior on 4.3.22.
If I use the command:
~/server/bin/xymongrep --debug --hosts=./server/etc/hosts.cfg *
- snip -
Have you tried escaping the '*'? It's possible your shell is eating it
off
the command line.
Bingo! Thank you.
Now the issue is, xymongrep does not seem to be .default. aware. So if I
have a noconn tag on a specific host, I can xymongrep for it. But if
that noconn tag on a .default. line, nothing is found even if it affects
a hundred hosts :( It is parsing enough to handle 'include' but not
enough to handle '.default.'.
Unfortunately, yes that'll be a problem. It was really more intended as a
literal replacement for grepping the hosts.cfg file that could handle
includes rather than a true hosts database dump from xymond... Even with
--loadhostsfromxymond, below, that's more about not having local access to
hosts.cfg than a post-parsed view.
One option might be to use the 'hostinfo' message type, which will pull
info from xymond in a more structured format, but you'll lose the ability
to look at textual data in hosts.cfg that xymond didn't understand, unless
you're also pulling in XMH_RAW. Kind of hairy.
And what is up with its case-sensitivity?
On Solaris, a xymongrep for noprop* matches
"NOPROPRED::+msgs" and "nopropyellow:+msgs"
But a xymongrep for client* returns nothing, while a xymongrep for
CLIENT* finds a whole bunch of hosts with upper-cased tags.
That's... probably a bug :) I'll put that on the list.
On Linux (4.3.17), the matching all appears to be case-insensitive.
I'm probably going to scrap trying to use xymongrep for the task at
hand. I've lived this long without it, it won't hurt me to to a little
longer :)
FWIW, the man page doesn't match the source code. man offers:
xymongrep [--noextras] [--test-untagged] [--web] [--net]
[--loadhostsfromxymond] TAG [TAG...]
while the source shows xymongen also handling:
--help
--no-down
--version
--hosts
Maybe these are intentionally un-doumented, but --hosts is pretty darned
useful.
Also FWIW, the --loadhostsfromxymond may not be port-aware. When I try
to use it on my linux box (4.3.17), the debug output indicates it is
trying to talk to the "Xymon daemon" on port 1984. It does not succeed
because my xymon is listening on port 1985. When I then prefix the
xymongrep with a xymoncmd, it seems to refuse to honor the
--loadhostsfromxymond tag and insists on loading from the hosts.cfg.
--no-down should be documented, definitely. Parts of this are going to be
restructured a little bit in 4.4, since we're trying to "genericize" the
common options (like --loadhostsfromxymond) which can be used in multiple
programs.
xymongrep's historical lack of docs stems from its original intent as a
script command replacement. Since it was always running via xymonlaunch in
a pre-populated environment, it didn't have much in the way of
customization.
As a quick fix, you can pass it in via environment variables:
- ]$ XYMSRV=127.0.0.2 XYMONDPORT=9000 xymongrep --loadhostsfromxymond ssh
See http://lists.xymon.com/pipermail/xymon/2015-August/042138.html
HTH,
-jc