Mailing List Archive

> 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

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.

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

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

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

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

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:~$

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.

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

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.

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

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

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

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

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

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

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

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

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

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

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.

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

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.

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.