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

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

[Grant Taylor]

Hi,

I'm reading Kerberos - The Definitive Guide[1] and it makes the 
following comment:

> And to make matters worse, some Unix systems map their own hostname 
> to 127.0.0.1 (the loopback IP address).

This makes me think that the local host name /shouldn't/ be included in 
the 127.0.0.1 (or ::1) entry in the /etc/hosts file.

However, according to the Gentoo AMD64 Handbook[2], we are supposed to 
add the local host name to the 127.0.0.1 (and ::1) entry in the 
/etc/hosts file.

Will someone please explain why the Gentoo AMD64 Handbook ~> Gentoo (at 
large) says to add the local host name to the 127.0.0.1 (or ::1) entry 
in the /etc/hosts file?  What was the thought process behind that?

Incidentally, adding the local host name to the 127.0.0.1 (or ::1) entry 
in the /etc/hosts file causes "hostname -i" to return 127.0.0.1 instead 
of the IP address bound to the network interface.

Thank you for any input you can provide.

[1] Kerberos: The Definitive Guide (p. 109). O'Reilly Media. Kindle Edition.
[2] 
https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/System#The_hosts_file



-- 
Grant. . . .
unix || die

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

[Andrew Udvare]

> On 2021-02-21, at 17:23, Grant Taylor <gtaylor@gentoo.tnetconsulting.net> wrote:
> 
> Hi,
> 
> I'm reading Kerberos - The Definitive Guide[1] and it makes the following comment:
> 
>> And to make matters worse, some Unix systems map their own hostname to 127.0.0.1 (the loopback IP address).
> 
> This makes me think that the local host name /shouldn't/ be included in the 127.0.0.1 (or ::1) entry in the /etc/hosts file.
> 
> However, according to the Gentoo AMD64 Handbook[2], we are supposed to add the local host name to the 127.0.0.1 (and ::1) entry in the /etc/hosts file.
> 
> Will someone please explain why the Gentoo AMD64 Handbook ~> Gentoo (at large) says to add the local host name to the 127.0.0.1 (or ::1) entry in the /etc/hosts file?  What was the thought process behind that?

The thought process is the same as the guide you are reading. https://www.oreilly.com/library/view/kerberos-the-definitive/0596004036/ch04s03.html

It says in the last paragraph on this page that the /etc/hosts file should have the '127.0.0.1 localhost <not-FQDN>' (last part is definitely optional) and then that the next entry should have the outer IP address mapped to the FQDN.

-- 
Andrew

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

[Peter Humphrey]

On Sunday, 21 February 2021 22:23:00 GMT Grant Taylor wrote:
> Hi,
> 
> I'm reading Kerberos - The Definitive Guide[1] and it makes the
> 
> following comment:
> > And to make matters worse, some Unix systems map their own hostname
> > to 127.0.0.1 (the loopback IP address).
> 
> This makes me think that the local host name /shouldn't/ be included in
> the 127.0.0.1 (or ::1) entry in the /etc/hosts file.
> 
> However, according to the Gentoo AMD64 Handbook[2], we are supposed to
> add the local host name to the 127.0.0.1 (and ::1) entry in the
> /etc/hosts file.
> 
> Will someone please explain why the Gentoo AMD64 Handbook ~> Gentoo (at
> large) says to add the local host name to the 127.0.0.1 (or ::1) entry
> in the /etc/hosts file?  What was the thought process behind that?
> 
> Incidentally, adding the local host name to the 127.0.0.1 (or ::1) entry
> in the /etc/hosts file causes "hostname -i" to return 127.0.0.1 instead
> of the IP address bound to the network interface.

Isn't it a matter of simple logic? The loopback address is just that: the 
machine talking to itself, with no reference to the outside world. Whereas, 
while talking to other machines on the network its address is that of the 
interface. There's no connection between those two.

-- 
Regards,
Peter.

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

[Grant Taylor]

On 2/24/21 7:37 PM, Peter Humphrey wrote:
> Isn't it a matter of simple logic?

No.  It is not.  Consider my question to be calling the logic into 
question.  Or at least asking for what the logic was to be explained.

> The loopback address is just that: the machine talking to itself, with 
> no reference to the outside world. Whereas, while talking to other 
> machines on the network its address is that of the interface. There's 
> no connection between those two.

That doesn't explain /why/ the local host name is added to the line 
containing 127.0.0.1 and / or ::1.

Remember, that /all/ traffic to a local IP, of any interface, runs 
through the loopback interface.

Try pinging your Ethernet / WiFi IP address in one window and then 
shutting the lo interface down.  The pings will stop responding.  Then 
they will start again when you turn the lo interface back up.

So, even if you do (questionably) connect to the IP address of the 
Ethernet / WiFi adapter instead of 127.0.0.1 / ::1 you are still going 
through the lo interface.

So, again, will someone please explain why the Gentoo AMD64 Handbook ~> 
Gentoo (at large) says to add the local host name to the 127.0.0.1 (or 
::1) entry in the /etc/hosts file?  What was the thought process behind 
that?



-- 
Grant. . . .
unix || die

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

[Arve Barsnes]

On Thu, 25 Feb 2021 at 03:50, Grant Taylor
<gtaylor@gentoo.tnetconsulting.net> wrote:
> > The loopback address is just that: the machine talking to itself, with
> > no reference to the outside world. Whereas, while talking to other
> > machines on the network its address is that of the interface. There's
> > no connection between those two.
>
> That doesn't explain /why/ the local host name is added to the line
> containing 127.0.0.1 and / or ::1.

I don't think that was the question Peter sought to answer, but rather
that 'hostname -i' returns the loopback address either way.

Might still defy logic depending on the way you look at it, but that's
a different question.

