The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:

Feature #2128

Allow arbitrary fact as node_name identifier

Added by Bill Bartlett about 7 years ago. Updated about 3 years ago.

Status:ClosedStart date:04/01/2009
Priority:HighDue date:
Assignee:Nick Lewis% Done:

0%

Category:node
Target version:2.6.9
Affected Puppet version:0.24.7 Branch:
Keywords: customer

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com


Description

Currently, the only fact available as a node_name identifier is the hostname. I would like to have the capability of having any fact be the node_name identifier.

Use Case:

The reason this discussion came about is EC2. When an EC2 node is brought up, the hostname is not known. If we were to have a large, auto-scaling infrastructure, it is currently very difficult (impossible?) to automate bringing these EC2 nodes into puppet.

One possible solution is to allow any fact as a node_name, and then for each particular EC2 instance type that one would need scaling (apache, memcache, mysql all come to mind among many others), the AMI would be customized with a custom fact. An example could be a fact called “hostclass” that would then be set to “ec2_apache”, “ec2_memcache”, or similar. This allows the auto-created machine, which we would otherwise be unable to differentiate from any other EC2 node, access to puppet in an automated way.


Related issues

Related to Puppet - Bug #7859: auth.conf does not allow back references with colons Duplicate 06/09/2011
Related to Puppet - Bug #7867: node names should work consistently across all supported ... Needs Decision 06/09/2011

History

#1 Updated by James Turnbull about 7 years ago

  • Category set to node
  • Status changed from Unreviewed to Needs Decision
  • Assignee set to Luke Kanies

I don’t have an issue with this but I suspect this has all sorts of potential pitfalls. Luke?

#2 Updated by Luke Kanies about 7 years ago

  • Status changed from Needs Decision to Accepted
  • Assignee changed from Luke Kanies to Puppet Community

I’m comfortable with this.

#3 Updated by James Turnbull almost 7 years ago

  • Target version set to 4

#4 Updated by James Turnbull almost 7 years ago

  • Assignee deleted (Puppet Community)

#5 Updated by James Turnbull over 6 years ago

So the question here becomes … what fact becomes the value of the node_name? The default values are “cert” (Subject CN) or “hostname” with a default of “cert”. You need a unique value for each node?

I also suggest looking at client auto-signing and node regex expressions as another approach?

#6 Updated by Paul Lathrop over 6 years ago

James Turnbull wrote: > So the question here becomes … what fact becomes the value of the node_name? The default values are "cert" (Subject CN) or "hostname" with a default of "cert". You need a unique value for each node?

Does the value need to be unique? I don’t see why.

> I also suggest looking at client auto-signing and node regex expressions as another approach?

This definitely isn’t enough. Auto-signing doesn’t let you affect node lookup, and the regex expressions are still run just against the node name. For example, I want to match against IP addresses because we don’t use names in our environment.

#7 Updated by James Turnbull over 6 years ago

Paul Lathrop wrote:

James Turnbull wrote: > So the question here becomes … what fact becomes the value of the node_name? The default values are "cert" (Subject CN) or "hostname" with a default of "cert". You need a unique value for each node?

Does the value need to be unique? I don’t see why.

Hmmm maybe you are right. In which case it’s just a matter of adding another type of node_name choice in node.rb using some arbitrary fact.

#8 Updated by James Turnbull almost 5 years ago

  • Status changed from Accepted to Needs Decision
  • Assignee set to Nigel Kersten

#9 Updated by Nigel Kersten almost 5 years ago

  • Status changed from Needs Decision to Accepted
  • Assignee deleted (Nigel Kersten)
  • Target version changed from 4 to 3.x

#10 Updated by Nigel Kersten almost 5 years ago

  • Priority changed from Normal to High
  • Target version changed from 3.x to 2.6.x

We have a paying customer who cares deeply about this issue, so it’s being bumped in priority and targeted at 2.6.x and up.

#11 Updated by Nick Lewis almost 5 years ago

