1 2 Previous Next 15 Replies Latest reply on Oct 25, 2011 7:29 AM by Bill Robinson

    HOST vs FQ_HOST vs IP_ADDRESS properties

    Bret Roemhild

      Bill, (All)

      Someone posted a thread not to long ago about keying off of HOST property vs. NAME or IP_ADDRESS etc...

      Sean Daley chimed in with his expert advice on the topic on how bl determines these values and why you might want to use one vs. the other. In addition, why 1 wasn't reliable. It might have been related to SOCKS proxy.


      Does anyone remember this thread because I tried searching and had no luck (imagine that)?


        • 1. Re: HOST vs FQ_HOST vs IP_ADDRESS properties

          I remember the thread you're talking about but I'm not sure where it is now. In summary though, the safest property to use is TARGET.NAME. Especially if you're using SOCKS where the SOCKS proxy is responsible for resolving the IP address of the target.

          • 2. Re: HOST vs FQ_HOST vs IP_ADDRESS properties
            Bret Roemhild

            Hey Sean,

            Actually my problem is slighty different and I thought that thread had some info that would help....

            here is what we are seeing in 7.4.5:


            We added windows hosts with FQDNs all lower case to the CM:

            So TARGET.NAME = hostname.domain.org

            TARGET.FQ_HOST = hostname.domain.org

            TARGET.HOST = hostname.domain.org


            Shouldn't HOST be the short netbios name??

            We also saw some servers that put TARGET.FG_HOST = HOSTNAME.domain.org .... (note CAPs)...


            What is going on here?


            • 3. Re: HOST vs FQ_HOST vs IP_ADDRESS properties

              As a UNIX guy, I have to ask, "what is this netbios thingy?"


              All kidding aside though. The rules for HOST are:


              If NAME != "an ipaddress" then



              HOST="nodename as reported by uname from target agent"



              So HOST is basically there for the cases where you're putting in an IP address. Then we'll try to get a hostname for you. As for the CAPS issue with FQ_HOST, I'd bet that they added in the NAME with all caps as well. All we're basically doing is the equivalent of an nslookup and returning what that says. We don't do any munging of the results that come back from DNS. For example, you can see this just running the nslookup command:


              C:\>nslookup korriban

              Server: hoth2.int.bladelogic.com



              Name: korriban.dev.bladelogic.com




              C:\>nslookup KORRIBAN

              Server: hoth2.int.bladelogic.com



              Name: KORRIBAN.dev.bladelogic.com


              • 4. Re: HOST vs FQ_HOST vs IP_ADDRESS properties
                Bill Robinson

                NETBIOS only applies to windows, there's no netbios for unix, just a "shortname" - but a windows server can have a "shortname" that's not a netbios name.... and netbios was supposed to go away 8 years ago.



                so a question - do we only use dns to resolve names, or do we use any mechanism available on the appserver ? (eg netbios, ldap, etc)

                • 5. Re: HOST vs FQ_HOST vs IP_ADDRESS properties

                  We don't "use" anything. We make a standard Java call which ties in to whatever the underlying libraries/configs are for the OS.




                  In particular, the getByName and getCanonicalHostName calls.

                  • 6. Re: HOST vs FQ_HOST vs IP_ADDRESS properties
                    Bret Roemhild

                    I think some of the issue is the client's environment...I am gone try a few things without BL....


                    This is a brand new install, only added 4 servers, all lower case fqdn so not sure why one server's FQ_HOST had CAPS in short name portion, i.e. SERVERNAME.domain.org ...


                    Sean, I usually recommend as a best practice for client's to add all servers using their fqdn (lowercase). We were hoping the TARGET.NAME & FQ_HOST would be same (fqdn) and that TARGET.HOST would be shortname ...The main reason is so that inventory reports will display cleaner for upper management. This client has long fqdns.


                    So ... Sean 2 questions:

                    -why do we get fqdn for TARGET.HOST (seems this should be shortname)?

                    -based on your expertise would you agree fqdn is best practice for TARGET.NAME?




                    • 7. Re: HOST vs FQ_HOST vs IP_ADDRESS properties
                      Bill Robinson

                      yeah - that's what i mean. so if your appserver os uses netbios, dns, files, whatever, we'll use that to try and resolve names.


                      so how does that work w/ the socks proxy ? because i've heard that w/ the proxy, it resolves the target hostnames/ips, not the appserver ?

                      • 8. Re: HOST vs FQ_HOST vs IP_ADDRESS properties
                        Bret Roemhild

                        I am using 7.4.5 and I don't quite understand what is going on or intended behavior for TARGET.HOST & TARGET.FQ_HOST server properties:


                        1) all servers are added to console using fqdn ... so shouldn't I see the following under server properties:

                        TARGET.NAME = server1.subdomain.domain.com

                        TARGET.HOST = SERVER1

                        TARGET.FQ_HOST = server1.subdomain.domain.com


                        We are seeing some servers where TARGET.HOST is the fqdn and TARGET.FQ_HOST is the shortname. Seems backwards to me especially since the description of FQ_HOST is fqdn of server.


                        Shouldn't TARGET.HOST be the shortname of the server?


                        • 9. Re: HOST vs FQ_HOST vs IP_ADDRESS properties

                          I already answered the why is the HOST = FQ_HOST in my post on:


                          Re: HOST vs FQ_HOST vs IP_ADDRESS properties

                          Posted: Sep 18, 2008 11:18 PM


                          But I'll repeat it again. TARGET.HOST is for those cases where TARGET.NAME

                          is an IP address. In that case we'll try to figure out what the HOST is. In

                          all other cases TARGET.HOST == TARGET.NAME.


                          As for the FQ_HOST being the shortname the best answer I can come up with is

                          from the javadoc of the method we use:




                          public String getCanonicalHostName()


                          Gets the fully qualified domain name for this IP address. Best effort method, meaning we may not be able to return the FQDN depending on the underlying system configuration.

                          • 10. Re: HOST vs FQ_HOST vs IP_ADDRESS properties
                            Bret Roemhild


                            OK .. so I understand how TARGET.HOST & NAME work ...


                            Question then for FQ_HOST?

                            Is the get getCanonicalHostName call only used when TARGET.NAME is an IP? Or is it also used when entering fqdn?


                            The main issue here is not necessarily the differences we are seeing for some of these properties but client needs ability to use shortname in reports since fqdn is very long in some cases. It looks to me like none of the intrinsic properties work for this purpose and I need to create a custom server property to populate shortname from fqdn ....

                            • 11. Re: HOST vs FQ_HOST vs IP_ADDRESS properties

                              Regardless of what you set for name (IP, short-name, FQDN, etc.) FQ_HOST will be

                              the result of a call to getCanonicalHostName (or empty if that call fails).

                              • 12. Re: HOST vs FQ_HOST vs IP_ADDRESS properties
                                Bret Roemhild

                                Thanks Sean ... now I have a better understanding of the 3 props.


                                Unfortunately, it also tells me we have nothing out of the box to use shortnames. TARGET.NAME is the only one but some clients have to put in fqdns because shortname will not always resolve from the appserver to other domains...


                                • 13. Re: HOST vs FQ_HOST vs IP_ADDRESS properties

                                  attached is a single compiled class to test the response from the java code as we do in our code for populating FQ_HOST.


                                  In our code, we do:



                                  InetAddress addr = InetAddress.getByName(name);

                                  updateIntrinsicPropertyValue(PropertySetClass.SERVER_FQ_HOST_PROPERTY, addr.getCanonicalHostName());



                                  This class source java code is:

                                  % cat Lookup.java

                                  import java.net.*;

                                  import java.io.*;


                                  public class Lookup {

                                  private static int i;


                                  public static void main(String args[]) {

                                  for (String name: args) {


                                  try {

                                  System.out.println("- Performing DNS query on " + name);

                                  InetAddress address[] = InetAddress.getAllByName(name);

                                  for (InetAddress each: address) {


                                  System.out.println(". Record " + i + ")");

                                  System.out.println("Name (from DNS): " + each.getHostName());

                                  System.out.println("Addr (reverse lookup): " + each.getHostAddress());

                                  System.out.println("Canonical (FQDN): " + each.getCanonicalHostName());

                                  System.out.println("Is Reachable (ping): " + each.isReachable(3000));



                                  } catch (UnknownHostException e) {

                                  System.err.println("Unable to lookup " + name);

                                  } catch (IOException e) {

                                  System.err.println("Unable to reach " + name);







                                  You can compile it yourself if you want with a 1.5 javac compiler: javac Lookup.java that will build a Lookup.class class. Also use a java 1.5 jvm (the one that comes with our appserver is fine) to run that class (usage is: java args).


                                  For ex:

                                  1. /usr/nsh/br/java/bin/java Lookup google.com dbiebakp04.ent.ad.ntrs.com localhost

                                  - Performing DNS query on google.com

                                  . Record 1)

                                  Name (from DNS): google.com

                                  Addr (reverse lookup):

                                  Canonical (FQDN): cg-in-f100.google.com

                                  Is Reachable (ping): true

                                  . Record 2)

                                  Name (from DNS): google.com

                                  Addr (reverse lookup):

                                  Canonical (FQDN): qb-in-f100.google.com

                                  Is Reachable (ping): true

                                  . Record 3)

                                  Name (from DNS): google.com

                                  Addr (reverse lookup):

                                  Canonical (FQDN): yx-in-f100.google.com

                                  Is Reachable (ping): true


                                  - Performing DNS query on dbiebakp04.ent.ad.ntrs.com

                                  Unable to lookup dbiebakp04.ent.ad.ntrs.com

                                  - Performing DNS query on localhost

                                  . Record 1)

                                  Name (from DNS): localhost

                                  Addr (reverse lookup):

                                  Canonical (FQDN): localhost.localdomain

                                  Is Reachable (ping): true


                                  - Performing DNS query on

                                  . Record 1)

                                  Name (from DNS): web-xp2b-pws.ntrs.com

                                  Addr (reverse lookup):

                                  Canonical (FQDN): web-xp2b-pws.ntrs.com

                                  Is Reachable (ping): false



                                  A machine not configured properly will not find the FQDN for the host. For ex, "bsara1" is neither declared in the /etc/hosts or in the DNS with a FQDN, therefore the canonical name is the same as the name:


                                  1. cat /etc/hosts | grep bsara1



                                  1. /usr/nsh/br/java/bin/java Lookup bsara1

                                  - Performing DNS query on bsara1

                                  . Record 1)

                                  Name (from DNS): bsara1

                                  Addr (reverse lookup):

                                  Canonical (FQDN): bsara1

                                  Is Reachable (ping): true



                                  Adding the FQDN in the /etc/hosts:

                                  1. cat /etc/hosts | grep bsara1

                         bsara1.adprob.bmc.com bsara1


                                  and the canonical name is correct:

                                  1. /usr/nsh/br/java/bin/java Lookup bsara1

                                  - Performing DNS query on bsara1

                                  . Record 1)

                                  Name (from DNS): bsara1

                                  Addr (reverse lookup):

                                  Canonical (FQDN): bsara1.adprob.bmc.com

                                  Is Reachable (ping): true



                                  • 14. Re: HOST vs FQ_HOST vs IP_ADDRESS properties

                                    Is the networkaddress.cache.ttl value set to the default -1 ("cache forever") in the BSA application servers and, if so, how can this value be safely changed so that updated information on "old" servers can be obtained and configured for FQ_HOST?

                                    1 2 Previous Next