The operating system value changes after first puppet run

Support
1

Hi,

I have a situation where I want to have different pxe/ipxe/kickstart
scripts for certain hosts (personal VMs running on Windows based desktop
systems).
Background: I ask some questions in iPXE and use the answers in the
kickstart script.

Because these scripts are linked to the Operating System entry in the
database I created a "new" operating system which I called "CentOSHadoopVM".

However : After I install a system with that all is well until the puppet
run goes.

Then I see three seperate events with changes in the audit log for that
system:

  1. The build is set to false and the installation date is set.
  2. The Certname is set (I have autosign configured for puppet)
  3. The Model and Ip are set (which were previously unset) and the
    Operatingsystem is changed.
    ItemOldNewModelN/AVirtualBoxOperatingsystemCentOSHadoopVMCentOS 6.5IpN/A
    10.0.2.15
    As a consequence of this change of the Operatingsystem the link to the
    special scripts is lost and as such a reinstallation of this system will go
    wrong.

What is causing this to happen and how do I avoid this?

Niels Basjes

2

I just noticed this overview of the operating systems on the
/operatingsystems page.
Look closely at the numbers and realize that I have 3 hosts in the system
at this moment:

Name Hosts
CentOS 6.5 6
CentOSHadoopVM -2
CentOS 6.5xx 1

Apparently this automatically moving around has some side effects…

Niels Basjes

3

Yesterday I found a feature I didn't know before that seems to be the
'right' way of doing things.

I found that you can associate the provisioning scripts not only with an
Operating system but also with a list of < 'host group' + 'environment' >
I tried that and now my virtuals that are in a different group get the
right scripts.
For the Operating system I now only have a single "CentOS 6.5"

4

what do you have configured in the name, major, minor, and description
fields for each OS?

5

Good stuff! Yeah, that feature doesn't get enough coverage, and it's
very useful :slight_smile:

6

1:
name = CentOS
major = 6
minor = 5
description = CentOS 6.5

2:
name = CentOSHadoopVM
major = 6
minor = 5
description = CentOSHadoopVM

··· Op maandag 7 juli 2014 18:14:28 UTC+2 schreef Greg Sutcliffe: > > what do you have configured in the name, major, minor, and description > fields for each OS? >
7

You have a few options:

  1. Try setting the name to CentOS on both - the facts_parser code uses
    name/major/minor to identify the host. The downside here is that both
    OSes will match the query, so you may get a random one each time (I
    think) - that's probably worth raising a bug

  2. Override the "operatingsystem" fact on your Hadoop VMs to match the
    name. I think that should work - a quck test on one of my VMs:

mkdir /etc/facter/facts.d -p

echo -e "—\noperatingsystem: DebianHadoop\n" > /etc/facter/facts.d/os.yaml

facter -p operatingsystem

DebianHadoop

Worth a try :slight_smile:

··· On 7 July 2014 21:10, Niels Basjes wrote: > Op maandag 7 juli 2014 18:14:28 UTC+2 schreef Greg Sutcliffe: >> >> what do you have configured in the name, major, minor, and description >> fields for each OS? > > > 1: > name = CentOS > major = 6 > minor = 5 > description = CentOS 6.5 > > 2: > name = CentOSHadoopVM > major = 6 > minor = 5 > description = CentOSHadoopVM
8

2 years later and it still doesn't!I've lost a few hours today trying to
figure this out!

My next question though is how do we do this via the API? Taking a look at
what is generated by foreman:

2016-09-15T21:46:41 [app] [I] Started PATCH
"/templates/provisioning_templates/22-Kickstart%20RHEL%20default" for
127.0.0.1 at 2016-09-15 21:46:41 -0400

2016-09-15T21:46:42 [app] [I] Processing by
ProvisioningTemplatesController#update as /

2016-09-15T21:46:42 [app] [I] Parameters: {"utf8"=>"✓",
"authenticity_token"=>"RMIiR7+Dn1xqM8EL0IvjeLwKrFvBGkDm+x36bAU1K5k=",
"provisioning_template"=>{"name"=>"Kickstart RHEL default", "default"=>"1",
"template"=>"SNIP", "audit_comment"=>"", "snippet"=>"0",
"template_kind_id"=>"4", "operatingsystem_ids"=>[""],
"template_combinations_attributes"=>{"1473990106406"=>{"hostgroup_id"=>"1",
"environment_id"=>"", "_destroy"=>"false"}}, "location_ids"=>["", "1"],
"organization_ids"=>["", "2"]}, "preview_host_id"=>"2", "mode"=>"ruby",
"keybinding"=>"Default", "id"=>"22-Kickstart RHEL default"}

It looks like this might be done via template_combinations_attributes and
a PATCH method. Neither of these are documented in the API calls
at Foreman :: API v2. Does anybody know? Likewise
for assigning a template to an OS…