Being able to specify the node name used for classification on the master via arbitrary facts won’t address the deeper concurrency issues surrounding having multiple nodes with the same name check in at the same time. You should still have unique node names for each host that checks in (IE: ec2_apache_${uuid}).

#12 Updated by Anonymous almost 5 years ago

Being able to specify the node name used for classification on the master via arbitrary facts won’t address the deeper concurrency issues surrounding having multiple nodes with the same name check in at the same time.

It would be great if you could spell out what those concurrency issues are; it isn’t immediately obvious to me what they are, and I know this area of the code fairly well compared to most folks. :)

#13 Updated by Anonymous almost 5 years ago

Nick Lewis wrote:

Being able to specify the node name used for classification on the master via arbitrary facts won’t address the deeper concurrency issues surrounding having multiple nodes with the same name check in at the same time. You should still have unique node names for each host that checks in (IE: ec2_apache_${uuid}).

So to be clear. The issue we face today is that a fact can be used for classification that is not the node name. This is the fqdn fact. This is problem because we’re only bothering to do classification using this fact and everything else in the system still uses the node name.

e.g. the exec node terminus, reporting, the facts terminus, all still use node name.

This ticket is more than just classification. Everything needs to support the identification of a node using an arbitrary fact, not just classification. In this situation, I don’t understand the statement, “You should still have unique node names for each host that checks in (IE: ec2_apache_${uuid}).” because the fact itself becomes the unique node name.

#14 Updated by Anonymous almost 5 years ago

Also, a couple of points about terminology:

“node name” or node_name specifically refers to the string value of the client certificate’s distinguished name. At no point should we assume this is a hostname or something that looks like an FQDN. We should file bugs for anything we find in the system where node_name must look like a hostname or fully qualified domain name.

“node identifier” is a more abstract term we’ve been using to describe the desired behavior. We do still need a unique way to identify nodes. This ticket is stating that the node identifier and the node name should not be tightly coupled. Specifically, the node identifier should be able to be stored and presented to the master as a custom fact.

The node identifier should be used in all situations where a node needs to be identified. e.g. when submitting a report, when asking for a catalog (in all cases, site.pp and custom terminuses), when storing facts, and when retrieving files and plugins.

The one final thing to note is that all authorization should continue to be done with the node name and not the node identifier. This is because the node name is the only piece of information digitally signed by the certificat authority and as such is the root of all trust in the Puppet security model.

So, in summary:

  • node_name == cert DN
  • node_name != hostname
  • node_name != fqdn
  • node id = defaults to node_name
  • node id = could be switched to another fact
  • node id = used for all API requests
  • node_name = used for all API authorizations

#15 Updated by Jacob Helwig almost 5 years ago

Jeff McCune wrote:

Nick Lewis wrote:

Being able to specify the node name used for classification on the master via arbitrary facts won’t address the deeper concurrency issues surrounding having multiple nodes with the same name check in at the same time. You should still have unique node names for each host that checks in (IE: ec2_apache_${uuid}).

So to be clear. The issue we face today is that a fact can be used for classification that is not the node name. This is the fqdn fact. This is problem because we’re only bothering to do classification using this fact and everything else in the system still uses the node name.

e.g. the exec node terminus, reporting, the facts terminus, all still use node name.

This ticket is more than just classification. Everything needs to support the identification of a node using an arbitrary fact, not just classification. In this situation, I don’t understand the statement, “You should still have unique node names for each host that checks in (IE: ec2_apache_${uuid}).” because the fact itself becomes the unique node name.

The changes that are being worked on for this feature request affect the node name that the agent will use at all levels, so this will address everything you’re concerned about (node terminus, reporting, facts, etc).

The warning about still requiring this node name to be unique is because there are inherent concurrency issues on the master side when multiple agents connect at the same time using the same node name. The changes that Nick and I have been working on will not address this problem.

#16 Updated by Anonymous almost 5 years ago

Jacob Helwig wrote:

Jeff McCune wrote:

