Bug 1963834

In the associated case we found that the reproducer kickstart file the '--noipv6' shall be removed, because with that bond0 would be taken as active-link device and anaconda will force DHCP on it although that will not work because there is no untagged VLAN to the device. The result is that the bond0 dhcp times out after 45 seconds and networkmanager takes it down bond0 including the working vlan209. Honestly i doubt that behaviour is even correct. If the untagged bond0 is not working then the child VLANs can still be working valid.

The additonal info regression was that it worked with RHEL8.2 and RHEL7.x. Checking the log files i noticed that there is a massive rewrite between RHEL8.2 and RHEL8.3/8.4 in creating the ifcfg files, in RHEL8.2 it was created by dracut scripts directly, in RHEL8.4 it is all written by Networkmanager

If the point of the network command in kickstart file is just to configure hostname, there should contain just the --hostname option and --noipv6 should be removed.

If there are also other options then --hostname in the network command, Anaconda considers the command as a request to configure the device with implicit "--device link" specification, which means the first device with link (can be resolved to bond0 as in the case of this BZ). The option was targeted to environments with just single device being connected (having carrier) so that the device does not have to be known / specified for configuration via kickstart.

Radek,

i already got the feedback that the --noipv6 had to be removed. But where is this feature documented that 'network --hostname <hostname>' is handled differently?

Second i opened yesterday another case where the 'network --hostname <hostname>' is breaking another use case i have where the network interface is now doing a DHCP/DNS lookup to get its hostname from DNS for that interface although i explcitly defined the hostname to be used.


Peter