··· On Wednesday, July 16, 2014 at 1:16:11 PM UTC-4, Greg Sutcliffe wrote: > > Good stuff! Yeah, that feature doesn't get enough coverage, and it's > very useful :) >
9

Ok, thanks i'll try this .

I'm a bit surprised about how this works right now.
The way i looked at it is that the "operating system" in foreman is actually a "provisioning procedure to install a certain operating system".
The fact comming from facter is only the installed operating system, this does not include the provisioning procedure to get this system from bare metal to running system.
If you assume that all computers that need to run CentOS will all use the same scripting than this is fine.
In my scenario I want to install virtuals on a users Desktop and ask ths user a few questions (ipxe lets you do that) and react to the answers in the scripting that follows. The 'normal' machines do not need this and as such will have different scripting.

Would it make sense to change what is now called 'operating system' into 'provisioning for an operating system' and let the 'operating system' fact be just that what has been installed?

Niels Basjes

10

Ok, for anybody who is curious.

Doing a PUT to /provisioning_templates/:id with

{"provisioning_template" : {"template_combinations_attributes" :
[{"hostgroup_id" : "73"}, {"hostgroup_id" : "77"}, {"hostgroup_id" : "81"},
{"hostgroup_id" : "85"}]}}

Seems to do this trick.

··· On Thursday, September 15, 2016 at 9:58:37 PM UTC-4, Andrew Schofield wrote:

2 years later and it still doesn’t!I’ve lost a few hours today trying to
figure this out!

My next question though is how do we do this via the API? Taking a look at
what is generated by foreman:

2016-09-15T21:46:41 [app] [I] Started PATCH
"/templates/provisioning_templates/22-Kickstart%20RHEL%20default" for
127.0.0.1 at 2016-09-15 21:46:41 -0400

2016-09-15T21:46:42 [app] [I] Processing by
ProvisioningTemplatesController#update as /

2016-09-15T21:46:42 [app] [I] Parameters: {“utf8”=>“✓”,
“authenticity_token”=>“RMIiR7+Dn1xqM8EL0IvjeLwKrFvBGkDm+x36bAU1K5k=”,
“provisioning_template”=>{“name”=>“Kickstart RHEL default”, “default”=>“1”,
“template”=>“SNIP”, “audit_comment”=>"", “snippet”=>“0”,
“template_kind_id”=>“4”, “operatingsystem_ids”=>[""],
“template_combinations_attributes”=>{“1473990106406”=>{“hostgroup_id”=>“1”,
“environment_id”=>"", “_destroy”=>“false”}}, “location_ids”=>["", “1”],
“organization_ids”=>["", “2”]}, “preview_host_id”=>“2”, “mode”=>“ruby”,
“keybinding”=>“Default”, “id”=>“22-Kickstart RHEL default”}

It looks like this might be done via template_combinations_attributes
and a PATCH method. Neither of these are documented in the API calls at
Foreman :: API v2. Does anybody know? Likewise
for assigning a template to an OS…

On Wednesday, July 16, 2014 at 1:16:11 PM UTC-4, Greg Sutcliffe wrote:

Good stuff! Yeah, that feature doesn’t get enough coverage, and it’s
very useful :slight_smile:

11

Whilst you have a point, thats a fairly invasive change. I'd suggest
we need to make the import/detection system more flexible, that's all.
We already have a setting to ignore the IP/MAC of imported facts
(which by default are also used to update hosts in Foreman) - that
should be extended to allow you to not update the OS. In addtion, the
ability to customize the name of the fact used to detect the OS should
be added too, I think.

Greg

··· On 10 July 2014 09:03, Niels Basjes wrote: > Would it make sense to change what is now called 'operating system' into 'provisioning for an operating system' and let the 'operating system' fact be just that what has been installed?
12

This! These kinds of features could be best implemented by just adding more
custom configurable facts to influence which data gets pulled from where
for what, in addition to binary "should foreman update these informations
from facts at all?" flags.
I'd say a configurable foreman_primary_mac (/foreman_primary_ip) fact would
round this out?

··· On Thursday, July 10, 2014 5:39:09 PM UTC+2, Greg Sutcliffe wrote: > > On 10 July 2014 09:03, Niels Basjes <ni...@basj.es > wrote: > > Would it make sense to change what is now called 'operating system' into > 'provisioning for an operating system' and let the 'operating system' fact > be just that what has been installed? > > Whilst you have a point, thats a fairly invasive change. I'd suggest > we need to make the import/detection system more flexible, that's all. > We already have a setting to ignore the IP/MAC of imported facts > (which by default are also used to update hosts in Foreman) - that > should be extended to allow you to not update the OS. In addtion, the > ability to customize the name of the fact used to detect the OS should > be added too, I think. > > Greg >