F37 proposal: Fallback Hostname (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/FallbackHostname

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
This proposal is for the fallback hostname for server like variants of
Fedora to use `localhost` as the fallback hostname.

== Owner ==
* Name: [[User:dustymabe| Dusty Mabe]] (Fedora CoreOS)
* Email: dustymabe(a)redhat.com
* Name: [[User:davdunc| David Duncan]] (Fedora Cloud)
* Email: davdunc(a)gmail.com
* Name: [[User:pwhalen| Paul Whalen]] (Fedora IoT)
* Email: pwhalen(a)redhat.com
* Name: [[User:salimma| Michel Alexandre Salim]] (Fedora Server)
* Email: michel(a)michel-slm.name
* Name: [[User:ngompa| Neal Gompa]] (Fedora Workstation/KDE)
* Email: ngompa13(a)gmail.com


== Detailed Description ==

In Fedora 33 the default fallback hostname was changed from
`localhost` to `fedora` for Fedora Linux instances that didn't get the
hostname set in any other way (i.e. it's the fallback if it's not set
anywhere else). This change came in a systemd update and was never
proposed as a change in Fedora itself.

The enablement upstream was in
https://github.com/systemd/systemd/pull/5175 and the BZ requesting the
change in Fedora was
https://bugzilla.redhat.com/show_bug.cgi?id=1392925. The original
reasoning being that `localhost` is a bad hostname for auto-discovery
protocols (think `avahi`) that are useful for more desktop
applications.

Unfortunately, this caused issues because setting the hostname via
reverse DNS lookups (via NetworkManager) stopped working along with
breaking third party tools that set the hostname. The NetworkManager
problem was subsequently fixed, but it still remains that a lot of
third party software will check to see if an instance's hostname is
"unset" by checking the current hostname against the string
"localhost". Additionally it appears this change will never be picked
up by Fedora's primary downstream in CentOS/RHEL (see
https://src.fedoraproject.org/rpms/systemd/c/13d1341b108a24d13f5922054307...).

The proposal here is to enable variants of Fedora Linux to configure
their default/fallback hostname and to set the default for variants
targetting servers (Cloud, CoreOS, IoT, Server) to `localhost`.


== Benefit to Fedora ==
With this change Fedora's server-like variants will become more
compatible with third party tools that expect a hostname of
`localhost` means the system is unconfigured. It also will mean system
administrator's will see `localhost` and assume the hostname is
unconfigured.

== Scope ==
* Proposal owners:
The feature owners will update the systemd compile time switch for
fallback hostname back to `localhost`. The `fedora-release` package
will be updated such that the Fedora Server, IoT, Cloud, and CoreOS
editions will use `localhost` as the fallback hostname. All other
variants of Fedora (the ones that target desktop/laptop uses) will
default to `fedora` as the fallback hostname.

The proposed changes are a relatively small amount of a work.


* Other developers:
For any variants other than Cloud, CoreOS, IoT, and Server they will
see no change. Work with QA to verify other editions continue to have
a fallback hostname of `fedora`.

For Cloud, CoreOS, IoT, and Server the default fallback hostname would
be `localhost`.


* Release engineering: No changes needed for release engineering.

* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)

* Alignment with Objectives: N/A

== Upgrade/compatibility impact ==

There will be NO upgrade impact to systems where:

* An admin statically set the hostname
* A hostname was provided to a system via DHCP
* A hostname was found for a system via reverse DNS lookup

In the case where none of the above are true for a system (i.e. a
fallback hostname will be used) the following upgrade impact will be
observed:

* Fedora Cloud: No impact. A booted Fedora Cloud 36 instance has
`/etc/hostname` written by `cloud-init` on first boot.
* Fedora CoreOS: No impact. Already using `localhost` as fallback hostname.
* Fedora IoT: Some impact. The fallback hostname will change from
`fedora` to `localhost` after upgrade.
* Fedora Server: Some impact. The fallback hostname will change from
`fedora` to `localhost` after upgrade.

For Fedora IoT and Fedora Server we will announce the change and
encourage users to statically set a hostname for their machines if
they don't want the change in behavior.


== How To Test ==

Boot an instance of the flavor of Fedora you are testing in an
environment where there is no DHCP hostname provided and no answer to
a reverse DNS lookup for the instance IP. Run `hostnamectl hostname`
and verify that it matches expectation. For Fedora Cloud, CoreOS, IoT,
Server it should be `localhost`. For all others it should be `fedora`.