Regards,
Arve

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

[Grant Taylor]

On 2/25/21 12:02 AM, Arve Barsnes wrote:
> I don't think that was the question Peter sought to answer, but rather
> that 'hostname -i' returns the loopback address either way.

But 'hostname -i' /doesn't/ return the 127.0.0.1 or ::1 if the hostname 
isn't on lines with 127.0.0.1 or ::1.

> Might still defy logic depending on the way you look at it, but that's
> a different question.

Hence why I'm seeking the logic behind what was done.



-- 
Grant. . . .
unix || die

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

[Grant Taylor]

On 2/21/21 3:23 PM, Grant Taylor wrote:
> Will someone please explain why the Gentoo AMD64 Handbook ~> Gentoo (at 
> large) says to add the local host name to the 127.0.0.1 (or ::1) entry 
> in the /etc/hosts file?  What was the thought process behind that?

Shameless Bump  --  I'm still interested in understanding the logic 
behind the choice in the Gentoo Handbook.

Additional information.

The Samba Wiki states the following in the Preparing the Installation 
section of the Setting up Samba as an Active Directory Domain Controller 
document.

"The host name and FQDN must not resolve to the 127.0.0.1 IP address or 
any other IP address than the one used on the LAN interface of the DC."

Link - Setting up Samba as an Active Directory Domain Controller - 
Preparing the Installation
  - 
https://wiki.samba.org/index.php/Setting_up_Samba_as_an_Active_Directory_Domain_Controller#Preparing_the_Installation



-- 
Grant. . . .
unix || die

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

[Mark Knecht]

[-- Attachment #1: Type: text/plain, Size: 2562 bytes --]

On Tue, Mar 9, 2021 at 10:10 PM Grant Taylor <
gtaylor@gentoo.tnetconsulting.net> wrote:
>
> On 2/21/21 3:23 PM, Grant Taylor wrote:
> > Will someone please explain why the Gentoo AMD64 Handbook ~> Gentoo (at
> > large) says to add the local host name to the 127.0.0.1 (or ::1) entry
> > in the /etc/hosts file?  What was the thought process behind that?
>
> Shameless Bump  --  I'm still interested in understanding the logic
> behind the choice in the Gentoo Handbook.
>
> Additional information.
>
> The Samba Wiki states the following in the Preparing the Installation
> section of the Setting up Samba as an Active Directory Domain Controller
> document.
>
> "The host name and FQDN must not resolve to the 127.0.0.1 IP address or
> any other IP address than the one used on the LAN interface of the DC."
>
> Link - Setting up Samba as an Active Directory Domain Controller -
> Preparing the Installation
>   -
>
https://wiki.samba.org/index.php/Setting_up_Samba_as_an_Active_Directory_Domain_Controller#Preparing_the_Installation
>

AND

[quote]
I'm reading Kerberos - The Definitive Guide[1] and it makes the
following comment:

> And to make matters worse, some Unix systems map their own hostname
> to 127.0.0.1 (the loopback IP address).
[/quote]

Caveat - not an expert, just my meager understanding:

1) The name 'localhost' is historically for developers who want to access
their own machine _without_ using DNS.

2) By general practice sometime in the deep, dark times 127.0.0.1 was
accepted for this purpose. There's nothing special about the address.

3) I read the original quoted comment in the Kerberos Guide as a warning -
'to make matters worse, __SOME__"

4) In my /etc/hosts I do _NOT_ map my machine's name to the same address as
localhost, avoiding the Kerberos warning:

mark@science:~$ cat /etc/hosts
127.0.0.1       localhost
127.0.1.1       science

# 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

mark@science:~$ ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.032 ms

mark@science:~$ ping science
PING science (127.0.1.1) 56(84) bytes of data.
64 bytes from science (127.0.1.1): icmp_seq=1 ttl=64 time=0.032 ms

mark@science:~$ hostname
science
mark@science:~$ hostname -I
192.168.86.42
mark@science:~$ hostname -A
science.lan
mark@science:~$ hostname -f
science
mark@science:~$ hostname -i
127.0.1.1
mark@science:~$

[-- Attachment #2: Type: text/html, Size: 5478 bytes --]

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]

[-- Attachment #1: Type: text/plain, Size: 3448 bytes --]

On Wednesday, 10 March 2021 13:27:24 GMT Mark Knecht wrote:
> On Tue, Mar 9, 2021 at 10:10 PM Grant Taylor <
> 
> gtaylor@gentoo.tnetconsulting.net> wrote:
> > On 2/21/21 3:23 PM, Grant Taylor wrote:
> > > Will someone please explain why the Gentoo AMD64 Handbook ~> Gentoo (at
> > > large) says to add the local host name to the 127.0.0.1 (or ::1) entry
> > > in the /etc/hosts file?  What was the thought process behind that?
> > 
> > Shameless Bump  --  I'm still interested in understanding the logic
> > behind the choice in the Gentoo Handbook.
> > 
> > Additional information.
> > 
> > The Samba Wiki states the following in the Preparing the Installation
> > section of the Setting up Samba as an Active Directory Domain Controller
> > document.
> > 
> > "The host name and FQDN must not resolve to the 127.0.0.1 IP address or
> > any other IP address than the one used on the LAN interface of the DC."
> > 
> > Link - Setting up Samba as an Active Directory Domain Controller -
> > Preparing the Installation
> > 
> >   -
> 
> https://wiki.samba.org/index.php/Setting_up_Samba_as_an_Active_Directory_Dom
> ain_Controller#Preparing_the_Installation
> 
> 
> AND
> 
> [quote]
> I'm reading Kerberos - The Definitive Guide[1] and it makes the
> 
> following comment:
> > And to make matters worse, some Unix systems map their own hostname
> > to 127.0.0.1 (the loopback IP address).
> 
> [/quote]
> 
> Caveat - not an expert, just my meager understanding:
> 
> 1) The name 'localhost' is historically for developers who want to access
> their own machine _without_ using DNS.
> 
> 2) By general practice sometime in the deep, dark times 127.0.0.1 was
> accepted for this purpose. There's nothing special about the address.
> 
> 3) I read the original quoted comment in the Kerberos Guide as a warning -
> 'to make matters worse, __SOME__"
> 
> 4) In my /etc/hosts I do _NOT_ map my machine's name to the same address as
> localhost, avoiding the Kerberos warning:
> 
> mark@science:~$ cat /etc/hosts
> 127.0.0.1       localhost
> 127.0.1.1       science
> 
> # 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
> 
> mark@science:~$ ping localhost
> PING localhost (127.0.0.1) 56(84) bytes of data.
> 64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.032 ms
> 
> mark@science:~$ ping science
> PING science (127.0.1.1) 56(84) bytes of data.
> 64 bytes from science (127.0.1.1): icmp_seq=1 ttl=64 time=0.032 ms
> 
> mark@science:~$ hostname
> science
> mark@science:~$ hostname -I
> 192.168.86.42
> mark@science:~$ hostname -A
> science.lan
> mark@science:~$ hostname -f
> science
> mark@science:~$ hostname -i
> 127.0.1.1
> mark@science:~$

