On 11/01/2024 10:19, Greg Wooledge wrote:
On Thu, Jan 11, 2024 at 10:10:43AM +0700, Max Nikulin wrote:
On 11/01/2024 03:25, Greg Wooledge wrote:
On Wed, Jan 10, 2024 at 07:19:41PM +0000, Rodolfo Medina wrote:
Greg Wooledge <g...@wooledge.org> writes:
What is the output of "grep -F $(hostname) /etc/hosts"?
127.0.1.1 caterina-thinkpad.home caterina-thinkpad
I would say that it is better to fix discrepancy between (likely)
/etc/hostname and /etc/hosts and to use a consistent name. If "thinkpad" is
the preferred one then update /etc/hosts otherwise check
I wouldn't
want to assume that nothing is using the name "caterina-thinkpad", so it
would be wise to retain it.
A fair point. Adding FQDN and "thinkpad" before existing names should be
better. I would still try to find and fix existing occurrences of the
old name
grep -r caterina-thinkpad /etc
or even "grep -R"
Also, for the love of glob, WHY THE SYSTEMD bullshit... you change the
hostname on Debian by editing the /etc/hostname file, and then by
running the "hostname" command as root with the new name as its
argument (or rebooting).
I don't know why "hostnamectl" even exists as a concept. It's repulsive.
It also fails to be init-system-agnostic, with no upside to compensate.
I assume that systemd is the default, otherwise the chance that the user
knows lower level commands is higher. hostnamectl changes both the
/etc/hostname file and kernel runtime state, so it ensures consistent
configuration. Moreover, I expect that more services using hostname are
notified and will not use the stale name. Candidates may be (while I am
unsure if it really applicable) bluetoothd, multicast DNS responder for
names and service discovery queries, and perhaps more.
Perhaps hostname was changed from GUI and it is similar to hostnamectl.