Nick Lewis wrote:

Being able to specify the node name used for classification on the master via arbitrary facts won’t address the deeper concurrency issues surrounding having multiple nodes with the same name check in at the same time. You should still have unique node names for each host that checks in (IE: ec2_apache_${uuid}).

So to be clear. The issue we face today is that a fact can be used for classification that is not the node name. This is the fqdn fact. This is problem because we’re only bothering to do classification using this fact and everything else in the system still uses the node name.

e.g. the exec node terminus, reporting, the facts terminus, all still use node name.

This ticket is more than just classification. Everything needs to support the identification of a node using an arbitrary fact, not just classification. In this situation, I don’t understand the statement, “You should still have unique node names for each host that checks in (IE: ec2_apache_${uuid}).” because the fact itself becomes the unique node name.

The changes that are being worked on for this feature request affect the node name that the agent will use at all levels, so this will address everything you’re concerned about (node terminus, reporting, facts, etc).

The warning about still requiring this node name to be unique is because there are inherent concurrency issues on the master side when multiple agents connect at the same time using the same node name. The changes that Nick and I have been working on will not address this problem.

OK, could we please use the node id and node_name terms for clarity?

Given an agent with the same SSL certificate as all other agents, the node name (which is the cert DN) will be the same when multiple agents are checking in simultaneously.

Do the changes cause the agent to use a different ID when making API calls, e.g. https://puppetmaster.puppetlabs.lan/production/catalog/${my_custom_fact} ?

Where:

  • my_custom_fact = “abc_123”
  • node_name (cert DN) = “ec2_node”

So the value of my_custom_fact will be unique per node, but the value of node_name will not be unique. Are there still the concurrency issues in this situation? If so, what are the concurrency issues?

#17 Updated by Jacob Helwig almost 5 years ago

Jeff McCune wrote:

Also, a couple of points about terminology:

“node name” or node_name specifically refers to the string value of the client certificate’s distinguished name. At no point should we assume this is a hostname or something that looks like an FQDN. We should file bugs for anything we find in the system where node_name must look like a hostname or fully qualified domain name.

“node identifier” is a more abstract term we’ve been using to describe the desired behavior. We do still need a unique way to identify nodes. This ticket is stating that the node identifier and the node name should not be tightly coupled. Specifically, the node identifier should be able to be stored and presented to the master as a custom fact.

The node identifier should be used in all situations where a node needs to be identified. e.g. when submitting a report, when asking for a catalog (in all cases, site.pp and custom terminuses), when storing facts, and when retrieving files and plugins.

The one final thing to note is that all authorization should continue to be done with the node name and not the node identifier. This is because the node name is the only piece of information digitally signed by the certificat authority and as such is the root of all trust in the Puppet security model.

So, in summary:

  • node_name == cert DN
  • node_name != hostname
  • node_name != fqdn
  • node id = defaults to node_name
  • node id = could be switched to another fact
  • node id = used for all API requests
  • node_name = used for all API authorizations

The changes Nick and I have been working on do introduce a new setting (node_name_value) that defaults to the certname setting, which is settable via the command line, and config file. This setting is used everywhere we were previously using certname in the code to identify the node. There is also another new setting (node_name_fact) which will set the node_name_value setting from the value of the specified fact. These two new settings cannot both be set at the same time.

#18 Updated by Jacob Helwig almost 5 years ago

Jeff McCune wrote:

OK, could we please use the node id and node_name terms for clarity?

No, because they only perpetuate an existing conflation of concepts.

“node name” as you have described it is simply the “certificate name”, and should never be confused with the “node name”, and should never be (directly) used for identifying the agent to the master. The “node name” is a completely separate entity (though historically wasn’t represented as such), that just happens to default to the value of the “certificate name”.

“node identifier” is the “node name”. After the changes that Nick and I have made will be represented on its own (though will still default to the value of the “certificate name”).

