Foreman Discover - Provision not working

Support
1

After a host has been discovered, when trying to provision, the pxeboot
file is not being created in the pxelinux.cfg folder.

The production.log shows:

Processing by DiscoversController#edit as /
Parameters: {"id"=>"080027be2282"}
Operation FAILED: undefined method `becomes' for nil:NilClass
Rendered common/500.html.erb (3.5ms)

I think the problem occurs in the Discovers Controller here:

def edit
@host = @host.becomes(::Host::Managed)
@host.type = 'Host::Managed'
@host.managed = true
@host.build = true

render :template => 'hosts/edit'

end

Any ideas on a fix?

2

It may also be a foreman proxy issue as tftp is logging
Oct 21 10:10:28 theforeman in.tftpd[4446]: tftp: client does not accept
options

into syslog

··· On Sunday, October 20, 2013 7:26:38 PM UTC+1, Alan Sergeant wrote: > > After a host has been discovered, when trying to provision, the pxeboot > file is not being created in the pxelinux.cfg folder. > > The production.log shows: > > Processing by DiscoversController#edit as */* > Parameters: {"id"=>"080027be2282"} > Operation FAILED: undefined method `becomes' for nil:NilClass > Rendered common/500.html.erb (3.5ms) > > > I think the problem occurs in the Discovers Controller here: > > def edit > @host = @host.becomes(::Host::Managed) > @host.type = 'Host::Managed' > @host.managed = true > @host.build = true > > render :template => 'hosts/edit' > end > > Any ideas on a fix? >
3

With some debugging output, production.log

Started PUT "/discovers/080027be2282" for 10.55.164.101 at Mon Oct 21
10:20:39 +0100 2013
Processing by DiscoversController#update as /
Parameters: {"host"=>{"progress_report_id"=>"[FILTERED]",
"root_pass"=>"[FILTERED]", "mac"=>"08:00:27:be:22:82", "ip"=>"10.0.1.10",
"disk"=>"", "model_id"=>"1", "name"=>"080027be2282",
"puppet_proxy_id"=>"1", "architecture_id"=>"1", "operatingsystem_id"=>"1",
"ptable_id"=>"7",
"interfaces_attributes"=>{"new_interfaces"=>{"_destroy"=>"false",
"mac"=>"", "ip"=>"", "name"=>"", "provider"=>"IPMI", "domain_id"=>"",
"type"=>"Nic::Managed"}}, "enabled"=>"1", "overwrite"=>"false",
"puppet_ca_proxy_id"=>"1", "managed"=>"true", "domain_id"=>"1",
"build"=>"1", "is_owned_by"=>"2-Users", "comment"=>"", "hostgroup_id"=>"1",
"environment_id"=>"1", "puppetclass_ids"=>[""], "type"=>"Host::Managed",
"provision_method"=>"build", "medium_id"=>"5"}, "id"=>"080027be2282",
"utf8"=>"✓",
"authenticity_token"=>"oMKdFYVm3jlE2JO1griC6+i+2pklGFYF0ytcVLf9pMA="}
UPDATING this host
#<Host::Discovered id: 27, name: "080027be2282", ip: "10.0.1.10",
last_compile: nil, last_freshcheck: nil, last_report: "2013-10-21
09:17:46", updated_at: "2013-10-21 09:17:46", source_file_id: nil,
created_at: "2013-10-21 09:17:46", mac: "08:00:27:be:22:82", root_pass:
nil, serial: nil, puppet_status: 0, domain_id: nil, architecture_id: nil,
operatingsystem_id: nil, environment_id: nil, subnet_id: nil, ptable_id:
nil, medium_id: nil, build: false, comment: nil, disk: nil, installed_at:
nil, model_id: 1, hostgroup_id: nil, owner_id: nil, owner_type: nil,
enabled: true, puppet_ca_proxy_id: nil, managed: nil, use_image: nil,
image_file: nil, uuid: nil, compute_resource_id: nil, puppet_proxy_id: nil,
certname: nil, image_id: nil, organization_id: nil, location_id: nil, type:
"Host::Discovered">
ForemanDiscovery: Rebooting 080027be2282.cell as its being discovered and
assigned
ForemanDiscovery: reboot result: successful
Redirected to https://10.55.164.201/hosts/080027be2282.cell
UPDATE SUCCESS
HOST updated to
#<Host::Managed id: 27, name: "080027be2282.cell", ip: "10.0.1.10",
last_compile: nil, last_freshcheck: nil, last_report: "2013-10-21
09:17:46", updated_at: "2013-10-21 09:20:39", source_file_id: nil,
created_at: "2013-10-21 09:17:46", mac: "08:00:27:be:22:82", root_pass:
nil, serial: nil, puppet_status: 0, domain_id: 1, architecture_id: 1,
operatingsystem_id: 1, environment_id: 1, subnet_id: nil, ptable_id: 7,
medium_id: 5, build: true, comment: "", disk: "", installed_at: nil,
model_id: 1, hostgroup_id: 1, owner_id: 2, owner_type: "User", enabled:
true, puppet_ca_proxy_id: 1, managed: true, use_image: nil, image_file:
nil, uuid: nil, compute_resource_id: nil, puppet_proxy_id: 1, certname:
nil, image_id: nil, organization_id: nil, location_id: nil, type:
"Host::Managed">
Completed 302 Found in 421ms (ActiveRecord: 29.2ms)
Started GET "/hosts/080027be2282.cell" for 10.55.164.101 at Mon Oct 21
10:20:39 +0100 2013
Processing by HostsController#show as /
Parameters: {"id"=>"080027be2282.cell"}
Rendered hosts/_overview.html.erb (237.5ms)
Rendered hosts/show.html.erb within layouts/application (628.4ms)
Rendered home/_user_dropdown.html.erb (2.3ms)
Read fragment views/tabs_and_title_records-2 (0.4ms)
Rendered home/_topbar.html.erb (4.8ms)
Completed 200 OK in 657ms (Views: 528.9ms | ActiveRecord: 115.7ms)
Started GET "/discovers/080027be2282/edit" for 10.55.164.101 at Mon Oct 21
10:20:40 +0100 2013
Processing by DiscoversController#edit as /
Parameters: {"id"=>"080027be2282"}
Editing
Operation FAILED: undefined method `becomes' for nil:NilClass
Rendered common/500.html.erb (3.2ms)
Completed 500 Internal Server Error in 16ms (Views: 6.9ms | ActiveRecord:
1.4ms)

··· On Monday, October 21, 2013 10:12:04 AM UTC+1, Alan Sergeant wrote: > > It may also be a foreman proxy issue as tftp is logging > Oct 21 10:10:28 theforeman in.tftpd[4446]: tftp: client does not accept > options > > into syslog > > On Sunday, October 20, 2013 7:26:38 PM UTC+1, Alan Sergeant wrote: >> >> After a host has been discovered, when trying to provision, the pxeboot >> file is not being created in the pxelinux.cfg folder. >> >> The production.log shows: >> >> Processing by DiscoversController#edit as */* >> Parameters: {"id"=>"080027be2282"} >> Operation FAILED: undefined method `becomes' for nil:NilClass >> Rendered common/500.html.erb (3.5ms) >> >> >> I think the problem occurs in the Discovers Controller here: >> >> def edit >> @host = @host.becomes(::Host::Managed) >> @host.type = 'Host::Managed' >> @host.managed = true >> @host.build = true >> >> render :template => 'hosts/edit' >> end >> >> Any ideas on a fix? >> >
4

