Why doesn't "hostname --fqdn" work on my Ubuntu computer?

Question

I'm using Ubuntu 10.04 LTS, and when I type the command hostname --fqdn, I get the message: hostname: Name or service not known.

Because of this, I cannot install global successfully, and get the following error when I try:

Setting up global (5.7.1-1) ...
hostname: Name or service not known
dpkg: error processing global (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 global
E: Sub-process /usr/bin/dpkg returned an error code (1)

My /etc/nsswitch.conf is below.

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Does anyone have any ideas on what this means and how I can fix this?

Solution 1

Can you provide the content of /etc/nsswitch.conf ?

It looks like /etc/nsswitch.conf has a bad value for the "hosts" line. Does it start with "files" ?

Otherwise the FQDN is set by editing /etc/hosts and putting the FQDN on the line where the hostname appears. Suppose you have an hostname "foo", and you find a line:

127.0.0.1 foo

You would edit it like this:

127.0.0.1 foo.localdomain foo

foo.localdomain would be your new FQDN.

Solution 2

edit /etc/hosts to add your FQDN

Information on syntax located here: http://www.faqs.org/docs/securing/chap9sec95.html

update: reading over your question again it almost sounds like you either don't have your path set right, or there is something wrong with the hostname program.

do 'which hostname'

it should return with the path '/bin/hostname'

if that works try the command again like,

'/bin/hostname --fqdn'

Solution 3

Unlike the simple hostname command invocation, the invocation hostname --fqdn will attempt to do a few more things, which will often result in some DNS lookups.

Take for example the following (successful) invocation (this is from a Red Hat 6 box which had 'hostname' from the 'net-tools' package; newer machines, such as RHEL7, have a different implementation which lacks the --verbose option):

# hostname --fqdn --verbose
gethostname()=`myserver.example.com'
Resolving `myserver.example.com' ...
Result: h_name=`myserver.example.com'
Result: h_addr_list=`10.1.2.3'
myserver.example.com

Note the very helpful --verbose option.

In short, anything other than a simple hostname is probably doing more than you expect. Here's another example:

# hostname --ip --verbose
gethostname()=`myserver.example.com'
Resolving `myserver.example.com' ...
Result: h_name=`myserver.example.com'
Result: h_addr_list=`10.1.2.3'
10.1.2.3

And to round it off:

# hostname --verbose
gethostname()=`myserver.example.com'
myserver.example.com

Note that the hostname of a system (as returned by gethostname) can me an unqualified hostname, such as just 'myserver'. This is why the program you are wanting to install is using the hostname --fqdn instead.

The error message hostname: Name or service not known comes from the resolver functions: these are the parts of the system library that translate between names and addresses (typically DNS names and IP addresses).

Actually, the resolver does more than just DNS (and more than just translating between hostnames and IP addresses); its behaviour is configured in part by the file /etc/nsswitch.conf, and typically it will consult the following, typically in this order:

• 'hosts' (on Linux, the means /etc/hosts)
• (sometimes) nscd (name-service caching daemon)
• 'dns'

(note, you can also have a caching DNS server such as dnsmasqd --- for the point of the above, that is still under the 'dns' mechanism).

It is worth pointing out that tools such as dig, host and the venerable nslookup do not follow this order; they are explicitly DNS querying tools. This means that if you rely on them (in a script for example) you may end up getting a different result than what regular client programs would (that use the system resolver). For this reason, use the getent program in scripts, particularly if you have a caching component such as nscd running.

# getent hosts myserver.example.com
10.1.2.3    myserver.example.com

So the key takeaway here is that a) if you have /etc/hosts well configured with an entry for your own machine, and b) your /etc/nsswitch.conf has the usual configuration -- hosts: files dns in that order, then c) even if you don't have DNS well-configured in your environment, then hostname --fqdn should work.

In a well-configured DNS, you would be expected to have one 'reverse' address (a "PTR record") that gives the 'canonical' name of your server, and that name should also be able to be looked up (an "A record" for IPv4).

Short version: (for RHEL6 and similar ages) add --verbose; it will point you to what you are lacking. For newer platforms, you may need to just do the reverse and forward look-ups manually.

Hope that helps you to understand what is going on.

Comments

[msw]

Why do you want a FQDN? If you have to ask, you probably don't want one or can't make use of one or both.

[Jesse Nickles]

For Google: -f is the same as --fqdn or --long.

[RadiantHex]

Thanks!!! Sorry if I ask this, but how do I find out my FQDN?

[RadiantHex]

Thanks @Mudfly! I tried your instructions, the last commands returns "hostname: Name or service not known" again!

[Mudfly]

Without more info its hard to know the conditions of your problem. EG: is this a local install, are you logged in over ssh, are you using a user account or logged in root? You might want to visit ubuntuforums.org and search for others who have solved similar issues.

[RadiantHex]

It's a server, I'm connected through SSH as root. Thanks for your advice.

[Mudfly]

This is taking a wild jump here but, Ubuntu favors using sudo over the use of root. It is quite possible that the shell isnt setup correctly. To test this is very simple. First you can do 'ls -al /root/' and see if you can see a .bashrc Second if you don't have a .bashrc copy it from skel 'cp /etc/skel/.bashrc ./' you can do this even if you already have the file. Third do '/bin/bash' to make sure you are running bash. Finally try your original command again, you should be running in a fully configured bash shell.

[Mudfly]

Update: The "Second" set of instructions is assuming you are in the home directory of root "cd /root"

[RadiantHex]

I have included the contents of that file as you asked! THANKS for the reply!! :)

[Muhammad Adeel Zahid]

@Rapael I changed the /etc/hosts file but it started giving me Temporary failure in name resolution. Any ideas why its happening?

[Isaac Chugunov]

"this is from a Red Hat box" is it? hostname on RHEL7 and CentOS7 don't include a --verbose option

[Cameron Kerr]

@Rich RHEL6 has (had) it, as 'hostname' on that platform was from net-tools. RHEL7 seems to have a different implementation of 'hostname'. Thanks for pointing out the difference.

[Isaac Chugunov]

Cool - didn't think to go backwards for new options :-)