== User Experience ==
For Cloud, CoreOS, IoT and Server users will notice intances now
default to `localhost` if a hostname is not provided to an instance by
any other means. For all other variants of Fedora there will be no
change.

== Dependencies ==
There will be changes to the `systemd` and `fedora-release` packages
for this change.


== Contingency Plan ==
* Contingency mechanism: Revert the pull requests to the `systemd` and
`fedora-release` packages.
* Contingency deadline: Final Freeze
* Blocks release? Yes


== Documentation ==
The fallback hostname has now changed to `localhost` for the Cloud,
CoreOS, IoT, and Server variants of Fedora.

== Release Notes ==
The fallback hostname has now changed for the Cloud, CoreOS, IoT, and
Server editions of Fedora to `localhost`. The fallback hostname is the
hostname that is set if the hostname cannot be determined by any other
mechanism (statically set, DHCP, or reverse DNS). This change was done
in order to conform to the common expectation that a hostname of
`localhost` on a system means the hostname is "unset".


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jun 02, 2022 at 03:27:43PM -0400, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/FallbackHostname
>  The proposal here is to enable variants of Fedora Linux to configure
>  their default/fallback hostname and to set the default for variants
>  targetting servers (Cloud, CoreOS, IoT, Server) to `localhost`.
>  
>  
>  == Benefit to Fedora ==
>  With this change Fedora's server-like variants will become more
>  compatible with third party tools that expect a hostname of
>  `localhost` means the system is unconfigured. It also will mean system
>  administrator's will see `localhost` and assume the hostname is
>  unconfigured. 
I'm a bit sad. This is giving in to crappy software. In particular if
you do actually configure the hostname as localhost, this software will
still assume that the hostname is unconfigured. But maybe it's easier to
accept that than to fight it :(

Zbyszek

[Neal Gompa]

On Fri, Jun 10, 2022 at 3:55 PM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
>  On Thu, Jun 02, 2022 at 03:27:43PM -0400, Ben Cotton wrote:
>  > https://fedoraproject.org/wiki/Changes/FallbackHostname
>  > The proposal here is to enable variants of Fedora Linux to configure
>  > their default/fallback hostname and to set the default for variants
>  > targetting servers (Cloud, CoreOS, IoT, Server) to `localhost`.
>  >
>  >
>  > == Benefit to Fedora ==
>  > With this change Fedora's server-like variants will become more
>  > compatible with third party tools that expect a hostname of
>  > `localhost` means the system is unconfigured. It also will mean system
>  > administrator's will see `localhost` and assume the hostname is
>  > unconfigured.
>
>  I'm a bit sad. This is giving in to crappy software. In particular if
>  you do actually configure the hostname as localhost, this software will
>  still assume that the hostname is unconfigured. But maybe it's easier to
>  accept that than to fight it :(
>  
The problem is that the hostname is never unique. If it was, then we
wouldn't be in this mess.

openSUSE uses a randomly generated suffix for default hostnames, which
neatly solves this problem. It makes autodiscovery and other things
actually work properly. As it is, having just "fedora" breaks too much
stuff. If it was "fedora-XXXXX", then we could probably keep it.

At least everything knows to ignore "localhost" properly.




--
真実はいつも一つ！/ Always, there's only one truth!

[Matthew Miller]

On Thu, Jun 02, 2022 at 03:27:43PM -0400, Ben Cotton wrote:
>  The enablement upstream was in
>  https://github.com/systemd/systemd/pull/5175 and the BZ requesting the
>  change in Fedora was
>  https://bugzilla.redhat.com/show_bug.cgi?id=1392925. The original
>  reasoning being that `localhost` is a bad hostname for auto-discovery
>  protocols (think `avahi`) that are useful for more desktop
>  applications. 
In retrospect, that pretty clearly should have gone through the system-wide
change process. Oh well.

I'm not fond of "fedora" as the default hostname — leaving aside my
"Fedora
is the _project_" windmill-tilting, it's just not likely to be unique. But I
think this proposal (which includes just keeping that) is reasonable enough
for now.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Matthew Miller]

On Fri, Jun 10, 2022 at 04:01:03PM -0400, Neal Gompa wrote:
>  openSUSE uses a randomly generated suffix for default hostnames,
> which
>  neatly solves this problem. It makes autodiscovery and other things
>  actually work properly. As it is, having just "fedora" breaks too much
>  stuff. If it was "fedora-XXXXX", then we could probably keep it. 
How do they implement this? I wonder if it would make sense to have
systemd-hostname understand some character like # (which isn't valid in
hostnames) in DEFAULT_HOSTNAME to be replaced with a random number seeded
from the machine-id?


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Neal Gompa]

