Split write network and hostname configuration #4870
Conversation
|
A bit of context why this change was made. A derivative of ROSA - MOS (ROSA-based distro for schools) - sets can_configure_network=False by default, because every teacher/student in Moscow schools has a personal password for the local WiFi network. Someone's password was made visible to every user by can_configure_network=True. But we in ROSA generate random hostnames on start of the LiveCD (https://abf.io/import/anaconda/blob/rosa2023.1/anaconda-livecd-init.sh) and then inherit them into the installed system (see also: https://abf.io/import/anaconda/blob/6b6591efa3/0046-Copy-current-hostname-into-installed-system.patch , I think this could also be upstreamized, what do you think?). But without the changes in the PR both a randomly and manually (in the network spoke) set hostname was not copied into the installed system. Setting random hostnames helps to identify machines inside network. |
|
@rvykydal Radku, can you please take a look at this? |
rvykydal
added
the
manual testing required
There was a problem hiding this comment.
I think the split of hostname configuration makes sense.
In the PR can_configure_network still implies can_configure_hostname which seems reasonable and should prevent us from possible breaking of some current use cases.
But I'd prefer to split the hostname configuration from write_configuration completely and call it separately after "Network confgiration" task (if can_configure_network or can_configure_hostname) so we are more clear and explicit in the tasks and logs in what is happening.
pyanaconda/installation.py
Outdated
| ) | ||
| hostname_config.append(Task( | ||
| "Hostname configuration", | ||
| network.network.write_configuration_hostname, |
There was a problem hiding this comment.
Anaconda crashes here, there should be network.write_configuration_hostname
There was a problem hiding this comment.
That's exactly what was done. First, the operation is divided into two functions, and then they are called in turn depending on can_change. Moreover, the formulation of the name configuration task comes just after the network configuration task.
There was a problem hiding this comment.
Anaconda crashes here, there should be
network.write_configuration_hostname
fixed typo :-)
+1 , code flow is not obvious otherwise |
I am afraid making this default behavior would be in conflict with #643 where we stopped using the hostname from installer environment for target system. |
Hm... Commit message there says: "Doing so, the installed system would not use new transient hostname if it boots in different environment". But the current behaviour is to set the same static hostname, but not skip setting it, isn't it? |
|
The script generates a random hostname only if another hostname, including a transient one via DHCP, was not set: |
When the parameter can_configure_network is disabled in the configuration, the file /etc/hostname is not written to the installed system.
temaps
force-pushed
the
write-hostname-configuration
branch
from
7bc60ac
to
432153c
Compare
|
This PR is stale because it has been open 60 days with no activity. |
|
The tests are confused by the name "hostname" (write-hostname-configuration), there don't seem to be any more problems. Is this an obstacle? |
|
This PR is stale because it has been open 60 days with no activity. |
|
This PR was closed because it has been stalled for 30 days with no activity. |
|
manual testing required... |
When the parameter can_configure_network is disabled in the configuration, the file /etc/hostname is not written to the installed system.