[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: domain name



On Aug 31, 2012, at 11:28 PM, 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.

>> 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...

> 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).

> 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'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 :-)

> 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. 

But I don't have any idea what's going on down in the kernel code. I was 
thinking I might be doing something that wouldn't work someday or was using 
extra CPU cycles or something. I just wanted to know the *one* place the 
kernel goes to most efficiently to determine the Internet domain name. As 
best I can tell, that place is a properly written /etc/hosts.

> 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.

> 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.

> 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. It's all too easy to have the kernel and 
Postfix thinking they're running at different domains.

> 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.

> 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.

> 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?? Or might it be more efficient to have a localhost IP to use 
for internal tasks??

> 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.

Thanks again.

-- 
Glenn English




Reply to: