Fqdn and hostname


#1

On an Ubuntu box, let’s say the hostname is machine1.example.com.

In /etc/hosts, the first line is

1.2.3.4 machine1 machine1.example.com

What will chef consider the fqdn and hostname? Apparently just “machine1”.

Now that I have discovered this strange quirk, I wonder if I should use this on
purpose, to make the machine names smaller. Or, be careful to avoid this
loophole. I am just thinking out loud. Do people generally use the whole
fqdn…


#2

FQDN stands for fully-qualified hostname, so I’d say that the short host name shouldn’t be used as one.

Have you tried running “hostname” and “hostname -f” on the host to see if it’s actually properly configured? The former should give you the short hostname, and the latter, the fqdn.

  • cassiano

On Thursday, January 24, 2013 at 15:40, samuel.d.darwin@gmail.com wrote:

On an Ubuntu box, let’s say the hostname is machine1.example.com (http://machine1.example.com).

In /etc/hosts, the first line is

1.2.3.4 machine1 machine1.example.com (http://machine1.example.com)

What will chef consider the fqdn and hostname? Apparently just “machine1”.

Now that I have discovered this strange quirk, I wonder if I should use this on
purpose, to make the machine names smaller. Or, be careful to avoid this
loophole. I am just thinking out loud. Do people generally use the whole
fqdn…


#3

On 1/24/13 9:40 AM, samuel.d.darwin@gmail.com wrote:

On an Ubuntu box, let’s say the hostname is machine1.example.com.

In /etc/hosts, the first line is

1.2.3.4 machine1 machine1.example.com

What will chef consider the fqdn and hostname? Apparently just “machine1”.

Now that I have discovered this strange quirk, I wonder if I should use this on
purpose, to make the machine names smaller. Or, be careful to avoid this
loophole. I am just thinking out loud. Do people generally use the whole
fqdn…

when you’re doing a reverse lookup on 1.2.3.4 with that config you’re
getting back the first name which is the short hostname. to get the
FQDN just reverse that to:

1.2.3.4 machine1.example.com machine1


#4

on centos, chef returns the same hostname and fqdn as the responses from
the hostname and hostname -f commands

On Thu, Jan 24, 2013 at 1:47 PM, Lamont Granquist lamont@opscode.comwrote:

On 1/24/13 9:40 AM, samuel.d.darwin@gmail.com wrote:

On an Ubuntu box, let’s say the hostname is machine1.example.com.

In /etc/hosts, the first line is

1.2.3.4 machine1 machine1.example.com

What will chef consider the fqdn and hostname? Apparently just
"machine1".

Now that I have discovered this strange quirk, I wonder if I should use
this on
purpose, to make the machine names smaller. Or, be careful to avoid
this
loophole. I am just thinking out loud. Do people generally use the
whole
fqdn…

when you’re doing a reverse lookup on 1.2.3.4 with that config you’re
getting back the first name which is the short hostname. to get the FQDN
just reverse that to:

1.2.3.4 machine1.example.com machine1


#5

A reverse lookup has different semantics depending on context. This can
cause unexpected behavior.

  1. The object returned from gethostbyaddr() contains a list of host
    aliases and a list of addresses. In other words, it’s perfectly
    reasonable for there to be multiple hostnames associated with a single
    address. Ordering is not guaranteed in either list. However the object
    also has an attribute for the official hostname. Whether that is the
    long or the short name depends on how the underlying database is
    configured. For that, see the man page for nsswitch.conf. Conventions
    vary from one site to another.

  2. If your nsswitch.conf causes the reverse lookup to be passed to DNS,
    the behavior when there are multiple PTR records for a given address is
    /undefined/. You might get a list. You might get a singleton that is
    round-robined. You might consistently get the same singleton from one
    DNS server and a different singleton from another. You might get nothing.

On 13-01-24 10:47 AM, Lamont Granquist wrote:

when you’re doing a reverse lookup on 1.2.3.4 with that config you’re
getting back the first name which is the short hostname. to get the
FQDN just reverse that to:

1.2.3.4 machine1.example.com machine1


#6

typical nsswitch.conf configuration is for /etc/hosts to override DNS in
which case it just does a scan for the first line matching the IP
address and returns the first name on that line. i suspect that if the
OP simply reverses the order on that line that it’ll start returning the
FQDN correctly.

and i typically use chef to enforce nsswitch.conf settings and write out
/etc/hosts to have the primary IP address of the host resolve this way
so there’s no ambiguity.

On 1/24/13 11:37 AM, Dan Razzell wrote:

A reverse lookup has different semantics depending on context. This
can cause unexpected behavior.

  1. The object returned from gethostbyaddr() contains a list of host
    aliases and a list of addresses. In other words, it’s perfectly
    reasonable for there to be multiple hostnames associated with a single
    address. Ordering is not guaranteed in either list. However the
    object also has an attribute for the official hostname. Whether that
    is the long or the short name depends on how the underlying database
    is configured. For that, see the man page for nsswitch.conf.
    Conventions vary from one site to another.

  2. If your nsswitch.conf causes the reverse lookup to be passed to
    DNS, the behavior when there are multiple PTR records for a given
    address is /undefined/. You might get a list. You might get a
    singleton that is round-robined. You might consistently get the same
    singleton from one DNS server and a different singleton from another.
    You might get nothing.

On 13-01-24 10:47 AM, Lamont Granquist wrote:

when you’re doing a reverse lookup on 1.2.3.4 with that config you’re
getting back the first name which is the short hostname. to get the
FQDN just reverse that to:

1.2.3.4 machine1.example.com machine1