On Mon, Jun 13, 2022 at 2:10 PM Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Fri, Jun 10, 2022 at 04:01:03PM -0400, Neal Gompa wrote:
>  > openSUSE uses a randomly generated suffix for default hostnames, which
>  > neatly solves this problem. It makes autodiscovery and other things
>  > actually work properly. As it is, having just "fedora" breaks too much
>  > stuff. If it was "fedora-XXXXX", then we could probably keep it.
>
>  How do they implement this? I wonder if it would make sense to have
>  systemd-hostname understand some character like # (which isn't valid in
>  hostnames) in DEFAULT_HOSTNAME to be replaced with a random number seeded
>  from the machine-id?
>  
YaST generates a linux-XXXX hostname when you install it. The "XXXX"
string is alphanumeric.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Neal Gompa]

On Mon, Jun 13, 2022 at 2:11 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Mon, Jun 13, 2022 at 2:10 PM Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  >
>  > On Fri, Jun 10, 2022 at 04:01:03PM -0400, Neal Gompa wrote:
>  > > openSUSE uses a randomly generated suffix for default hostnames, which
>  > > neatly solves this problem. It makes autodiscovery and other things
>  > > actually work properly. As it is, having just "fedora" breaks too
> much
>  > > stuff. If it was "fedora-XXXXX", then we could probably keep it.
>  >
>  > How do they implement this? I wonder if it would make sense to have
>  > systemd-hostname understand some character like # (which isn't valid in
>  > hostnames) in DEFAULT_HOSTNAME to be replaced with a random number seeded
>  > from the machine-id?
>  >
>
>  YaST generates a linux-XXXX hostname when you install it. The "XXXX"
>  string is alphanumeric.
>  
Also, yeah, I think if systemd-hostname could do something like that,
we could do that instead of forcing localhost.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Matthew Miller]

On Mon, Jun 13, 2022 at 02:09:35PM -0400, Matthew Miller wrote:
>  How do they implement this? I wonder if it would make sense to have
>  systemd-hostname understand some character like # (which isn't valid in
>  hostnames) in DEFAULT_HOSTNAME to be replaced with a random number seeded
>  from the machine-id? 

Zbyszek, do you think we could get something like this into upstream
systemd?

We used to ask about it in the installer, and then maybe also initial setup.
But in the interest of asking fewer questions, we don't anymore. I can see
the argument either way.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Peter Boy]

>  Am 13.06.2022 um 20:15 schrieb Neal Gompa
> <ngompa13(a)gmail.com&gt;:
>  
>  On Mon, Jun 13, 2022 at 2:11 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
> > 
> > ...
> > YaST generates a linux-XXXX hostname when you install it. The "XXXX"
> > string is alphanumeric.
> > 
>  
>  Also, yeah, I think if systemd-hostname could do something like that,
>  we could do that instead of forcing localhost.
>   
One big argument pro change proposal was resp. is, that many tools recognise localhost as
unconfigured and don’t work anymore when you change to something different. 

Doesn't a change to linux-xxxx contradict the original rationale pro the change
proposal?

[Matthew Miller]

On Mon, Jun 13, 2022 at 09:38:01PM +0200, Peter Boy wrote:
>  >> YaST generates a linux-XXXX hostname when you install it.
> The "XXXX"
>  >> string is alphanumeric.
>  >> 
>  > 
>  > Also, yeah, I think if systemd-hostname could do something like that,
>  > we could do that instead of forcing localhost.
>  
>  One big argument pro change proposal was resp. is, that many tools
>  recognise localhost as unconfigured and don’t work anymore when you change
>  to something different.
>  
>  Doesn't a change to linux-xxxx contradict the original rationale pro the change
> proposal? 
My take is: a freshly- but fully-installed Fedora Server or Fedora
Workstation system _shouldn't_ be "unconfigured". It should be basically
ready to go. And it's ideal of we can get to that state without asking a
litany of questions.

