Hide Forgot
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.
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.
Created redmine issue http://projects.theforeman.org/issues/19646 from this bug
Upstream bug assigned to mhulan
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/19646 has been resolved.
*** Bug 1433034 has been marked as a duplicate of this bug. ***
Verified on Sat 6.4 snap 7
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