I think this is relevant to DNS resolution of/with domain controllers and may 
depend on the AD/DC topology.  The idea is to use the LAN address of the box 
as the first address in /etc/hosts and use 127.0.0.1 as the second address in 
the file.  If more AD/DNS servers exist in the network, then 127.0.0.1 could 
be even further down the list.

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff807362(v=ws.10)?redirectedfrom=MSDN

I haven't over-thought this and there may be more to it, but on a pure linux 
environment I expect this would not be a requirement, hence the handbook 
approach.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Mark Knecht]

[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]

<SNIP>

> mark@science:~$ cat /etc/hosts
> 127.0.0.1       localhost
> 127.0.1.1       science
>
<SNIP>
<SNIP
I think this is relevant to DNS resolution of/with domain controllers and
may
depend on the AD/DC topology.  The idea is to use the LAN address of the box
as the first address in /etc/hosts and use 127.0.0.1 as the second address
in
the file.  If more AD/DNS servers exist in the network, then 127.0.0.1 could
be even further down the list.

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff807362(v=ws.10)?redirectedfrom=MSDN

I haven't over-thought this and there may be more to it, but on a pure linux
environment I expect this would not be a requirement, hence the handbook
approach.
<SNIP>

It could very well be but I have vague memories when I first started
getting
interested in Linux, circa 1996-97 with Redhat, that I would buy books that
liberally sprinkled http://localhost or ping localhost sorts of lines in
the text and
examples.

My undocumented (and unsupported by data) opinion is that this localhost
thing has been around a long, long time - possibly longer than Linux for
all I know. Check out

http://acme.com

I have no real admin experience with any version of Windows. Even though
I wrote, published and made a tiny bit of money selling a Windows program
written in Turbo Pascal in those days I didn't even have networking.
Everything
was passed around on floppies.

[-- Attachment #2: Type: text/html, Size: 1983 bytes --]

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]

[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]

On Wednesday, 10 March 2021 16:00:19 GMT Mark Knecht wrote:
> <SNIP>
> 
> > mark@science:~$ cat /etc/hosts
> > 127.0.0.1       localhost
> > 127.0.1.1       science
> 
> <SNIP>
> <SNIP
> I think this is relevant to DNS resolution of/with domain controllers and
> may
> depend on the AD/DC topology.  The idea is to use the LAN address of the box
> as the first address in /etc/hosts and use 127.0.0.1 as the second address
> in
> the file.  If more AD/DNS servers exist in the network, then 127.0.0.1 could
> be even further down the list.
> 
> https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-se
> rver-2008-R2-and-2008/ff807362(v=ws.10)?redirectedfrom=MSDN
> 
> I haven't over-thought this and there may be more to it, but on a pure linux
> environment I expect this would not be a requirement, hence the handbook
> approach.
> <SNIP>
> 
> It could very well be but I have vague memories when I first started
> getting
> interested in Linux, circa 1996-97 with Redhat, that I would buy books that
> liberally sprinkled http://localhost or ping localhost sorts of lines in
> the text and
> examples.
> 
> My undocumented (and unsupported by data) opinion is that this localhost
> thing has been around a long, long time - possibly longer than Linux for
> all I know. Check out
> 
> http://acme.com
> 
> I have no real admin experience with any version of Windows. Even though
> I wrote, published and made a tiny bit of money selling a Windows program
> written in Turbo Pascal in those days I didn't even have networking.
> Everything was passed around on floppies.

I always thought the localhost class A addresses were from days of old 'inter-
network' era.  The difference with 127.0.0.1 and a private LAN address is the 
127.0.0.1 does not reach the data link layer, but loops-back at IP layer 3 and 
responds to any applications on the local PC.  So, I understood this to mean 
it never went through the whole network stack, as it does when you ping a 
remote host.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Grant Taylor]

On 3/10/21 9:38 AM, Michael wrote:
> I always thought the localhost class A addresses were from days of old 
> 'inter- network' era.  The difference with 127.0.0.1 and a private 
> LAN address is the 127.0.0.1 does not reach the data link layer, 
> but loops-back at IP layer 3 and responds to any applications on the 
> local PC.  So, I understood this to mean it never went through the 
> whole network stack, as it does when you ping a remote host.