(In reply to Peter Vreman from comment #5)
> Radek,
> 
> i already got the feedback that the --noipv6 had to be removed. But where is
> this feature documented that 'network --hostname <hostname>' is handled
> differently?

Good point, I think it is not documented and should be added to installation guide / kickstart reference (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/performing_an_advanced_rhel_installation/index/#network_kickstart-commands-for-network-configuration). What do you think Jan?

Yes, I agree with documenting the network --hostname behavior.

Bilhar, could you please have a look at comment 4 and add a note to the installation guide?

PR with port of the patch from the description: https://github.com/rhinstaller/anaconda/pull/3441

Closing this BZ as the updated content is now published on the customer portal:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/performing_an_advanced_rhel_installation/index#network_kickstart-commands-for-network-configuration

We still want to apply https://github.com/rhinstaller/anaconda/pull/3441 as a resolution of this BZ.

Feedback on the improvements:

I looked at the new text and i miss in the second paragraph 'with additonal options' what is going to be done with the value provided to 'hostname', how/where/when is it going to be used when 'network command configures a device using the options specified' is being applied?

~~~
If you only want to configure the target system’s host name, use the --hostname option in the network command and do not include any other option.

If you provide additional options when configuring the host name, the network command configures a device using the options specified. If you do not specify which device to configure using the --device option, the default --device link value is used. Additionally, if you do not specify the protocol using the --bootproto option, the device is configured to use DHCP by default.
~~~



The statement a bit lower about FQDN is not 100% correct and conflicts with SAP requirements of requiring a short hostname:
~~~
If your network does not provide a DHCP service, always use the FQDN as the system’s host name.
~~~

(In reply to Peter Vreman from comment #20)
> Feedback on the improvements:
> 
> I looked at the new text and i miss in the second paragraph 'with additonal
> options' what is going to be done with the value provided to 'hostname',
> how/where/when is it going to be used when 'network command configures a
> device using the options specified' is being applied?

It should work exactly the same as if only hostname is configured (the first paragraph of the --hostname option section) regarding the hostname configuration of the target system - which is the purpose of network --hostname command.

It seems that regarding the installer environment hostname the situation is different when a network device is re-activated (can happen for the second paragraph below) which might cause for example update of the current hostname by NM from dns (perhaps something you are commenting / hitting in bug 1975349). Still the value of such updated hostname is not related to the value of network --hostname command.
We may need to update the documentation with regard to hostname of installer environment but I am afraid the behaviour has not been scrictly specified or guaranteed. Maybe we can describe the current behaviour and consider RFE from https://bugzilla.redhat.com/show_bug.cgi?id=1975349#c4

> 
> ~~~
> If you only want to configure the target system’s host name, use the
> --hostname option in the network command and do not include any other option.
> 
> If you provide additional options when configuring the host name, the
> network command configures a device using the options specified. If you do
> not specify which device to configure using the --device option, the default
> --device link value is used. Additionally, if you do not specify the
> protocol using the --bootproto option, the device is configured to use DHCP
> by default.
> ~~~

Radek,

My feedback was on the Documentation only. I split on purpose requests to different BZs
Honestly the documentation of 'network --hostname' also does not belong in this BZ about VLAN and Bonding

The fix for the BZ shall be https://github.com/rhinstaller/anaconda/pull/3441
I can confirm that the PR3441 fixes it, i already implemented it as a temporary workaround in the %pre using a sed-command.




Back to the documentation as we were on that topic also. Just adding a small remark that also the hostname will be set would be enough for me
~~~
If you provide additional options when configuring the host name, the network command configures a device using the options specified.
~~~

to 

~~~
If you provide additional options when configuring the host name, the network command configures ___the hostname and___ device using the options specified.
~~~


I also personally like to look at reference examples what is working and what not:

Maybe also an example might work, e.g. can you do split on several lines or combine it.
~~~
network --hostname blah
network --device ens192 --bootproto=x ...
~~~
is the same as
~~~
network --hostname blah --device ens192 --bootproto=x ...
~~~

And how does --hostname work (or fail) if multiple devices with multiple hostnames are set:
~~~
network --hostname blah.example.com --device ens192 --bootproto=x ...
network --hostname blah-management.example.com --device ens256 --bootproto=x ...
~~~

I am not asking for any code change. This feedback is only provided to improve the documentation on the behaviour

(In reply to Peter Vreman from comment #22)
> Radek,
> 
> My feedback was on the Documentation only. I split on purpose requests to
> different BZs
> Honestly the documentation of 'network --hostname' also does not belong in
> this BZ about VLAN and Bonding
> 
> The fix for the BZ shall be https://github.com/rhinstaller/anaconda/pull/3441
> I can confirm that the PR3441 fixes it, i already implemented it as a
> temporary workaround in the %pre using a sed-command.
> 
> 
> 
> 
> Back to the documentation as we were on that topic also. Just adding a small
> remark that also the hostname will be set would be enough for me
> ~~~
> If you provide additional options when configuring the host name, the
> network command configures a device using the options specified.
> ~~~
> 
> to 
> 
> ~~~
> If you provide additional options when configuring the host name, the
> network command configures ___the hostname and___ device using the options
> specified.
> ~~~
> 

Looks good to me.

> 
> I also personally like to look at reference examples what is working and
> what not:
> 
> Maybe also an example might work, e.g. can you do split on several lines or
> combine it.
> ~~~
> network --hostname blah
> network --device ens192 --bootproto=x ...
> ~~~
> is the same as
> ~~~
> network --hostname blah --device ens192 --bootproto=x ...
> ~~~
> 

I agree, good idea.

> And how does --hostname work (or fail) if multiple devices with multiple
> hostnames are set:
> ~~~
> network --hostname blah.example.com --device ens192 --bootproto=x ...
> network --hostname blah-management.example.com --device ens256 --bootproto=x
> ...
> ~~~

This is a bit of a grey zone but we should try to document it.

> 
> I am not asking for any code change. This feedback is only provided to
> improve the documentation on the behaviour

Thank you, these are all great suggestions. I think we should open a documentation ticket for them. Bilhar, could you giude us to the right place?

(In reply to Radek Vykydal from comment #23)
> (In reply to Peter Vreman from comment #22)
> > Radek,
> > 
> > My feedback was on the Documentation only. I split on purpose requests to
> > different BZs
> > Honestly the documentation of 'network --hostname' also does not belong in
> > this BZ about VLAN and Bonding
> > 
> > The fix for the BZ shall be https://github.com/rhinstaller/anaconda/pull/3441
> > I can confirm that the PR3441 fixes it, i already implemented it as a
> > temporary workaround in the %pre using a sed-command.
> > 
> > 
> > 
> > 
> > Back to the documentation as we were on that topic also. Just adding a small
> > remark that also the hostname will be set would be enough for me
> > ~~~
> > If you provide additional options when configuring the host name, the
> > network command configures a device using the options specified.
> > ~~~
> > 
> > to 
> > 
> > ~~~
> > If you provide additional options when configuring the host name, the
> > network command configures ___the hostname and___ device using the options
> > specified.
> > ~~~
> > 
> 
> Looks good to me.
> 
> > 
> > I also personally like to look at reference examples what is working and
> > what not:
> > 
> > Maybe also an example might work, e.g. can you do split on several lines or
> > combine it.
> > ~~~
> > network --hostname blah
> > network --device ens192 --bootproto=x ...
> > ~~~
> > is the same as
> > ~~~
> > network --hostname blah --device ens192 --bootproto=x ...
> > ~~~
> > 
> 
> I agree, good idea.
> 
> > And how does --hostname work (or fail) if multiple devices with multiple
> > hostnames are set:
> > ~~~
> > network --hostname blah.example.com --device ens192 --bootproto=x ...
> > network --hostname blah-management.example.com --device ens256 --bootproto=x
> > ...
> > ~~~
> 
> This is a bit of a grey zone but we should try to document it.
> 
> > 
> > I am not asking for any code change. This feedback is only provided to
> > improve the documentation on the behaviour
> 
> Thank you, these are all great suggestions. I think we should open a
> documentation ticket for them. Bilhar, could you giude us to the right place?

Hi Radek,

I think the best thing at this point would be to lodge a documentation BZ, which I think will automatically create an internal JIRA ticket. Otherwise, we can just track this work in that BZ.

Thanks,

Bilhar

(In reply to Radek Vykydal from comment #23)
> (In reply to Peter Vreman from comment #22)
> > Radek,
> > 
> > My feedback was on the Documentation only. I split on purpose requests to
> > different BZs
> > Honestly the documentation of 'network --hostname' also does not belong in
> > this BZ about VLAN and Bonding
> > 
> > The fix for the BZ shall be https://github.com/rhinstaller/anaconda/pull/3441
> > I can confirm that the PR3441 fixes it, i already implemented it as a
> > temporary workaround in the %pre using a sed-command.
> > 
> > 
> > 
> > 
> > Back to the documentation as we were on that topic also. Just adding a small
> > remark that also the hostname will be set would be enough for me
> > ~~~
> > If you provide additional options when configuring the host name, the
> > network command configures a device using the options specified.
> > ~~~
> > 
> > to 
> > 
> > ~~~
> > If you provide additional options when configuring the host name, the
> > network command configures ___the hostname and___ device using the options
> > specified.
> > ~~~
> > 
> 
> Looks good to me.
> 
> > 
> > I also personally like to look at reference examples what is working and
> > what not:
> > 
> > Maybe also an example might work, e.g. can you do split on several lines or
> > combine it.
> > ~~~
> > network --hostname blah
> > network --device ens192 --bootproto=x ...
> > ~~~
> > is the same as
> > ~~~
> > network --hostname blah --device ens192 --bootproto=x ...
> > ~~~
> > 
> 
> I agree, good idea.
> 
> > And how does --hostname work (or fail) if multiple devices with multiple
> > hostnames are set:
> > ~~~
> > network --hostname blah.example.com --device ens192 --bootproto=x ...
> > network --hostname blah-management.example.com --device ens256 --bootproto=x
> > ...
> > ~~~
> 
> This is a bit of a grey zone but we should try to document it.
> 
> > 
> > I am not asking for any code change. This feedback is only provided to
> > improve the documentation on the behaviour
> 
> Thank you, these are all great suggestions. I think we should open a
> documentation ticket for them. Bilhar, could you giude us to the right place?

Hi Radek,

I think the best thing at this point would be to lodge a documentation BZ, which I think will automatically create an internal JIRA ticket. Otherwise, we can just track this work in that BZ.

Thanks,

Bilhar

Pre-verified with anaconda-33.16.5.3-1 in RHEL-8.5.0-20210718.d.2, manual reproducer and automated kickstart-test passed.

naconda-33.16.5.3-1.el8 is present in RHEL-8.5.0-20210730.n.0, moving to VERIFIED.

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-2021:4254