Register host does not use puppet settings from host group

Support
,
#1

Problem:

I’m trying to use the Register Host function to enroll a host into Puppet. While the host gets registered in Foreman the generated script does not install or call Puppet.

Expected outcome:

I’d expect the host to get registered in Puppet because the Host Group specified in the Register Host form has all the Puppet parameters setup (I cannot see any other to specify Puppet for Register Host). If I use the same Host Group to provision a host the ‘normal’ way through Preseed it does setup Puppet perfectly.

Foreman and Proxy versions:

Foreman: 2.4.0
Proxy 1: Logs, BMC, and Registration 2.4.0
Proxy 2: Puppet CA, Puppet, Logs, and Registration 2.4.0
Plugin Bootdisk: 17.0.2
Plugin Setup: 6.0.0

Distribution and version:

Installed using Foreman Puppet modules – all the latest versions.

Other relevant data:

I think the problem is that the Puppet fields from the Host Group are not applied to the new host, and therefore <% if @host.puppetmaster.present? -%> in the template is not true. Here’s a crop of the Host Group showing that all Puppet fields have been speicified:

image
image678×994 34.4 KB

And here’s the Host that results after registering. You can see it’s linked to the Host Group but the fields have not been populated (yet specify inherit):

image
image1226×396 21.2 KB

I also submitted this as a bug: Bug #32304: Register host does not use puppet settings from host group - Foreman

#2

I think the problem is, the registration (renamed to host init) template does not try to setup the puppet at all (based on what I see at foreman/host_init_config_default.erb at develop · theforeman/foreman · GitHub) but I guess you tried to add it to the template and found out the puppet fields for some reason don’t get inhretired. I’m not sure why. I know this has been just modified and perhaps will start working in 2.5, @lstejskal any thoughts? I’d expect if I pick a hostgroup that defines puppet proxy, it should be inherited and I’d see that puppet proxy set for the registered host (as any other attribute such as OS).

1 Like
#3

It seems there is a setting in Administer - Settings - Provisioning called “Default Global registration template” which is set to “Global Registration” by default.

If I try “Register Host” and enter the curl command to see the generated script, it’s the Global Registration template. If you want to use the “Linux registration default” instead, which does install puppet, you’ll have to set it there or I guess clone the template and set the hostgroup/environment combination there to bind it to the hostgroup.

#4

I could not find anything about Registration in the manual so this is all a bit of guesswork.

@Marek_Hulan Yes, I can see from the link it’s changed a lot. But I think host_init_config_default.erb replaces the old Linux registration default template, not the Global registration one. It does the same functions as the Linux registration default in 2.4 and host_init_config_default.erb doesn’t send any of the details entered into Host registration (e.g. Host group) that is present in Global registration.

And yes. But I suspect that the <% if host_puppet_server.present? -%> check in host_init_config_default.erb will fail, just like the old <% if @host.puppetmaster.present? -%> because Puppet fields (environment, proxy, CA) aren’t applied to the new host from the Host group.

@gvde I presume the Global registration template uses curl to pull down and execute a script generated from Linux registration default template. So they are both used.

#5

Yes, the problem is that for some reason, these values don’t propagate from the host group. I guess it’s related to how we represent “inherit value” in the form vs overriding it to blank value. I reproduced the behavior with the current development version. This is a valid bug that we need to fix. I’ve opened a redmine issue to track this at Bug #32457: Normally Inherited fields are not inherited upon host registreation - Foreman

For the documentation about the registration feature, please refer to Managing Hosts

The 2.5 documentation changes are in progress 2.5 Host Registration changes by stejskalleos · Pull Request #514 · theforeman/foreman-documentation · GitHub

Any feedback regarding what’s missing in the documentation or registration feature in general is very welcome.

1 Like
#6

Thanks @Marek_Hulan. I had already submitted a bug so I’ve marked it as a duplicate of this new one.

Oh, I’ve completed missed that documentation before. I’ve Google’ed many, many times for Foreman (I’ve been using it for years now) and always end up in this manual: Foreman :: Manual Thanks, I’ll have a read.

#7

Thanks, that’s a good feedback. @mcorr and @lzap perhaps we should start linking guides from the manual.

#8

Mel is working on getting the remaining content migrated, then we will indeed link from the old manual to keep links alive. Thanks.

#9

It appears there could still be a bug in Foreman 3.0.0 that exhibits the same behaviour. (original bug: 32304)