The 127/8 (formerly called a class A) network is reserved / allocated 
for a host to communicate with itself.

However, /how/ local addresses are used is entirely implementation 
specific.  This goes for both 127.0.0.1 and other addresses bound to 
local network cards.

Linux will not send traffic to the local LAN IP to the NIC either.  But 
that's a /Linux/ /implementation/ detail.  Other OSs, e.g. Windows, 
don't use a loopback adapter for 127.0.0.1.  Instead it's purely a 
software construct.  But that's a /Windows/ /implementation/ detail.

Aside:  Windows (2k and onward) does have a loopback adapter that you 
can optionally install.  However you /can't/ assign 127.0.0.1 (or any 
127/8) to it.  It is meant to be used like Linux uses the dummy adapter.



-- 
Grant. . . .
unix || die

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

[Grant Taylor]

On 3/10/21 9:00 AM, Mark Knecht wrote:
> My undocumented (and unsupported by data) opinion is that this 
> localhost thing has been around a long, long time - possibly longer 
> than Linux for all I know. Check out

Yes, very much so.

TL;DR:  The "localhost" name is a shortcut to say this host that I'm on 
without worrying what the actual host name is or that said name is 
configured to resolve to an IP on this system.

The localhost concept goes back a LONG way in TCP/IP.  I think that it 
even pre-dates TCP/IP, via the NCP protocol.



-- 
Grant. . . .
unix || die

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

[Grant Taylor]

On 3/10/21 8:25 AM, Michael wrote:
> I think this is relevant to DNS resolution of/with domain controllers 
> and may depend on the AD/DC topology.

I disagree.  Pure Linux in a MIT / Heimdal Kerberos environment has the 
same requirements.  Hence having nothing specific to do with Active 
Directory, much less the AD topology.

> The idea is to use the LAN address of the box as the first address 
> in /etc/hosts and use 127.0.0.1 as the second address in the file.

Please elaborate.  Because I believe the following qualifies with your 
statement:

192.0.2.1	host.example.net host
127.0.0.1	localhost

Which is effectively the same as the following:

127.0.0.1	localhost
192.0.2.1	host.example.net host

Both of which are different than the following:

192.0.2.1	host.example.net host
127.0.0.1	localhost host.example.net host

Putting host.example.net and host on the 127.0.0.1 line doesn't 
accomplish anything.  And it still suffers from -- what I think is -- 
the poor recommendation that I'm inquiring about.

> If more AD/DNS servers exist in the network, then 127.0.0.1 could be 
> even further down the list.
> 
> https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff807362(v=ws.10)?redirectedfrom=MSDN

What does the number of DNS servers have to do with the contents of the 
/etc/hosts file?

How is the contents of the /etc/hosts file related to the 
/etc/resolv.conf file?

> I haven't over-thought this and there may be more to it, but on a 
> pure linux environment I expect this would not be a requirement, 
> hence the handbook approach.

Apples and bowling balls.  /etc/hosts is not the same concept as 
/etc/resolv.conf.



-- 
Grant. . . .
unix || die

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]

[-- Attachment #1: Type: text/plain, Size: 3475 bytes --]

On Wednesday, 10 March 2021 16:58:47 GMT Grant Taylor wrote:
> On 3/10/21 8:25 AM, Michael wrote:
> > I think this is relevant to DNS resolution of/with domain controllers
> > and may depend on the AD/DC topology.
> 
> I disagree.  Pure Linux in a MIT / Heimdal Kerberos environment has the
> same requirements.  Hence having nothing specific to do with Active
> Directory, much less the AD topology.

I'm losing my thread in this ... thread, but what I'm trying to say is the AD/
DC and Kerberos way of processing the /etc/hosts entries, when an /etc/hosts 
file is used, is different to your run of the mill Linux box and server.

The Samba link in a previous message makes it clear the DC must have a DNS 
domain, which corresponds to the domain for the AD forest, this will be used 
by the Kerberos AD realm; and,

the DC must have a static IP address.


> > The idea is to use the LAN address of the box as the first address
> > in /etc/hosts and use 127.0.0.1 as the second address in the file.
> 
> Please elaborate.  Because I believe the following qualifies with your
> statement:
> 
> 192.0.2.1	host.example.net host
> 127.0.0.1	localhost
> 
> Which is effectively the same as the following:
> 
> 127.0.0.1	localhost
> 192.0.2.1	host.example.net host
> 
> Both of which are different than the following:
> 
> 192.0.2.1	host.example.net host
> 127.0.0.1	localhost host.example.net host

Yes.


> Putting host.example.net and host on the 127.0.0.1 line doesn't
> accomplish anything.  And it still suffers from -- what I think is --
> the poor recommendation that I'm inquiring about.

The syntax is:

IP_address canonical_hostname [aliases...]

Therefore, in an entry like:

127.0.0.1	localhost host.example.net host

the "host.example.net" and "host" are both entered as aliases, but will 
nevertheless resolve to 127.0.0.1 - which will break the Samba AD DC 
requirement.  The host name and FQDN must resolve to the static IP of the DC 
on the LAN.

Since /etc/hosts is parsed from the top, things may work fine when the 
localhost entry is further down the list and further down than any other 
entries acting as AD DNS resolvers - I don't recall testing this on Samba to 
know for sure.

The same syntax won't break a LAMP, or vanilla linux PC, as long as the same 
box is not acting as a DC.


> > If more AD/DNS servers exist in the network, then 127.0.0.1 could be
> > even further down the list.
> > 
> > https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-> > server-2008-R2-and-2008/ff807362(v=ws.10)?redirectedfrom=MSDN
> 
> What does the number of DNS servers have to do with the contents of the
> /etc/hosts file?

See my statement above re. entries for AD DNS resolvers, if these are listed 
in the /etc/hosts file.


> How is the contents of the /etc/hosts file related to the
> /etc/resolv.conf file?

The /etc/hosts file specifies the LAN IP address(es) of the DC which acts as 
DNS resolver for the AD DNS zones.  The DC's /etc/resolv.conf shouldn't be 
pointing to non-AD compatible resolvers.


> > I haven't over-thought this and there may be more to it, but on a
> > pure linux environment I expect this would not be a requirement,
> > hence the handbook approach.
> 
> Apples and bowling balls.  /etc/hosts is not the same concept as
> /etc/resolv.conf.

ACK.  I hope what I've written above better reflects my understanding, 
although it could be factually incorrect.  Other contributors should soon put 
me right.  :-)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Grant Taylor]