The pre-existing “node_name” setting only confuses matters, and should be deprecated under its current name, since it isn’t actually about setting the node name, but about how we generate the list of “fallback node names” to use when doing node lookups on the master. (See: lib/puppet/node.rb)

#19 Updated by Nick Lewis almost 5 years ago

  • Assignee set to Nick Lewis

Here’s a branch with the code so far:

https://github.com/nicklewis/puppet/tree/ticket/2.6.x/2128

It still needs some acceptance tests before merging though, and is subject to change.

#20 Updated by James Turnbull almost 5 years ago

I think the part that has me befuddled is the code in the names method in lib/puppet/node.rb. I am confused how this now relates to the changes in this ticket.

#21 Updated by Nick Lewis almost 5 years ago

James Turnbull wrote:

I think the part that has me befuddled is the code in the names method in lib/puppet/node.rb. I am confused how this now relates to the changes in this ticket.

That code is trying to infer other possible names for the node, when determining which node declaration in the manifests to use. In addition to the node name itself (previously certname, now node_name_value), it will use each prefix of the fqdn. If the fqdn isn’t available, it will construct one by joining the hostname and the domain. The primary effect is that a node with the fqdn:

foo.example.lan

will have node declarations searched for in this order:

a) if the node_name setting on the master is ‘cert", then whatever is specified as node_name_value. Otherwise, the value of the 'hostname’ fact.

b) ‘foo.example.lan’

c) ‘foo.example’

d) ‘foo’

In the case where node_name_value isn’t anything remotely related to the hostname, these don’t make a lot of sense as fallbacks. In that case, the strict_hostname_checking setting can be enabled to only allow node_name_value as a valid node name.

#22 Updated by James Turnbull almost 5 years ago

Nick Lewis wrote:

In the case where node_name_value isn’t anything remotely related to the hostname, these don’t make a lot of sense as fallbacks. In that case, the strict_hostname_checking setting can be enabled to only allow node_name_value as a valid node name.

So this is still used for:

lib/puppet/indirector/node/exec.rb lib/puppet/indirector/node/ldap.rb lib/puppet/rails/host.rb

Should we perhaps refactor this code a little to make it a bit saner as part of this exercise? I think in light of the node_name_value change this violates the principal of least surprise but happy to be wrong too. :)

#23 Updated by Nick Lewis almost 5 years ago

James Turnbull wrote:

Nick Lewis wrote:

In the case where node_name_value isn’t anything remotely related to the hostname, these don’t make a lot of sense as fallbacks. In that case, the strict_hostname_checking setting can be enabled to only allow node_name_value as a valid node name.

So this is still used for:

lib/puppet/indirector/node/exec.rb lib/puppet/indirector/node/ldap.rb lib/puppet/rails/host.rb

Should we perhaps refactor this code a little to make it a bit saner as part of this exercise? I think in light of the node_name_value change this violates the principal of least surprise but happy to be wrong too. :)

That would be ideal, but I don’t really feel comfortable doing that in 2.6.x, particularly this late into its lifetime, and with code that’s a) important, and b) complex. Some of those sorts of refactors would be extremely valuable and appropriate against master, though. There are certainly places in the code that still want to assume the node’s name is its certname is its hostname, and this fix really just sort of hacks around them.

#24 Updated by Nick Lewis almost 5 years ago

  • Status changed from Accepted to Merged - Pending Release

Pushed this to 2.6.x in commit:3d09ca82e57d0c8836b77623d876cd5dc9a3a5e6.

This provides settings node_name_value and node_name_fact. The node_name_value defaults to certname, and is used as the catalog requested by the agent. node_name_fact specifies a fact to use to determine the node_name_value. The two settings are mutually exclusive, because it would be ambiguous which ought to take precedence. The node_name_value is used for everything except authentication/authorization. That means it is the “host” referred to in a report, the name under which fact and node YAML are saved, etc. This name should still be unique for each node.

It may also be good to deprecate the node_name setting, which is rather misleading, and eventually repurpose it for what is currently node_name_value.

#25 Updated by Anonymous almost 5 years ago