For Fedora Server, it may be that "configure your DNS" is actually part of
what's expected. But for Fedora Workstation, that's probably not reasonable
— lots of laptops which move networks, etc.


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Peter Boy]

>  Am 13.06.2022 um 22:12 schrieb Matthew Miller
> <mattdm(a)fedoraproject.org&gt;:
>  
>  On Mon, Jun 13, 2022 at 09:38:01PM +0200, Peter Boy wrote:
> >>> YaST generates a linux-XXXX hostname when you install it. The
> "XXXX"
> >>> string is alphanumeric.
> >>> 
> >> 
> >> Also, yeah, I think if systemd-hostname could do something like that,
> >> we could do that instead of forcing localhost.
> > 
> > One big argument pro change proposal was resp. is, that many tools
> > recognise localhost as unconfigured and don’t work anymore when you change
> > to something different.
> > 
> > Doesn't a change to linux-xxxx contradict the original rationale pro the change
> proposal?
>  
>  My take is: a freshly- but fully-installed Fedora Server or Fedora
>  Workstation system _shouldn't_ be "unconfigured". It should be basically
>  ready to go. And it's ideal of we can get to that state without asking a
>  litany of questions. 
Agreed. This has long been one of Fedora's strengths compared to other distributions.


However, the initiators of the change proposal (almost?) all come from server type
variants, especially cloud. On the one hand, they want the option to configure via DHCP
back again, and on the other hand, they want the option to explicitly leave the hostname
„unconfigured“ = "localhost", because this triggers various post-installation
tools that automatically adapt post-installation tasks to adapt the system to different
runtime environments. The unconfigured hostname thus paradoxically becomes practically
part of a fully configured installed system.  

At least that is how I understood our discussion.


>  For Fedora Server, it may be that "configure your DNS" is
> actually part of
>  what's expected. But for Fedora Workstation, that's probably not reasonable
>  — lots of laptops which move networks, etc. 

Yes, for desktops und specifically laptops an unkonfigured hostname is generally bad. But,
the current situation having a network with dozens of Workstation all named fedora is
similarly bad as all named localhost (before the switch to fedora). 

So we might have to handle this differently for desktop type and server type systems.

[Matthew Miller]

On Mon, Jun 13, 2022 at 11:08:21PM +0200, Peter Boy wrote:
>  So we might have to handle this differently for desktop type and
> server
>  type systems. 
I think the key difference is whether basic configuration is
expected as part of Anaconda, or whether there's a further configuration
step. The first approach is common for individual desktop or server
installs. But the latter is common for image-based installs -- whether it be
Fedora IoT or a server VM or cloud image, or a pre-installed desktop.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jun 13, 2022 at 04:12:49PM -0400, Matthew Miller wrote:
>  On Mon, Jun 13, 2022 at 09:38:01PM +0200, Peter Boy wrote:
>  > >> YaST generates a linux-XXXX hostname when you install it. The
> "XXXX"
>  > >> string is alphanumeric.
>  > > 
>  > > Also, yeah, I think if systemd-hostname could do something like that,
>  > > we could do that instead of forcing localhost. 
That sounds like it would be very simple to implement.

This could be a useful feature, e.g. I'd finally be able to distuinguish
all my fedora VMs without figuring out unique names for them.

>  > One big argument pro change proposal was resp. is, that many
> tools
>  > recognise localhost as unconfigured and don’t work anymore when you change
>  > to something different.
>  > 
>  > Doesn't a change to linux-xxxx contradict the original rationale pro the change
> proposal? 
And this is the hard part: the question is whether those … subpar tools
that hardcode "localhost" will be happy with anything else.

(For people who are not familiar with the backstory: we now have an
D-Bus API where you can query the hostname but also the origin of that
configuration: static/transient/default).

>  My take is: a freshly- but fully-installed Fedora Server or Fedora
>  Workstation system _shouldn't_ be "unconfigured". It should be basically
>  ready to go. And it's ideal of we can get to that state without asking a
>  litany of questions.
>  
>  For Fedora Server, it may be that "configure your DNS" is actually part of
>  what's expected. But for Fedora Workstation, that's probably not reasonable
>  — lots of laptops which move networks, etc. 
Zbyszek

