Project

General

Profile

Actions

Bug #11955

closed

Auto-Signing Fails When Using Image-Based Provisioning

Added by John Wesorick over 8 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
-
Difficulty:
Triaged:
Fixed in Releases:
Found in Releases:

Description

When using VM image based provisioning, Foreman never creates an autosign entry for the server in Salt. When the server is deployed, I can see in the Salt proxy's log that it tries to remove the nonexistent autosign entry:

E, [2015-09-24T11:37:15.429912 #19082] ERROR -- : Attempt to remove nonexistant client autosign for testserver.mydomain                                                                                                        
10.1.2.81 - - [24/Sep/2015 11:37:15] "DELETE /salt/autosign/testserver.mydomain HTTP/1.1" 404 76 0.0036

I can also see all the keys and existing autosign entries in Foreman, and everything else Salt related seems to be working, so I think my configuration is correct. Could this be related to the fact that image based provisioning only has a finish script?

Actions #1

Updated by Joris van der Laan over 8 years ago

For me exactly the same happens when doing Vmware image based deployments. My images already contain preconfigured salt-minion, with the keys removed. Network configuration is done with Vmware Guest OS Customisation on CentOS via data passed in a user_data template. No other templates are used or can be used with SSH unreachable private IP addresses.

Manually adding a Autosign entry in Infrastructure > Smart proxies -> Salt -> Autosign results in keys being passed in autosign.conf and being auto accepted, so the communication between foreman, the foreman-proxy and autosign.conf works. Manually accepting keys in foreman works too.

Foreman 1.9.2-1 (el7) from the Foreman yum repo.

So it seems that autosign is set only in:

foreman/app/models/host/managed.rb (line 267)

which comments:

  1. Cleans Certificate and enable Autosign
  2. Called before a host is given their provisioning template

Does this mean that it's called in all Provisioning Templates? Or in "provision" style templates?

Anyway, the setAutosign is done in "def handle_ca" . This is called (among others) in:

foreman/app/models/concerns/orchestration/compute.rb in "def setUserData". But wait a sec, the UserData Provisioning Template is used succesfully. At the top of "def setUserData" it logs "Rendering UserData template for" (line 86) and this is actually logged. No other code snippet had "Rendering UserData template for". But then if no failure is logged self.handle_ca must be called at line 101 .

But wait a second, handle_ca is defined too in foreman/app/controllers/unattended_controller.rb line 158 and this does not set autosign.

I am not familiar with Ruby code, so my "analysis" can be quite illogical and not relevant, but it's the only exact pointers I can give.

Actions #2

Updated by Stephen Benjamin over 8 years ago

Thanks for the report! It's indeed broken - or rather, never worked at all for image-based provisioning.

I'll try to fix it when I can, for now you can pre-add it to autosign or accept the key in the Smart Proxy UI after its built.

Actions #3

Updated by The Foreman Bot over 8 years ago

  • Status changed from New to Ready For Testing
  • Pull request https://github.com/theforeman/foreman_salt/pull/51 added
  • Pull request deleted ()
Actions #4

Updated by Anonymous over 8 years ago

  • Status changed from Ready For Testing to Closed
  • % Done changed from 0 to 100
Actions #5

Updated by Joris van der Laan over 8 years ago

Thanks for the fast follow-up and changing of the code. I very much appreciate it and do not let my critic underneath think there is lack of appreciation.

The problem with the bug fix is dat it changes the process flow of provisioning a virtual machine. By design Foreman accepted keys within the provisioning phase, thus letting the opportunity open to use Salt (or Chef or Puppet, let's call it Configmanagement) to actually confirm the server was provisioned. So let Configmanagement do the wget to /unattended/built . This is useful too where certain things need to be done by the "Configmanagement" before saying it's build or in our case to use the "new minion" trigger in Salt to call the wget. Specifically this is useful where the hosts are on (unreachable) private network IP's, so they cannot be reached by SSH.

Since the process is changed, I have to find another mechanism (without ssh or "abusing" Salt for it) to make a call to Foreman /unattended/built .

I just wanted to give you my 2 cents. Agains, thanks for the work! I think it will solve the problem of many.

Actions #6

Updated by The Foreman Bot over 8 years ago

  • Assignee set to Stephen Benjamin
  • Pull request https://github.com/theforeman/smart_proxy_remote_execution_ssh/pull/14 added
Actions #7

Updated by Stephen Benjamin over 8 years ago

  • Pull request deleted (https://github.com/theforeman/smart_proxy_remote_execution_ssh/pull/14)
Actions

Also available in: Atom PDF