I’ve just gone through 2 test installs of Foreman 3.0.0 and Katello 4.2 RC3, setup a hostgroup and defined all the parameters including environment and Puppet and Puppet CA proxies:

Foreman-hostgroup-definition
Foreman-hostgroup-definition819×706 36.6 KB

When using the “Register Host” function, it registers with Katello and doesn’t install Puppet. It looks like the “host_puppet_server.present” isn’t set, and when reviewing the newly registered host, the Environment and Puppet fields are blank:

Foreman-newly-registered-host
Foreman-newly-registered-host462×673 25.3 KB

Am I missing something or is this truly a bug?

Thanks!

#10

Perhaps @lstejskal would know if there was some other fix required

#11

TBH I don’t know, need to setup puppet on my DEV env and look at it.

#12

I just did a fresh install of Foreman 3.0 and Katello 4.2 and followed the same documented steps I used previously and everything appears to be working fine.

Either a step was missed in my 3.0/4.2 RC3 setup or something was fixed in the 4.2 release from 4.2RC3. Either way, we’re back in action now.

Thanks.

#13

Ok, I take that back.

All my tests have used the “Register Host” functionality for registering existing hosts. After my latest install of Foreman 3.0/4.2, I setup a host group and ran some tests including registering a host and it installed and registered with Foreman no problem. The puppet environment and proxies were listed on the host so I thought it was good to go.

I then went ahead and added some managed content and attempted to register a host again. This time it went through all the client setup and registered with Katello but not with Puppet. Looking at the host details, it is missing the puppet environment and proxies again.

So it seems that when using the registration script and the host is registered with Katello, it does not pull the puppet details from the host group into the provisioning templates and puppet doesn’t get installed and registered.

Seems like a bug to me. Anything else I should be trying? I may just go ahead and customize the provisioning templates to go through puppet install and register first then katello.

#14

Should this really be fixed in the meanwhile? I can still reproduce the issue:

I use a Global Registration Template to register the client. First, force-puppet = true has to be set on hostgroup to even install puppet-agent on the host. On first registration, host_puppet_ca_server and host_puppet_server are empty, so puppet does not work, but host object is created. Running the registration script again, the parameters are read correctly from the host object and puppet.conf is written correctly as well.

#15

I’m the OP but in recent versions of Foreman this hasn’t been a problem for me.

#16

Does not work for me. Might be related to the fact that I am using nested hostgroups. Are you using them as well?

#17

I have tried again with flat host groups and got the same result. Latest Foreman/Katello.

Steps to reproduce:
Create a Host Group
Define Puppet Proxy, Puppet CA and Environment on the Host Group
Create a Global Registration Template associated with the newly created Host Group
Register a client using the Global Registration template

The client is registered, but Puppet Parameters from the Host Group are not adopted, leading to Empty ‘Environment’ ‘Puppet Proxy’ and ‘Puppet CA Proxy’ on the host object and a puppet.conf on the client which looks like this:

[main]

[agent]
pluginsync      = true
report          = true
certname        = my.host.tld
#18

Yes, my hostgroups are nested and some puppet settings come from the root, and some from the child.

#19

Thanks, are you using the latest Version of Foreman? Have you upgraded from a previous version?

I am facing the issue with a fresh installation of Foreman, with Katello, REX and rh-cloud Plugins active. Do you have any puppet-related global or hostgroup variables set?

Above I have described the steps to reproduce, and I would be happy if you could confirm this on a current Foreman installation.

#20

If you create your own global registration template you really need to post it. It’s difficult to guess what you do. Why don’t you use the default global registration template?

Also it’s unclear to me how you did that. You cannot select a registration template on the register host page. Are you sure your custom template is used at all?

Puppet is installed using a host_init_config template. Did you modify that as well? Which template is used?
Only a single template comes with foreman which is “Linux host_init_config default”.

I suggest you check the templates used after the registration by going to the host page of the new client, click Edit, go to the operating system tab and click the resolve button to see which host init template has been used.

And go to the template, i.e. Hosts - Provisioning Templates - click the name of the host init template, e.g. “Linux host_init_config default” to get into the edit page. Switch from the editor to the preview view, select the name of the new host in the drop down. You should see the script used for the initial configuration for this specific client.

I have just tried it and the initial config script writes the puppet.conf file with the puppet ca, master and environment selected in the host group using the original global registration and host init config templates…