On 3/11/21 6:38 AM, Michael wrote:
> I'm losing my thread in this ... thread, but what I'm trying to say 
> is the AD/ DC and Kerberos way of processing the /etc/hosts entries, 
> when an /etc/hosts file is used, is different to your run of the mill 
> Linux box and server.

I disagree.

First, AD/DC ~ Kerberos don't process the /etc/hosts file.  They do ask 
the system to resolve names to IP addresses.

Second, the system will process the /etc/hosts file, DNS, NIS(+) in the 
order configured in the /etc/nsswitch file so that it can resolve names 
to IP addresses for programs that ask it to do so.

Third, both non-AD / non-Kerberos and AD / Kerberos systems ask the 
system to resolve names to IP addresses.  Further, I'll bet dollars to 
donuts that they call the same functions and use the same subsystems.

I will agree that non-AD / non-Kerberos systems are not sensitive to -- 
what some consider to be -- the misconfigurations that AD / Kerberos 
systems are.

> The Samba link in a previous message makes it clear the DC must have 
> a DNS domain, which corresponds to the domain for the AD forest, 
> this will be used by the Kerberos AD realm; and, the DC must have a 
> static IP address.

Yes.  But that has nothing to do with the contents of the /etc/hosts file.

> The syntax is:
> 
> IP_address canonical_hostname [aliases...]

Agreed.  That's what it should be.  Though I've seen all sorts of failures.

> Therefore, in an entry like:
> 
> 127.0.0.1	localhost host.example.net host
> 
> the "host.example.net" and "host" are both entered as aliases, but 
> will nevertheless resolve to 127.0.0.1 - which will break the Samba 
> AD DC requirement.

Agreed.

> The host name and FQDN must resolve to the static IP of the DC on 
> the LAN.

Remember, that this also applies to clients, not just DCs.

> Since /etc/hosts is parsed from the top, things may work fine when 
> the localhost entry is further down the list and further down than 
> any other entries acting as AD DNS resolvers - I don't recall testing 
> this on Samba to know for sure.

Why are you putting entries for the DNS servers in the /etc/hosts file?

> The same syntax won't break a LAMP, or vanilla linux PC, as long as 
> the same box is not acting as a DC.

Actually it can.  I've seen it multiple times in the past.

Bind a service to /only/ the LAN IP.  Then have the system try to 
connect to itself.  It will fail because the service isn't listening on 
the loopback IP.

This is (or was) common on web servers that had multiple IP addresses to 
use different TLS certificates before SNI became a viable thing.  Have 
each virtual web server listen on only it's specific IP address.  Have 
the virtual web server for the system's FQDN follow suit for consistency 
reasons.  Then trying to connect to the FQDN would fail if it was an 
alias for 127.0.0.1 or ::1.

> See my statement above re. entries for AD DNS resolvers, if these 
> are listed in the /etc/hosts file.

You didn't answer my question.

What does the number of DNS servers (configured in /etc/resolv.conf) 
have to do with the contents of the /etc/hosts file?

> The /etc/hosts file specifies the LAN IP address(es) of the DC which 
> acts as DNS resolver for the AD DNS zones.

No, the /etc/hosts file has nothing to do with how /DNS/ resolution 
operates.

> The DC's /etc/resolv.conf shouldn't be pointing to non-AD compatible 
> resolvers.

Which has nothing to do with the contents of /etc/hosts.

> ACK.  I hope what I've written above better reflects my understanding, 
> although it could be factually incorrect.  Other contributors should 
> soon put me right.  :-)

I'm wondering if your understanding is that there's a close relationship 
and interaction between the contents of /etc/hosts and /etc/resolv.conf 
as in the former effects the latter.  This is not the case.

/etc/hosts and /etc/resolv.conf are completely independent and can each 
quite happily exist without the other.  You can even run systems without 
one or the other.  Running without both is technically possible, but 
things start to get ... cumbersome.

You can add entries in /etc/hosts for the DNS servers as a convenience. 
But doing so has no influence on how the DNS resolution subsystem 
functions.  The DNS resolution subsystem is driven by options in the 
/etc/resolv.conf file.  And it's done independently of the contents of 
the /etc/hosts file.

Yes, the /etc/hosts file and the /etc/resolv.conf file both have to do 
with name to IP (and IP to name) resolution.  But they are as 
independent of each other as looking up a phone number in the phone book 
vs calling and asking the operator to look it up for you.  They achieve 
the same goal, but do so completely different ways and completely 
independently of each other.

This has been and is an interesting discussion.  However, I'm still no 
closer to learning why the Gentoo handbook wants the local host name 
added to the 127.0.0.1 / ::1 entry in the /etc/hosts file.  Something 
which I believe is wrong and bad advice.



-- 
Grant. . . .
unix || die

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]

