On Fri, Oct 27, 2023 at 02:00:21PM +0000, Andrew M.A. Cater wrote:
> > > On Oct 27, 2023, at 9:05 AM, Greg Wooledge <g...@wooledge.org> wrote:
> > >>> If you're using short-form hostnames like this:
> > >>>
> > >>> unicorn:~$ hostname
> > >>> unicorn
> > >>>
> > >>> then yeah, [/etc/hosts is] all you need. If you're using long-form
> > >>> hostnames
> > >>> (with dots in them), then you also need to configure /etc/hostname.
> > >>>
>
> hostnamectl set-hostname is the command to do it - and will survive a reboot.
"set-hostname" is not included in the list of COMMANDS in hostnamectl(1)
on Debian 12. The only occurrence of this string is in the OPTIONS
section:
--static, --transient, --pretty
If status is invoked (or no explicit command is given) and one of
these switches is specified, hostnamectl will print out just this
selected hostname.
If used with set-hostname, only the selected hostnames will be
updated. When more than one of these switches are specified, all
the specified hostnames will be updated.
which looks very much like "we removed this command from the COMMANDS
section but forgot to update the reference to it in OPTIONS".
What does "hostnamectl set-hostname" or "hostnamectl hostname NAME"
actually *do*? How does its action "survive a reboot"? Does it
modify the /etc/hostname file for you? Or does it use some other
systemd-specific information storage mechanism? If it's the latter,
then *where* is it, and how is a conflict between /etc/hostname and
the systemd-specific storage mechanism resolved?
More importantly, why on earth would this be recommended over editing
the /etc/hostname file, which is *much* simpler, and which appears to
be independent of the init system that's in use?
