I don't think you can force functions like getnameinfo(3) to use DNS instead of /etc/hosts, because they rely on the system configuration to determine how to resolve things. For example, on Linux look at the glibc config file /etc/nsswitch.conf, a lot of systems will probably have a line like:
hosts: files dns which means all glibc functions, like getnameinfo, will first try /etc/hosts and then dns if it is not found in the local file. If you want to force gmond to always use dns then you would have to replace getnameinfo with some dns client library function, possibly from bind or some other library. This might introduce portability problems though, and some people might not want that behavior so it might have to be made configurable. ~Jason On Wed, 2005-08-17 at 10:00 -0500, Utsav Agarwal wrote: > We are using udp unicast packets from our cluster to the gmond 'collector', > which gets polled by a gmetad server. My reasoning is mainly based on the > above scenario. > > The reason gmond may do the lookups is that it is hierarchically closer > (cluster using NAT, own dns server?) in dns to the cluster, whereas the > Gmetad can be in a different dns zone or site. However, there could be an > option in the config files to state where name lookups need to be done. > In our case, it is not a bad idea for gmond to do the lookups, as long as it > could use a consistent scheme for lookups. Right now the library that gmond > plugs into seems to use dns for external ip's and /etc/hosts for its own ip. > > I am not a programmer: While looking at the source code, I saw some > references to apr_getnameinfo, which calls getnameinfo. Man getnameinfo > gives no flag to force a FQDN response, but there is a flag to force a short > response. Perhaps FQDN response is the default, but then why would we get > the short version for the 'collector' gmond. > > Snippet from manpage: > The flags argument modifies the behaviour of getnameinfo(3) as follows: > > NI_NOFQDN > If set, return only the hostname part of the FQDN for local > hosts. > > NI_NUMERICHOST > If set, then the numeric form of the hostname is returned. > (When not set, this will > still happen in case the node's name cannot be looked up.) > > NI_NAMEREQD > If set, then a error is returned if the hostname cannot be > looked up. > > NI_NUMERICSERV > If set, then the service address is returned in numeric > form, for example by its port > number. > > NI_DGRAM > If set, then the service is datagram (UDP) based rather than > stream (TCP) based. This is > required for the few ports (512-514) that have different > services for UDP and TCP. > > Utsav. > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jason A. > Smith > Sent: Wednesday, August 17, 2005 9:16 AM > To: [EMAIL PROTECTED] > Cc: steven wagner; Ganglia General > Subject: Re: [Ganglia-general] gmond - fully qualified host lookup > > I was thinking about this a little more, why does gmond need to resolve > IPs anyway? Convenience when debugging and to spare gmetad and possibly > other third party collectors of the xml data from doing the lookups. > Why not just let gmond keep the IPs only and then make gmetad resolve > the IPs? > > One option that Matt suggested is to modify gmond and create a config > section where you could statically define names for IPs which gmond > would use to fill its internal hash table and therefore preventing it > from resolving those IPs. > > Another option I was thinking of is to make a config setting in gmond > where it could specify if and what fqdn it should send out for itself, > like the location setting. This would also benefit multi-nic'd hosts so > you could specify the hostname you would like that node to be known as > if it happens to be different than what it is known by on its multicast > interface. For example, this would be useful if you are using a private > network for gmond's multicast but would like to have your nodes known by > their public name. The only drawback is that since gmond uses udp, > there is no guarantee of successful data delivery, so how do you handle > the case when there is no fqdn data for some nodes? Any thoughts? > > ~Jason > > > On Tue, 2005-08-16 at 18:29 -0400, Jason A. Smith wrote: > > This has come up a few times in the past I believe, once a few years ago > > when we had similar problems on some Solaris servers we were monitoring > > with a similar /etc/hosts file setup. > > > > I believe that ganglia just uses system calls like gethostbyaddr which > > rely on the OS/system libs to determine how to resolve names (for glibc > > see /etc/nsswitch.conf). To get consistent results you would probably > > have to force ganglia to always do DNS lookups (like changing it to use > > bind libs instead), but I think this might introduce some portability > > problems (or some people might not want to rely on DNS so this would > > have to be made a config option). We just ended up changing the format > > in our /etc/hosts files instead of opening up this can of worms. > > > > ~Jason > > > > > > On Tue, 2005-08-16 at 16:56 -0500, [EMAIL PROTECTED] wrote: > > > Steven, > > > Thanks for the response. It will not be practical to change the > /etc/hosts entry in a production environment. I am going to look at the > gmond source code. Any other pointers will be helpful. > > > > > > Thanks, > > > Utsav Agarwal > > > > > > ------------------------------------------------ > > > On Tue, 16 Aug 2005 14:43:45 -0700, steven wagner <[EMAIL PROTECTED]> > wrote: > > > > > > > Change the order of the hosts entry to: > > > > > > > > <IP address> node1.domain.com node1 any-other-aliases > > > > > > > > That should do it... > > > > > > > > [EMAIL PROTECTED] wrote: > > > > > Hello all, > > > > > We have the following setup and issue: > > > > > > > > > > All cluster nodes send (unicast udp) data to node1 and the main > gmetad server collects data from node1. The XML stream obtained from node1 > reports all nodes except itself in a fully qualified fashion. We would like > node1's gmond to report itself as fully qualified without changing > /etc/hosts file. > > > > > > > > > > On node1: > > > > > The command host <ip of node1> reports node1's FQDN. > > > > > The command hostname reports node1 > > > > > In /etc/hosts, the entry is: > > > > > <ipadress> node1 node1.domain.com > > > > > > > > > > Any suggestions will be helpful. > > > > > > > > > > Thanks, > > > > > Utsav Agarwal > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > > > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > > > > > Agile & Plan-Driven Development * Managing Projects & Teams * > Testing & QA > > > > > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > > > > > _______________________________________________ > > > > > Ganglia-general mailing list > > > > > Ganglia-general@lists.sourceforge.net > > > > > https://lists.sourceforge.net/lists/listinfo/ganglia-general > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > > > > Agile & Plan-Driven Development * Managing Projects & Teams * Testing > & QA > > > > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > > > > _______________________________________________ > > > > Ganglia-general mailing list > > > > Ganglia-general@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/ganglia-general > > > > > > > > > > > > > ------------------------------------------------------- > > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > > > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & > QA > > > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > > > _______________________________________________ > > > Ganglia-general mailing list > > > Ganglia-general@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/ganglia-general > > > > > -- > > /------------------------------------------------------------------\ > > | Jason A. Smith Email: [EMAIL PROTECTED] | > > | Atlas Computing Facility, Bldg. 510M Phone: (631)344-4226 | > > | Brookhaven National Lab, P.O. Box 5000 Fax: (631)344-7616 | > > | Upton, NY 11973-5000 | > > \------------------------------------------------------------------/ > > > > > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > > _______________________________________________ > > Ganglia-general mailing list > > Ganglia-general@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/ganglia-general > > -- /------------------------------------------------------------------\ | Jason A. Smith Email: [EMAIL PROTECTED] | | Atlas Computing Facility, Bldg. 510M Phone: (631)344-4226 | | Brookhaven National Lab, P.O. Box 5000 Fax: (631)344-7616 | | Upton, NY 11973-5000 | \------------------------------------------------------------------/
