Taken from our Etherpad on Brans request, I was unable to find what is this all about. Bryan can you add more details?
Created from redmine issue http://projects.theforeman.org/issues/8146
From the issue, this seems to work on a per-host basis, but not a generic basis.
Upstream bug assigned to gsutclif
We need this in 6.1 to support capsule isolation as promised.
Doco BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1235335
Feature: Foreman bootdisk now generates host-based images that work with template proxying (Capsule isolation feature of 6.1). New "Subnet" type image is provided as a counterpart to generic image which works with any host. Reason: With introduction of template proxying, Foreman bootdisk had to be modified to generate valid bootdisk images which works against Capsule proxies. Result:
Upstream bug component is Bootdisk Plugin
Moving to POST since upstream bug http://projects.theforeman.org/issues/8146 has been closed ------------- Anonymous Applied in changeset commit:foreman_bootdisk|367b1e6d37475adfe3bad52fe58c05b53505514e.
It's two commits, not just one. Should apply cleanly tho.
Chris++ Thank you! Please give us feedback on how it works for you. Documentation is at https://github.com/theforeman/foreman_bootdisk/pull/9/files#diff-04c6e90faac2675aa89e2176d2eec7d8 Usage is as easy as downloading "Subnet" image.
Created attachment 1105541 [details] foreman-proxy patch (In reply to Lukas Zapletal from comment #32) > Oh wait, Chris would you mind doing smart-proxy build as well? > > We need this patch which was already merged as well: > > https://gitlab.sat.lab.tlv.redhat.com/satellite6/smart-proxy/merge_requests/7 /me not knowing how to build smart-proxy RPM (and dont have time to learn it) combined the three commits to a single patch. Havent tested it yet due to my independent capsule issue, though.
You should see a new menu item for a Host - Subnet image. That's a Generic host image that works via the associated Capsule. Host-based images were always working correctly through Capsules.
Verified with satellite 6.1.6 compose3. I can generate the subnet boodisk iso via webUI and can provision a host using subnet bootdisk iso on default capsule as well as on external capsule.
Make sure to enable the templates feature on using following: for default capsule: katello-installer --capsule-templates true for external capsule: capsule-installer --templates true (by default its set to true)
Created attachment 1113588 [details] dropdown option to download subnet bootdisk iso from webUI
Since we don't have hammer command to generate subnet bootdisk so I filed another issue to track that: https://bugzilla.redhat.com/show_bug.cgi?id=1297324. And based on comment 44, 45, and 46, moving this bz to verified.
For the record, this was shipped with 6.1.5. The bootdisk process of Full host and Host bootdisks host no longer directly contact Satellite Server, but the request is proxied through Smart Proxy running on the Capsule. In other words, the initial iPXE bootstrap script from the boot ISO was: chain http://SATELLITE/unattended/iPXE?token=XXX&mac=YYY but now with Satellite 6.0.5 update it's chain http://CAPSULE/unattended/iPXE?token=XXX&mac=YYY The same applies to the iPXE script itself. It was: kernel http://CAPSULE/XYZ ks=http://SERVER/unattended/provision?token=XYZ initrd http://CAPSULE but now it's a bit different: kernel http://CAPSULE/XYZ ks=http://CAPSULE/unattended/provision?token=XYZ initrd http://CAPSULE In other words, before this update, your provisioned hosts were taking with Satellite, now they try to talk with Capsule and Capsule proxies this to Server back and forth. THE PROBLEM We have not communicated clearly in the Errata documentation that this update will change behavior of how bootdisks work. There are some manual steps required to get bootdisks working again. Although Generic bootdisk should not be affected by the change, the provided solution should help in case Generic bootdisk is generated to proxy via Capsule as well. In fact, there are reports that Generic host images are proxied through Capsule as well, which might be a bug. SOLUTION First, verify the Smart Proxy associated with a Host (via Subnet). Feature called "Templates" must be enabled. If the Templates feature is not present, plugin must be enabled on all Capsules involved in bootdisk provisioning. The installer can be executed to configure the service: ~~~ capsule-installer -v --templates true ~~~ Warning - the installer overwrites all configuration files removing all manual configurations. To do manual installation instead, do: ~~~ CAPSULE# cat /etc/foreman-proxy/settings.d/templates.yml --- :enabled: true :template_url: http://CAPSULE_URL:8000 CAPSULE# grep foreman_url /etc/foreman-proxy/settings.yml :foreman_url: https://SATELLITE_URL CAPSULE# service foreman-proxy restart ~~~ Note the YAML format has the starting three dashes on the first line. On the Capsule page in Satellite 6 interface, Refresh Features button must be hit to make this change effective. Host detail page now contains new menu item underneeth Bootdisk dropdown callled "Subnet image". Subnet images are similar to Generic images, but chain-loading is done via the TFTP Smart Proxy assigned to the Subnet of the host. After this change, also Generic and Host images requests are proxied through Capsules. Generate new bootdisk ISOs for existing hosts in order to make the change effective on them. TROUBLESHOOTING - foreman_url setting in settings.yml - template_url in settings.d/templates.yml - Capsule -> Server communication (HTTPS 443) - Server -> Capsule communication (HTTP 8000) - Host -> Capsule communication (HTTPS 9090 or HTTP 8000) - firewall and routing setup and DNS - check Host configuration in Web UI (Subnet must be associated properly) - check Subnet configuration in Web UI (TFTP Capsule must be set) - regenerate bootdisk again ALTERNATIVE APPROACH Since our customers are experiencing hardware, firmware and driver issues with iPXE technology, we have introduced new feature in 6.1.5 version called PXE-less discovery. This allows to avoid Bootdisk images completely with new generic Discovery ISO that boots via SYSLINUX and chainloads via PXELinux. More info here: https://access.redhat.com/blogs/1169563/posts/2090011
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/RHBA-2016:0052