On 4/5/2016 5:50 PM, J.C. Cleaver wrote:
- snip -
It might be because DNS is tested distinct from the resolution involved in
initial xymonnet setup.
I think it is more than that. Please consider this test condition:
10.10.10.10 ns1-int.foo.com # noconn dns=ns1.foo.com
0.0.0.0 ns2-int.foo.com # noconn dns=ns2.foo.com
0.0.0.0 ns3-int.foo.com # noconn dns
In this case, snooping the network while explicitly running xymonnet shows very different results for ns2-int and ns3-int
When testing ns2-int, there is a query to the normal resolver asking for an address for ns2-int.foo.com and there is an answer. That is all.
When testing ns3-int, the query to the normal resolver for ns3-int.foo.com is performed (and answered). This if followed by a query to ns3-int.foo.com for ns3-int.foo.com.
The presence of the equal-sign separated parameter to the DNS test is breaking the test function. In my tests, the equal-sign syntax is only functional if the host to be tested is specified with an ip address. This is true even if xymonnet is called with --dns=only
I suspect xymonnet is finding the equal-sign, but not parsing the parameters and adding them to the query list. The dns-test code, is then being asked to perform a lookup for nothing, and is doing exactly that. The non-results are then evaluated, no success-markers are found, so the test is reported as RED.
These tests have been performed on Solaris 10 with 4.3.26. I'm going to try similar tests on Linux on 4.3.17 and see how those results compare.
--
Do things because you should, not just because you can.
John Thurston XXX-XXX-XXXX
user-ce4d79d99bab@xymon.invalid
Enterprise Technology Services
Department of Administration
State of Alaska