[-- Attachment #1: Type: text/plain, Size: 8303 bytes --]

On Thursday, 11 March 2021 16:50:37 GMT Grant Taylor wrote:
> On 3/11/21 6:38 AM, Michael wrote:
> > I'm losing my thread in this ... thread, but what I'm trying to say
> > is the AD/ DC and Kerberos way of processing the /etc/hosts entries,
> > when an /etc/hosts file is used, is different to your run of the mill
> > Linux box and server.
> 
> I disagree.
> 
> First, AD/DC ~ Kerberos don't process the /etc/hosts file.  They do ask
> the system to resolve names to IP addresses.

Yes, of course.  I realise I didn't express this point accurately.  I think 
the hosts file is parsed, if it exists, by the glibc which then provides the 
required IP info to applications.


> Second, the system will process the /etc/hosts file, DNS, NIS(+) in the
> order configured in the /etc/nsswitch file so that it can resolve names
> to IP addresses for programs that ask it to do so.

Yes, /etc/hosts could be even be configured to be the last source to be 
consulted, or not exist at all.


> Third, both non-AD / non-Kerberos and AD / Kerberos systems ask the
> system to resolve names to IP addresses.  Further, I'll bet dollars to
> donuts that they call the same functions and use the same subsystems.
> 
> I will agree that non-AD / non-Kerberos systems are not sensitive to --
> what some consider to be -- the misconfigurations that AD / Kerberos
> systems are.

Right.  That's the nub of it.  Samba, with AD-DC and Kerberos configuration 
deserves special attention and the apps devs advise accordingly.


> > The Samba link in a previous message makes it clear the DC must have
> > a DNS domain, which corresponds to the domain for the AD forest,
> > this will be used by the Kerberos AD realm; and, the DC must have a
> > static IP address.
> 
> Yes.  But that has nothing to do with the contents of the /etc/hosts file.

It does, insofar the hosts file contents and syntax could break Samba, AD/DC 
and Kerberos, if the Samba devs advice is not heeded.

Unless I got all this thread wrong, this is the main bone of contention - 
handbook recommendations can lead to such breakage.


[snip...]

> > Since /etc/hosts is parsed from the top, things may work fine when
> > the localhost entry is further down the list and further down than
> > any other entries acting as AD DNS resolvers - I don't recall testing
> > this on Samba to know for sure.
> 
> Why are you putting entries for the DNS servers in the /etc/hosts file?

You wouldn't normally add in the hosts file the IP addresses of DNS 
forwarders/resolvers, but depending on the topology of the AD forest you could 
if you wanted to.


> > The same syntax won't break a LAMP, or vanilla linux PC, as long as
> > the same box is not acting as a DC.
> 
> Actually it can.  I've seen it multiple times in the past.
> 
> Bind a service to /only/ the LAN IP.  Then have the system try to
> connect to itself.  It will fail because the service isn't listening on
> the loopback IP.

Quite.  If you set up this service to only listen to the LAN IP address, 
rather than any address, it should do just so.  There is also the question why 
should a service for the LAN need to listen to localhost, it's not always 
necessary.


> This is (or was) common on web servers that had multiple IP addresses to
> use different TLS certificates before SNI became a viable thing.  Have
> each virtual web server listen on only it's specific IP address.  Have
> the virtual web server for the system's FQDN follow suit for consistency
> reasons.  Then trying to connect to the FQDN would fail if it was an
> alias for 127.0.0.1 or ::1.

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.


> > See my statement above re. entries for AD DNS resolvers, if these
> > are listed in the /etc/hosts file.
> 
> You didn't answer my question.
> 
> What does the number of DNS servers (configured in /etc/resolv.conf)
> have to do with the contents of the /etc/hosts file?

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


> > The /etc/hosts file specifies the LAN IP address(es) of the DC which
> > acts as DNS resolver for the AD DNS zones.
> 
> No, the /etc/hosts file has nothing to do with how /DNS/ resolution
> operates.

Yes, but I was not referring to DNS resolution mechanism itself, other than 
specifying static addresses of other DCs PCs in the hosts file.  It's just a 
list of IP addresses after all.  Since the localhost (DC) provides DNS 
resolution, its LAN address will be included.


> I'm wondering if your understanding is that there's a close relationship
> and interaction between the contents of /etc/hosts and /etc/resolv.conf
> as in the former effects the latter.  This is not the case.

Yes, we agree.  Two different files, mechanisms and purposes.


> /etc/hosts and /etc/resolv.conf are completely independent and can each
> quite happily exist without the other.  You can even run systems without
> one or the other.  Running without both is technically possible, but
> things start to get ... cumbersome.
> 
> You can add entries in /etc/hosts for the DNS servers as a convenience.

Yes, that's what I was trying to express, evidently unsuccessfully.  :-)


[snip... ]

> This has been and is an interesting discussion.  However, I'm still no
> closer to learning why the Gentoo handbook wants the local host name
> added to the 127.0.0.1 / ::1 entry in the /etc/hosts file.  Something
> which I believe is wrong and bad advice.

I wouldn't call it majorly "wrong" on a standalone desktop use case, in the 
sense that it shouldn't break things - I think.  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.  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.  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.

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.

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


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
       192.168.1.10    foo.mydomain.org       foo
       192.168.1.13    bar.mydomain.org       bar
       146.82.138.7    master.debian.org      master
       209.237.226.90  www.opensource.org

       # The following lines are desirable for IPv6 capable hosts
       ::1             localhost ip6-localhost ip6-loopback
       ff02::1         ip6-allnodes
       ff02::2         ip6-allrouters


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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Grant Taylor]

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

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]