[Peter Boy]

>  Am 14.06.2022 um 06:25 schrieb Matthew Miller
> <mattdm(a)fedoraproject.org&gt;:
>  
>  On Mon, Jun 13, 2022 at 11:08:21PM +0200, Peter Boy wrote:
> > So we might have to handle this differently for desktop type and server
> > type systems.
>  
>  I think the key difference is whether basic configuration is
>  expected as part of Anaconda, or whether there's a further configuration
>  step. The first approach is common for individual desktop or server
>  installs. But the latter is common for image-based installs -- whether it be
>  Fedora IoT or a server VM or cloud image, or a pre-installed desktop. 
Given that cloud-init, for example, can configure a system as fine-grained as Anaconda, I
think it's more about whether a system is running in a managed or unmanaged
environment.

Practically more important seems to me that Anaconda on the workstation live medium is so
reduced that you can configure neither the network nor a hostname (only keyboard, storage
medium and time zone). Therefore, we need to configure a plausible default hostname on
desktops anyways, and the Change Proposal is for server type systems only.

And with server type systems, perhaps we can assume that system administrators knows what
they are doing?

[Neal Gompa]

On Tue, Jun 14, 2022 at 6:53 AM Peter Boy <pboy(a)uni-bremen.de&gt; wrote:
>  > Am 14.06.2022 um 06:25 schrieb Matthew Miller <mattdm(a)fedoraproject.org&gt;:
>  >
>  > On Mon, Jun 13, 2022 at 11:08:21PM +0200, Peter Boy wrote:
>  >> So we might have to handle this differently for desktop type and server
>  >> type systems.
>  >
>  > I think the key difference is whether basic configuration is
>  > expected as part of Anaconda, or whether there's a further configuration
>  > step. The first approach is common for individual desktop or server
>  > installs. But the latter is common for image-based installs -- whether it be
>  > Fedora IoT or a server VM or cloud image, or a pre-installed desktop.
>
>  Given that cloud-init, for example, can configure a system as fine-grained as Anaconda, I
> think it's more about whether a system is running in a managed or unmanaged
> environment.
>
>  Practically more important seems to me that Anaconda on the workstation live medium is so
> reduced that you can configure neither the network nor a hostname (only keyboard, storage
> medium and time zone). Therefore, we need to configure a plausible default hostname on
> desktops anyways, and the Change Proposal is for server type systems only.
>
>  And with server type systems, perhaps we can assume that system administrators knows what
> they are doing?
>  
In my experience, this statement is so rarely true (in terms of
understanding the full consequences of choices and defaults) that it's
a bad cop-out. Anaconda does not require you to set a hostname as part
of installation. Since it does not require that, having a decent
fallback hostname is useful. The problem is that when you have
multiple machines with the same hostname, WINS/DNS and mDNS are
completely unusable.

This Change originally came out of Fedora CoreOS, where OpenShift
couldn't tolerate machines with the "fedora" hostname[1]. The problem
is that the machine-config-operator doesn't know how to handle
fallback hostnames *at all* and has hard coded logic to fix the
hostname only if it's "localhost". The operator's logic has not been
fixed to determine whether the machine's hostname is a fallback
hostname (and thus eligible to be reconfigured). If there was an easy
way for the operator code to determine that we're running with the
fallback hostname so that it knows to replace it, that would allow
OpenShift folks to fix the problem on their end.

I would be happy to withdraw this Change if we had solutions to these
problems, because from a Fedora Cloud perspective, we basically nearly
never hit the fallback case except for Vagrant (where it makes sense
to have it trigger). For desktops, we'd prefer to have the fallback
hostname be "fedora", but fixing it so that a randomly generated
string is appended would make it work properly in the multi-machine
home network case (which is commonplace these days).

[1]: https://github.com/coreos/fedora-coreos-tracker/issues/649



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Peter Boy]

>  Am 14.06.2022 um 13:13 schrieb Neal Gompa
> <ngompa13(a)gmail.com&gt;:
>  
>  On Tue, Jun 14, 2022 at 6:53 AM Peter Boy <pboy(a)uni-bremen.de&gt; wrote:
> > 
> > 
> > 
> > 
> > And with server type systems, perhaps we can assume that system administrators knows
> what they are doing?
> > 
>  
>  In my experience, this statement is so rarely true (in terms of
>  understanding the full consequences of choices and defaults) that it's
>  a bad cop-out. Anaconda does not require you to set a hostname as part
>  of installation. Since it does not require that, having a decent
>  fallback hostname is useful. The problem is that when you have
>  multiple machines with the same hostname, WINS/DNS and mDNS are
>  completely unusable. 