The name change is to be expected - the FQDN of a Managed Host is the
hostname (in this case the condensed MAC) plus the domain. It has no effect
on the TFTP, as that's all based on the actual 'mac' field, which I can see
in you output as the same in both queries.

I can't think of any reason why Discovery would fail to write PXE boot
files if normal hosts are provisioning OK. Is that the case? Can you create
a normal Host and get a TFTP file written? I did test this on Friday, and
for me the TFTP config file was correctly written…

Greg

··· On 21 October 2013 10:26, Alan Sergeant wrote:

With some debugging output, production.log

5

It's strange, because i can generate the PXE Default template (in theory
checks write permissions to the directory), but normal hosts aren't
provisioning either. I'll do a clean install and report back.

··· On Monday, October 21, 2013 11:14:17 AM UTC+1, Greg Sutcliffe wrote: > > On 21 October 2013 10:26, Alan Sergeant <aserg...@gmail.com >wrote: > >> With some debugging output, production.log >> > > The name change is to be expected - the FQDN of a Managed Host is the > hostname (in this case the condensed MAC) plus the domain. It has no effect > on the TFTP, as that's all based on the actual 'mac' field, which I can see > in you output as the same in both queries. > > I can't think of any reason why Discovery would fail to write PXE boot > files if normal hosts are provisioning OK. Is that the case? Can you create > a normal Host and get a TFTP file written? I did test this on Friday, and > for me the TFTP config file was correctly written... > > Greg >
6

Check your Subnet has the TFTP proxy assigned to it - that would be the
most likely cause (after write permissions on /tftp - which is obviously
fine if you can write the default file).

··· On 21 October 2013 11:48, Alan Sergeant wrote:

It’s strange, because i can generate the PXE Default template (in theory
checks write permissions to the directory), but normal hosts aren’t
provisioning either. I’ll do a clean install and report back.

7

Cheers, i'll check that first

··· On Monday, October 21, 2013 11:50:17 AM UTC+1, Greg Sutcliffe wrote: > > On 21 October 2013 11:48, Alan Sergeant <aserg...@gmail.com >wrote: > >> It's strange, because i can generate the PXE Default template (in theory >> checks write permissions to the directory), but normal hosts aren't >> provisioning either. I'll do a clean install and report back. >> > > Check your Subnet has the TFTP proxy assigned to it - that would be the > most likely cause (after write permissions on /tftp - which is obviously > fine if you can write the default file). >
8

Subnet was the problem. Should it not validate and not submit unless it has
a subnet assigned?

··· On Monday, October 21, 2013 11:54:14 AM UTC+1, Alan Sergeant wrote: > > Cheers, i'll check that first > > On Monday, October 21, 2013 11:50:17 AM UTC+1, Greg Sutcliffe wrote: >> >> On 21 October 2013 11:48, Alan Sergeant wrote: >> >>> It's strange, because i can generate the PXE Default template (in theory >>> checks write permissions to the directory), but normal hosts aren't >>> provisioning either. I'll do a clean install and report back. >>> >> >> Check your Subnet has the TFTP proxy assigned to it - that would be the >> most likely cause (after write permissions on /tftp - which is obviously >> fine if you can write the default file). >> >
9

It's perfectly valid to create hosts without a subnet (or a subnet without
a tftp server) - not everyone has full control over their provisioning
environment, so we have to be flexible.

Glad you got it sorted.

··· On 21 October 2013 13:11, Alan Sergeant wrote:

Subnet was the problem. Should it not validate and not submit unless it
has a subnet assigned?