New to Foreman - new host deployment questions

Hi all,

Apologies in advance if I missed something obvious but I am new to Foreman/Puppet/Katello and I am still trying to get my head around it;/

We have recently upgraded our POC to Foreman 1.16 / Katello 3.5 hoping to test ovirt VM deployment (yay, image based template deployment now works!) but I have noticed few issues:

  • Creation of new host (ovirt’s template based VM) fails if we use puppet (puppet environment, master, ca defined under ‘Create Host’)

Following error is visible:

Render user data template for XXX task failed with the following error: ERF12-0104 [ProxyAPI::ProxyException]: Unable to set PuppetCA autosign for XXX ([RestClient::NotAcceptable]: 406 Not Acceptable) for proxy https://XYZ:9090/puppet/ca

I can see following errors in /var/log/foreman-proxy/proxy.log

E, [2017-12-20T11:01:57.317899 3ddd5794] ERROR -- : Failed to enable autosign for XXX: No such file or directory - /etc/puppet/autosign.conf
I, [2017-12-20T11:01:57.318295 3ddd5794]  INFO -- : - - [20/Dec/2017:11:01:57 +0000] "POST /puppet/ca/autosign/XXX HTTP/1.1"  406 113 0.0013

Which is bit weird as config file exists here: /etc/puppetlabs/puppet/autosign.conf and it already contains needed entry (domain name… yes, I know but hey)

I have checked Smart Proxy > Puppet CA and it seems like it’s pointing to non-existing autosign.conf file:

  • With file missing – autosign file count = 0
  • With manually created file – autosign file count = 1 (but VM creation still fails)

If we do not use puppet during host creation VM is created ok but it’s not registered as a content host – is this normally handled by puppet?
Any idea why puppet part is not working or is pointing to different config file?

Thanks in advance,

So the proxy normally autodetermines the location of the autosign file by knowing the version of Puppet that’s loaded - the path in the log is a Puppet 3 location, while your file is at the Puppet 4 location. I’m assuming you’re on Puppet 4, of course, so the real question is why the proxy is wrong. Could you post the contents of the /etc/foreman-proxy/settings.d/puppet.yml?

Oh, and welcome to the community :slight_smile:

Hi there,

thanks for coming back to me.

Yesterday when I was trying to find out what’s going on I have found some info about separate step to upgrade puppet post install/upgrade of Foreman… So I decided to give it a go…

foreman-installer --upgrade-puppet

Resolving Dependencies
–> Running transaction check
—> Package puppetserver.noarch 0:2.8.0-1.el7 will be updated
—> Package puppetserver.noarch 0:5.1.4-1.el7 will be an update
–> Processing Dependency: puppet-agent >= 4.99.0 for package: puppetserver-5.1.4-1.el7.noarch
–> Running transaction check
—> Package puppet-agent.x86_64 0:1.10.9-1.el7 will be updated
—> Package puppet-agent.x86_64 0:5.3.3-1.el7 will be an update
–> Finished Dependency Resolution

Puppet 4 to 5 upgrade param reset, continuing with installation
Installing Done [100%] […]


cat /etc/foreman-proxy/settings.d/puppet.yml
# Puppet management
:enabled: https
# valid providers:
#   puppet_proxy_puppetrun   (for puppetrun/kick, deprecated in Puppet 3)
#   puppet_proxy_mcollective (uses mco puppet)
#   puppet_proxy_ssh         (run puppet over ssh)
#   puppet_proxy_salt        (uses salt
#   puppet_proxy_customrun   (calls a custom command with args)
#:use_provider: puppet_proxy_puppetrun

:puppet_version: 5.3.3

Although still same problem persisted…

Then I have created /etc/puppet/autosign.conf file with correct permissions and ownership info and - tada, it’s working now…

Another Question:
Now I am wondering - what’s the best way to register/handle new VMs. How do I ensure that newly deployed VMs will:

  • have puppet installed and configured
  • be registered as content hosts in foreman/katello