If I try to summarise all the comments and discussions, the change proposal, as it is, is
not perfect. But each participant can be happy with the resulting configuration.

- desktops, because nothing changes for them
- cloud, they use cloud-init to configure hostname anyway on first boot with the exception
of vagrant, where localhost can be useful
- CoreOS, use localhost already, but it resolves the OpenShift issue
- IoT, may have so set hostname explicitly, but don’t have any objection 
- Server, usually set hostname explicitly according to some local naming convention or use
DHCP/revers DNS, gain the option to use some post-installation tools, and otherwise don’t
care anyway or doesn’t matter if it is fedora or localhost

So, it is fine to go with it.

>  For desktops, we'd prefer to have the fallback
>  hostname be "fedora", but fixing it so that a randomly generated
>  string is appended would make it work properly in the multi-machine
>  home network case (which is commonplace these days). 
Attaching a somehow generated unique string would be really an improvement. But that would
be another Change Proposal, maybe for F38.

This would affect desktops in particular. All others should be given the option to switch
to this unique default or to leave it at localhost. 

I think for servers a unique default would be useful, especially for a bulk creation of
server VMs in an un-managed environment. But we would have to change the default naming of
the first Volume Group from fedora_{hostname} to something like fedora_system to avoid a
too complex VG naming.

[Matthew Miller]

On Tue, Jun 14, 2022 at 12:53:19PM +0200, Peter Boy wrote:
>  Given that cloud-init, for example, can configure a system as
> fine-grained
>  as Anaconda, I think it's more about whether a system is running in a
>  managed or unmanaged environment. 
As I understand it, it's about the "hand off" between initial install and
the second step, whatever that might be (cloud-init, ignition, GNOME initial
setup).


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Matthew Miller]

On Tue, Jun 14, 2022 at 03:41:14PM +0200, Peter Boy wrote:
>  If I try to summarise all the comments and discussions, the change
> proposal, as it is, is not perfect. But each participant can be happy with the resulting
> configuration.
>  
>  - desktops, because nothing changes for them
>  - cloud, they use cloud-init to configure hostname anyway on first boot with the
> exception of vagrant, where localhost can be useful
>  - CoreOS, use localhost already, but it resolves the OpenShift issue
>  - IoT, may have so set hostname explicitly, but don’t have any objection 
>  - Server, usually set hostname explicitly according to some local naming convention or
> use DHCP/revers DNS, gain the option to use some post-installation tools, and otherwise
> don’t care anyway or doesn’t matter if it is fedora or localhost
>  
>  So, it is fine to go with it.
>  
>  > For desktops, we'd prefer to have the fallback
>  > hostname be "fedora", but fixing it so that a randomly generated
>  > string is appended would make it work properly in the multi-machine
>  > home network case (which is commonplace these days).
>  
>  Attaching a somehow generated unique string would be really an improvement. But that
> would be another Change Proposal, maybe for F38.
>  
>  This would affect desktops in particular. All others should be given the option to switch
> to this unique default or to leave it at localhost. 
>  
>  I think for servers a unique default would be useful, especially for a bulk creation of
> server VMs in an un-managed environment. But we would have to change the default naming of
> the first Volume Group from fedora_{hostname} to something like fedora_system to avoid a
> too complex VG naming.  
Agree to all of this. Thanks for the summary!

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Neal Gompa]

On Tue, Jun 14, 2022 at 10:29 AM Matthew Miller
<mattdm(a)fedoraproject.org&gt; wrote:
>  On Tue, Jun 14, 2022 at 12:53:19PM +0200, Peter Boy wrote:
>  > Given that cloud-init, for example, can configure a system as fine-grained
>  > as Anaconda, I think it's more about whether a system is running in a
>  > managed or unmanaged environment.
>
>  As I understand it, it's about the "hand off" between initial install and
>  the second step, whatever that might be (cloud-init, ignition, GNOME initial
>  setup).
>  
GNOME Initial Setup does not offer the ability to set your computer
name. I'm not sure why given that both Windows and Mac do to ensure
things work properly on a network, but it's not a thing with GNOME's
initial setup wizard.


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Michael Catanzaro]

