You are not logged in.
I had some googling, but still it seems like noone knows why it's there.
Offline
You did not run "echo your hostname > /etc/hostname. The Arch wiki has detailed instructions give it a read.
Take One Tablet By Mouth Twice A Day! Better to vote for a short term political guardian then to be ruled by a monarchy.
Offline
Offline
You are talking about in /etc/hosts correct?
localhost is a hostname
localdomain is a domain name
localhost.localdomain is a FQDM... well fully qualified on the localsystem
You need that record because it is suppose to be there. It is a standard. If you remove it some software you may run may not work correctly.
OpenBSD-current Thinkpad X230, i7-3520M, 16GB CL9 Kingston, Samsung 830 256GB
Contributor: linux-grsec
Offline
Sorry, it appeared I wasn't subscribed to topics I post in.
Just to clarify, is this a support question (as rm_/etc is assuming) or why "localhost.localdomain" instead of just "localhost"?
the latter
It is a standard.
De-facto standard you mean? Which distribution adhere to it?
Others on this list have pointed out that some applications expect
127.0.0.1 to resolve to localhost. When the resolver uses /etc/hosts,
it returns the first host in the list and the others are considered
aliases. In the first example above, localhost.localdomain would be
returned when resolving 127.0.0.1; this is because it is listed before
localhost. If /etc/hosts were changed to:127.0.0.1 localhost localhost.localdomain
Resolution of 127.0.0.1 would properly return localhost.
I've been unable to find any specific reference to a required structure
of a hosts file nor any specific requirement that a resolver should
resolve 127.0.0.1 to localhost. However, consider the following two
points:1 -- When configuring DNS, 127.0.0.1 must resolve to localhost and vice
versa [1]. Configuring an /etc/hosts file that resolves 127.0.0.1 to
localhost.localdomain is inconsistent. On the same host, resolving
127.0.0.1 by gethostbyname() and running nslookup will return two
different answers (provided nsswitch.conf is configured with "files
dns"). [1] RFC 1912 - http://www.ietf.org/rfc/rfc1912.txt2 -- Virtually all systems with a hosts file read something like this:
127.0.0.1 localhost <alias> <another alias> <...>
There is a long historical precedent for listing localhost first,
followed by other aliases. This results in the resolver properly
returning localhost when resolving 127.0.0.1.In summary: (1) It's reasonable to expect DNS and file based resolution
to function the same in regard to 127.0.0.1/localhost (proper DNS
resolution of 127.0.0.1 is documented in RFC 1912). (2) There is a long
historical precedent for localhost preceding all aliases of 127.0.0.1 in
a hosts file.Thanks!
http://lists.debian.org/debian-devel/20 … 00559.html
I consider using hostname -f for anything other then the initial default value
broken because computers can have multiple network cards, multiple IP
addresses, multiple domains, etc. I generally like to assume my computer isn't
going to break badly because I have to change the output hostname -f returns.Also, FQDNs are really not applicable to, say laptops, which frequently change
from one network to another. Or some desktops even. I notice on this Ubuntu
laptop `hostname` == `hostname -f` perhaps for this reason.
http://lists.debian.org/debian-devel/20 … 00778.html
The only reason debian had it for some time is because Red Hat had it for some reason. AFAIU debian got rid of it since 14 Oct 2005 and it somehow works since then.
Offline
As an extra data point: I run all of my systems (Linux and NetBSD) without any reference to 127.0.0.1 in /etc/hosts, only ::1 (the IPv6 equivalent), resolving to "localhost" and nothing else. I only had to change the config of some applications to refer to "localhost" instead of "127.0.0.1" explicitly. An easy grep 127.0.0.1 /etc finds most of them.
On most of those systems (except one where I need to support a proprietary IPv4-only VPN client which breaks on it), I actually remove the 127.0.0.1 address from the loopback interface, having only ::1 configured, ie. an IPv6-only localhost. Works fine.
There's to many mysticism around all this. Applications should use "localhost" for local connections or port bindings, and you define what it resolves to (some loopback interface). "localhost.localdomain" is a brain fart of someone who misunderstoond "FQDN", and is nowhere standardized.
Offline
hunterthomson wrote:It is a standard.
De-facto standard you mean? Which distribution adhere to it?
It is a standard on every operating system I know of. It is a networking standard. If it is a networked OS it is localhost.localdomain. Like I said though, "it may"... Sure, if you are not running any server software configured to use that then you will not notice any problems. However that is what it is for and why it is there.
Last edited by hunterthomson (2013-01-19 10:11:11)
OpenBSD-current Thinkpad X230, i7-3520M, 16GB CL9 Kingston, Samsung 830 256GB
Contributor: linux-grsec
Offline
hunterthomson, judging from your response:
1) you don't know which distributions (except for Arch Linux) resort to using localhost.localdomain,
2) no RFC or any other standard enforces specifying localhost.localdomain as a FQDN for localhost.
Sure, if you are not running any server software configured to use that then you will not notice any problems.
Sure, it's not the case.
Offline
Dude, basically it is there as a filler to make the /etc/hosts file consistent i.e. IP hostname.domain hostname
RedHat has it and I guess Debian as well. That is like.... just guessing 70-90% of the Linux Server market. If you don't like it in there then delete it and see what happens. Why would you expect me or anyone ells to search for RFC's # and other distro's for you?
I know Postfix SMTP server has a configuration for Hostname and Domain name. So, if you don't have localhost.localdomain you will have problems, because you don't have a local domain.
CentOS 5
/etc/postfix/main.cf
# INTERNET HOST AND DOMAIN NAMES
#
# The myhostname parameter specifies the internet hostname of this
# mail system. The default is to use the fully-qualified domain name
# from gethostname(). $myhostname is used as a default value for many
# other configuration parameters.
#
myhostname = localhost.localdomain
# The mydomain parameter specifies the local internet domain name.
# The default is to use $myhostname minus the first component.
# $mydomain is used as a default value for many other configuration
# parameters.
#
mydomain = localdomain
Last edited by hunterthomson (2013-01-28 10:29:00)
OpenBSD-current Thinkpad X230, i7-3520M, 16GB CL9 Kingston, Samsung 830 256GB
Contributor: linux-grsec
Offline
Dude, basically it is there as a filler to make the /etc/hosts file consistent i.e. IP hostname.domain hostname
In other words, you mean the point is in every hostname having its FQDN? But why do you prefer this consistency over consistency between /etc/hosts and bind (DNS)?. On top of it, localhost.localdomain is yet another special case.
I guess Debian as well
AFAIU debian got rid of it since 14 Oct 2005 and it somehow works since then.
Are you even reading my replies?
netcfg is the package responsible for creating initial /etc/hosts file in debian. Here is the quotation from Changelog:
netcfg (1.17) unstable; urgency=low
[ Thomas Hood ]
* Don't make 'localhost.localdomain' the canonical hostname of 127.0.0.1.
See Oct 2005 debian-devel discussion with Subject: localhost.localdomain,
e.g., http://lists.debian.org/debian-devel/20 … 00559.html
-- Frans Pop <fjp@debian.org> Tue, 15 Nov 2005 20:59:54 +0100
And here is the code, which creates /etc/hosts file:
if ((fp = file_open(HOSTS_FILE, "w"))) {
fprintf(fp, "127.0.0.1\tlocalhost");
if (!empty_str(ipaddress)) {
if (domain_nodot && !empty_str(domain_nodot))
fprintf(fp, "\n%s\t%s.%s\t%s\n", ipaddress, hostname, domain_nodot, hostname);
else
fprintf(fp, "\n%s\t%s\n", ipaddress, hostname);
} else {
#if defined(__linux__) || defined(__GNU__)
if (domain_nodot && !empty_str(domain_nodot))
fprintf(fp, "\n127.0.1.1\t%s.%s\t%s\n", hostname, domain_nodot, hostname);
else
fprintf(fp, "\n127.0.1.1\t%s\n", hostname);
#else
fprintf(fp, "\t%s\n", hostname);
#endif
}
fprintf(fp, "\n" IPV6_HOSTS);
fclose(fp);
}
RedHat has it and I guess Debian as well. That is like.... just guessing 70-90% of the Linux Server market.
Let us see (these are output from freshly installed systems):
$ cat /etc/centos-release
CentOS release 6.3 (Final)
$ cat /etc/hosts
127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
$ hostname
localhost.localdomain
$ hostname -f
localhost.localdomain
$ cat /etc/redhat-release
Fedora release 18 (Spherical Cow)
$ cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
$ hostname
localhost.localdomain
$ hostname -f
localhost
$ cat /etc/debian_version
6.0.6
$ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 tdeb
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
yuri@tdeb:~$ hostname
yuri-pc
yuri@tdeb:~$ hostname -f
yuri-pc
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 12.10
Release: 12.10
Codename: quantal
$ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 tubuntu
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
$ hostname
yuri-pc
$ hostname -f
yuri-pc
Consistency you say? Debian and ubuntu got rid of it. What is redhat doing? Beats me. Can someone explain?
If you don't like it in there then delete it and see what happens.
My servers work that way for at least several years.
Why would you expect me or anyone ells to search for RFC's # for you?
One might say, that if you say that it's a standard it's up to you to come up with a proof. But why don't you just tell us how things stand: you don't know if it's in any standard and you have no time/desire to prove it?
I know Postfix SMTP server has a configuration for Hostname and Domain name. So, if you don't have localhost.localdomain you will have problems, because you don't have a local domain.
Let us see what Arch Linux suggests to use for these settings. They are just placeholders for real data
Some more consistency:
MUAs again
~~~~~~~~~~
Different MUAs have very different ways of coming up with the
"host" part of message i.d.s.* /usr/bin/mail in the mailx package uses $(/bin/hostname)
* elm (or, rather, postfix) uses whatever postfix's "myhostname"
parameter is set to in /etc/postfix/main.cf
* mutt uses $(cat /etc/mailname)
* evolution mail uses $(/bin/hostname --fqdn)
* mozilla mail uses the host part of the sender's e-mail address
* balsa uses $(hostname) from the time that X starts
* sylpheed tacks on the whole sender e-mail addressClearly we should not allow the practices of mail software to
govern our decision about what we put into /etc/hosts.
http://bugs.debian.org/cgi-bin/bugrepor … =247734#27
P.S. Here's the discussion I mentioned in OP but in much more readable and easy to get familiarized with format. Or so I believe. Non-relevant/non-interesting parts are marked grey. There is not much left to read.
Last edited by x-yuri (2019-04-07 13:57:50)
Offline
Btw, do note how localhost.localdomain was introduced in debian:
I can not remember precisely. I think that at that time I was testing the debian-installer and I saw it was taken a long while to boot. I saw that my system had no FQDN (hostname -f). When you add .localdomain, the FQDN is complete and it helps to solve timeout in several application.
So it was just papering over a real bug, namely the existence of the “-f” option of hostname. “hostname -f” assumes that the hostname (as returned by gethostname(3)) has something to do with networking, which is false. It also assumes that the system has just one IP address with one FQDN which is also false.
This is a perfect example of a long-standing assumption that was wrong from the start but tended to work in the past when the wast majority of computers had really just one network interface with one IP address, and the few machines having multiple NICs/multiple IP addresses had good sysadmins who could deal with the breakage caused by this assumption.
Nowadays even desktop boards start to come with multiple NICs on-board so this “one IP – one FQDN” assumption must be stopped. “hostname -f” must be killed, and everything that uses it must be fixed. Well, it may take some time to sort out all the details, there are a lot of broken programs out there…
Last edited by x-yuri (2019-04-07 13:58:31)
Offline