c-ares
list Mark Felder
Is there any hope of getting xymon to compile against the system provided c-ares, or is xymon always going to bundle it? Just seems like it would be more efficient to use the system-provided c-ares if it's there...
list Japheth Cleaver
▸
On Fri, November 1, 2013 10:35 am, Mark Felder wrote:
Is there any hope of getting xymon to compile against the system provided c-ares, or is xymon always going to bundle it? Just seems like it would be more efficient to use the system-provided c-ares if it's there...
The xymon build process ends up making a library which the various binaries incorporate, and I don't think it's dynamic or would pull in the live system version in this case. I know there's a make option to do a dynamic lib, but IIRC it's experimental. That being said, with a few patches for CFLAGS/CPPFLAGS, xymon compiles fine with the current version of c-ares... The Terabithia RPMs all use 1.10.0, for example. HTH, -jc
list Mark Felder
▸
On Fri, Nov 1, 2013, at 13:03, Japheth Cleaver wrote:
On Fri, November 1, 2013 10:35 am, Mark Felder wrote:Is there any hope of getting xymon to compile against the system provided c-ares, or is xymon always going to bundle it? Just seems like it would be more efficient to use the system-provided c-ares if it's there...The xymon build process ends up making a library which the various binaries incorporate, and I don't think it's dynamic or would pull in the live system version in this case. I know there's a make option to do a dynamic lib, but IIRC it's experimental. That being said, with a few patches for CFLAGS/CPPFLAGS, xymon compiles fine with the current version of c-ares... The Terabithia RPMs all use 1.10.0, for example.
Thanks for the info. I was hoping to be able to change the build process for FreeBSD so it can pull in c-ares from the ports tree.
list John Thurston
▸
On 11/1/2013 9:35 AM, Mark Felder wrote:
Is there any hope of getting xymon to compile against the system provided c-ares, or is xymon always going to bundle it? Just seems like it would be more efficient to use the system-provided c-ares if it's there...
It's funny you bring this up right now. I am currently struggling with my pre-production xymon instance. The only way I seem able to get it to behave is to start xymonnet with --no-ares. When using c-ares, I routinely get hundreds of test failures due to inability to resolve names.
How is the c-ares library supposed to be superior to my system's built-in resolver functions?
--
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
list Mark Felder
▸
On Fri, Nov 1, 2013, at 13:11, John Thurston wrote:
On 11/1/2013 9:35 AM, Mark Felder wrote:Is there any hope of getting xymon to compile against the system provided c-ares, or is xymon always going to bundle it? Just seems like it would be more efficient to use the system-provided c-ares if it's there...It's funny you bring this up right now. I am currently struggling with my pre-production xymon instance. The only way I seem able to get it to behave is to start xymonnet with --no-ares. When using c-ares, I routinely get hundreds of test failures due to inability to resolve names. How is the c-ares library supposed to be superior to my system's built-in resolver functions?
c-ares offers non-blocking asynchronous lookups, I believe
list John Thurston
▸
On 11/1/2013 10:11 AM, John Thurston wrote:
On 11/1/2013 9:35 AM, Mark Felder wrote:Is there any hope of getting xymon to compile against the system provided c-ares, or is xymon always going to bundle it? Just seems like it would be more efficient to use the system-provided c-ares if it's there...It's funny you bring this up right now. I am currently struggling with my pre-production xymon instance. The only way I seem able to get it to behave is to start xymonnet with --no-ares. When using c-ares, I routinely get hundreds of test failures due to inability to resolve names.
I've been working on this today and have found the undocumented option to xymonnet "--maxdnsqueue". With this, I can limit the number of queries xymonnet sends to name servers in each batch. When I set it to =10, I get solid results. When I set it to =25 (or higher), I get hundreds of name resolution failures. When I use --no-ares, it also works fine. My original question remains, "Why is c-ares the default rather than the system resolver?" But more important is the practical question . . . Which way should I go: --no-ares and use the name server caching daemon (nscd) in Solaris? --maxdnsqueue and hope it becomes documented and not deleted?
▸
--
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
list Mark Felder
▸
On Fri, Nov 1, 2013, at 15:43, John Thurston wrote:
On 11/1/2013 10:11 AM, John Thurston wrote:On 11/1/2013 9:35 AM, Mark Felder wrote:Is there any hope of getting xymon to compile against the system provided c-ares, or is xymon always going to bundle it? Just seems like it would be more efficient to use the system-provided c-ares if it's there...It's funny you bring this up right now. I am currently struggling with my pre-production xymon instance. The only way I seem able to get it to behave is to start xymonnet with --no-ares. When using c-ares, I routinely get hundreds of test failures due to inability to resolve names.I've been working on this today and have found the undocumented option to xymonnet "--maxdnsqueue". With this, I can limit the number of queries xymonnet sends to name servers in each batch. When I set it to =10, I get solid results. When I set it to =25 (or higher), I get hundreds of name resolution failures. When I use --no-ares, it also works fine. My original question remains, "Why is c-ares the default rather than the system resolver?" But more important is the practical question . . . Which way should I go: --no-ares and use the name server caching daemon (nscd) in Solaris? --maxdnsqueue and hope it becomes documented and not deleted?
Honestly, I'd ask Henrik directly
list Henrik Størner
Bit of a late reply, but I am slowly digging through my mail archive ...
▸
Den 2013-11-01 21:43, John Thurston skrev:It's funny you bring this up right now. I am currently struggling with my pre-production xymon instance. The only way I seem able to get it to behave is to start xymonnet with --no-ares. When using c-ares, I routinely get hundreds of test failures due to inability to resolve names.I've been working on this today and have found the undocumented option to xymonnet "--maxdnsqueue". With this, I can limit the number of queries xymonnet sends to name servers in each batch. When I set it to =10, I get solid results. When I set it to =25 (or higher), I get hundreds of name resolution failures. When I use --no-ares, it also works fine. My original question remains, "Why is c-ares the default rather than the system resolver?" But more important is the practical question . .
Xymon uses the c-ares resolver because your system resolver library can only handle one lookup at a time, and may take a very long time to timeout if a DNS server is not responding. A consequence of this is that Xymon can quite easily flood a normal DNS server with queries, resulting in DNS lookups failing. I suspect that is what happens in your case. The simplest solution for this (and I would recoomend this for anyone running a Xymon network probe) is to install a local caching DNS server, which forwards all requests to your normal DNS servers. Such a setup is completely transparent to how Xymon works, but it moves the load to a dedicated DNS server running on your Xymon box. Since it will cache all of the responses after the initial request, it will be much more reliable and fast. So you can choose: a) Run xymonnet with --no-ares and live with the fact that xymonnet may take a very long time to run, resulting in purple tests and status messages not being up-to-date; or b) install a local caching BIND server where you put the normal DNS servers in the "forwarders" section. Regards, Henrik
list Roger
▸
On Fri, Jan 24, 2014 at 5:32 AM, <user-ce4a2c883f75@xymon.invalid> wrote:
So you can choose: a) Run xymonnet with --no-ares and live with the fact that xymonnet may take a very long time to run, resulting in purple tests and status messages not being up-to-date; or b) install a local caching BIND server where you put the normal DNS servers in the "forwarders" section.
wouldn't you have to do 'a' *and* 'b'? Just running a caching name server won't force xymonnet to use the local cache, right? Roger
list Henrik Størner
▸
Den 24-01-2014 22:17, Roger skrev:
On Fri, Jan 24, 2014 at 5:32 AM, <user-ce4a2c883f75@xymon.invalid> wrote:So you can choose: a) Run xymonnet with --no-ares and live with the fact that xymonnet may take a very long time to run, resulting in purple tests and status messages not being up-to-date; or b) install a local caching BIND server where you put the normal DNS servers in the "forwarders" section.wouldn't you have to do 'a' *and* 'b'?
you could, but if you have a local caching server then it can easily keep up with all of the Xymon requests. At least that is my experience.
▸
Just running a caching name server won't force xymonnet to use the local cache, right?
okay - no, you have to setup /etc/resolv.conf so it points to the local cache. (Actually, Xymon could use a caching server without having to tweak resolv.conf, but you cannot tell it what DNS server to use right now). Regards, Henrik