On Tue, Jun 14 2022 at 10:42:59 AM -0400, Neal Gompa 
<ngompa13(a)gmail.com&gt; wrote:
>  GNOME Initial Setup does not offer the ability to set your computer
>  name. I'm not sure why given that both Windows and Mac do to ensure
>  things work properly on a network, but it's not a thing with GNOME's
>  initial setup wizard. 
I think we should add this.

However, gnome-initial-setup is a bit late because currently anaconda 
uses hostname to name your btrfs subvolumes. :(

anaconda would perhaps be a better place, but only if it uses hostnamed 
so as to allow spaces, Unicode, etc. We don't want anaconda to use 
stricter rules for hostnames than the installed system does.

Michael

[Dusty Mabe]

On 6/13/22 14:15, Neal Gompa wrote:
>  On Mon, Jun 13, 2022 at 2:11 PM Neal Gompa <ngompa13(a)gmail.com&gt;
> wrote:
> >
> > On Mon, Jun 13, 2022 at 2:10 PM Matthew Miller <mattdm(a)fedoraproject.org&gt;
> wrote:
> >>
> >> On Fri, Jun 10, 2022 at 04:01:03PM -0400, Neal Gompa wrote:
> >>> openSUSE uses a randomly generated suffix for default hostnames, which
> >>> neatly solves this problem. It makes autodiscovery and other things
> >>> actually work properly. As it is, having just "fedora" breaks too
> much
> >>> stuff. If it was "fedora-XXXXX", then we could probably keep it.
> >>
> >> How do they implement this? I wonder if it would make sense to have
> >> systemd-hostname understand some character like # (which isn't valid in
> >> hostnames) in DEFAULT_HOSTNAME to be replaced with a random number seeded
> >> from the machine-id?
> >>
> >
> > YaST generates a linux-XXXX hostname when you install it. The "XXXX"
> > string is alphanumeric.
> >
>  
>  Also, yeah, I think if systemd-hostname could do something like that,
>  we could do that instead of forcing localhost. 
I agree that having a template like linux-XXXX that could be substituted
in would be useful and I think we should probably do that for all variants
that will stick with the existing fallback hostname today. Maybe in a followup
change proposal?

I don't think that fixes all concerns that are embedded in this proposal, though.

Dusty

[Dusty Mabe]

On 6/14/22 07:13, Neal Gompa wrote:
>  On Tue, Jun 14, 2022 at 6:53 AM Peter Boy <pboy(a)uni-bremen.de&gt;
> wrote:
> >
> >
> >
> >> Am 14.06.2022 um 06:25 schrieb Matthew Miller <mattdm(a)fedoraproject.org&gt;:
> >>
> >> On Mon, Jun 13, 2022 at 11:08:21PM +0200, Peter Boy wrote:
> >>> So we might have to handle this differently for desktop type and server
> >>> type systems.
> >>
> >> I think the key difference is whether basic configuration is
> >> expected as part of Anaconda, or whether there's a further configuration
> >> step. The first approach is common for individual desktop or server
> >> installs. But the latter is common for image-based installs -- whether it be
> >> Fedora IoT or a server VM or cloud image, or a pre-installed desktop.
> >
> > Given that cloud-init, for example, can configure a system as fine-grained as
> Anaconda, I think it's more about whether a system is running in a managed or
> unmanaged environment.
> >
> > Practically more important seems to me that Anaconda on the workstation live medium
> is so reduced that you can configure neither the network nor a hostname (only keyboard,
> storage medium and time zone). Therefore, we need to configure a plausible default
> hostname on desktops anyways, and the Change Proposal is for server type systems only.
> >
> > And with server type systems, perhaps we can assume that system administrators knows
> what they are doing?
> >
>  
>  In my experience, this statement is so rarely true (in terms of
>  understanding the full consequences of choices and defaults) that it's
>  a bad cop-out. Anaconda does not require you to set a hostname as part
>  of installation. Since it does not require that, having a decent
>  fallback hostname is useful. The problem is that when you have
>  multiple machines with the same hostname, WINS/DNS and mDNS are
>  completely unusable.
>  
>  This Change originally came out of Fedora CoreOS, where OpenShift
>  couldn't tolerate machines with the "fedora" hostname[1]. The problem
>  is that the machine-config-operator doesn't know how to handle
>  fallback hostnames *at all* and has hard coded logic to fix the
>  hostname only if it's "localhost". The operator's logic has not been
>  fixed to determine whether the machine's hostname is a fallback
>  hostname (and thus eligible to be reconfigured). If there was an easy
>  way for the operator code to determine that we're running with the
>  fallback hostname so that it knows to replace it, that would allow
>  OpenShift folks to fix the problem on their end. 
I think the OpenShift example is a good example of a class of problems. If
I thought we'd never hit this problem again if we just changed that OpenShift
code then I would go that route instead of this route.
 
