Bug 1975349

The references BZ1766944 looks to be introducing the changed behaviour to do the DNS lookup and enforce that value.

For me as an user this is not understandable. If i 'hardcode' the hostname in the Kickstart file then it should use that Hostname and not something dynamic.



Btw. when adding --noipv6 it suddenly works and the hostname is kept on <blah> and not taken from DNS
network --noipv6 --hostname=<blah>

So if I understand the RFE correctly the request is to provide an installer option that would allow to revert the change of behaviour introduced in RHEL 8.4 with bug 1766944.

Which means instead of opting in to the new behaviour (changing the hostname.only-from-default=true default) as proposed in https://bugzilla.redhat.com/show_bug.cgi?id=1766944#c20, the point of the option is to opt out from the new behaviour - the default hostname.only-from-default=false as present in RHEL 8.4 per https://bugzilla.redhat.com/show_bug.cgi?id=1766944#c42.

(Please note that the network --hostname option configures the hostname of target system. Configuration of installer environment has never been guaranteed and IIRC the behavior changed in this aspect in the past. )

The behavior is about the hostname being change to a 'random' value during %post section.
There are many customer dependent installation steps that you want to be done %post that rely on the hostname being already the target hostname.

In the past you could just kill NetworkManager in the post-nochroot and is documented at https://access.redhat.com/solutions/102823


This RFE is to ask that the 'network --hostname=<blah>' is honored to have a for the customer a predictable name without relying on external services (that might be out-of-control of the engineers, e.g. the DNS server is often Windows-AD controlled and without direct access for the Linux teams) to set also during the Kickstart process instead of a random name.

If a new option is preferred i can think of:

network --hostname=<blah> --kickstart-hostname

The '--kickstart-hostname' means that the kickstart process will also be continuing using the hostname


In the end it is about predictability/control for the customer, both the BZ1766944 and this RFE ask for this, only the source of the hostname is different
- BZ1766944 asks for predictability/control of the hostname by asking from DNS
- This RFE asks for predictability/control of the hostname through the kickstart-file
- Backwards/legacy behaviour is keep localhost.localdomain


Did you also check why there is then the difference between using 'network --hostname=<blah>' and 'network --noipv6 --hostname=<blah>'?

*** Bug 1975347 has been marked as a duplicate of this bug. ***

Anaconda is setting installer environment transient hostname to the value configured in kickstart (network --hostname) close to the end of installation, before running the %post scripts.
As also reported in comment #4 this setting is not stable and can be updated by NetworkManager. From my experience, (re-)activation of a network device by Network Manager can update the installer environment hostname. I used this kickstart to reproduce the issue from the Description:

network --hostname myhostname

%post
hostname
nmcli con up ens3
sleep 4
hostname
%end

For RHEL 8 it seems to start to happen in RHEL 8.4 release - the installer environment hostname is updated from address lookup by NM. The description suggests the issue is related to the change in the bug 1766944, but even when configuring NM to disable the change of default behavior in 8.4 by:

[connection]
hostname.only-from-defalut=1

the hostname is still modified from address lookup. Maybe there has been some more fundamental change than the one related to a device having/not having default route. So the option requested in the BZ Description does not seem to resolve the issue from comment #4.

The issue would be fixed by installer setting static hostname instead of transient hostname (as it does in RHEL-7). This patch should do the change:

https://github.com/rhinstaller/anaconda/pull/3627

I've prepared an installer updates image for RHEL 8.4 with the patch for checking the fix, it can be applied by boot option
updates=https://rvykydal.fedorapeople.org/updates.hostname-static-84.img
or by adding kickstart command
updates https://rvykydal.fedorapeople.org/updates.hostname-static-84.img

Also a workaround setting the static hostname at the beginning of the %post section could be used:

%post
hostnamectl --set-hostname $(hostname)
# your post section
%end

(In reply to Peter Vreman from comment #4)

 
> Did you also check why there is then the difference between using 'network
> --hostname=<blah>' and 'network --noipv6 --hostname=<blah>'?

In case of

network --hostname=<blah>

anaconda just configures the hostname.


If there are also options for a network device configuration present in the network command, like --noipv6 in

network --noipv6 --hostname=<blah>

anaconda assumes that also a network device should be configured with default values [1] (eg --device=link, --bootproto=dhcp) and configuration / activation of a network device by NM can trigger hostname update from DNS lookup as described in previous comment.


[1] The documentation has been recently updated with this information, in --hostname option of https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/performing_an_advanced_rhel_installation/kickstart-commands-and-options-reference_installing-rhel-as-an-experienced-user#network_kickstart-commands-for-network-configuration

Updating the BZ title to reflect the resolution proposed in comment #6.

(In reply to Radek Vykydal from comment #6)

> https://github.com/rhinstaller/anaconda/pull/3627

Moving into POST

I found that using the rhsm directive with an activation key in a kickstart, combined with a "network --bootproto=dhcp --hostname=foo" line, results with a system being registered as localhost.localdomain. If the network line has static config, the hostname is set before registration. I'm guessing this is the same issue; will this patch set the hostname prior to registration (which is done before %post scripts)?

If there's a hostname in the kickstart, it should be applied as soon as possible, before taking any action for the to-be-installed system. Multiple things can use the hostname during install - I've seen RPMs with %post scripts that create sample configs for example. Even just building a Linux software RAID set encodes the hostname it was created on.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (anaconda bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:1780