Should this be done on a template level and then they will re-register when deployed with new hostnames? Or should this be done somehow as a step/part of deployment?

Thank you in advance


I can’t answer the content host question, I’ll leave that to the @katello team.

For installing Puppet by default on new hosts, our default provisioning templates already contain the necessary steps. They do require the puppet master field be set, and then the system will add an entry to autosign during host provisioning, the host will install Puppet & retrieve the cert, and the autosign will be removed at the end.

If that’s not working for you, then my first question, naturally, is if you’re using our provisioning templates? :slight_smile:

What do you mean by ‘our provisioning templates’ exactly?

Yes, I am using default templates although I am not sure which one I should be using really. Documentation ( says to use ‘finish templates’ but on ‘Create Host’ page (Create Host > Operating System > Image Based) when I click Resolve I got ‘User data template’ (using cloud-init in ovirt template and ‘User Data’ is Enabled in Ovirt’s Compute Resource’s Image).

I am not sure which template is really in use but it might be the ‘user data’ one (Katello Kickstart Default User Data) as the finish template does not set the hostname. Strangely only hostname config works - the other part of default template does not (admin group, admin login, /tmp/ etc.) and there are no errors in cloud-init.log that could explain this ;/

It would be great if you could point me into some direction/docs to read about this.


That’s where the confusion is coming from. Finish templates and user-data templates are mutually exclusive - the first is for completing VMs where Foreman has SSH access, the latter for cloud-init. Only one can be in use at a given time.

That said, our default user-data template does include Puppet setup (assuming a puppetmaster is set on the host), which you can see here:

You can review the exact templates in use by a host from the Host page (under the templates tab) - the Preview button will give you the rendered version for that host, the Edit button will take you to the template itself. Can you check if the template in use by the host does actually include Puppet setup? That will tell us if we need to focus on the templates themselves, or on why the host isn’t executing it properly.

I ‘think’ that it’s a problem with foreman / cloud-init / ovirt - looks similar to this:

When using default 'Katello Kickstart Default User Data' only single line cloud-init ‘code’ is parsed (hostname config) - everything else is ignored / not executed including group / user creation as well as main part of creating a content of which in theory handles katello / puppet registration…

I guess for now I will need to stick to Finish template via ssh unless anyone has other idea?


I have tried switching to finish template (new ovirt template without cloud-init with default centos/rhel sshd config) but I am having few issues there as well. It seems that Foreman is not able to ssh into the VM to execute the script - errors from production.log below:

cf4db50a [app] [I] Starting SSH provisioning script - waiting for to respond
cf4db50a [app] [W] SSH error
cf4db50a [app] [I] Remove puppet certificate for XXX
cf4db50a [app] [I] Adding autosign entry for XXX
cf4db50a [app] [I] Revoked old certificates and enabled autosign
cf4db50a [app] [I] SSH connection established to - executing template
cf4db50a [app] [W] Failed to launch script on XXX Inappropriate ioctl for device
cf4db50a [app] [W] Rolling back due to a problem: [#<Orchestration::Task:0x007f909c7f8b48 @name=“Configure instance XXX via SSH”, @status="failed
cf4db50a [app] [I] Remove puppet certificate for XXX
cf4db50a [app] [I] Delete the autosign entry for XXX
cf4db50a [app] [I] Processed 4 tasks from queue ‘Host::Managed Post’, completed 0/4
cf4db50a [app] [E] Task ‘Prepare post installation script for XXX’ rollbacked
cf4db50a [app] [E] Task ‘Wait for XXX to come online’ rollbacked
cf4db50a [app] [E] Task ‘Enable certificate generation for XXX’ rollbacked
cf4db50a [app] [E] Task ‘Configure instance XXX via SSH’ failed

any idea what below means?

SSH connection established to - executing template
cf4db50a [app] [W] Failed to launch script on XXX Inappropriate ioctl for device

Thanks in advance,

@Tomasz_Zajaczkowski, Did you ever figure out what caused this issue? I’ve just run into it myself.