[-- Attachment #1: Type: text/plain, Size: 6251 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Peter Humphrey]

On Tuesday, 16 March 2021 12:16:43 GMT Michael wrote:

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

I tried raising a bug report against the Wiki once, and was rebuked and told 
to go away.

-- 
Regards,
Peter.

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

[Grant Taylor]

On 3/16/21 6:16 AM, Michael wrote:
> Yes, I won't argue against this all around rational position.

;-)

Thank you for the CRC / checksum on my logic and possibly even my position.

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

That should be addressed as well.

I think that any concerns regarding DEs being able to resolve the 
systems FQDN (?) when using dynamic IPs should also be addressed.

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

Kerberos and AD (Windows or Samba) were the most poignant examples of 
why I thought having the FQDN resolve to 127.0.0.1 was incorrect.

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

I consider the domain name to be part of the host name.  But that's a 
different discussion.

> my_laptop.home.com
> 
> my_laptop.work.com

Think about an email server, in different locations:

    smtp.branch-office-1.example.com
    smtp.branch-office-2.example.com

Remember that kernels only have a singular name, which is free form text 
string, including periods, as their host name.  As such, the kernel on 
each system should know it's own name as something that humans can 
differentiate between the two systems.  Thus, the output of `hostname` 
should return an FQDN.

With this in mind, and the methodology of using the same configuration 
everywhere, I think your notebook's hostname should be the same at home 
and at work.

There is an independent name for a given connection, which can, and 
frequently does, differ from what the attached system thinks the 
hostname is.  E.g. my home router thinking that it's FQDN is

    home-router-gw.home.example.net

While a reverse DNS lookup for it's IP will be something like

    dhcp-a-b-c-d.town.isp.example

But, like I said, that's another, different, probably larger conversation.

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

I think the /hostname/ is completely independent of anything network 
interface related.  So, /etc/conf.d/hostname.

Aside:  This also touches on the strong vs weak host model and what the 
interfaces & names belong to.  Linux by default uses the weak host model 
where IPs and interfaces belong to the system (thus any interface).

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

Inquiring minds....

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

Perhaps.

I do appreciate the sanity check on my logic, and the result of my logic.

Thank you for the discussion Michael.  :-)



-- 
Grant. . . .
unix || die

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

[Grant Taylor]

On 3/11/21 6:38 AM, Michael wrote:
> The syntax is:
> 
> IP_address canonical_hostname [aliases...]

The man page for hosts has the following to say:

> DESCRIPTION
> This  manual  page  describes  the format of the /etc/hosts file. 
> This file is a simple text file that associates IP addresses with 
> hostnames, one line per IP address.  For each host a single line 
> should be present with the following information:
> 
>      IP_address canonical_hostname [aliases...]
> 
> The IP address can conform to either IPv4 or IPv6.  Fields of the 
> entry are separated by any number of blanks and/or tab characters. 
> Text from a "#" character until the end of the line is a comment, and 
> is ignored.  Host names may contain only alphanumeric characters, minus 
> signs ("-"), and periods (".").  They must begin with an alphabetic 
> character and end with an alphanumeric character.  Optional aliases 
> provide for name changes, alternate spellings, shorter hostnames, 
> or generic hostnames (for example, localhost).  If required, a host 
> may have two separate entries in this file; one for each version of 
> the Internet Protocol (IPv4 and IPv6).

I want to call out "For /each/ /host/ a *single* *line* should be 
present" and "a host /may/ /have/ *two* /separate/ /entries/ in this 
file; *one* /for/ /each/ /version/ /of/ /the/ /Internet/ /Protocol/".

I interpret this to mean that any given host name (alias or canonical) 
should appear on at most one line per protocol family.

As such, having the local host's name, qualified or not, appear on 
multiple lines for the same protocol is contrary to what the man page 
states.



-- 
Grant. . . .
unix || die

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

[Grant Taylor]

On 3/10/21 6:27 AM, Mark Knecht wrote:
> Caveat - not an expert, just my meager understanding:
> 
> 1) The name 'localhost' is historically for developers who want to 
> access their own machine _without_ using DNS.

Eh....

Using the /name/ "localhost" still uses name resolution.  It could use 
DNS or it may not.  It /typically/ means the /etc/hosts file.  But it 
could mean DNS or NIS(+) or LDAP or something more esoteric.

IMHO what's special about the "localhost" name in particular is that 
it's an agnostic / anycast method to say the local host that a given 
program is running on without regard to what the actual host name is.

> 2) By general practice sometime in the deep, dark times 127.0.0.1 was 
> accepted for this purpose. There's nothing special about the address.

Deep, dark times?  It's still used every single day across multiple 
platforms, Linux, Unix, Windows, z/OS, i/OS, you name it.

> 3) I read the original quoted comment in the Kerberos Guide as a warning 
> - 'to make matters worse, __SOME__"

What did the warning mean to you?  Because I took it as "be careful, 
your $OS /may/ do this incorrectly".  Where "this" is putting the FQDN 
on the same line as 127.0.0.1 and / or ::1.

> 4) In my /etc/hosts I do _NOT_ map my machine's name to the same address 
> as localhost, avoiding the Kerberos warning:

ACK

I'm grateful for corroboration, but unfortunately that doesn't speak to 
why the Gentoo handbook suggests what it does.



-- 
Grant. . . .
unix || die

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

[Mark Knecht]

[-- Attachment #1: Type: text/plain, Size: 3089 bytes --]

On Wed, Mar 10, 2021 at 9:44 AM Grant Taylor <
gtaylor@gentoo.tnetconsulting.net> wrote:
>
> On 3/10/21 6:27 AM, Mark Knecht wrote:
> > Caveat - not an expert, just my meager understanding:
> >
> > 1) The name 'localhost' is historically for developers who want to
> > access their own machine _without_ using DNS.
>
> Eh....
>
> Using the /name/ "localhost" still uses name resolution.  It could use
> DNS or it may not.  It /typically/ means the /etc/hosts file.  But it
> could mean DNS or NIS(+) or LDAP or something more esoteric.
>