Nick, Jacob,

On site with a customer using 2.6.7 (not with this change set) I’m seeing this error when we’ve modified the incoming request using a config.ru man in the middle hack.

Error 400 on SERVER: Invalid pattern i-9bbfXXXX::netops-puppet-0-4679.int.acme.com

This error seems to be in:

➜  puppet git:(2.6.8) ack Invalid.pattern
lib/puppet/network/authstore.rb
244:          raise AuthStoreError, "Invalid pattern #{value}"

Is this changes required to auth.conf in order to allow the agent to request a resource not matching the certificate name?

#26 Updated by Anonymous almost 5 years ago

0.24.8 Question

Again, on site with a customer they are considering applying this patch before release to abandon their custom modifications to Puppet. The question came up:

Does this change set affect the behavior of 0.24.8 clients?

I don’t think it does since it’s using the REST API code path rather than the XMLRPC code path, but I’d like to double check before I say “No”

A “We don’t think so” is a good enough answer as long as it’s reasonably confident. We’ll be testing the 0.24.8 clients against the patched 2.6.8.

-Jeff

#27 Updated by Jacob Helwig almost 5 years ago

Regarding the auth.conf question: Looks like we forgot to mention this here in the ticket, even though we put it in the commit message:

commit 1c70f0ce54022b55119b9e2d6d60cd1ae9bc019e
Author: Nick Lewis <nick@puppetlabs.com>
Date:   Thu Jun 2 16:24:16 2011

    (#2128) Add support for setting node name based on a fact

    This adds the node_name_fact setting, which specifies a fact to use to
    determine the node name. This allows dynamically determining the node name
    without having to modify puppet.conf or command line options.

    Using this setting requires modifying auth.conf to allow nodes to request
    catalogs not matching their certnames.

    For example, this would allow any authenticated node to retrieve any catalog:

      # $confdir/auth.conf
      path ~ /catalog/.+
      allow *

    The node_name_fact and node_name_value options are mutually exclusive, because
    it is ambiguous which setting should take precedence.

    Paired-With: Jacob Helwig <jacob@puppetlabs.com>

Regarding 0.24.8: The change as written requires agent/master combinations where both have the change, so 0.24.8 won’t work.

#28 Updated by Anonymous almost 5 years ago

Added options

These configuration options have been added in this change set. Both of these options are in the [agent] section.

    [agent]

    # The fact to use as the node name.
    # The default value is ''.
    # node_name_fact =

    # The name of the node.
    # The default value is '$certname'.
    node_name_value = foo.bar.com

These configuration settings should probably be better documented. Should this be a separate ticket, or is documentation part of this ticket?

#29 Updated by Anonymous almost 5 years ago

Plugin Sync

Note, I’ve tested that if the agent does not already have the fact used to set the node name, and the fact is downloaded from the master in the plugin sync phase, the agent does re-evaluate the fact before the catalog request.

Therefore, one puppet run to obtain the catalog is all that is required from a bare machine.

(Adding this information since I believe it will be a common question)

#30 Updated by Jacob Helwig almost 5 years ago

Jeff McCune wrote:

These configuration settings should probably be better documented. Should this be a separate ticket, or is documentation part of this ticket?

Which documentation are you thinking of? If there’s more documentation that needs to be updated in puppet.git then it definitely makes sense to say that this ticket isn’t actually “done”. If it’s in puppet-docs.git then it might make more sense to open up a reminder there and let this one be “done” (even though we should get that taken care of as quickly as possible).

#31 Updated by Anonymous almost 5 years ago

  • Status changed from Merged - Pending Release to Accepted
  • Assignee changed from Nick Lewis to Anonymous

Reopened

Jacob, I’d like to provide more detailed information in the documentation strings of the options. This information will then flow into the online documentation, the commented puppet.conf and the help command.

This should be a quick fix so I’ll take care of it rather than making you and nick switch contexts again.

I likely won’t have it done tonight but wanted to update the ticket status.

#32 Updated by Anonymous almost 5 years ago

  • Status changed from Accepted to In Topic Branch Pending Review

Updated

I’ve updated this as branch: ticket/2.6.x/2128_docstrings in git://github.com/jeffmccune/puppet.git

Submitted pull request: https://github.com/puppetlabs/puppet/pull/13

We should update the following links to point at whatever documentation we’d like to direct users using the interface at: http://links.puppetlabs.com/content.py

I’ve configured them to point to this ticket for the time being.

#33 Updated by Anonymous almost 5 years ago

  • Assignee changed from Anonymous to Nick Lewis

Assigning back to Nick to review the docs and merge if they’re OK.

#34 Updated by Anonymous almost 5 years ago

auth.conf

Jacob,

The auth.conf setting you mentioned in the commit history actually breaks “normal” Puppet Agents that have a certificate name matching their node name.

This is the auth.conf I’m using at a site that uses both certificate names matching node names AND a common certificate named ‘all-catalog-access’.

# allow nodes to retrieve their own catalog (ie their configuration)
path ~ ^/catalog/([^/]+)$
method find
allow $1
allow all-catalog-access

This is necessary because only the FIRST match is used to authenticate clients in auth.conf as per the REST Access Control documentation

#35 Updated by Anonymous almost 5 years ago

  • Status changed from In Topic Branch Pending Review to Merged - Pending Release

Merged as b1a506c into 2.6.x after review from Randall.

#36 Updated by Anonymous almost 5 years ago

  • Status changed from Merged - Pending Release to Accepted

Reopened – authstore.rb issue

I believe I’ve found a potential authstore.rb issue related to this tickets that blocks it from fully working.

The certificate the customer I’m working with is using doesn’t look like a traditional FQDN. It contains a simple alpha string with a hypen. e.g. “foo-jeffrey”

Here’s what I’m seeing. The error the agent gets is:

err: Invalid pattern i-XXXXXXXX::dev2-jeff-01.int.ec2.acme.com
Breakpoint 1 at /usr/lib/ruby/site_ruby/1.8/puppet/network/authstore.rb:224/usr/lib/ruby/site_ruby/1.8/puppet/network/authstore.rb:224
@name,@exact,@length,@pattern = *case value
(rdb:4) l
[219, 228] in /usr/lib/ruby/site_ruby/1.8/puppet/network/authstore.rb
   219        # It should be:
   220        #     IP = "#{IPv4}|#{IPv6_full}|(#{IPv6_partial}#{IPv4})".gsub(/_/,'([0-9a-fA-F]{1,4})').gsub(/\(/,'(?:')
   221        # but ruby's ipaddr lib doesn't support the hybrid format
   222        IP = "#{IPv4}|#{IPv6_full}".gsub(/_/,'([0-9a-fA-F]{1,4})').gsub(/\(/,'(?:')
   223        def parse(value)
=> 224          @name,@exact,@length,@pattern = *case value
   225          when /^(?:#{IP})\/(\d+)$/                                   # 12.34.56.78/24, a001:b002::efff/120, c444:1000:2000::9:192.168.0.1/112
   226            [:ip,:inexact,$1.to_i,IPAddr.new(value)]
   227          when /^(#{IP})$/                                          # 10.20.30.40,
   228            [:ip,:exact,nil,IPAddr.new(value)]
(rdb:4) value
*** Unknown command: "value".  Try "help".
(rdb:4) irb
irb(allow: ):001:0> value
=> "foo-jeffrey"

This foo-jeffrey does match the final conditional of:

   241          when /^\w[-.@\w]*$/                                       # ? Just like a host name but allow '@'s and ending '.'s
=> 242            [:opaque,:exact,nil,[value]]
   243          else

But then the parse() code path is re-entered:

[219, 228] in /usr/lib/ruby/site_ruby/1.8/puppet/network/authstore.rb
   219        # It should be:
   220        #     IP = "#{IPv4}|#{IPv6_full}|(#{IPv6_partial}#{IPv4})".gsub(/_/,'([0-9a-fA-F]{1,4})').gsub(/\(/,'(?:')
   221        # but ruby's ipaddr lib doesn't support the hybrid format
   222        IP = "#{IPv4}|#{IPv6_full}".gsub(/_/,'([0-9a-fA-F]{1,4})').gsub(/\(/,'(?:')
   223        def parse(value)
=> 224          @name,@exact,@length,@pattern = *case value
   225          when /^(?:#{IP})\/(\d+)$/                                   # 12.34.56.78/24, a001:b002::efff/120, c444:1000:2000::9:192.168.0.1/112
   226            [:ip,:inexact,$1.to_i,IPAddr.new(value)]
   227          when /^(#{IP})$/                                          # 10.20.30.40,
   228            [:ip,:exact,nil,IPAddr.new(value)]
(rdb:4) e value
"$1"

So this seems to be OK, (My agent has timed out while I stepped through this.)

On the next puppet run, I get a different value that matches the node_name and not the cert_name:

Breakpoint 1 at /usr/lib/ruby/site_ruby/1.8/puppet/network/authstore.rb:224/usr/lib/ruby/site_ruby/1.8/puppet/network/authstore.rb:224
@name,@exact,@length,@pattern = *case value
(rdb:18) l
[219, 228] in /usr/lib/ruby/site_ruby/1.8/puppet/network/authstore.rb
   219        # It should be:
   220        #     IP = "#{IPv4}|#{IPv6_full}|(#{IPv6_partial}#{IPv4})".gsub(/_/,'([0-9a-fA-F]{1,4})').gsub(/\(/,'(?:')
   221        # but ruby's ipaddr lib doesn't support the hybrid format
   222        IP = "#{IPv4}|#{IPv6_full}".gsub(/_/,'([0-9a-fA-F]{1,4})').gsub(/\(/,'(?:')
   223        def parse(value)
=> 224          @name,@exact,@length,@pattern = *case value
   225          when /^(?:#{IP})\/(\d+)$/                                   # 12.34.56.78/24, a001:b002::efff/120, c444:1000:2000::9:192.168.0.1/112
   226            [:ip,:inexact,$1.to_i,IPAddr.new(value)]
   227          when /^(#{IP})$/                                          # 10.20.30.40,
   228            [:ip,:exact,nil,IPAddr.new(value)]
(rdb:18) e value
"i-XXXXXXXX::dev2-jeff-01.int.ec2.acme.com"

This pattern drops into the exception case:

(rdb:18) n
/usr/lib/ruby/site_ruby/1.8/puppet/network/authstore.rb:244
raise AuthStoreError, "Invalid pattern #{value}"
(rdb:18) l =
[239, 248] in /usr/lib/ruby/site_ruby/1.8/puppet/network/authstore.rb
   239          when /\$\d+/                                              # a backreference pattern ala $1.reductivelabs.com or 192.168.0.$1 or $1.$2
   240            [:dynamic,:exact,nil,munge_name(value)]
   241          when /^\w[-.@\w]*$/                                       # ? Just like a host name but allow '@'s and ending '.'s
   242            [:opaque,:exact,nil,[value]]
   243          else
=> 244            raise AuthStoreError, "Invalid pattern #{value}"
   245          end
   246        end
   247      end
   248    end
(rdb:18)

#37 Updated by Anonymous almost 5 years ago

Steps to reproduce

Simply try a node_name_value of “foo::bar”

puppet agent --test --node_name_value="foo::bar"

#38 Updated by Anonymous almost 5 years ago

  • Status changed from Accepted to Closed

Closed

The problem described with node names that have colons is actually another bug related to, but not this issue.

This has been filed as #7859

#39 Updated by James Turnbull almost 5 years ago

  • Target version changed from 2.6.x to 2.6.9

#40 Updated by Charlie Sharpsteen about 3 years ago

  • Keywords set to customer

Also available in: Atom PDF