Bug 1713103 - Unable to do image based provisioning with Cloud Init and VMware
Summary: Unable to do image based provisioning with Cloud Init and VMware
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Compute Resources - VMWare
Version: 6.6.0
Hardware: x86_64
OS: Linux
high vote
Target Milestone: 6.6.0
Assignee: Lukas Zapletal
QA Contact: Sanket Jagtap
Depends On:
TreeView+ depends on / blocked
Reported: 2019-05-22 21:20 UTC by Chris Roberts
Modified: 2019-11-07 12:07 UTC (History)
11 users (show)

Fixed In Version: foreman-proxy-,foreman-
Doc Type: Release Note
Doc Text:
The schema (HTTP/HTTPS) of `unattended_url` setting now affects if the provisioning templates are available through HTTP. Please check if you are not specifying the url with HTTPS schema, but using HTTP to get provisioning/userdata templates, this is unsupported behaviour as of Satellite 6.6.
Clone Of:
Last Closed: 2019-10-22 12:47:30 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:3172 None None None 2019-10-22 12:47:40 UTC

Description Chris Roberts 2019-05-22 21:20:25 UTC
Description of problem:

Following this guide:


We are unable to fetch the `<fqdn_foreman>/userdata/meta-data` because of HTTPS, if I turn off SSL on Foreman this works correctly. 

This worked fine on 6.3

Version-Release number of selected component (if applicable):

Katello 3.11
Foreman 1.21
vCenter 6.7

How reproducible:

Steps to Reproduce:

1. Install Katello 3.11
2. Setup Compute resource for VMware
3. Create a RHEL 7 template with cloud-init
4. Follow https://access.redhat.com/blogs/1169563/posts/3640721

Actual results:

Host builds and gets hostname correctly but does not do anything that it was instructed to with cloud-init, also in the Foreman UI it shows that the build is pending and since cloud-init can not pull down the metadata it never phones home to Foreman.

Expected results:

Build to finish correctly and UI to change from pending install to finished without having to turn off SSL.

Additional info:

It looks like here in the plugin we ignore HSTS:


I tried turning off HSTS both with the installer and in the /etc/foreman/settings.yml and that did not appear to fix the issue.


It looks like we force SSL here:





We can see from the cloud-init logs on a client we are getting redirected because of https:


Since we don't have the SSL CA we get a verify fail

I turned off https on Foreman with


Now we can see from a new client that we can curl the meta-data and the logs look good

[root@tonya-dunkel ~]# curl http://foreman.toledo.satellite.lab.eng.rdu2.redhat.com/userdata/meta-data
instance-id: i-c1dfd96eea8cc2b627
hostname: tonya-dunkel.toledo.satellite.lab.eng.rdu2.redhat.com
mac: 00:50:56:9e:63:06


Foreman Userdata Templates is now part of Foreman 1.23 so this might work with latest upstream since it is part of core

Comment 10 Lukas Zapletal 2019-07-04 11:17:23 UTC
QA: Please follow this older tutorial on settings things up: https://access.redhat.com/blogs/1169563/posts/3640721

Process will be very similar if not the same, except there is no need of installing any plugin - all code is now part of Foreman core. Templates are also available.

Comment 11 Sanket Jagtap 2019-07-17 08:43:07 UTC
Build : Satellite 6.6 snap 11

I was able to provision and install the Vm on VMware with cloud init successfully following the above blogpost

2019-07-17 08:40:00,099 - url_helper.py[DEBUG]: [0/11] open 'http://sat-host/unattended/built?token=5398f5ce-95ab-4ee9-ac04-881dc4d3e24d' with {'url': 'http://sat-host/unattended/built?token=5398f5ce-95ab-4ee9-ac04-881dc4d3e24d', 'headers': {'User-Agent': 'Cloud-Init/18.2'}, 'allow_redirects': True, 'method': 'GET', 'timeout': 5.0} configuration
2019-07-17 08:40:01,201 - url_helper.py[DEBUG]: Read from http://sat-host/unattended/built?token=5398f5ce-95ab-4ee9-ac04-881dc4d3e24d (201, 0b) after 1 attempts
2019-07-17 08:40:01,202 - handlers.py[DEBUG]: finish: modules-final/config-phone-home: SUCCESS: config-phone-home ran successfully
2019-07-17 08:40:01,202 - main.py[DEBUG]: Ran 5 modules with 0 failures

Comment 13 errata-xmlrpc 2019-10-22 12:47:30 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.


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