Re: [gentoo-user] Why do we add the local host name to the 127.0.0.1 / ::1 entry in the /etc/hosts file?

[Michael]

On Saturday, 13 March 2021 19:01:05 GMT Grant Taylor wrote:
> 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 won't argue against this all around rational position.


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

Fair enough.  It is clear to me your proposal won't break things.  Quite the 
opposite it will eliminate the chance of being the cause of localhost 
misconfiguration breaking various services.  The syntax of /etc/hosts as 
presently configured in the Gentoo handbook doesn't even agree with the hosts 
man page installed by baselayout - the man page I believe follows the Debian 
convention.


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

ACK.  This and Samba AD is where this thread started I think.


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

I was talking about the domain name changing, not the host name.

my_laptop.home.com

my_laptop.work.com

However, the hostname should be set in /etc/conf.d/hostname, or netifrc(?).


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

Right, the topic has been (re)visited a number of times.  I wonder what has 
brought about the hosts file syntax in the current version of the Handbook.


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


Perhaps it is time to file a bug to propose a way forward both on the Handbook 
and the Wiki pages to ensure network configuration remains consistent across 
the documentation.