| 1 |
On 3/16/21 6:16 AM, Michael wrote: |
| 2 |
> Yes, I won't argue against this all around rational position. |
| 3 |
|
| 4 |
;-) |
| 5 |
|
| 6 |
Thank you for the CRC / checksum on my logic and possibly even my position. |
| 7 |
|
| 8 |
> Fair enough. It is clear to me your proposal won't break things. |
| 9 |
> Quite the opposite it will eliminate the chance of being the cause |
| 10 |
> of localhost misconfiguration breaking various services. |
| 11 |
|
| 12 |
:-) |
| 13 |
|
| 14 |
> The syntax of /etc/hosts as presently configured in the Gentoo handbook |
| 15 |
> doesn't even agree with the hosts man page installed by baselayout - |
| 16 |
> the man page I believe follows the Debian convention. |
| 17 |
|
| 18 |
That should be addressed as well. |
| 19 |
|
| 20 |
I think that any concerns regarding DEs being able to resolve the |
| 21 |
systems FQDN (?) when using dynamic IPs should also be addressed. |
| 22 |
|
| 23 |
> ACK. This and Samba AD is where this thread started I think. |
| 24 |
|
| 25 |
Kerberos and AD (Windows or Samba) were the most poignant examples of |
| 26 |
why I thought having the FQDN resolve to 127.0.0.1 was incorrect. |
| 27 |
|
| 28 |
> I was talking about the domain name changing, not the host name. |
| 29 |
|
| 30 |
I consider the domain name to be part of the host name. But that's a |
| 31 |
different discussion. |
| 32 |
|
| 33 |
> my_laptop.home.com |
| 34 |
> |
| 35 |
> my_laptop.work.com |
| 36 |
|
| 37 |
Think about an email server, in different locations: |
| 38 |
|
| 39 |
smtp.branch-office-1.example.com |
| 40 |
smtp.branch-office-2.example.com |
| 41 |
|
| 42 |
Remember that kernels only have a singular name, which is free form text |
| 43 |
string, including periods, as their host name. As such, the kernel on |
| 44 |
each system should know it's own name as something that humans can |
| 45 |
differentiate between the two systems. Thus, the output of `hostname` |
| 46 |
should return an FQDN. |
| 47 |
|
| 48 |
With this in mind, and the methodology of using the same configuration |
| 49 |
everywhere, I think your notebook's hostname should be the same at home |
| 50 |
and at work. |
| 51 |
|
| 52 |
There is an independent name for a given connection, which can, and |
| 53 |
frequently does, differ from what the attached system thinks the |
| 54 |
hostname is. E.g. my home router thinking that it's FQDN is |
| 55 |
|
| 56 |
home-router-gw.home.example.net |
| 57 |
|
| 58 |
While a reverse DNS lookup for it's IP will be something like |
| 59 |
|
| 60 |
dhcp-a-b-c-d.town.isp.example |
| 61 |
|
| 62 |
But, like I said, that's another, different, probably larger conversation. |
| 63 |
|
| 64 |
> However, the hostname should be set in /etc/conf.d/hostname, |
| 65 |
> or netifrc(?). |
| 66 |
|
| 67 |
I think the /hostname/ is completely independent of anything network |
| 68 |
interface related. So, /etc/conf.d/hostname. |
| 69 |
|
| 70 |
Aside: This also touches on the strong vs weak host model and what the |
| 71 |
interfaces & names belong to. Linux by default uses the weak host model |
| 72 |
where IPs and interfaces belong to the system (thus any interface). |
| 73 |
|
| 74 |
> Right, the topic has been (re)visited a number of times. I wonder |
| 75 |
> what has brought about the hosts file syntax in the current version |
| 76 |
> of the Handbook. |
| 77 |
|
| 78 |
Inquiring minds.... |
| 79 |
|
| 80 |
> Perhaps it is time to file a bug to propose a way forward both on the |
| 81 |
> Handbook and the Wiki pages to ensure network configuration remains |
| 82 |
> consistent across the documentation. |
| 83 |
|
| 84 |
Perhaps. |
| 85 |
|
| 86 |
I do appreciate the sanity check on my logic, and the result of my logic. |
| 87 |
|
| 88 |
Thank you for the discussion Michael. :-) |
| 89 |
|
| 90 |
|
| 91 |
|
| 92 |
-- |
| 93 |
Grant. . . . |
| 94 |
unix || die |
Archives