Jira (PUP-6247) Allow for certname_fact setting to be used to override default fqdn

[Chris Barker (JIRA)]

Chris Barker created an issue

Puppet / PUP-6247 Allow for certname_fact setting to be used to override default fqdn Issue Type: Improvement Assignee: Unassigned Created: 2016/04/28 8:46 PM Priority: Major Reporter: Chris Barker Currently there is no way to customize how a node determines what certificate name it should use: the certname value in the puppet.conf or failing that, using the fqdn returned by factor. We should allow for a certname_fact setting to allow this value to be overridden, allowing for a generic puppet.conf file to be reused across images / templates. For example, in AWS this would allow for a puppet.conf that contains a certname_fact = ec2_metadata.instance-id, bypassing any need to execut a puppet config set command at instance boot. This, combined with PUP-6239 would enable for the reuse of a standard puppet.conf file for agents across an environment that is dynamically scaling and not conforming to standard hostname based classification (aka cloud environments). Add Comment

This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)

[Lindsey Smith (JIRA)]

Lindsey Smith assigned an issue to Kylo Ginsberg

Puppet / PUP-6247 Allow for certname_fact setting to be used to override default fqdn

Change By: Lindsey Smith Assignee: Kylo Ginsberg Scrum Team: Client Platform

Add Comment

This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)

[Henrik Lindberg (JIRA)]

Henrik Lindberg commented on PUP-6247

Re: Allow for certname_fact setting to be used to override default fqdn Does this affect how users write their hiera.conf? Now I believe the recommendation is to use $trusted[certname] instead of $fqdn.

Add Comment

This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)

[Josh Cooper (JIRA)]

Josh Cooper commented on PUP-6247

Re: Allow for certname_fact setting to be used to override default fqdn

Does node_name_fact work for this? I think the answer is no, but it would be good to identify why. I don't think node_name_fact currently handles structured fact data like ec2_metadata.instance-id, but I haven't tried it. Side note, since the fact is required to figure out the agent's certname, we should only allow it to be derived based on core facts (and possibly non-pluginsync'ed external facts, e.g. /etc/puppetlabs/facter/facts.d, but not pluginsync'ed custom or external facts because of the catch-22 of having to pluginsync to get the facts, but you need a client cert before you can pluginsync.

Add Comment

[Lindsey Smith (JIRA)]

Lindsey Smith assigned an issue to Chris Barker

Puppet / PUP-6247

Allow for certname_fact setting to be used to override default fqdn

Change By: Lindsey Smith Assignee: Kylo Ginsberg Chris Barker

Add Comment

[Chris Barker (JIRA)]

Chris Barker commented on PUP-6247

Re: Allow for certname_fact setting to be used to override default fqdn node_name_fact doesn't change cert name, they are two separate values. What node_name changes is what is used for reports (but you have to change auth rules server side first). It allows for you to use the same certificate for multiple machines and indicate different node_name for each machine. This was the case in 2013 anyway, I doubt we've considered that node_name and cert name could ever be different in new features so it might not even work as it is today. Henrik Lindberg for hiera.yaml, in this use case, people would be using pp_role and other ssl attributes to identify the node. And cert name is still cert name, it's just saying in the puppet.conf the node resolves a fact other than fqdn if a cert name isn't present. This allows for a static puppet.conf, mean cloning and launching a machine removes a lot of the manual first boot scripting.

Add Comment

[Chris Barker (JIRA)]

Chris Barker assigned an issue to Unassigned

Puppet / PUP-6247

Allow for certname_fact setting to be used to override default fqdn

Change By: Chris Barker Assignee: Chris Barker

Add Comment

This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)

[Sean McDonald (JIRA)]

Sean McDonald updated an issue

Puppet / PUP-6247 Allow for certname_fact setting to be used to override default fqdn

Change By: Sean McDonald Team: Agent

Add Comment

[Sean McDonald (JIRA)]

Sean McDonald updated an issue

Puppet / PUP-6247 Allow for certname_fact setting to be used to override default fqdn

Change By: Sean McDonald Labels: triaged

Add Comment

[Sean McDonald (JIRA)]

Sean McDonald updated an issue

Puppet / PUP-6247 Allow for certname_fact setting to be used to override default fqdn

Change By: Sean McDonald Labels: needs_decision triaged

Add Comment

[Josh Cooper (JIRA)]

Josh Cooper updated an issue

Puppet / PUP-6247 Allow for certname_fact setting to be used to override default fqdn

Change By: Josh Cooper

Currently there is no way to customize how a node determines what certificate name it should use: the certname value in the puppet.conf

or failing that, using the fqdn returned by factor facter .

We should allow for a certname_fact setting to allow this value to be overridden, allowing for a generic puppet.conf file to be reused across images / templates.

For example, in AWS this would allow for a puppet.conf that contains a certname_fact = ec2_metadata.instance-id, bypassing any need to execut execute a puppet config set command at instance boot.

This, combined with PUP-6239 would enable for the reuse of a standard puppet.conf file for agents across an environment that is dynamically scaling and not conforming to standard hostname based classification (aka cloud environments).

Add Comment

This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)

[Jorie Tappa (JIRA)]

Jorie Tappa updated an issue

Puppet / PUP-6247 Allow for certname_fact setting to be used to override default fqdn

Change By: Jorie Tappa Sprint: Coremunity Grooming

Add Comment

[Jorie Tappa (JIRA)]

[Josh Cooper (JIRA)]

Josh Cooper commented on PUP-6247

Re: Allow for certname_fact setting to be used to override default fqdn I moved this to a different epic so we can capture related tickets

Add Comment