OK, agreed, completely. localhost must be turned into an IP address.

I guess what I was thinking was DNS means Server. If it's a Service
then that's different. I think we're in agreement that if it can find the
name in /etc/hosts, either actively or cached somewhere in memory,
then it doesn't have to send anything over a cable to get the answer.

And cable is too generic as I understand that DNS might be on this
machine.

Point taken.

> IMHO what's special about the "localhost" name in particular is that
> it's an agnostic / anycast method to say the local host that a given
> program is running on without regard to what the actual host name is.
>

Agreed but I suspect if I don't have it in /etc/hosts then I'm unlikely
to get results that make sense in real time, but that's case buy case.

Again, completely agreed.

> > 2) By general practice sometime in the deep, dark times 127.0.0.1 was
> > accepted for this purpose. There's nothing special about the address.
>
> Deep, dark times?  It's still used every single day across multiple
> platforms, Linux, Unix, Windows, z/OS, i/OS, you name it.
>

<LOL> I'm approaching my 66th birthday. Deep dark times for me are
almost certainly more recent dates than for you. ;-)

> > 3) I read the original quoted comment in the Kerberos Guide as a warning
> > - 'to make matters worse, __SOME__"
>
> What did the warning mean to you?  Because I took it as "be careful,
> your $OS /may/ do this incorrectly".  Where "this" is putting the FQDN
> on the same line as 127.0.0.1 and / or ::1.
>

I took it as simply a Kerberos setup/config warning. Whoever wrote that
had an opinion, experience or both and wanted you to know that. I
didn't read anything more into it. The author cannot change what
"some distros" do but wants to give you a fighting chance to get
Kerberos working in case you're using one. Makes no sense to mention
a specific distro because the list probably changes over time.

Basically "You'd be wise to look at your /etc/hosts file and fix this
silly configuration error that some distros do before trying to
setup Kerberos"

<SNIP>

> I'm grateful for corroboration, but unfortunately that doesn't speak to
> why the Gentoo handbook suggests what it does.

I'm not a sys admin nor a Gentoo developer or documenter so I cannot
comment on the manual specifically.

As I no longer run Gentoo - I haven't for about 3 years other than one
remaining VM seldom used and seldom updated - I'm way out of
touch with the actual manual but interested in the subject.

Over and out.

- Mark

[-- Attachment #2: Type: text/html, Size: 4138 bytes --]

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

[Grant Taylor]

On 3/10/21 10:43 AM, Mark Knecht wrote:
> OK, agreed, completely. localhost must be turned into an IP address.

:-)

> I guess what I was thinking was DNS means Server. If it's a Service 
> then that's different. I think we're in agreement that if it can find 
> the name in /etc/hosts, either actively or cached somewhere in memory, 
> then it doesn't have to send anything over a cable to get the answer.
> 
> And cable is too generic as I understand that DNS might be on this 
> machine.

How about we settle on a UDP and / or TCP connection to a service 
somewhere, local or remote, that translates a name to an IP.  ;-)

> Agreed but I suspect if I don't have it in /etc/hosts then I'm unlikely 
> to get results that make sense in real time, but that's case buy case.

I think a number of DNS servers are defaulting to resolve A queries for 
"localhost" to 127.0.0.1 and AAAA to ::1.  So, even if it's not in 
/etc/hosts, you'll still probably get the expected resolution.

> <LOL> I'm approaching my 66th birthday. Deep dark times for me are 
> almost certainly more recent dates than for you. ;-)

~chuckle~

> I took it as simply a Kerberos setup/config warning. Whoever wrote 
> that had an opinion, experience or both and wanted you to know that. I 
> didn't read anything more into it.

ACK

By default, Kerberos includes IP restrictions in tickets.  It chooses 
the IP based on what the system returns.  So if the system returns 
127.0.0.1 (or ::1) for the hostname, any tickets that use that IP will 
be non-viable / useless anywhere but localhost.

> The author cannot change what "some distros" do but wants to give 
> you a fighting chance to get Kerberos working in case you're using 
> one. Makes no sense to mention a specific distro because the list 
> probably changes over time.

Agreed.

> Basically "You'd be wise to look at your /etc/hosts file and fix 
> this silly configuration error that some distros do before trying to 
> setup Kerberos"

Yep.  Experience has shown that it breaks things.

> I'm not a sys admin nor a Gentoo developer or documenter so I cannot 
> comment on the manual specifically.
> 
> As I no longer run Gentoo - I haven't for about 3 years other than 
> one remaining VM seldom used and seldom updated - I'm way out of 
> touch with the actual manual but interested in the subject.

Fair enough.



-- 
Grant. . . .
unix || die

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

[Wols Lists]

On 10/03/21 18:37, Grant Taylor wrote:
> ACK
> 
> By default, Kerberos includes IP restrictions in tickets.  It chooses
> the IP based on what the system returns.  So if the system returns
> 127.0.0.1 (or ::1) for the hostname, any tickets that use that IP will
> be non-viable / useless anywhere but localhost.

Could it be (I don't use Kerberos) this tricks Kerberos into associating
127.0.0.1 with your FQDN, so it works for the first person to request
it, and then breaks for everyone else?

Also, bear in mind I think in certain setups /etc/hosts is redundant.
Don't you specify somewhere a list of services to use to look up
computer names, and if /etc/hosts is missing/disabled in that list, it
gets ignored?

Cheers,
Wol