Glenn English wrote:
> Bob Proulx wrote:
> > Debian sets the hostname from /etc/hostname.
>
> I never had a problem with the hostname. It was the domain name
> that was making me crazy.
But you can't talk about one without the context of the other. :-)
And confusingly NIS/yp also talks about domain names but means
something completely different! So beware of the context of the
discussion or it may take a turn into a different area.
> >> and not from the "kernel.domainname = "
> >> line in /etc/sysctl.conf? ("kernel.domainname = example.com" is
> >> that line, commented out, in my recently installed squeeze.)
> >
> > Definitely not.
>
> Apparently not :-) I tried, but couldn't get it to have any effect
> on anything. It does make me wonder, though, what that line is doing
> there. It looks like it should (used to?) set the domain name...
I have no idea why that is there. I don't know what nook that
configures. I would let it lie dormant. It might be some legacy
xerox or token ring network interface for all I know.
> > DNS is used for the ill conceived 'hostname -f' option. Whoever wrote
> > that code should be stripped of any street cred. It is terrible.
>
> It may be terrible code, but that doesn't seem to be how it works
> here. hostname -f returns the fqdn of the host in question, even if
> its DNS server is set incorrectly (/etc/hosts is correct, and I've
> set the resolver to look first at hosts, then DNS).
I have actually looked at the source code to hostname. It has been a
while so I refreshed my memory just now. Basically it does this:
gethostname(buf, buf_len)
hints.ai_flags = AI_CANONNAME;
getaddrinfo(buf, NULL, &hints, &res)
printf("%s\n", res->ai_canonname);
That looks up the hostname. Gets an IP address. Due to hints having
AI_CANONNAME it causes the resolver library to include the reverse
lookup of the IP address back to a name. It then prints that name.
I previously said that it got an IP address from the machine with some
vague hand waving about the first one it finds because I wasn't sure
how it got it. But it doesn't look at the actual system. It simply
does a DNS lookup of the hostname. This doesn't change the fact that
a host may have multiple IP addresses and each of those will have
hostnames associated with them.
I just tried an experiment to verify this behavior. I changed the
hostname of a system to another machine that had both forward and
reverse DNS set correctly. Doing nothing but changing the hostname to
the short name of the other machine caused 'hostname -f' to return the
fQDN of that other machine. Really 'hostname -f' is operating
entirely on domain name information and nothing more.
> > That may be okay for a very large number of
> > typical systems but it is also completely incorrect for many valid
> > systems with more IP addresses than just one and more network
> > interfaces than just one.
>
> I've got systems with more than one interface, and I've never run into
> that problem.
I just got confused. What is the exact problem being referred to at
this moment in the conversation? *I* am not having any problems. I
thought you were? And now you say that you aren't. I'm confused.
> I'm guessing that's just because I've always set up eth0
> to be the 'Net facing interface. A long time ago, I wrote a big shell
> script to init iptables, and the way it's written, eth0 *has* to point
> to the 'Net. Just lucky, I guess :-)
I am sorry for the vague hand waving where I thought hostname -f got
the IP address to look up from what was actually configured. I
thought it did. But looking at the hostname code it I see that it
simply does a dns lookup of the hostname. Sorry for the diversion
into the weeds on this part of the topic.
> > Note that a perfectly valid configuration may specify the hostname as
> > a fully qualified domain name. Many BSD systems are set that way.
> > And BSD is the progenitor of networking.
>
> Yup. But the Debian dox say very clearly not to do that. It does seem to
> work pretty well, though. I've set up several machines that way.
I usually recommend to follow the documentation. Except when I
recommend the opposite. :-)
This is one of those times where I think in general that the
recommended config of a short hostname is good. But knowing how
things are actually working inside the box I also know that it is okay
to set a fully qualified domain name there regardless of what the
documenation says.
> > If all you changed was /etc/hosts then it is likely that your change
> > is incomplete.
>
> Quite possibly, but it seems to have done the job. AFAIK, it's the only
> place, outside of some server configs, where the domain name is mentioned.
Some server configs? That is pretty vague! :-)
But probably in the MTA configuration for sure. And I would count
that as being in the set of "some server configs". (chuckle)
> > Also, what mail transfer agent are you using? Postfix? Exim? Almost
> > certainly one of those will need a tweak too.
>
> Postfix. And there's a domain name in its config for sure.
Yes. That is the primary need for domain information.
> > Because it pulls together information from several different and
> > independent programs that are not related to each other except by all
> > running on the same machine.
>
> That's very true. But if I were writing all that stuff, the host's domain
> name relevant to TCP/IP would be in one place, and everybody would go there
> (or to a kernel call) to get it.
If *I* were writing it I wouldn't store this information in the kernel
at all. The kernel doesn't need it. I would store it in a file on
the filesystem and have the libc routine look it up from there.
> It's all too easy to have the kernel and
> Postfix thinking they're running at different domains.
Since the kernel doesn't care if I replace "kernel" with "general
config outside postfix" then I would counter that it is a perfectly
valid configuration. I can think of a lot of hosts that handle mail
for other sites and that type of thing is normal standard operating
procedure.
> > Many modern systems associate the hostname with 127.0.1.1
>
> I ran across that -- IIRC, it's supposed to be what I put in hosts
> when the host's IP is dynamic or it has no domain. And it can cause
> troubles when the host is a server on the 'Net with a static IP and
> a domain.
Hmm... It is kind'a a good idea in most situations. But sometimes it
is simpler to list the public IP on an always connected server host.
Simpler is usually better so I like simpler. But using the public IP
isn't as general. It has problems for mobile devices for example.
And so the 127.0.1.1 technique was created.
That isn't to say that using 127.* isn't sometimes troublesome. In
cases where network software is trying to pass around IP addresses the
technique doesn't work. Or rather the software that is trying to pass
around IP addresses is broken. But if that is a proprietary CAD/EDA
program for $100k then you probably won't get it fixed and working
around it is easier. If it passes around IP addresses then it will
pass over to its peer 127.0.1.1 (same problem if it were 127.0.0.1
too) and the peer won't be able to connect back. What it *should* do
instead is pass around the hostname or FQDN so that the peer can use
it to connect back.
For something a little more fun I have seen this problem with the
Spring RTS game too. It is why the lobby and the game host needs to
be on different machines. If on the same machine then clients can't
connect since they are handed a 127.* address instead of the correct
remote peer address. And that is in a free software game! The code
is there (somewhere) and could be fixed. :-) But it is extremely easy
to work around too and so there isn't a very deep itch to scratch.
> And it can cause troubles when the host is a server on the 'Net with
> a static IP and a domain.
I have no idea what you are meaning here. It is pretty vague. Could
you say a few more words describing the problem?
> > And alternatively using 127.0.0.1 is problematic because then instead
> > of the desired name 'hostname -f' would return "localhost" or possibly
> > "localhost.localdomain" depending upon what is in /etc/hosts.
>
> Seems to me it should return "localhost" in that case, because 127.0.0.1
> *is* localhost.
Yes. On Debian. But on Red Hat (at least at some point in the
history if not now) it used to be localhost.localdomain there.
Probably even on Debian at one point. This is an area that hasn't
been completely stable over the years.
People start with a problem and then try various implementations to
solve the problem. That is good. And I think we have matured to the
point where it is relatively well understood by operating system gurus
who are assembling a software distribution. (I said it like that
because we have already discussed that it might not be particularly
well documented. But the people who need to know the most have
figured it out. I think.)
> > The localhost.localdomain is a hack / trick to make all of the system
> > configuration internally consistent with a private configuration in
> > isolation from a public network. That's great. But if you have a
> > public name and IP address then you would use it instead.
>
> Depending of whether you wanted to talk to yourself or somebody outside
> the host??
If you refer to localhost or localhost.localdomain for software that
insists upon having a fqdn then it will successfully talk to itself.
If you talk to other systems such as www.debian.org then it will talk
successfully there too. But if you were to set up an apache web
server and try to server web pages then using the fqdn URL of
http://localhost.localdomain/ would only work from the local system.
You wouldn't use it from other systems. They would end up connecting
to themselves. From other systems for services like that you would
need to assign and configure a name and IP address known outside of
the localhost.
> Or might it be more efficient to have a localhost IP to use
> for internal tasks??
Now there you have mentioned an interesting historical facet!
(Interesting to history buffs such as myself anyway.) If a system has
a public IP address configured then these days using TCP to talk to it
will be almost as efficient as talking to the loopback device.
$ ping -c 10 localhost
$ ping -c 10 $(hostname)
Today that should be almost the same. But in the old days the one
that needed to go out to the network card was slower. It had to pass
through more network code layers. The data would actually travel
through the entire software stack to the network card, ping there, and
then return. It was noticeably slower. This was one reason why BSD
Unix domain network sockets were used for things like X window
communication on the local host. It was hugely faster. Since then
that path of code down to the network card has been optimized out as
useless extra work. So today it isn't a difference. But it used to be.
So by using the 127.* loopback device locally it was more efficient.
So that was yet another reason to use it instead of a public IP
address in /etc/hosts for local proceses. (Or to use a Unix domain
socket instead.) Of course that reason has gone away now. I didn't
mention it until you brought up efficiency. Because in ancient times
it was more efficient.
> > If you have questions then ask. The above was simply an off the top
> > of the head description and I am sure I didn't do a great job of it.
>
> Thanks hugely for the long, detailed response. But you seem to hold a
> couple opinions that I don't think are optimally correct on Debian. Or
> maybe they are. I really don't know -- I haven't looked at the source.
> Whatever, both ways seem to work. Maybe someday the Debian documentation
> will describe this process more clearly...
>
> If you *do* know the code, and it indicates that my impression(s) are
> wrong, I'd love to hear about it.
A very nice and tactfully worded response! Very well done. :-)
Let me say that I have looked at the source of a lot of software. I
have written a number of network daemons over the years. But memory
fades with time. And I am only human and I make my fair share of
mistakes! I don't intentionally lead people astray. But sometimes
errors do creep in.
If you have particular points where you think I have it wrong I would
appreciate being educated on what is actually happening. A good team
is always stronger than any individual.
Bob
Attachment:
signature.asc
Description: Digital signature