Bug 1454903 - Marking new host's NIC as "provisioning" does not suffice for PXE boot, tooltip is misleading.
Summary: Marking new host's NIC as "provisioning" does not suffice for PXE boot, toolt...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Networking
Version: 6.2.7
Hardware: Unspecified
OS: Unspecified
low
medium vote
Target Milestone: 6.4.0
Assignee: Marek Hulan
QA Contact: Peter Ondrejka
URL:
Whiteboard:
: 1433034 (view as bug list)
Depends On:
Blocks: 1122832 1455059
TreeView+ depends on / blocked
 
Reported: 2017-05-23 17:55 UTC by Pablo Hess
Modified: 2020-12-14 08:44 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1455059 (view as bug list)
Environment:
Last Closed: 2018-10-16 19:21:00 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 19646 0 Low Closed Marking new host's NIC as "provisioning" does not suffice for PXE boot, tooltip is misleading. 2020-08-21 02:30:55 UTC
Red Hat Knowledge Base (Solution) 2971551 0 None None None 2017-09-04 13:51:32 UTC

Description Pablo Hess 2017-05-23 17:55:49 UTC
Description of problem:
On a Satellite with external DNS and DHCP services not managed by Satellite, when creating a new host (Hosts > New Host), one is required to check/uncheck a few boxes for each Network Interface on the new host.

Checking the Provision checkbox is not sufficient to have a new host successfully PXE-boot, although the tooltip says "The Provisioning interface is used for TFTP of PXELinux (or SSH for image-based hosts)".

Checking the Managed checkbox is also required in addition to the Provision checkbox, otherwise the MAC-address-based files under /var/lib/tftpboot/pxelinux.cfg/ are not generated at all.

However, the tooltip for the Managed checkbox reads, "Should this interface be managed via DHCP and DNS capsule and should it be configured during provisioning?". If I'm using external DHCP and DNS services, and not managing them from Satellite, then this tooltip will lead me to unchecking this box, thus rendering my Satellite unable to provide the PXE boot entry file i.e. /var/lib/tftpboot/pxelinux.cfg/01-<mac address>.



Version-Release number of selected component (if applicable):
Verified on 6.2.7, should apply to all 6.2.x

How reproducible:
Every time.


Steps to Reproduce:

1. Disable DNS and DHCP (and their management) on Satellite's internal capsule, while keeping TFTP enabled. Set up the DHCP server to point to the Satellite server ("next-server" option) and to look for the PXE boot loader ("filename" option).

2. On the Satellite WebUI, click Hosts > New Host, fill out the required fields.

3. On the Interface tab, configure the NIC that will be used to PXE-boot from and check its Provision box and uncheck the Managed box.

4. PXE-boot the new host.



Actual results:
The new host will successfully download pxelinux.0 (the boot loader) but will fail to download its entry file i.e. 01-<mac address>, thus halting the install.


Expected results:
The new host should download pxelinux.0 and also its 01-<mac address> file so it knows how to boot up.


Additional info:

Steps to fix (numbers following Steps to Reproduce):


5. On the Satellite, check that /var/lib/tftpboot/pxelinux.cfg/ indeed does not contain the 01-<mac address> file. It was just not generated.

6. Edit that same new host, checking the Managed box for the appropriate NIC.

7. PXE-boot the new host, it will successfully download pxelinux.0 and also its 01-<mac address> file, thus successfully installing to the end.




Suggested fix:

* Make the Provision checkbox enable Satellite's ability to generate the required 01-<mac address> file instead of relying on the apparently unrelated Managed checkbox.

Comment 1 Marek Hulan 2017-05-24 07:02:23 UTC
Thanks for the report. I believe the system works as expected but I agree the inline help can lead to confusion. Here's some explanation.

Provisioning flag determines which interface is used for PXE boot (or in case of image base provisioning, which interface and therefore IP is used to connect through SSH). You can have provisioning interface but want avoid TFTP configuration since you might want to configure the TFTP manually (like the customer does with DHCP and DNS). There are multiple switches that have impact on whether the TFTP will or will not be configured by Satellite. "Managed" is one of them but is shared for all external services. If "Managed" is disabled, no DNS no DHCP and no TFTP configuration is updated. You can see this as some kind of a master switch that turns of configuration of all external services. If you want to modify subset of external services, in this case TFTP only, you must configure the subnet, in which you provision the host, accordingly. To do that, go to subnet edit form, go to Capsules tab and keep only TFTP capsule selected. DNS and DHCP should remain as "None". As long as the interface is "managed" and attached to this subnet, it will use this subnet's TFTP capsule to update TFTP service.

So bottom line, I'm keeping this open since we should improve the inline help for "Managed" checkbox. We should also update the product documentation with what I've described above.

Comment 2 Marek Hulan 2017-05-24 07:06:55 UTC
Created redmine issue http://projects.theforeman.org/issues/19646 from this bug

Comment 3 Satellite Program 2017-05-24 08:06:07 UTC
Upstream bug assigned to mhulan

Comment 4 Satellite Program 2017-05-24 08:06:11 UTC
Upstream bug assigned to mhulan

Comment 12 Satellite Program 2017-06-02 16:06:14 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/19646 has been resolved.

Comment 13 Marek Hulan 2017-09-04 13:51:32 UTC
*** Bug 1433034 has been marked as a duplicate of this bug. ***

Comment 14 Peter Ondrejka 2018-06-15 10:42:03 UTC
Verified on Sat 6.4 snap 7

Comment 15 Bryan Kearney 2018-10-16 19:21:00 UTC
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, 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/RHSA-2018:2927


Note You need to log in before you can comment on or make changes to this bug.