>  I would be happy to withdraw this Change if we had solutions to
> these
>  problems, because from a Fedora Cloud perspective, we basically nearly
>  never hit the fallback case except for Vagrant (where it makes sense
>  to have it trigger). For desktops, we'd prefer to have the fallback
>  hostname be "fedora", but fixing it so that a randomly generated
>  string is appended would make it work properly in the multi-machine
>  home network case (which is commonplace these days).
>   
I would still prefer to not withdraw this change. If we could make changes
to make it more likely that a user will set a hostname properly then that
is great and they won't hit the fallback case.

setting initial hostname and volume names

[Matthew Miller]

On Tue, Jun 14, 2022 at 09:50:17AM -0500, Michael Catanzaro wrote:
>  However, gnome-initial-setup is a bit late because currently
>  anaconda uses hostname to name your btrfs subvolumes. :( 
Changing the subject because I've caused the thread to drift from the change
proposal... :)

I don't think hostname is the best choice for volume name anyway. The
initial hostname might change after install --
`fedora_dhcp-192-168-5-45-home` isn't very useful. Let alone the case where
it gets named "fedora_localhost-live"!

Are there other reasons to do it that early? If not, I think maybe the
solution here is to change from using the hostname to using something like
mount point plus a random (first 8 of the UUID?).

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

setting initial hostname and volume names

[Neal Gompa]

On Tue, Jun 14, 2022 at 1:43 PM Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Tue, Jun 14, 2022 at 09:50:17AM -0500, Michael Catanzaro wrote:
>  > However, gnome-initial-setup is a bit late because currently
>  > anaconda uses hostname to name your btrfs subvolumes. :(
>
>  Changing the subject because I've caused the thread to drift from the change
>  proposal... :)
>
>  I don't think hostname is the best choice for volume name anyway. The
>  initial hostname might change after install --
>  `fedora_dhcp-192-168-5-45-home` isn't very useful. Let alone the case where
>  it gets named "fedora_localhost-live"!
>
>  Are there other reasons to do it that early? If not, I think maybe the
>  solution here is to change from using the hostname to using something like
>  mount point plus a random (first 8 of the UUID?).
>  
The name should not be hard to type in a basic terminal, since we don't have
a graphical rescue/recovery environment that makes fancier names not painful.




--
真実はいつも一つ！/ Always, there's only one truth!

[Kamil Paral]

On Tue, Jun 14, 2022 at 4:50 PM Michael Catanzaro <mcatanzaro(a)gnome.org&gt;
wrote:

>  I think we should add this.
>
>  However, gnome-initial-setup is a bit late because currently anaconda
>  uses hostname to name your btrfs subvolumes. :(
>
>  anaconda would perhaps be a better place, but only if it uses hostnamed
>  so as to allow spaces, Unicode, etc. We don't want anaconda to use
>  stricter rules for hostnames than the installed system does.
>  
I think we currently hardcode all live images to have "localhost-live"
hostname in the kickstart, because of some x11 bug a long time ago which
failed with a plain "localhost":
https://pagure.io/fedora-kickstarts/blob/main/f/fedora-live-base.ks#_207

Changing it to "fedora-NNNN" would be great.

[Matthew Miller]

On Wed, Jun 15, 2022 at 02:11:11PM +0200, Kamil Paral wrote:
>  I think we currently hardcode all live images to have
> "localhost-live"
>  hostname in the kickstart, because of some x11 bug a long time ago which
>  failed with a plain "localhost":
>  https://pagure.io/fedora-kickstarts/blob/main/f/fedora-live-base.ks#_207 
Oh, _there's_ some irony!

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader