On 3/12/21 12:04 PM, Michael wrote:
Right. That's the nub of it. Samba, with AD-DC and Kerberos
configuration deserves special attention and the apps devs advise
accordingly.
I see it differently.
There's the sloppy / slipshod way that doesn't negatively effect /most/
things. Then there's the better / proper way that doesn't negatively
effect anything.
I see no reason to ever do it the sloppy / slipshod way when it's simple
to do it the better / proper way.
Yes, I recall apache would fail if you tried to contact
http://localhost or its FQDN from the server itself, with something
like "... host name not valid for this server", but it would serve
the default "It works!" webpage when the server's FQDN was called
from clients. Anyway, all this is O/T from the main question.
It is on topic as supporting evidence to why the main topic, having the
hostname on the 127.0.0.1 / ::1 IP in the /etc/hosts file, is a bad idea.
It doesn't, obviously the two files are fulfilling different purposes.
You could however specify in the DC's host file any additional DNS
servers in the AD DNS zone with their static IP addresses. I tend
to do this and also check the hosts file in the first instance when I
forget what other machines play some (important) role on the current
host's functions. This is by no means a rule or even a recommendation
for others to do the same. ;-)
Ah. So you're (ab)using the /etc/hosts file as a form of documentation
to make life for future you easier. Fair enough. But call the spade
the spade that it is. State that you're putting the information there
for documentation purposes, not because it's needed for some other reason.
I wouldn't call it majorly "wrong" on a standalone desktop use case, in
the sense that it shouldn't break things - I think.
I would call a configuration that works in all cases to be superior to a
configuration that only works in some cases and fails in other cases.
As such I'm describing the inferior configuration as "wrong".
Address 127.0.0.1 is for internal consumption, it won't be seen by the
external network and the host can refer to itself as its user desires.
External hosts will see the 127.0.0.1 / ::1 address when things, like
Kerberos, use gethostbyname() and put the returned value into traffic
that leaves the system.
Aside: localhost / 127.0.0.1 / ::1 is /not/ unique to any system.
Conversely a hosts name /is/ unique to /only/ the system. Thus anything
that wants the local host's unique name should never use / see localhost
/ 127.0.0.1 / ::1. As such, any time that a hosts unique name resolves
to a non-unique address should be considered wrong.
Furthermore, LAN addresses and domains may change all the time on
say a roaming laptop, so setting up aliases against a temporary LAN
IP becomes cumbersome.
I never allow an external DHCP server (et al.) to specify the local
system's host name. Especially DHCP servers that I don't know, much
less trust.
People's names don't change when they move to a different address. At
least this is the norm for the vast majority of people in the U.S.A. I
assume the same for the rest of the world.
Yes, specifying a FQDN against localhost doesn't align with the
practice of most distros and a number of RFCs, therefore asking why
the handbook offers this guidance without qualifying it is worth
exploring further.
Very good point.
We have already established the handbook suggestion creates breakage on
Samba with AD/DC, potentially on a webserver, and perhaps other server
applications. I agree using 127.0.0.1 for the special "localhost"
hostname is cleaner and in these use cases the right solution.
Yes.
I recalled old bugs filed about this and had a look. I don't know of
other dev conversations/bugs and what might have produced the current
guidance in the handbook:
https://bugs.gentoo.org/40203
https://bugs.gentoo.org/53188
These hint at other underlying bugs / (mis)configuration issues.
I can see why people might have chosen to hack around this problem by
causing the host's name to resolve to 127.0.0.1 / ::1. -- However,
I'll argue that a better solution would be to add an additional IP
address to the lo (or dummy) interface and make the name resolve to that.
Interestingly you attracted my attention to the man page for the
hosts file, which I assume is installed by baselayout. I noticed
this example quoted at the bottom where 127.0.1.1 is used for the
host's FQDN:
EXAMPLES
# The following lines are desirable for IPv4 capable hosts
127.0.0.1 localhost
# 127.0.1.1 is often used for the FQDN of the machine
127.0.1.1 thishost.mydomain.org thishost
You can probably guess that I think this is a bug which should be corrected.
Or at the very least call out that this is inferior and can cause problems.
If the Gentoo handbook recommends something different, I think the devs
should at least qualify why this is so and potentially offer warnings
on use cases where the handbook recommendation is inappropriate and
must be deviated from.
Agreed.
Also, see prior comment about superior / everywhere vs inferior / not
everywhere options.
--
Grant. . . .
unix || die
