Jira (PUP-11846) The --no-preprocess_deferred option breaks deferring of Sensitive file content
Title: Message Title Nate McCurdy updated an issue Puppet / PUP-11846 The --no-preprocess_deferred option breaks deferring of Sensitive file content Change By: Nate McCurdy Affects Version/s: PUP 8.0.1 Add Comment This message was sent by Atlassian Jira (v8.20.21#820021-sha1:38274c8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.485142.1683044961000.1501.1684879740029%40Atlassian.JIRA.
Jira (PUP-11846) The --no-preprocess_deferred option breaks deferring Sensitive file content
Title: Message Title Nate McCurdy updated an issue Puppet / PUP-11846 The --no-preprocess_deferred option breaks deferring Sensitive file content Change By: Nate McCurdy Summary: Munging failed for value # in class content: The -- no implicit conversion of Puppet::Pops::Types::PSensitiveType:: -preprocess_deferred option breaks deferring Sensitive into String file content Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.485142.1683044961000.11194.1683317640044%40Atlassian.JIRA.
Jira (PUP-11846) The --no-preprocess_deferred option breaks deferring of Sensitive file content
Title: Message Title Nate McCurdy updated an issue Puppet / PUP-11846 The --no-preprocess_deferred option breaks deferring of Sensitive file content Change By: Nate McCurdy Summary: The --no-preprocess_deferred option breaks deferring of Sensitive file content Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.485142.1683044961000.11195.1683317640108%40Atlassian.JIRA.
Jira (PUP-11846) Munging failed for value # in class content: no implicit conversion of Puppet::Pops::Types::PSensitiveType::Sensitive into String
Title: Message Title
Nate McCurdy commented on PUP-11846
Re: Munging failed for value # in class content: no implicit conversion of Puppet::Pops::Types::PSensitiveType::Sensitive into String
I've found an even simpler, more to the point, reproduction case. So I've removed references to inline_epp() in the ticket description since that was apparently a red herring:
file { '/tmp/test.txt':
ensure => 'file',
content => Deferred('new', [Sensitive, "hello world\n"]),
}
Add Comment
This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8)
Jira (PUP-11846) Munging failed for value # in class content: no implicit conversion of Puppet::Pops::Types::PSensitiveType::Sensitive into String
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-11846
Munging failed for value # in class content: no implicit conversion of Puppet::Pops::Types::PSensitiveType::Sensitive into String
Change By:
Nate McCurdy
*Puppet Version:* 7.24.0*Puppet Server Version:* n/a*OS Name/Version:* n/ah2. The ProblemUsing a {{Deferred}} {{inline_epp()}} to render Sensitive content into a {{file}} resource while using {{--no-preprocess_deferred}} throws the following error message:{noformat}Error: Failed to apply catalog: Munging failed for value # in class content: no implicit conversion of Puppet::Pops::Types::PSensitiveType::Sensitive into String{noformat}h2. ReproductionGiven this Puppet code:{code} $cert = Sensitive('hello')$intermediate = Sensitive('world')$chain= Deferred('inline_epp', ["<%= \$cert %>\n<%= \$intermediate %>\n", { 'cert' => $cert, 'intermediate' => $intermediate,}]) file { '/tmp/ test_chain test . pem txt ': ensure => 'file', content => $chain Deferred('new' , [Sensitive, "hello world\n"]), }{code}With Puppet 7.24.0 and the {{--no-preprocess_deferred}} option, apply the manifest above:{noformat}$ puppet apply test.pp --no-preprocess_deferredNotice: Compiled catalog for nate in environment production in 0.01 secondsError: Failed to apply catalog: Munging failed for value # in class content: no implicit conversion of Puppet::Pops::Types::PSensitiveType::Sensitive into String{noformat}Running puppet apply without {{--no-preprocess_deferred}} succeeds:{noformat}$ puppet apply test.ppNotice: Compiled catalog for nate in environment production in 0.01 secondsNotice: /Stage[main]/Main/File[/tmp/ test_chain test . pem txt ]/ensure: changed [redacted] to [redacted]Notice: Applied catalog in 0.01 seconds{noformat}h2. More Info I also found that I can fix Moving the problem by not using {{inline_epp()}}.If I change the {{$chain}} variable Sensitive cast to be built with {{join()}}, it works outside of the Deferred type does work : {code} # This isn't ideal because the file needs a trailing newline, which join() can { ' t do /tmp/test . txt': $chain ensure = > 'file', content => Sensitive(Deferred(' join new ', [ [$cert.unwrap String , $intermediate.unwrap], " hello world \n"])) , } {code}Here's a stack trace from using {{--trace}} of the error, which shows that it might be an issue with how file checksums are calculated :{noformat}Error: Failed to apply catalog: Munging failed for value # in class content: no implicit conversion of Puppet::Pops::Types::PSensitiveType::Sensitive into String/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/checksums.rb:57:in `digest'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/checksums.rb:57:in `hexdigest'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/checksums.rb:57:in `sha256'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/file/checksum.rb:27:in `sum'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/file/content.rb:67:in `block (2 levels) in
Jira (PUP-11846) Munging failed for value # in class content: no implicit conversion of Puppet::Pops::Types::PSensitiveType::Sensitive into String
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-11846
Munging failed for value # in class content: no implicit conversion of Puppet::Pops::Types::PSensitiveType::Sensitive into String
Change By:
Nate McCurdy
*Puppet Version:* 7.24.0*Puppet Server Version:* n/a*OS Name/Version:* n/ah2. The ProblemUsing a {{Deferred}} {{inline_epp()}} to render Sensitive content into a {{file}} resource while using {{--no-preprocess_deferred}} throws the following error message:{noformat}Error: Failed to apply catalog: Munging failed for value # in class content: no implicit conversion of Puppet::Pops::Types::PSensitiveType::Sensitive into String{noformat}h2. ReproductionGiven this Puppet code:{code}$cert = Sensitive('hello')$intermediate = Sensitive('world')$chain= Deferred('inline_epp', ["<%= \$cert %>\n<%= \$intermediate %>\n", { 'cert' => $cert, 'intermediate' => $intermediate,}])file { '/tmp/test_chain.pem': ensure => 'file', content => $chain,}{code}With Puppet 7.24.0 and the {{--no-preprocess_deferred}} option, apply the manifest above:{noformat}$ puppet apply test.pp --no-preprocess_deferredNotice: Compiled catalog for nate in environment production in 0.01 secondsError: Failed to apply catalog: Munging failed for value # in class content: no implicit conversion of Puppet::Pops::Types::PSensitiveType::Sensitive into String{noformat}Running puppet apply without {{--no-preprocess_deferred}} succeeds:{noformat}$ puppet apply test.ppNotice: Compiled catalog for nate in environment production in 0.01 secondsNotice: /Stage[main]/Main/File[/tmp/test_chain.pem]/ensure: changed [redacted] to [redacted]Notice: Applied catalog in 0.01 seconds{noformat}h2. More InfoI also found that I can fix the problem by not using {{inline_epp()}}.If I change the {{$chain}} variable to be built with {{join()}}, it works:{code}# This isn't ideal because the file needs a trailing newline, which join() can't do.$chain = Sensitive(Deferred('join', [[$cert.unwrap, $intermediate.unwrap], "\n"])){code}Here's a stack trace from using {{--trace}}:{noformat}Error: Failed to apply catalog: Munging failed for value # in class content: no implicit conversion of Puppet::Pops::Types::PSensitiveType::Sensitive into String/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/checksums.rb:57:in `digest'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/checksums.rb:57:in `hexdigest'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/checksums.rb:57:in `sha256'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/file/checksum.rb:27:in `sum'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/file/content.rb:67:in `block (2 levels) in '/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/parameter.rb:443:in `munge'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/property.rb:551:in `block in should='/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/property.rb:551:in `collect'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/property.rb:551:in
Jira (PUP-11846) Munging failed for value # in class content: no implicit conversion of Puppet::Pops::Types::PSensitiveType::Sensitive into String
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-11846
Munging failed for value # in class content: no implicit conversion of Puppet::Pops::Types::PSensitiveType::Sensitive into String
Change By:
Nate McCurdy
*Puppet Version:* 7.24.0*Puppet Server Version:* n/a*OS Name/Version:* n/ah2. The ProblemUsing a {{Deferred}} {{inline_epp()}} to render Sensitive content while using {{--no-preprocess_deferred}} throws the following error message:{noformat}Error: Failed to apply catalog: Munging failed for value # in class content: no implicit conversion of Puppet::Pops::Types::PSensitiveType::Sensitive into String{noformat}h2. ReproductionGiven this Puppet code:{code}$cert = Sensitive('hello')$intermediate = Sensitive('world')$chain= Deferred('inline_epp', ["<%= \$cert %>\n<%= \$intermediate %>\n", { 'cert' => $cert, 'intermediate' => $intermediate,}])file { '/tmp/test_chain.pem': ensure => 'file', content => $chain,}{code}With Puppet 7.24.0 and the {{--no-preprocess_deferred}} option, apply the manifest above:{noformat}$ puppet apply test.pp --no-preprocess_deferredNotice: Compiled catalog for nate in environment production in 0.01 secondsError: Failed to apply catalog: Munging failed for value # in class content: no implicit conversion of Puppet::Pops::Types::PSensitiveType::Sensitive into String{noformat}Running puppet apply without {{--no-preprocess_deferred}} succeeds:{noformat}$ puppet apply test.ppNotice: Compiled catalog for nate in environment production in 0.01 secondsNotice: /Stage[main]/Main/File[/tmp/test_chain.pem]/ensure: changed [redacted] to [redacted]Notice: Applied catalog in 0.01 seconds{noformat}h2. More InfoI also found that I can fix the problem by not using {{inline_epp()}}.If I change the {{$chain}} variable to be built with {{join()}}, it works:{code}# This isn't ideal because the file needs a trailing newline, which join() can't do.$chain = Sensitive(Deferred('join', [[$cert.unwrap, $intermediate.unwrap], "\n"])){code} Here's a stack trace from using {{--trace}}:{noformat}Error: Failed to apply catalog: Munging failed for value # in class content: no implicit conversion of Puppet::Pops::Types::PSensitiveType::Sensitive into String/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/checksums.rb:57:in `digest'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/checksums.rb:57:in `hexdigest'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/checksums.rb:57:in `sha256'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/file/checksum.rb:27:in `sum'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/file/content.rb:67:in `block (2 levels) in '/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/parameter.rb:443:in `munge'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/property.rb:551:in `block in should='/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/property.rb:551:in `collect'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/property.rb:551:in
Jira (PUP-11846) Munging failed for value # in class content: no implicit conversion of Puppet::Pops::Types::PSensitiveType::Sensitive into String
Title: Message Title
Nate McCurdy created an issue
Puppet / PUP-11846
Munging failed for value # in class content: no implicit conversion of Puppet::Pops::Types::PSensitiveType::Sensitive into String
Issue Type:
Bug
Affects Versions:
PUP 7.24.0
Assignee:
Unassigned
Created:
2023/05/02 9:29 AM
Priority:
Normal
Reporter:
Nate McCurdy
Puppet Version: 7.24.0 Puppet Server Version: n/a OS Name/Version: n/a The Problem Using a Deferred inline_epp() to render Sensitive content while using --no-preprocess_deferred throws the following error message:
Error: Failed to apply catalog: Munging failed for value # in class content: no implicit conversion of Puppet::Pops::Types::PSensitiveType::Sensitive into String
Reproduction Given this Puppet code:
$cert = Sensitive('hello')
$intermediate = Sensitive('world')
Jira (PUP-11597) 'puppet generate types' does not account for changes in the PuppetX module namespace
Title: Message Title Nate McCurdy commented on PUP-11597 Re: 'puppet generate types' does not account for changes in the PuppetX module namespace Based on a quick Slack conversation in the #puppet community channel, here's an extremely raw proof-of-concept fix for this problem: https://github.com/puppetlabs/puppet/pull/8928 It just enumerates all /lib/*/.rb files and compares their timestamps to the generated .resource_types/*.pp file. Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.456703.1658797423000.3725.1658868180232%40Atlassian.JIRA.
Jira (PUP-11597) 'puppet generate types' does not account for changes in the PuppetX module namespace
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-11597
'puppet generate types' does not account for changes in the PuppetX module namespace
Change By:
Nate McCurdy
*Puppet Version:* 7.18.0, 6.28.0*OS Name/Version:* CentOS 7h3. The ProblemWhen deploying changes to a custom type that includes relative code from the {{PuppetX}} namespace, and only the {{PuppetX}} ruby files have changed, the '{{{}generate types{}}}' command skips the type because it thinks it's up-to-date.This means any new/removed type parameters possibly won't be available due the environment isolation problem that {{puppet generate types}} was meant to solve.h3. Actual BehaviorThe '{{{}puppet generate types{}}}' command uses the following implementation to determine if a custom type's attributes should be built into '{{{}/.resource_types/*.pp{}}}':{code:ruby}Puppet::FileSystem::exist?(f) && (Puppet::FileSystem::stat(@path) <=> Puppet::FileSystem::stat(f)) <= 0{code}That's from [https://github.com/puppetlabs/puppet/blob/7.18.0/lib/puppet/generate/type.rb#L49]This compares the modified timestamp of the type file with that of the generated {{.resource_types/*.pp}} file.But if the file in {{lib/puppet/type/*.rb}} didn't change, it's timestamp will not get updated and Puppet will think the generated types are up to date.h3. Desired Behavior'{{ {} puppet generate types { }} } ' should account for PuppetX namespaced name-spaced code (e.g. '{{ {} /lib/puppet_x// { \ * } .rb {* } { } }}{*} ') that is included by a type that lives at '{{ {} /lib/puppet/type/ {}}}{ \ * }{{{} .rb { }} } '.
Add Comment
Jira (PUP-11597) 'puppet generate types' does not account for changes in the PuppetX module namespace
Title: Message Title Nate McCurdy updated an issue Puppet / PUP-11597 'puppet generate types' does not account for changes in the PuppetX module namespace Change By: Nate McCurdy Component/s: Type System Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.456703.1658797423000.3360.1658801280037%40Atlassian.JIRA.
Jira (PUP-11597) 'puppet generate types' does not account for changes in the PuppetX module namespace
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-11597
'puppet generate types' does not account for changes in the PuppetX module namespace
Change By:
Nate McCurdy
*Puppet Version:* 7.18.0, 6.28.0*OS Name/Version:* CentOS 7 h3. The Problem When deploying changes to a custom type that includes relative code from the {{PuppetX}} namespace, and only the {{PuppetX}} ruby files have changed, the '{{ {} generate types { }} } ' command skips the type because it thinks it's up-to-date.This means any new/removed type properties parameters possibly won't be available due the environment isolation problem that {{puppet generate types}} was meant to solve. h3. Actual BehaviorThe '{{ {} puppet generate types { }} } ' command uses the following implementation to determine if a custom type's attributes should be built into '{{ {} /.resource_types/*.pp { }} } ':{code:ruby} Puppet::FileSystem::exist?(f) && (Puppet::FileSystem::stat(@path) <=> Puppet::FileSystem::stat(f)) <= 0{code}That's from [ https://github.com/puppetlabs/puppet/blob/7.18.0/lib/puppet/generate/type.rb#L49 ] This compares the modified timestamp of the type file with that of the generated {{.resource_types/*.pp}} file.But if the file in {{lib/puppet/type/*.rb}} didn't change, it's timestamp will not get updated and Puppet will think the generated types are up to date. h3. Desired Behavior'{{ {} puppet generate types { }} } ' should account for PuppetX namespaced code (e.g. '{{ {} /lib/puppet_x// { * } .rb {* } { } }}{*} ') that is included by a type that lives at '{{ {} /lib/puppet/type/ {}}}{ * }{{{} .rb { }} } '.
Add Comment
Jira (PUP-11597) 'puppet generate types' does not account for changes in the PuppetX module namespace
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-11597
'puppet generate types' does not account for changes in the PuppetX module namespace
Change By:
Nate McCurdy
*Puppet Version:* 7.18.0, 6.28.0*OS Name/Version:* CentOS 7h3. The ProblemWhen deploying changes to a custom type that includes relative code from the {{PuppetX}} namespace, and only the {{PuppetX}} ruby files have changed, the '{{generate types}}' command skips the type because it thinks it's up-to-date.This means any new/removed type properties possibly won't be available due the environment isolation problem that {{puppet generate types}} was meant to solve.h3. Actual BehaviorThe '{{puppet generate types}}' command uses the following implementation to determine if a custom type's attributes should be built into '{{/.resource_types/*.pp}}':{code:ruby}Puppet::FileSystem::exist?(f) && (Puppet::FileSystem::stat(@path) <=> Puppet::FileSystem::stat(f)) <= 0{code}That's from https://github.com/puppetlabs/puppet/blob/7.18.0/lib/puppet/generate/type.rb#L49This compares the modified timestamp of the type file with that of the generated {{.resource_types/*.pp}} file.But if the file in {{lib/puppet/type/*.rb}} didn't change, it's timestamp will not get updated and Puppet will think the generated types are up to date.h3. Desired Behavior'{{puppet generate types}}' should account for PuppetX namespaced code (e.g. " ' {{/lib/puppet_x//*.rb}} " ' ) that is included by a type that lives at ' {{/lib/puppet/type/*.rb}} ' .
Add Comment
This message
Jira (PUP-11597) 'puppet generate types' does not account for changes in the PuppetX module namespace
Title: Message Title Nate McCurdy created an issue Puppet / PUP-11597 'puppet generate types' does not account for changes in the PuppetX module namespace Issue Type: Bug Affects Versions: PUP 6.28.0, PUP 7.18.0 Assignee: Unassigned Created: 2022/07/25 6:03 PM Priority: Normal Reporter: Nate McCurdy Puppet Version: 7.18.0, 6.28.0 OS Name/Version: CentOS 7 The Problem When deploying changes to a custom type that includes relative code from the PuppetX namespace, and only the PuppetX ruby files have changed, the 'generate types' command skips the type because it thinks it's up-to-date. This means any new/removed type properties possibly won't be available due the environment isolation problem that puppet generate types was meant to solve. Actual Behavior The 'puppet generate types' command uses the following implementation to determine if a custom type's attributes should be built into '/.resource_types/*.pp': Puppet::FileSystem::exist?(f) && (Puppet::FileSystem::stat(@path) <=> Puppet::FileSystem::stat(f)) <= 0 That's from https://github.com/puppetlabs/puppet/blob/7.18.0/lib/puppet/generate/type.rb#L49 This compares the modified timestamp of the type file with that of the generated .resource_types/*.pp file. But if the file in lib/puppet/type/*.rb didn't change, it's timestamp will not get updated and Puppet will think the generated types are up to date. Desired Behavior 'puppet generate
Jira (FACT-1557) Extend "cloud" fact to Google Compute Engine
Title: Message Title Nate McCurdy commented on FACT-1557 Re: Extend "cloud" fact to Google Compute Engine I would also like to see the cloud fact support GCP/GCE. I put up a proposed patch which allows cloud.provider to resolve to "gce": https://github.com/puppetlabs/facter/pull/2479 Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.168608.148349210.10700.1649788080046%40Atlassian.JIRA.
Jira (PUP-11440) No option to fail fast when agent-specified environment does not exist
Title: Message Title Nate McCurdy commented on PUP-11440 Re: No option to fail fast when agent-specified environment does not exist Ah, thank you josh; your responses make sense, and I see now how PUP-6802 does help agents to self-heal. I'm also definitely going to start using strict_environment_mode for our agent-specified environment hosts (after this current bug gets fixed, that is). Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.433415.1643667502000.21652.1645563480035%40Atlassian.JIRA.
Jira (PUP-11440) No option to fail fast when agent-specified environment does not exist
Title: Message Title Nate McCurdy commented on PUP-11440 Re: No option to fail fast when agent-specified environment does not exist Having strict mode abort early sounds good to me. But switching to the "production" environment by default in the non-strict mode is still a bit concerning to me. In a setup where there is no server-specified environment, how can we be sure that "production" is the correct one to fall back to? For example, if a chunk of nodes normally run against a canary environment (e.g. -E canary) then want to run against a feature branch but a human typos the name, that node will then revert to production for a run rather than the usual canary environment. We don't currently see this auto-switching behavior in our systems that are running 6.19.1. When did that make it in to Puppet? I see that we should start using strict mode to guard against this problem, but I'm not sure when we need to and when we can. Is that a Puppet 7 only feature? Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.433415.1643667502000.13642.1644513600144%40Atlassian.JIRA.
Jira (PUP-11440) No option to fail fast when agent-specified environment does not exist
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-11440
No option to fail fast when agent-specified environment does not exist
Change By:
Nate McCurdy
h2. The ProblemWhen using an agent-specified environment workflow and the requested environment does not exist, there is no way to halt the Puppet run early and prevent a catalog compilation.Additionally, the behavior of automatically switching to the "production" environment is unexpected and not desired in an agent-specified environment workflow.This behavior exposes multiple issues... *When not using sctrict_environment_mode:* * The agent gets a 404 from the {{file_metadatas}} endpoint, but it still submits a catalog request: ** {noformat}[root@agent7 ~]# puppet agent -t --environment fake --http_debugInfo: Using environment 'fake'opening connection to server7.vagrant:8140...openedstarting SSL for server7.vagrant:8140...SSL established, protocol: TLSv1.3, cipher: TLS_AES_128_GCM_SHA256<- "GET /puppet/v3/file_metadatas/plugins?recurse=false=manage_type=sha256_per.5-p203 (x86_64-linux)\r\nAccept: application/json, text/pson\r\nAccept-Encoding: gzip;q=1.0,deflate-> "HTTP/1.1 404 Not Found\r\n"-> "Date: Mon, 31 Jan 2022 21:47:28 GMT\r\n"-> "Content-Type: application/json;charset=utf-8\r\n"-> "X-Puppet-Version: 7.14.0\r\n"-> "Content-Length: 87\r\n"-> "\r\n"reading 87 bytes...-> "{\"message\":\"Not Found: Could not find environment 'fake'\",\"issue_kind\":\"RUNTIME_ERROR\"}"read 87 bytesConn keep-aliveNotice: Environment 'fake' not found on server, skipping initial pluginsync.<- "POST /puppet/v3/catalog/agent7.vagrant?environment=fake HTTP/1.1\r\nX-Puppet-Version: 7.14.0\r\n{noformat} * ** This puts unneeded load on the Puppetserver while it compiles a catalog. * The server responds with a 200, which is odd considering the environment doesn't exist. ** {noformat}-> "HTTP/1.1 200 OK\r\n"-> "Date: Mon, 31 Jan 2022 21:47:28 GMT\r\n"-> "Content-Type: application/vnd.puppet.rich+json; charset=utf-8\r\n"-> "X-Puppet-Version: 7.14.0\r\n" {noformat} * The agent then switches to the "production" environment. Supposedly Apparently because it's server-specified is "production" . But in my case the external node classifier (ENC) is NOT specifying any environment at all. ** {noformat}Notice: Local environment: 'fake' doesn't match server specified environment 'production', restarting agent run with environment 'production' {noformat} * Here's my ENC script used for testing: ** {code:bash}#!/bin/bashcat <---class: {}parameters: {}EOF {code} * The agent then does pluginsync against the production environment and follows up with another catalog request, this time against production. ** {noformat}<- "POST /puppet/v3/catalog/agent7.vagrant?environment=production HTTP/1.1\r\nX-Puppet-Version: 7.14.0\r\nUser-Agent: Puppet/7.14.0 Ruby/2.7.5-p203 (x86_64-linux)\r\nAccept: application/vnd.puppet.rich+json, application/json, text/pson\r\nContent-Type: application/x-www-form-urlencoded\r\nAccept-Encoding:
Jira (PUP-11324) puppet-agent-6.25.0 breaks puppetserver-6.17.0 with multithreading enabled
Title: Message Title Nate McCurdy commented on PUP-11324 Re: puppet-agent-6.25.0 breaks puppetserver-6.17.0 with multithreading enabled I've been seeing a lot of these "Attempt to redefine loader" errors shortly after puppetserver has started and is taking some agent traffic. The errors go away after being thrown 1-3 times. stacktrace-attempt_to_redefine_loader.txt My Puppetserver host is using: puppet-agent-7.14.0-1.el7.x86_64 puppetserver-7.6.0-1.el7.noarch Attached is a stack trace from one such error. stacktrace-attempt_to_redefine_loader.txt Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.420333.1634736217000.7704.1643843580113%40Atlassian.JIRA.
Jira (PUP-11324) puppet-agent-6.25.0 breaks puppetserver-6.17.0 with multithreading enabled
Title: Message Title Nate McCurdy updated an issue Puppet / PUP-11324 puppet-agent-6.25.0 breaks puppetserver-6.17.0 with multithreading enabled Change By: Nate McCurdy Attachment: stacktrace-attempt_to_redefine_loader.txt Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.420333.1634736217000.7703.1643843580065%40Atlassian.JIRA.
Jira (PUP-11440) No option to fail fast when agent-specified environment does not exist
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-11440
No option to fail fast when agent-specified environment does not exist
Change By:
Nate McCurdy
h2. The ProblemWhen using an agent-specified environment workflow and the requested environment does not exist, there is no way to halt the Puppet run early and prevent a catalog compilation.Additionally, the behavior of automatically switching to the "production" environment is unexpected and not desired in an agent-specified environment workflow.This behavior exposes multiple issues... *When not using sctrict_environment_mode:* * The agent gets a 404 from the {{file_metadatas}} endpoint, but it still submits a catalog request: ** {noformat}[root@agent7 ~]# puppet agent -t --environment fake --http_debugInfo: Using environment 'fake'opening connection to server7.vagrant:8140...openedstarting SSL for server7.vagrant:8140...SSL established, protocol: TLSv1.3, cipher: TLS_AES_128_GCM_SHA256<- "GET /puppet/v3/file_metadatas/plugins?recurse=false=manage_type=sha256_per.5-p203 (x86_64-linux)\r\nAccept: application/json, text/pson\r\nAccept-Encoding: gzip;q=1.0,deflate-> "HTTP/1.1 404 Not Found\r\n"-> "Date: Mon, 31 Jan 2022 21:47:28 GMT\r\n"-> "Content-Type: application/json;charset=utf-8\r\n"-> "X-Puppet-Version: 7.14.0\r\n"-> "Content-Length: 87\r\n"-> "\r\n"reading 87 bytes...-> "{\"message\":\"Not Found: Could not find environment 'fake'\",\"issue_kind\":\"RUNTIME_ERROR\"}"read 87 bytesConn keep-aliveNotice: Environment 'fake' not found on server, skipping initial pluginsync.<- "POST /puppet/v3/catalog/agent7.vagrant?environment=fake HTTP/1.1\r\nX-Puppet-Version: 7.14.0\r\n{noformat} * ** This puts unneeded load on the Puppetserver while it compiles a catalog. * The server responds with a 200, which is odd considering the environment doesn't exist. ** {noformat}-> "HTTP/1.1 200 OK\r\n"-> "Date: Mon, 31 Jan 2022 21:47:28 GMT\r\n"-> "Content-Type: application/vnd.puppet.rich+json; charset=utf-8\r\n"-> "X-Puppet-Version: 7.14.0\r\n" {noformat} * The agent then switches to the "production" environment. Supposedly because it's server-specified. But in my case the external node classifier (ENC) is NOT specifying any environment at all. ** {noformat}Notice: Local environment: 'fake' doesn't match server specified environment 'production', restarting agent run with environment 'production' {noformat} * Here's my ENC script used for testing: ** {code:bash}#!/bin/bashcat <---class: {}parameters: {}EOF {code} * The agent then does pluginsync against the production environment and follows up with another catalog request, this time against production. ** {noformat}<- "POST /puppet/v3/catalog/agent7.vagrant?environment=production HTTP/1.1\r\nX-Puppet-Version: 7.14.0\r\nUser-Agent: Puppet/7.14.0 Ruby/2.7.5-p203 (x86_64-linux)\r\nAccept: application/vnd.puppet.rich+json, application/json, text/pson\r\nContent-Type: application/x-www-form-urlencoded\r\nAccept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3\r\nHost:
Jira (PUP-10582) Puppet runs should fail fast when no environment can be found
Title: Message Title Nate McCurdy commented on PUP-10582 Re: Puppet runs should fail fast when no environment can be found Opened PUP-11440 to look at a regression in Puppet 7 Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.365528.1594348057000.4863.1643668021887%40Atlassian.JIRA.
Jira (PUP-11440) No option to fail fast when agent-specified environment does not exist
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-11440
No option to fail fast when agent-specified environment does not exist
Change By:
Nate McCurdy
h2. The ProblemWhen using an agent-specified environment workflow and the requested environment does not exist, there is no way to halt the Puppet run early and prevent a catalog compilation.Additionally, the behavior of automatically switching to the "production" environment is unexpected and not desired in an agent-specified environment workflow.This behavior exposes multiple issues... *When not using sctrict_environment_mode:* * The agent gets a 404 from the {{file_metadatas}} endpoint, but it still submits a catalog request: ** {noformat}[root@agent7 ~]# puppet agent -t --environment fake --http_debugInfo: Using environment 'fake'opening connection to server7.vagrant:8140...openedstarting SSL for server7.vagrant:8140...SSL established, protocol: TLSv1.3, cipher: TLS_AES_128_GCM_SHA256<- "GET /puppet/v3/file_metadatas/plugins?recurse=false=manage_type=sha256_per.5-p203 (x86_64-linux)\r\nAccept: application/json, text/pson\r\nAccept-Encoding: gzip;q=1.0,deflate-> "HTTP/1.1 404 Not Found\r\n"-> "Date: Mon, 31 Jan 2022 21:47:28 GMT\r\n"-> "Content-Type: application/json;charset=utf-8\r\n"-> "X-Puppet-Version: 7.14.0\r\n"-> "Content-Length: 87\r\n"-> "\r\n"reading 87 bytes...-> "{\"message\":\"Not Found: Could not find environment 'fake'\",\"issue_kind\":\"RUNTIME_ERROR\"}"read 87 bytesConn keep-aliveNotice: Environment 'fake' not found on server, skipping initial pluginsync.<- "POST /puppet/v3/catalog/agent7.vagrant?environment=fake HTTP/1.1\r\nX-Puppet-Version: 7.14.0\r\n{noformat} * ** This puts unneeded load on the Puppetserver while it compiles a catalog. * The server responds with a 200, which is odd considering the environment doesn't exist. ** { code:java noformat }-> "HTTP/1.1 200 OK\r\n"-> "Date: Mon, 31 Jan 2022 21:47:28 GMT\r\n"-> "Content-Type: application/vnd.puppet.rich+json; charset=utf-8\r\n"-> "X-Puppet-Version: 7.14.0\r\n" { code noformat } * The agent then switches to the "production" environment. Supposedly because it's server-specified. But in my case the external node classifier (ENC) is NOT specifying any environment at all. ** { code:java noformat }Notice: Local environment: 'fake' doesn't match server specified environment 'production', restarting agent run with environment 'production' { code noformat } * Here's my ENC script used for testing: ** {code: java bash }#!/bin/bashcat <---class: {}parameters: {}EOF {code} * The agent then does pluginsync against the production environment and follows up with another catalog request, this time against production. ** { code:java noformat }<- "POST /puppet/v3/catalog/agent7.vagrant?environment=production HTTP/1.1\r\nX-Puppet-Version: 7.14.0\r\nUser-Agent: Puppet/7.14.0 Ruby/2.7.5-p203 (x86_64-linux)\r\nAccept: application/vnd.puppet.rich+json, application/json, text/pson\r\nContent-Type: application/x-www-form-urlencoded\r\nAccept-Encoding:
Jira (PUP-11440) No option to fail fast when agent-specified environment does not exist
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-11440
No option to fail fast when agent-specified environment does not exist
Change By:
Nate McCurdy
h2. The ProblemWhen using an agent-specified environment workflow and the requested environment does not exist, there is no way to halt the Puppet run early and prevent a catalog compilation.Additionally, the behavior of automatically switching to the "production" environment is unexpected and not desired in an agent-specified environment workflow.This behavior exposes multiple issues... *When not using sctrict_environment_mode:* * The agent gets a 404 from the {{file_metadatas}} endpoint, but it still submits a catalog request: ** {noformat}[root@agent7 ~]# puppet agent -t --environment fake --http_debugInfo: Using environment 'fake'opening connection to server7.vagrant:8140...openedstarting SSL for server7.vagrant:8140...SSL established, protocol: TLSv1.3, cipher: TLS_AES_128_GCM_SHA256<- "GET /puppet/v3/file_metadatas/plugins?recurse=false=manage_type=sha256_per.5-p203 (x86_64-linux)\r\nAccept: application/json, text/pson\r\nAccept-Encoding: gzip;q=1.0,deflate-> "HTTP/1.1 404 Not Found\r\n"-> "Date: Mon, 31 Jan 2022 21:47:28 GMT\r\n"-> "Content-Type: application/json;charset=utf-8\r\n"-> "X-Puppet-Version: 7.14.0\r\n"-> "Content-Length: 87\r\n"-> "\r\n"reading 87 bytes...-> "{\"message\":\"Not Found: Could not find environment 'fake'\",\"issue_kind\":\"RUNTIME_ERROR\"}"read 87 bytesConn keep-aliveNotice: Environment 'fake' not found on server, skipping initial pluginsync.<- "POST /puppet/v3/catalog/agent7.vagrant?environment=fake HTTP/1.1\r\nX-Puppet-Version: 7.14.0\r\n{noformat} * ** This puts unneeded load on the Puppetserver while it compiles a catalog. * The server responds with a 200, which is odd considering the environment doesn't exist. ** {code:java}-> "HTTP/1.1 200 OK\r\n"-> "Date: Mon, 31 Jan 2022 21:47:28 GMT\r\n"-> "Content-Type: application/vnd.puppet.rich+json; charset=utf-8\r\n"-> "X-Puppet-Version: 7.14.0\r\n" {code} * The agent then switches to the "production" environment. Supposedly because it's server-specified. But in my case the external node classifier (ENC) is NOT specifying any environment at all. ** {code:java}Notice: Local environment: 'fake' doesn't match server specified environment 'production', restarting agent run with environment 'production' {code} * Here's my ENC script used for testing: ** {code:java}#!/bin/bashcat <---class: {}parameters: {}EOF {code} * The agent then does pluginsync against the production environment and follows up with another catalog request, this time against production. ** {code:java}<- "POST /puppet/v3/catalog/agent7.vagrant?environment=production HTTP/1.1\r\nX-Puppet-Version: 7.14.0\r\nUser-Agent: Puppet/7.14.0 Ruby/2.7.5-p203 (x86_64-linux)\r\nAccept: application/vnd.puppet.rich+json, application/json, text/pson\r\nContent-Type: application/x-www-form-urlencoded\r\nAccept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3\r\nHost:
Jira (PUP-11440) No option to fail fast when agent-specified environment does not exist
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-11440
No option to fail fast when agent-specified environment does not exist
Change By:
Nate McCurdy
h2. The ProblemWhen using an agent-specified environment workflow and the requested environment does not exist, there is no way to halt the Puppet run early and prevent a catalog compilation.Additionally, the behavior of automatically switching to the "production" environment is unexpected and not desired in an agent-specified environment workflow. This behavior exposes multiple issues ... *When not using sctrict_environment_mode : * * The agent gets a 404 from the {{file_metadatas}} endpoint, but it still submits a catalog request: ** {noformat}[root@agent7 ~]# puppet agent -t --environment fake --http_debugInfo: Using environment 'fake'opening connection to server7.vagrant:8140...openedstarting SSL for server7.vagrant:8140...SSL established, protocol: TLSv1.3, cipher: TLS_AES_128_GCM_SHA256<- "GET /puppet/v3/file_metadatas/plugins?recurse=false=manage_type=sha256_per.5-p203 (x86_64-linux)\r\nAccept: application/json, text/pson\r\nAccept-Encoding: gzip;q=1.0,deflate-> "HTTP/1.1 404 Not Found\r\n"-> "Date: Mon, 31 Jan 2022 21:47:28 GMT\r\n"-> "Content-Type: application/json;charset=utf-8\r\n"-> "X-Puppet-Version: 7.14.0\r\n"-> "Content-Length: 87\r\n"-> "\r\n"reading 87 bytes...-> "{\"message\":\"Not Found: Could not find environment 'fake'\",\"issue_kind\":\"RUNTIME_ERROR\"}"read 87 bytesConn keep-aliveNotice: Environment 'fake' not found on server, skipping initial pluginsync.<- "POST /puppet/v3/catalog/agent7.vagrant?environment=fake HTTP/1.1\r\nX-Puppet-Version: 7.14.0\r\n{noformat} * ** This puts unneeded load on the Puppetserver while it compiles a catalog. * * The server responds with a 200, which is odd considering the environment doesn't exist. ** * {code:java}-> "HTTP/1.1 200 OK\r\n"-> "Date: Mon, 31 Jan 2022 21:47:28 GMT\r\n"-> "Content-Type: application/vnd.puppet.rich+json; charset=utf-8\r\n"-> "X-Puppet-Version: 7.14.0\r\n" {code} * The agent then switches to the "production" environment. Supposedly because it's server-specified. But in my case the external node classifier (ENC) is NOT specifying any environment at all. ** {code:java}Notice: Local environment: 'fake' doesn't match server specified environment 'production', restarting agent run with environment 'production' {code} * ** Here's my ENC script used for testing: ** * {code:java}#!/bin/bashcat <---class: {}parameters: {}EOF {code} * The agent then does pluginsync against the production environment and follows up with another catalog request, this time against production. ** {code:java}<- "POST /puppet/v3/catalog/agent7.vagrant?environment=production HTTP/1.1\r\nX-Puppet-Version: 7.14.0\r\nUser-Agent: Puppet/7.14.0 Ruby/2.7.5-p203 (x86_64-linux)\r\nAccept: application/vnd.puppet.rich+json, application/json, text/pson\r\nContent-Type: application/x-www-form-urlencoded\r\nAccept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3\r\nHost:
Jira (PUP-11440) No option to fail fast when agent-specified environment does not exist
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-11440
No option to fail fast when agent-specified environment does not exist
Change By:
Nate McCurdy
h2. The ProblemWhen using an agent-specified environment workflow and the requested environment does not exist, there is no way to halt the Puppet run early and prevent a catalog compilation.Additionally, the behavior of automatically switching to the "production" environment is unexpected and not desired in an agent-specified environment workflow. This behavior exposes multiple issues: * The agent gets a 404 from the {{file_metadatas}} endpoint, but it still submits a catalog request: ** {noformat} [root@agent7 ~]# puppet agent -t --environment fake --http_debugInfo: Using environment 'fake'opening connection to server7.vagrant:8140...openedstarting SSL for server7.vagrant:8140...SSL established, protocol: TLSv1.3, cipher: TLS_AES_128_GCM_SHA256<- "GET /puppet/v3/file_metadatas/plugins?recurse=false=manage_type=sha256_per.5-p203 (x86_64-linux)\r\nAccept: application/json, text/pson\r\nAccept-Encoding: gzip;q=1.0,deflate-> "HTTP/1.1 404 Not Found\r\n"-> "Date: Mon, 31 Jan 2022 21:47:28 GMT\r\n"-> "Content-Type: application/json;charset=utf-8\r\n"-> "X-Puppet-Version: 7.14.0\r\n"-> "Content-Length: 87\r\n"-> "\r\n"reading 87 bytes...-> "{\"message\":\"Not Found: Could not find environment 'fake'\",\"issue_kind\":\"RUNTIME_ERROR\"}"read 87 bytesConn keep-aliveNotice: Environment 'fake' not found on server, skipping initial pluginsync.<- "POST /puppet/v3/catalog/agent7.vagrant?environment=fake HTTP/1.1\r\nX-Puppet-Version: 7.14.0\r\n{noformat} * ** This puts unneeded load on the Puppetserver while it compiles a catalog. ** The server responds with a 200, which is odd considering the environment doesn't exist. *** {code:java} -> "HTTP/1.1 200 OK\r\n"-> "Date: Mon, 31 Jan 2022 21:47:28 GMT\r\n"-> "Content-Type: application/vnd.puppet.rich+json; charset=utf-8\r\n"-> "X-Puppet-Version: 7.14.0\r\n" {code} * * The agent then switches to the "production" environment. Supposedly because it's server-specified. But in my case the external node classifier (ENC) is NOT specifying any environment at all. ** * {code:java} Notice: Local environment: 'fake' doesn't match server specified environment 'production', restarting agent run with environment 'production' {code} * ** Here's my ENC script used for testing: *** * {code:java} #!/bin/bashcat <---class: {}parameters: {}EOF {code} * * The agent then does pluginsync against the production environment and follows up with another catalog request, this time against production. ** * {code:java} <- "POST /puppet/v3/catalog/agent7.vagrant?environment=production HTTP/1.1\r\nX-Puppet-Version: 7.14.0\r\nUser-Agent: Puppet/7.14.0 Ruby/2.7.5-p203 (x86_64-linux)\r\nAccept: application/vnd.puppet.rich+json, application/json, text/pson\r\nContent-Type: application/x-www-form-urlencoded\r\nAccept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3\r\nHost: server7.vagrant:8140\r\nContent-Length:
Jira (PUP-11440) No option to fail fast when agent-specified environment does not exist
Title: Message Title Nate McCurdy created an issue Puppet / PUP-11440 No option to fail fast when agent-specified environment does not exist Issue Type: Bug Affects Versions: PUP 7.14.0 Assignee: Unassigned Created: 2022/01/31 2:18 PM Priority: Normal Reporter: Nate McCurdy The Problem When using an agent-specified environment workflow and the requested environment does not exist, there is no way to halt the Puppet run early and prevent a catalog compilation. Additionally, the behavior of automatically switching to the "production" environment is unexpected and not desired in an agent-specified environment workflow. This behavior exposes multiple issues: The agent gets a 404 from the file_metadatas endpoint, but it still submits a catalog request: [root@agent7 ~]# puppet agent -t --environment fake --http_debug Info: Using environment 'fake'
Jira (PUP-6802) Agent cannot compile catalog if it specifies an non-existent environment in puppet.conf even when the classifier is controlling environment
Title: Message Title Nate McCurdy commented on PUP-6802 Re: Agent cannot compile catalog if it specifies an non-existent environment in puppet.conf even when the classifier is controlling environment This looks like it introduced a regression in behavior related to PUP-1763 and PUP-10582 for non-existent environments. In cases where and ENC is not providing an environment, the "ignore_plugin_failures: false" setting should be causing a failed/skipped pluginsync to immediately fail the Puppet run. But in Puppet 7.14.0, the pluginsync failure is ignored and the agent continues to request a catalog from the puppetserver, which results in a 500 error due to the environment not existing. For example, on Puppet 6.19.1, using "ignore_plugin_failures: false" correctly stops the run: [agent]> puppet --version 6.19.1 [agent]> sudo puppet agent -t --environment fake --no-ignore_plugin_errors Info: Retrieving pluginfacts Error: /File[/opt/puppetlabs/puppet/cache/facts.d]: Could not evaluate: Could not retrieve information from environment fake source(s) puppet:///pluginfacts Error: Failed to apply catalog: Failed to retrieve pluginfacts: Could not retrieve information from environment fake source(s) puppet:///pluginfacts But with Puppet 7.14.0, the run does not stop and a catalog is requested. Ultimately, in my case the run fails because the code-id script can't read from a non-existent environment: [agent]> puppet --version
Jira (PUP-11402) puppet lookup --explain fails out of the box starting with 7.13.1
Title: Message Title Nate McCurdy commented on PUP-11402 Re: puppet lookup --explain fails out of the box starting with 7.13.1 I did a bit of digging into recent changes since 7.12.1, and I found that this change https://github.com/puppetlabs/puppet/pull/8789 from PUP-8094 is most likely related. That change was part of the unreleased 7.13.0 tag. That change, which switches to using trusted information from the agent's cert when getting the node object for puppet lookup, creates a connection to the configured CA server to fetch the agent's cert. It's that connection that ultimately leads to the error in this ticket. service = Puppet.runtime[:http] session = service.create_session cert = session.route_to(:ca) # <== This is where the error originates from. cert = cert.get_certificate(node) trusted = Puppet::Context::TrustedInformation.new(true, node, cert) That patch looks like it assumes the user will always want to fetch trusted information from the agent's cert on the CA server. That the patch also adds a certificate setup step to the acceptance tests also implies that. I think that assumption can't be made though since there are legitimate reasons to run puppet lookup without having an agent<->server relationship or trusted information (e.g. debugging local code deploys for a puppet apply workflow with puppet lookup).
Jira (PDB-5350) puppet-query for null fact returns empty set
Title: Message Title Nate McCurdy commented on PDB-5350 Re: puppet-query for null fact returns empty set To extend this question a bit: What PQL query should we use to search for nodes that do not contain a given fact? Is that fundamentally different than searching for nodes with a fact whose value is undef (in Puppet)? Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.421378.1635377172000.165085.1635377460048%40Atlassian.JIRA.
Jira (PUP-11241) Not all user attributes honor forcelocal (e.g. home, shell)
Title: Message Title Nate McCurdy commented on PUP-11241 Re: Not all user attributes honor forcelocal (e.g. home, shell) I've put up a proposed patch here: https://github.com/puppetlabs/puppet/pull/8767 Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.415709.1631667793000.130871.1631738520028%40Atlassian.JIRA.
Jira (PUP-11241) Not all user attributes honor forcelocal (e.g. home, shell)
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-11241
Not all user attributes honor forcelocal (e.g. home, shell)
Change By:
Nate McCurdy
*Puppet Version:* 6.19.1, 7.9.0*Puppet Server Version:* N/A*OS Name/Version:* CentOS 7When setting {{forcelocal => true}} on a {{user}} resource, I'd expect all user attributes available via {{/etc/passwd}} to be used as the "is" value for the insync? check.This appears to not be the case for the {{home} ] } and {{shell}} attributes.Those are always checked against their values from directory services rather than from {{/etc/passwd}}, which means those attributes appear to change on each puppet run and the {{user}} resource is no longer idempotent.*Desired Behavior:*When an OS has directory services enabled (e.g. LDAP via SSSD) and a puppet-managed user exists in LDAP...Given an {{/etc/passwd}} file containing:{noformat}nate:x:1000:1001:hello world:/opt/hello:/bin/zsh{noformat}This code should read "shell", "home", and "comment" all from {{/etc/passwd}} when comparing the "is" state to the "should" state:{code}user { 'nate': ensure => present, forcelocal => true, shell => '/bin/zsh', home => '/opt/hello', comment=> 'hello world',}{code}*Actual Behavior:*Only "uid", "gid", "comment", and "groups" are fetched from {{/etc/passwd}} when {{forcelocal => true}}:https://github.com/puppetlabs/puppet/blob/7.11.0/lib/puppet/provider/user/useradd.rb#L60-L78"home" and "shell" are fetched from directory services, not from {{/etc/passwd}}.The user resource shows a change to "home" and "shell" on each Puppet run even though nothing is changing.*Related:*Support for "comment" when forcelocal is true was added here: https://github.com/puppetlabs/puppet/pull/7768Basically, I'm asking for that same support for all the other attributes pulled from {{/etc/passwd}} in [the finduser() method|https://github.com/puppetlabs/puppet/blob/7.11.0/lib/puppet/provider/user/useradd.rb#L80-L96]
Add Comment
Jira (PUP-11241) Not all user attributes honor forcelocal (e.g. home, shell)
Title: Message Title Nate McCurdy updated an issue Puppet / PUP-11241 Not all user attributes honor forcelocal (e.g. home, shell) Change By: Nate McCurdy Affects Version/s: PUP 7.10.0 Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.415709.1631667793000.130170.1631668860032%40Atlassian.JIRA.
Jira (PUP-11241) Not all user attributes honor forcelocal (e.g. home, shell)
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-11241
Not all user attributes honor forcelocal (e.g. home, shell)
Change By:
Nate McCurdy
*Puppet Version:* 6.19.1, 7.9.0*Puppet Server Version:* N/A*OS Name/Version:* CentOS 7When setting {{forcelocal => true}} on a {{user}} resource, I'd expect all user attributes available via {{/etc/passwd}} to be used as the "is" value for the insync? check.This appears to not be the case for the {{home}] and {{shell}} attributes.Those are always checked against their values from directory services rather than from {{/etc/passwd}}, which means those attributes appear to change on each puppet run and the {{user}} resource is no longer idempotent.*Desired Behavior:*When an OS has directory services enabled (e.g. LDAP via SSSD) and a puppet-managed user exists in LDAP...Given an {{/etc/passwd}} file containing:{noformat}nate:x:1000:1001:hello world:/opt/hello:/bin/zsh{noformat}This code should read "shell", "home", and "comment" all from {{/etc/passwd}} when comparing the "is" state to the "should" state:{code}user { 'nate': ensure => present, forcelocal => true, shell => '/bin/zsh', home => '/opt/hello', comment=> 'hello world',}{code}*Actual Behavior:*Only "uid", "gid", "comment", and "groups" are fetched from {{/etc/passwd}} when {{forcelocal => true}}:https://github.com/puppetlabs/puppet/blob/7.11.0/lib/puppet/provider/user/useradd.rb#L60-L78"home" and "shell" are fetched from directory services, not from {{/etc/passwd}}.The user resource shows a change to "home" and "shell" on each Puppet run even though nothing is changing. *Related:*Support for "comment" when forcelocal is true was added here: https://github.com/puppetlabs/puppet/pull/7768Basically, I'm asking for that same support for all the other attributes pulled from {{/etc/passwd}} in [the finduser() method|https://github.com/puppetlabs/puppet/blob/7.11.0/lib/puppet/provider/user/useradd.rb#L80-L96]
Add Comment
Jira (PUP-11241) Not all user attributes honor forcelocal (e.g. home, shell)
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-11241
Not all user attributes honor forcelocal (e.g. home, shell)
Change By:
Nate McCurdy
*Puppet Version:* 6.19.1, 7.9.0*Puppet Server Version:* N/A*OS Name/Version:* CentOS 7When setting {{forcelocal => true}} on a {{user}} resource, I'd expect all user attributes available via {{/etc/passwd}} to be used as the "is" value for the insync? check.This appears to not be the case for the {{home}] and {{shell}} attributes.Those are always checked against their values from directory services rather than from {{/etc/passwd}}, which means those attributes appear to change on each puppet run and the {{user}} resource is no longer idempotent.*Desired Behavior:*When an OS has directory services enabled (e.g. LDAP via SSSD) , and with a puppet-managed user exists in LDAP...Given an {{/etc/passwd}} file containing:{noformat}nate:x:1000:1001:hello world:/opt/hello:/bin/zsh{noformat}This code should read "shell", "home", and "comment" all from {{/etc/passwd}} when comparing the "is" state to the "should" state:{code}user { 'nate': ensure => present, forcelocal => true, shell => '/bin/zsh', home => '/opt/hello', comment=> 'hello world',}{code}*Actual Behavior:*Only "uid", "gid", "comment", and "groups" are fetched from {{/etc/passwd}} when {{forcelocal => true}}:https://github.com/puppetlabs/puppet/blob/7.11.0/lib/puppet/provider/user/useradd.rb#L60-L78"home" and "shell" are fetched from directory services, not from {{/etc/passwd}}.The user resource shows a change to "home" and "shell" on each Puppet run even though nothing is changing.
Add Comment
Jira (PUP-11241) Not all user attributes honor forcelocal (e.g. home, shell)
Title: Message Title
Nate McCurdy created an issue
Puppet / PUP-11241
Not all user attributes honor forcelocal (e.g. home, shell)
Issue Type:
Bug
Affects Versions:
PUP 7.9.0, PUP 6.19.1
Assignee:
Unassigned
Created:
2021/09/14 6:03 PM
Priority:
Normal
Reporter:
Nate McCurdy
Puppet Version: 6.19.1, 7.9.0 Puppet Server Version: N/A OS Name/Version: CentOS 7 When setting forcelocal => true on a user resource, I'd expect all user attributes available via /etc/passwd to be used as the "is" value for the insync? check. This appears to not be the case for the home}] and {{shell attributes. Those are always checked against their values from directory services rather than from /etc/passwd, which means those attributes appear to change on each puppet run and the user resource is no longer idempotent. Desired Behavior: When an OS has directory services enabled (e.g. LDAP via SSSD), and with an /etc/passwd file containing:
nate:x:1000:1001:hello world:/opt/hello:/bin/zsh
This code should read "shell", "home", and "comment" all from /etc/passwd when comparing the "is" state to the "should" state:
Jira (FACT-2918) FACTER_ environmental facts overrides don't work with external facts
Title: Message Title Nate McCurdy commented on FACT-2918 Re: FACTER_ environmental facts overrides don't work with external facts +1 to getting this fixed. Glad to see it's being triaged now. It's a common workflow where I am to allow unprivileged users to run Puppet and set FACTER_ environment variables to toggle feature flags that we've built in to our code. As the users are unprivileged, they aren't able to write files to disk to modify an external fact. but they do have the rights to set an ENV variable for a one-off Puppet run. This bug breaks that workflow. Also of note, there's a test for this exact behavior in Facter so it's definitely meant to be working: https://github.com/puppetlabs/facter/blob/4.0.49/acceptance/tests/external_facts/env_var_overrides_external_fact.rb#L35-L42 How is that test passing? ...I guess it works when using Facter directory, but not when run through puppet facts. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.383195.1610609261000.128169.1611882360257%40Atlassian.JIRA.
Jira (PUP-4039) package resource doesn't find new packages in yum repo
Title: Message Title
Nate McCurdy commented on PUP-4039
Re: package resource doesn't find new packages in yum repo
I've found another problem caused by the patch made for PUP-2182, and it has to do with installing RPM's using the package resource and yum provider in cases where the RPM is specified in the source parameter. For example:
# This causes 'yum list pdk' to be run before 'yum install pdk'.
# And in the case where we don't have the 'puppet6' repo installed, 'yum list' fails\
# as it can't find the 'pdk' package.
package { 'pdk':
ensure => 'installed',
source => 'http://yum.puppet.com/puppet6/el/8/x86_64/pdk-1.18.1.0-1.el8.x86_64.rpm',
provider=> 'yum',
allow_virtual => false,
}
# This works because 'yum list' is not called prior to 'yum install'.
package { 'pdk':
Jira (PUP-10648) puppet 6 agent doesn't honor usecacheonfailure setting
Title: Message Title Nate McCurdy updated an issue Puppet / PUP-10648 puppet 6 agent doesn't honor usecacheonfailure setting Change By: Nate McCurdy Affects Version/s: PUP 6.18.0 Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.370505.1598545662000.25316.1598546580029%40Atlassian.JIRA.
Jira (PUP-10648) puppet 6 agent doesn't honor usecacheonfailure setting
Title: Message Title Nate McCurdy commented on PUP-10648 Re: puppet 6 agent doesn't honor usecacheonfailure setting This looks to be an issue with server_list as it works for me when just using server [root@blank ~]# sudo puppet agent --onetime --no-daemonize --verbose --usecacheonfailure Error: Request to https://master.vagrant:8140/puppet/v3 failed after 0.004 seconds: Failed to open TCP connection to master.vagrant:8140 (getaddrinfo: Name or service not known) Wrapped exception: Failed to open TCP connection to master.vagrant:8140 (getaddrinfo: Name or service not known) Warning: Unable to fetch my node definition, but the agent run will continue: Warning: No more routes to puppet Info: Retrieving pluginfacts Error: Request to https://master.vagrant:8140/puppet/v3 failed after 0.001 seconds: Failed to open TCP connection to master.vagrant:8140 (getaddrinfo: Name or service not known) Wrapped exception: Failed to open TCP connection to master.vagrant:8140 (getaddrinfo: Name or service not known) Error: /File[/opt/puppetlabs/puppet/cache/facts.d]: Failed to generate additional resources using 'eval_generate': No more routes to fileserver
Jira (FACT-2724) Confine blocks behave differently with Facter 4, causing spec tests to suddenly fail
Title: Message Title Nate McCurdy commented on FACT-2724 Re: Confine blocks behave differently with Facter 4, causing spec tests to suddenly fail Makes sense. Thanks Bogdan Irimie Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.367390.1595872598000.11417.1596818760275%40Atlassian.JIRA.
Jira (FACT-2740) 'gce' fact missing in Facter 4.x
Title: Message Title
Nate McCurdy created an issue
Facter / FACT-2740
'gce' fact missing in Facter 4.x
Issue Type:
Bug
Affects Versions:
FACT 4.0.33
Assignee:
Unassigned
Components:
Facter 4
Created:
2020/08/06 5:27 PM
Priority:
Normal
Reporter:
Nate McCurdy
The Problem The core fact 'gce' is missing from Facter 4 when run on a Google Cloud instance. The Expectation I expected by Google Cloud instance to have a 'gce' fact that resolves to the metadata of the GCE instance just like it does in Facter 3. https://puppet.com/docs/facter/3.11/core_facts.html#gce The Reproduction On a GCE instance, start with Facter 3.x that ships with puppet-agent 5 or 6:
$ facter --version
3.11.8 (commit eb5f71136af5012f3a7169ed3a77a111c1e4d765)
$ facter gce | head
{
Jira (FACT-2740) 'gce' fact missing in Facter 4.x
Title: Message Title
Nate McCurdy updated an issue
Facter / FACT-2740
'gce' fact missing in Facter 4.x
Change By:
Nate McCurdy
h3. The Problem The core fact 'gce' is missing from Facter 4 when run on a Google Cloud instance. h3. The Expectation I expected by a Google Cloud instance to have a 'gce' fact that resolves to the metadata of the GCE instance just like it does in Facter 3. [ https://puppet.com/docs/facter/3.11/core_facts.html#gce ] h3. The ReproductionOn a GCE instance, start with Facter 3.x that ships with puppet-agent 5 or 6:{noformat} $ facter --version3.11.8 (commit eb5f71136af5012f3a7169ed3a77a111c1e4d765)$ facter gce | head{ instance => {attributes => { boot-script => "#!/usr/bin/python# Read this for more information on the startup-script process# https://cloud.google.com/deployment-manager/docs/step-by-step-guide/setting-metadata-and-startup-scriptsimport fcntlimport json$ facter gce --json | jq '.gce | keys'[ "instance", "oslogin", "project"]{noformat} Then install the Facter 4.0.33 gem and run {{facter gce}}:{noformat} $ sudo /opt/puppetlabs/puppet/bin/gem install facter-4.0.33.gem thor-1.0.1.gem hocon-1.3.1.gem --no-docSuccessfully installed hocon-1.3.1facter's executable "facter" conflicts with /opt/puppetlabs/puppet/bin/facterOverwrite the executable? [yN] ySuccessfully installed facter-4.0.33Successfully installed thor-1.0.1Successfully installed hocon-1.3.14 gems installed$ facter --version4.0.33$ facter gce${noformat}
Add Comment
This message was sent by Atlassian
Jira (FACT-2724) Confine blocks behave differently with Facter 4, causing spec tests to suddenly fail
Title: Message Title Nate McCurdy commented on FACT-2724 Re: Confine blocks behave differently with Facter 4, causing spec tests to suddenly fail Bogdan Irimie Correct, I was running the tests on a Mac laptop. Looking at the PR, does defaulting to 'physical' make sense considering MacOS can be virtualized? Though I suppose that's better than defaulting to 'nil' Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.367390.1595872598000.7166.1596478080023%40Atlassian.JIRA.
Jira (FACT-2724) Confine blocks behave differently with Facter 4, causing spec tests to suddenly fail
Title: Message Title
Nate McCurdy commented on FACT-2724
Re: Confine blocks behave differently with Facter 4, causing spec tests to suddenly fail
Figured out a workaround. And that was to add: allow(Facter.add(:virtual)) e.g.
before(:each) do
Facter.clear
allow(Facter.add(:virtual))
allow(Facter.fact(:kernel)).to receive(:value).and_return('Linux')
allow(Facter.fact(:virtual)).to receive(:value).and_return('physical')
end
Add Comment
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (FACT-2724) Confine blocks behave differently with Facter 4, causing spec tests to suddenly fail
Title: Message Title Nate McCurdy commented on FACT-2724 Re: Confine blocks behave differently with Facter 4, causing spec tests to suddenly fail Update... these tests only fail when I add the webmock gem to the Gemfile: https://github.com/bblimke/webmock If I remove the webmock gem, all the existing tests pass! The problem is that I need webmock in this module for some other tests. It looks like Webmock's hard block on all network requests is somehow interfering with Facter's ability to identify a node's platform. e.g. https://github.com/puppetlabs/puppet/pull/7767 and https://bugs.launchpad.net/puppet-nova/+bug/1492636 Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.367390.1595872598000.2605.1595888160042%40Atlassian.JIRA.
Jira (FACT-2724) Confine blocks behave differently with Facter 4, causing spec tests to suddenly fail
Title: Message Title
Nate McCurdy commented on FACT-2724
Re: Confine blocks behave differently with Facter 4, causing spec tests to suddenly fail
To simplify this down even more, it appears that confining a fact with syntax like:
confine :kernel => 'Linux'
confine :virtual => 'physical'
can no longer be mocked with stubs like this:
allow(Facter.fact(:virtual)).to receive(:value).and_return('physical')
allow(Facter.fact(:kernel)).to receive(:value).and_return('Linux')
How should we write spec tests for facts and mock other facts to satisfy a confine block?
Add Comment
Jira (FACT-2724) Confine blocks behave differently with Facter 4, causing spec tests to suddenly fail
Title: Message Title Nate McCurdy commented on FACT-2724 Re: Confine blocks behave differently with Facter 4, causing spec tests to suddenly fail This makes me think that some of the spec tests from stdlib (which is where I always get my examples from) will break with the latest version of PDK as well: https://github.com/puppetlabs/puppetlabs-stdlib/blob/v6.3.0/spec/unit/facter/root_home_spec.rb#L37-L38 https://github.com/puppetlabs/puppetlabs-stdlib/blob/v6.3.0/lib/facter/root_home.rb#L24 Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.367390.1595872598000.2304.1595873580076%40Atlassian.JIRA.
Jira (FACT-2724) Confine blocks behave differently with Facter 4, causing spec tests to suddenly fail
Title: Message Title
Nate McCurdy updated an issue
Facter / FACT-2724
Confine blocks behave differently with Facter 4, causing spec tests to suddenly fail
Change By:
Nate McCurdy
I have a custom Ruby fact that uses {{confine}} blocks to limit when it's run. The spec tests for this fact have worked up until I upgraded to the PDK 1.18 which comes with Facter 4 by default.Here's the fact:{code:ruby}# Our physical hosts have an alias interface of :1 as the logical one.Facter.add(:logical_interface) do confine kernel: 'Linux' confine virtual: 'physical' setcode donetworking = Facter.value(:networking)primary_alias_iface = "#{networking['primary']}:1"unless networking['interfaces'][primary_alias_iface].nil? networking['interfaces'][primary_alias_iface]end endend# In GCP and Virtualbox, always use eth0.Facter.add(:logical_interface) do confine kernel: 'Linux' confine virtual: ['gce', 'virtualbox'] setcode doFacter.value(:networking)['interfaces']['eth0'] endend{code}And here's the spec test:{code:ruby}require 'spec_helper'describe 'logical_interface', type: :fact do let(:networking_hash) do{ 'primary'=> 'eth42', 'interfaces' => {'eth0'=> { 'ip' => '2.2.2.2' },'eth42:1' => { 'ip' => '1.1.1.1' }, },} end let(:networking_hash_no_alias) do{ 'primary'=> 'eth0', 'interfaces' => {'eth0' => { 'ip' => '3.3.3.3' }, },} end # GCE should act the same as on-prem let(:networking_hash_gce) donetworking_hash end context 'On a physical host' dobefore(:each) do Facter.clear # Workaround for https://github.com/puppetlabs/pdk/issues/694 if Facter.fact(:networking).nil?Facter.add(:networking) {}Facter.flush end allow(Facter.fact(:networking)).to receive(:value).and_return(networking_hash) allow(Facter.fact(:kernel)).to receive(:value).and_return('Linux') allow(Facter.fact(:virtual)).to receive(:value).and_return('physical')endit "returns the primary's sub-interface hash" do expect(Facter.fact(:logical_interface).value).to eq('ip' => '1.1.1.1')end end context 'On a physical host with no sub-interface' dobefore(:each) do Facter.clear # Workaround for https://github.com/puppetlabs/pdk/issues/694 if Facter.fact(:networking).nil?Facter.add(:networking) {}Facter.flush end allow(Facter.fact(:networking)).to receive(:value).and_return(networking_hash_no_alias) allow(Facter.fact(:virtual)).to receive(:value).and_return('physical')endit 'returns nil (undef)' do expect(Facter.fact(:logical_interface).value).to be_nilend end context 'On a GCE host' dobefore(:each) do Facter.clear # Workaround for https://github.com/puppetlabs/pdk/issues/694 if Facter.fact(:networking).nil?Facter.add(:networking) {}Facter.flush end allow(Facter.fact(:networking)).to receive(:value).and_return(networking_hash_gce)
Jira (PUP-10582) Puppet runs should fail fast when no environment can be found
Title: Message Title
Nate McCurdy commented on PUP-10582
Re: Puppet runs should fail fast when no environment can be found
Josh Cooper It appears that adding `--strict_environment_mode` does not cause the run to fail early. It does hide this error about the node object not being found:
Warning: Unable to fetch my node definition, but the agent run will continue:
Warning: Find /puppet/v3/node/agent.corp.net resulted in 404 with the message: {"message":"Not Found: Could not find environment 'not_a_real_env'","issue_kind":"RUNTIME_ERROR"}
But the rest of the run continues with pluginsync and a catalog request similar the my original example in the ticket description.
Add Comment
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To
Jira (PUP-10582) Puppet runs should fail fast when no environment can be found
Title: Message Title Nate McCurdy commented on PUP-10582 Re: Puppet runs should fail fast when no environment can be found Ah, thanks for the tip on strict_environment_mode Josh Cooper! Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.365528.1594348057000.105132.1594406400024%40Atlassian.JIRA.
Jira (PUP-10582) Puppet runs should fail fast when no environment can be found
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-10582
Puppet runs should fail fast when no environment can be found
Change By:
Nate McCurdy
*Puppet Version: 6.15.0* *Puppet Server Version: 6.12.0 (open source)* *OS Name/Version: CentOS 7*When running {{puppet agent -t}} against an environment that doesn't exist, the Puppet run doesn't fail quickly and instead makes the following requests in order, all of which respond with a {{404}} (except for the catalog request, which gets a {{500}} response):* {{GET /puppet/v3/node}}* {{GET /puppet/v3/file_metadatas/pluginfacts}}* {{GET /puppet/v3/file_metadata/pluginfacts}}* {{GET /puppet/v3/file_metadatas/plugins}}* {{GET /puppet/v3/file_metadata/plugins}}* {{GET /puppet/v3/file_metadatas/locales}}* {{GET /puppet/v3/file_metadata/locales}}* {{POST /puppet/v3/catalog/}}From the agent's view, that looks like this:{noformat}$ sudo puppet agent -t --environment not_a_real_envWarning: Unable to fetch my node definition, but the agent run will continue:Warning: Find /puppet/v3/node/agent.corp.net resulted in 404 with the message: {"message":"Not Found: Could not find environment 'not_a_real_env'","issue_kind":"RUNTIME_ERROR"}Info: Retrieving pluginfactsError: /File[/opt/puppetlabs/puppet/cache/facts.d]: Could not evaluate: Could not retrieve information from environment not_a_real_env source(s) puppet:///pluginfactsInfo: Retrieving pluginWarning: /File[/opt/puppetlabs/puppet/cache/lib/facter]: Skipping because of failed dependenciesWarning: /File[/opt/puppetlabs/puppet/cache/lib/facter/facter_dot_d.rb]: Skipping because of failed dependenciesWarning: /File[/opt/puppetlabs/puppet/cache/lib/facter/package_provider.rb]: Skipping because of failed dependenciesWarning: /File[/opt/puppetlabs/puppet/cache/lib/facter/pe_version.rb]: Skipping because of failed dependenciesWarning: /File[/opt/puppetlabs/puppet/cache/lib/facter/puppet_settings.rb]: Skipping because of failed dependencies...(snip 100's of lines of failed pluginsync files)...Info: Retrieving localesError: /File[/opt/puppetlabs/puppet/cache/locales]: Could not evaluate: Could not retrieve information from environment not_a_real_env source(s) puppet:///localesNotice: /File[/opt/puppetlabs/puppet/cache/locales/ja]: Dependency File[/opt/puppetlabs/puppet/cache/locales] has failures: trueWarning: /File[/opt/puppetlabs/puppet/cache/locales/ja]: Skipping because of failed dependenciesWarning: /File[/opt/puppetlabs/puppet/cache/locales/ja/puppetlabs-stdlib.po]: Skipping because of failed dependenciesWarning: /File[/opt/puppetlabs/puppet/cache/locales/ja/puppetlabs-tomcat.po]: Skipping because of failed dependenciesInfo: Loading factsError: Could not retrieve catalog from remote server: Error 500 on SERVER: Internal Server Error: java.lang.IllegalStateException: Non-zero exit code returned while running '/etc/puppetlabs/puppet/code-id.sh'. exit-code: '1', stdout: '', stderr: '/etc/puppetlabs/puppet/code-id.sh: line 19: cd: /etc/puppetlabs/code/environments/not_a_real_env: No such file or
Jira (PUP-10582) Puppet runs should fail fast when no environment can be found
Title: Message Title Nate McCurdy created an issue Puppet / PUP-10582 Puppet runs should fail fast when no environment can be found Issue Type: Bug Affects Versions: PUP 6.15.0, PUP 5.5.20 Assignee: Unassigned Created: 2020/07/09 7:27 PM Priority: Normal Reporter: Nate McCurdy Puppet Version: 6.15.0 Puppet Server Version: 6.12.0 (open source) OS Name/Version: CentOS 7 When running puppet agent -t against an environment that doesn't exist, the Puppet run doesn't fail quickly and instead makes the following requests in order, all of which respond with a 404 (except for the catalog request, which gets a 500 response): GET /puppet/v3/node GET /puppet/v3/file_metadatas/pluginfacts GET /puppet/v3/file_metadata/pluginfacts GET /puppet/v3/file_metadatas/plugins GET /puppet/v3/file_metadata/plugins GET /puppet/v3/file_metadatas/locales GET /puppet/v3/file_metadata/locales POST /puppet/v3/catalog/ From the agent's view, that looks like this: $ sudo puppet agent -t --environment not_a_real_env
Jira (PUP-10579) Request: Add "source" and "content" attributes to the exec resource
Title: Message Title
Nate McCurdy commented on PUP-10579
Re: Request: Add "source" and "content" attributes to the exec resource
You can already do something very similar to what you're asking for Rob Nelson by using the shell provider and the file(), epp(), or template() function.
exec { 'hello':
command => file('foo/hello_world.sh'),
_onlyif_ => file('foo/check.sh'),
provider => 'shell',
}
A similar example is in the Windows, where the powershell exec provider was designed to handle cases like this: https://forge.puppet.com/puppetlabs/powershell#usage
exec { 'rename-guest':
command => file('guest/rename-guest.ps1'),
_onlyif_=> file('guest/guest-exists.ps1'),
provider => powershell,
logoutput => true,
}
Jira (PDB-2578) Puppetdb module's "don't manage $database_password" code doesn't work
Title: Message Title Nate McCurdy commented on PDB-2578 Re: Puppetdb module's "don't manage $database_password" code doesn't work My fix has been merged to master in https://github.com/puppetlabs/puppetlabs-puppetdb/pull/301 I suspect that the next release of the puppetdb module will have the new "manage_db_password" and "manage_read_db_password" parameters in it. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.124120.1459291158000.75318.1591052040105%40Atlassian.JIRA.
Jira (PUP-10532) Puppet fetches metadata for files with "ensure => absent"
Title: Message Title Nate McCurdy updated an issue Puppet / PUP-10532 Puppet fetches metadata for files with "ensure => absent" Change By: Nate McCurdy Method Found: Needs Assessment Customer Feedback Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.359734.1590173269000.71682.1590612480327%40Atlassian.JIRA.
Jira (PUP-10532) Puppet fetches metadata for files with "ensure => absent"
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-10532
Puppet fetches metadata for files with "ensure => absent"
Change By:
Nate McCurdy
h1. Problem*Puppet Version:* 6.15.0*Puppet Server Version:* 6.11.1*OS Name/Version:* CentOS 7Puppet makes a HTTP request for {{/file_metadata/}} for files that are set to "{{ensure => absent}}" and have {{source => 'puppet:///modules/...}}.This defeats the purpose of using static catalogs when your intent is to reduce the amount of file_metadata HTTP traffic. It causes unnecessary traffic and overheard on the Puppet server. h1. ReproductionGiven this Puppet code:{code} node 'agent1.vagrant' { file { '/root/one':ensure => file,owner => 0,group => 0,mode => '0644',source => 'puppet:///modules/test/one', } file { '/root/two':ensure => absent,owner => 0,group => 0,mode => '0644',source => 'puppet:///modules/test/two', }}{code} Running {{puppet agent -t}} from {{agent1.vagrant}} causes these messages in Puppetserver's logs: {noformat} ==> /var/log/puppetlabs/puppetserver/puppetserver.log <==2020-05-22T18:44:27.159Z INFO [qtp9036388-38] [puppetserver] Puppet Inlined resource metadata into static catalog for agent1.vagrant in environment production in 0.01 seconds2020-05-22T18:44:27.160Z INFO [qtp9036388-38] [puppetserver] Puppet Compiled static catalog for agent1.vagrant in environment production in 0.12 seconds==> /var/log/puppetlabs/puppetserver/puppetserver-access.log <==10.20.1.6 - - [22/May/2020:18:44:26 +] "GET /puppet/v3/node/agent1.vagrant?environment=production_environment=production_uuid=ee221fd5-13a0-4fdd-9413-1b57a98cd690 HTTP/1.1" 200 12572 "-" "Puppet/6.15.0 Ruby/2.5.8-p224 (x86_64-linux)" 33 - 3010.20.1.6 - - [22/May/2020:18:44:26 +] "GET /puppet/v3/file_metadatas/pluginfacts?recurse=true=.svn=CVS=.git=.hg=follow_type=md5_permissions=use=production HTTP/1.1" 200 240 "-" "Puppet/6.15.0 Ruby/2.5.8-p224 (x86_64-linux)" 17 - 1210.20.1.6 - - [22/May/2020:18:44:26 +] "GET /puppet/v3/file_metadatas/plugins?recurse=true=.svn=CVS=.git=.hg=follow_type=md5_permissions=ignore=production HTTP/1.1" 200 244 "-" "Puppet/6.15.0 Ruby/2.5.8-p224 (x86_64-linux)" 19 - 1410.20.1.6 - - [22/May/2020:18:44:26 +] "GET /puppet/v3/file_metadatas/locales?recurse=true=.svn=CVS=.git=.hg=%2A.pot=config.yaml=follow_type=md5_permissions=ignore=production HTTP/1.1" 200 244 "-" "Puppet/6.15.0 Ruby/2.5.8-p224 (x86_64-linux)" 76 - 7210.20.1.6 - - [22/May/2020:18:44:27 +] "POST /puppet/v3/catalog/agent1.vagrant?environment=production HTTP/1.1" 200 1864 "-" "Puppet/6.15.0 Ruby/2.5.8-p224 (x86_64-linux)" 272 25743 26810.20.1.6 - - [22/May/2020:18:44:27 +] "GET /puppet/v3/file_metadata/modules/test/two?links=manage_type=md5_permissions=ignore=production HTTP/1.1" 200 258 "-" "Puppet/6.15.0 Ruby/2.5.8-p224 (x86_64-linux)" 17 - 1310.20.1.6 - - [22/May/2020:18:44:27 +] "PUT /puppet/v3/report/agent1.vagrant?environment=production HTTP/1.1" 200 9 "-" "Puppet/6.15.0 Ruby/2.5.8-p224
Jira (PUP-10532) Puppet fetches metadata for files with "ensure => absent"
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-10532
Puppet fetches metadata for files with "ensure => absent"
Change By:
Nate McCurdy
# h1. Problem *Puppet Version:* 6.15.0*Puppet Server Version:* 6.11.1*OS Name/Version:* CentOS 7Puppet makes a HTTP request for {{/file_metadata/}} for files that are set to "{{ensure => absent}}" and have {{source => 'puppet:///modules/...}}.This defeats the purpose of using static catalogs when your intent is to reduce the amount of file_metadata HTTP traffic. It causes unnecessary traffic and overheard on the Puppet server. # h1. Reproduction Given this Puppet code:{code}node 'agent1.vagrant' { file { '/root/one':ensure => file,owner => 0,group => 0,mode => '0644',source => 'puppet:///modules/test/one', } file { '/root/two':ensure => absent,owner => 0,group => 0,mode => '0644',source => 'puppet:///modules/test/two', }}{code}Running {{puppet agent -t}} from {{agent1.vagrant}} causes these messages in Puppetserver's logs: {noformat}==> /var/log/puppetlabs/puppetserver/puppetserver.log <==2020-05-22T18:44:27.159Z INFO [qtp9036388-38] [puppetserver] Puppet Inlined resource metadata into static catalog for agent1.vagrant in environment production in 0.01 seconds2020-05-22T18:44:27.160Z INFO [qtp9036388-38] [puppetserver] Puppet Compiled static catalog for agent1.vagrant in environment production in 0.12 seconds==> /var/log/puppetlabs/puppetserver/puppetserver-access.log <==10.20.1.6 - - [22/May/2020:18:44:26 +] "GET /puppet/v3/node/agent1.vagrant?environment=production_environment=production_uuid=ee221fd5-13a0-4fdd-9413-1b57a98cd690 HTTP/1.1" 200 12572 "-" "Puppet/6.15.0 Ruby/2.5.8-p224 (x86_64-linux)" 33 - 3010.20.1.6 - - [22/May/2020:18:44:26 +] "GET /puppet/v3/file_metadatas/pluginfacts?recurse=true=.svn=CVS=.git=.hg=follow_type=md5_permissions=use=production HTTP/1.1" 200 240 "-" "Puppet/6.15.0 Ruby/2.5.8-p224 (x86_64-linux)" 17 - 1210.20.1.6 - - [22/May/2020:18:44:26 +] "GET /puppet/v3/file_metadatas/plugins?recurse=true=.svn=CVS=.git=.hg=follow_type=md5_permissions=ignore=production HTTP/1.1" 200 244 "-" "Puppet/6.15.0 Ruby/2.5.8-p224 (x86_64-linux)" 19 - 1410.20.1.6 - - [22/May/2020:18:44:26 +] "GET /puppet/v3/file_metadatas/locales?recurse=true=.svn=CVS=.git=.hg=%2A.pot=config.yaml=follow_type=md5_permissions=ignore=production HTTP/1.1" 200 244 "-" "Puppet/6.15.0 Ruby/2.5.8-p224 (x86_64-linux)" 76 - 7210.20.1.6 - - [22/May/2020:18:44:27 +] "POST /puppet/v3/catalog/agent1.vagrant?environment=production HTTP/1.1" 200 1864 "-" "Puppet/6.15.0 Ruby/2.5.8-p224 (x86_64-linux)" 272 25743 26810.20.1.6 - - [22/May/2020:18:44:27 +] "GET /puppet/v3/file_metadata/modules/test/two?links=manage_type=md5_permissions=ignore=production HTTP/1.1" 200 258 "-" "Puppet/6.15.0 Ruby/2.5.8-p224 (x86_64-linux)" 17 - 1310.20.1.6 - - [22/May/2020:18:44:27 +] "PUT /puppet/v3/report/agent1.vagrant?environment=production HTTP/1.1" 200 9 "-" "Puppet/6.15.0 Ruby/2.5.8-p224
Jira (PUP-10532) Puppet fetches metadata for files with "ensure => absent"
Title: Message Title
Nate McCurdy created an issue
Puppet / PUP-10532
Puppet fetches metadata for files with "ensure => absent"
Issue Type:
Bug
Affects Versions:
PUP 6.15.0, PUP 5.5.14
Assignee:
Unassigned
Created:
2020/05/22 11:47 AM
Priority:
Normal
Reporter:
Nate McCurdy
Problem Puppet Version: 6.15.0 Puppet Server Version: 6.11.1 OS Name/Version: CentOS 7
Puppet makes a HTTP request for /file_metadata/ for files that are set to "ensure => absent" and have source => 'puppet:///modules/ This defeats the purpose of using static catalogs when your intent is to reduce the amount of file_metadata HTTP traffic. It causes unnecessary traffic and overheard on the Puppet server.
Reproduction Given this Puppet code:
node 'agent1.vagrant' {
file { '/root/one':
Jira (PDB-2578) Puppetdb module's "don't manage $database_password" code doesn't work
Title: Message Title Nate McCurdy commented on PDB-2578 Re: Puppetdb module's "don't manage $database_password" code doesn't work I created this PR to add a "manage_db_password" boolean parameter: https://github.com/puppetlabs/puppetlabs-puppetdb/pull/301 Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.124120.1459291158000.681.1582931640029%40Atlassian.JIRA.
Jira (PDB-3300) Add command for deleting node data
Title: Message Title Nate McCurdy commented on PDB-3300 Re: Add command for deleting node data What's the fix version for this new feature and what's the API endpoint? Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.176102.1487778838000.52512.1575415020926%40Atlassian.JIRA.
Jira (PUP-8417) Add ability to refresh cached catalog & synced moduled without applying resources
Title: Message Title Nate McCurdy updated an issue Puppet / PUP-8417 Add ability to refresh cached catalog & synced moduled without applying resources Change By: Nate McCurdy Affects Version/s: PUP 5.5.14 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.235270.1517871107000.94371.1568233440833%40Atlassian.JIRA.
Jira (PUP-5921) Deprecate source_permissions
Title: Message Title Nate McCurdy commented on PUP-5921 Re: Deprecate source_permissions When is source_permissions being removed from Puppet? I see tickets about deprecating it, but no mention of when it will be removed. It's still available in Puppet 6.6. Also, I'd just like to throw my 2 cents in here and state that source_permissions is very handy for copying over the mode of a file. Really that's all I use it for, and I use it quite a bit. Removing the option to copy over the mode of a file from the source will cause a lot of busy work on our end and will mean that we need to find another solution to the workflow used by a few of the organizations i work with. We use it primarily to allow teams to check-in a directory of arbitrary files and scripts to be deployed by Puppet to their nodes. The teams have limited permissions to edit the Puppet manifests that control this behavior but have full rights to modify the files/ directory of a module. If source_permissions goes away, those teams would then need to edit the Puppet manifests to create on-off file resources to fix the mode of their scripts. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.117270.1455758203000.23643.1563567600247%40Atlassian.JIRA.
Jira (PUP-9826) Puppet exec timeout does not match documentation
Title: Message Title
Nate McCurdy commented on PUP-9826
Re: Puppet exec timeout does not match documentation
exec { 'test':
command => '/bin/sleep 5; /bin/false',
tries => 10,
try_sleep => 1,
timeout => 4,
}
That triggers the timeout error, but this does not:
exec { 'test':
command => '/bin/sleep 4; /bin/false',
tries => 10,
try_sleep => 1,
timeout => 5,
}
Jira (PUP-9826) Puppet exec timeout does not match documentation
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-9826
Puppet exec timeout does not match documentation
Change By:
Nate McCurdy
*Puppet Version: 5.5.14-1xenial *Puppet Server Version: 5.3.8-1xenial *OS Name/Version: Ubuntu 16.04 XenialDescribe your issue in as much detail as possible…When using tries in an exec resource the documentation states that the timeout parameter of the exec block applies to each try, but the code currently does not implement the functionality in that way. The timeout should apply to each try.Slack community chat snippet{quote}natemccurdy [11 minutes ago] The timeout is for *the entire exec*, not for each try. (edited)Jason Grammenos [10 minutes ago] `Note that the timeout parameter applies to each try rather than to the complete set of tries.`natemccurdy [10 minutes ago] err.. sorry, You’re right.natemccurdy [10 minutes ago] Read that wrong.josh [9 minutes ago] The docs are wrong unfortunatelyJason Grammenos [9 minutes ago] oh?natemccurdy [9 minutes ago] Oh, hah :slightly_smiling_face:josh [8 minutes ago] maybe it used to apply to each try at some point?natemccurdy [8 minutes ago] Either way, try removing the `timeout` or set it to `0` and see what happens.josh [6 minutes ago] Looks like it's been broken since [https://github.com/puppetlabs/puppet/commit/e0e6b642c4e]josh [5 minutes ago] The begin/rescue needs to be inside `tries.times do |try|` Describe steps to reproduce… {quote} *Desired Behavior:* {code} exec { 'test': command => '/bin/false', tries => 10, try_sleep => 5, timeout => 10,}{code} This should have a per try timeout of 10 seconds as per the documentation.*Actual Behavior:*The exec time's out because the current implementation applies the timeout to the whole set of tries.current documentation:[https://puppet.com/docs/puppet/6.6/types/exec.html#exec-attribute-tries]Please take a moment and attach any relevant log output and/or manifests. This will help us immensely when troubleshooting the issue.{code} Exec try 1/10 /etc/puppetlabs/code/modules/mm/manifests/graylog/graylog.pp:83 Jul 15 2019 - 14:10:34 Exec[configure-ldap](provider=posix) Executing 'curl -s -v -i --netrc-file /etc/graylog/server/configure_ldap.netrc -o /etc/graylog/server/configure_ldap.log -H "Content-Type: application/json" -H "X-Requested-By: puppet" -X PUT [http://localhost:9000/api/system/ldap/settings] --data @/etc/graylog/server/configure_ldap_data.json 2>&1 | grep 'HTTP/1.1 204''Jul 15 2019 - 14:10:34 Puppet debug Executing: 'curl -s -v -i --netrc-file /etc/graylog/server/configure_ldap.netrc -o /etc/graylog/server/configure_ldap.log -H "Content-Type: application/json" -H "X-Requested-By: puppet" -X PUT [http://localhost:9000/api/system/ldap/settings] --data @/etc/graylog/server/configure_ldap_data.json 2>&1 | grep 'HTTP/1.1 204'' Jul 15 2019 - 14:10:44 Puppet err Command exceeded timeout {code}
Jira (PUP-9826) Puppet exec timeout does not match documentation
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-9826
Puppet exec timeout does not match documentation
Change By:
Nate McCurdy
*Puppet Version: 5.5.14-1xenial *Puppet Server Version: 5.3.8-1xenial *OS Name/Version: Ubuntu 16.04 XenialDescribe your issue in as much detail as possible…When using tries in an exec resource the documentation states that the timeout parameter of the exec block applies to each try, but the code currently does not implement the functionality in that way. The timeout should apply to each try.Slack community chat snippet{quote}natemccurdy [11 minutes ago] The timeout is for *the entire exec*, not for each try. (edited)Jason Grammenos [10 minutes ago] `Note that the timeout parameter applies to each try rather than to the complete set of tries.`natemccurdy [10 minutes ago] err.. sorry, You’re right.natemccurdy [10 minutes ago] Read that wrong.josh [9 minutes ago] The docs are wrong unfortunatelyJason Grammenos [9 minutes ago] oh?natemccurdy [9 minutes ago] Oh, hah :slightly_smiling_face:josh [8 minutes ago] maybe it used to apply to each try at some point?natemccurdy [8 minutes ago] Either way, try removing the `timeout` or set it to `0` and see what happens.josh [6 minutes ago] Looks like it's been broken since [https://github.com/puppetlabs/puppet/commit/e0e6b642c4e]josh [5 minutes ago] The begin/rescue needs to be inside `tries.times do |try|` Describe steps to reproduce…{quote}*Desired Behavior:* {code} exec { 'test': command => '/bin/false', tries => 10, try_sleep => 5, timeout => 10,}{code} This should have a per try timeout of 10 seconds as per the documentation.*Actual Behavior:*The exec time's out because the current implementation applies the timeout to the whole set of tries.current documentation: [https://puppet.com/docs/puppet/ 5 6 . 3 6 /types/exec.html#exec-attribute-tries]Please take a moment and attach any relevant log output and/or manifests. This will help us immensely when troubleshooting the issue. {code} Exec try 1/10 /etc/puppetlabs/code/modules/mm/manifests/graylog/graylog.pp:83 Jul 15 2019 - 14:10:34 Exec[configure-ldap](provider=posix) Executing 'curl -s -v -i --netrc-file /etc/graylog/server/configure_ldap.netrc -o /etc/graylog/server/configure_ldap.log -H "Content-Type: application/json" -H "X-Requested-By: puppet" -X PUT [http://localhost:9000/api/system/ldap/settings] --data @/etc/graylog/server/configure_ldap_data.json 2>&1 | grep 'HTTP/1.1 204''Jul 15 2019 - 14:10:34 Puppet debug Executing: 'curl -s -v -i --netrc-file /etc/graylog/server/configure_ldap.netrc -o /etc/graylog/server/configure_ldap.log -H "Content-Type: application/json" -H "X-Requested-By: puppet" -X PUT [http://localhost:9000/api/system/ldap/settings] --data @/etc/graylog/server/configure_ldap_data.json 2>&1 | grep 'HTTP/1.1 204'' Jul 15 2019 - 14:10:44 Puppet err Command exceeded timeout {code}
Jira (PUP-9826) Puppet exec timeout does not match documentation
Title: Message Title Nate McCurdy commented on PUP-9826 Re: Puppet exec timeout does not match documentation Here's the faulty block of code: https://github.com/puppetlabs/puppet/blob/6.6.0/lib/puppet/type/exec.rb#L129-L142 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.316540.1563215346000.16321.1563216180448%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9826) Puppet exec timeout does not match documentation
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-9826
Puppet exec timeout does not match documentation
Change By:
Nate McCurdy
Affects Version/s:
PUP 5.5.14
Affects Version/s:
PUP 6.6.0
*Puppet Version: 5.5.14-1xenial*Puppet Server Version: 5.3.8-1xenial*OS Name/Version: Ubuntu 16.04 XenialDescribe your issue in as much detail as possible…When using tries in an exec resource the documentation states that the timeout parameter of the exec block applies to each try, but the code currently does not implement the functionality in that way. The timeout should apply to each try.Slack community chat snippet ``` {quote} natemccurdy [11 minutes ago]The timeout is for *the entire exec*, not for each try. (edited) Jason Grammenos [10 minutes ago]`Note that the timeout parameter applies to each try rather than to the complete set of tries.`natemccurdy [10 minutes ago]err.. sorry, You’re right.natemccurdy [10 minutes ago]Read that wrong.josh [9 minutes ago]The docs are wrong unfortunatelyJason Grammenos [9 minutes ago]oh?natemccurdy [9 minutes ago]Oh, hah :slightly_smiling_face:josh [8 minutes ago]maybe it used to apply to each try at some point?natemccurdy [8 minutes ago]Either way, try removing the `timeout` or set it to `0` and see what happens.josh [6 minutes ago]Looks like it's been broken since [ https://github.com/puppetlabs/puppet/commit/e0e6b642c4e ] josh [5 minutes ago]The begin/rescue needs to be inside `tries.times do |try|` ``` Describe steps to reproduce… {quote} *Desired Behavior:* ``` {code} exec { ' configure test ':command => " ' /bin/false ",path => [ ' /usr/bin' , '/bin'], tries => 10,try_sleep => 5,timeout = > 10, } ``` {code} This should have a per try timeout of 10 seconds as per the documentation.*Actual Behavior:*The exec time's out because the current implementation applies the timeout to the whole set of tries.current documentation: [ https://puppet.com/docs/puppet/5.3/types/exec.html#exec-attribute-tries ] Please take a moment and attach any relevant log output and/or manifests. This will help us immensely when troubleshooting the issue. ``` {code} Exec try 1/10 /etc/puppetlabs/code/modules/mm/manifests/graylog/graylog.pp:83Jul 15 2019 - 14:10:34 Exec[configure-ldap](provider=posix) Executing 'curl -s -v -i --netrc-file /etc/graylog/server/configure_ldap.netrc -o /etc/graylog/server/configure_ldap.log -H "Content-Type: application/json" -H "X-Requested-By: puppet" -X PUT [ http://localhost:9000/api/system/ldap/settings ] --data @/etc/graylog/server/configure_ldap_data.json 2>&1 | grep 'HTTP/1.1 204''
Jira (PUP-6165) it should not be possible to disable manifest ordering
Title: Message Title Nate McCurdy commented on PUP-6165 Re: it should not be possible to disable manifest ordering For the historical record, I found order = random to be very helpful for canary nodes and non-production tiers. Using random as a fuzzer to catch subtle ordering bugs was a useful tool in my opinion and I will miss it. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.126290.1460486885000.3339.1562087760335%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9511) Debug logging for Exec resources should include 'creates' checks
Title: Message Title Nate McCurdy commented on PUP-9511 Re: Debug logging for Exec resources should include 'creates' checks I've got a proof of concept up for review at https://github.com/puppetlabs/puppet/pull/7415 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9511) Debug logging for Exec resources should include 'creates' checks
Title: Message Title Nate McCurdy commented on PUP-9511 Re: Debug logging for Exec resources should include 'creates' checks Kris Bosland So that will show a message if the check fails, but it won't show any info that the check ran and succeeded, correct? I.E. we won't see a message like: Debug: Exec[wat](provider=posix): Executing check 'does /etc/creates.txt exist?' Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9511) Debug logging for Exec resources should include 'creates' checks
Title: Message Title Nate McCurdy commented on PUP-9511 Re: Debug logging for Exec resources should include 'creates' checks I see this asked out in the field and on Slack more often than not. Basically, any of the internal Ruby checks (i.e. checks that don't shell out) tend to always be hidden from a user even in debug mode. To get specific here, I think the request for this ticket is to get debug-level logging around this line: https://github.com/puppetlabs/puppet/blob/6.3.0/lib/puppet/type/exec.rb#L410 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9511) Debug logging for Exec resources should include 'creates' checks
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-9511
Debug logging for Exec resources should include 'creates' checks
Change By:
Nate McCurdy
Currently, running Puppet in debug mode with an Exec resource will indicate when the agent evaluates the 'onlyif' and 'unless' checks. It doesn't does not, however, indicate when 'creates' check is evaluated.From a user's perspective, this is inconsistent behavior and may cause confusion when troubleshooting Exec resources.{code:java}exec { 'wat': command => 'touch /etc/creates.txt', path => $facts['path'], creates => '/etc/creates.txt', _onlyif_ => 'test -d /etc', unless => 'test -d /unless',}{code}{code:java}Info: Applying configuration version '1551385197'Debug: Exec[wat](provider=posix): Executing check 'test -d /unless'Debug: Executing: 'test -d /unless'Debug: Exec[wat](provider=posix): Executing check 'test -d /etc'Debug: Executing: 'test -d /etc'Debug: Finishing transaction 70310589934020Debug: Storing stateDebug: Pruned old state cache entries in 0.00 secondsDebug: Stored state in 0.01 secondsNotice: Applied catalog in 0.06 seconds{code}
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (FACT-1876) Provide better documentation on structured executable facts
Title: Message Title Nate McCurdy commented on FACT-1876 Re: Provide better documentation on structured executable facts Big +1 to this ticket. Some simple examples of using BASH/Powershell to output arrays, hashes, and booleans would be good. Could start with simply documenting the tests used in Facter's acceptances tests: https://github.com/puppetlabs/facter/blob/master/acceptance/tests/external_facts/structured_executable_facts.rb Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8701) Update to Puppet help in PUP-8646 removed 'help easter egg'; please put it back!
Title: Message Title Nate McCurdy updated an issue Puppet / PUP-8701 Update to Puppet help in PUP-8646 removed 'help easter egg'; please put it back! Change By: Nate McCurdy Summary: Update to Puppet help in Pup PUP -8646 as removed 'help easter egg' ; please put it back! Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8701) Update to Puppet help in Pup-8646 as removed 'help easter egg' please put it back!
Title: Message Title Nate McCurdy commented on PUP-8701 Re: Update to Puppet help in Pup-8646 as removed 'help easter egg' please put it back! Here is the tragic event: https://github.com/puppetlabs/puppet/commit/b5dc2e4a40377109eaff84075cbceb19143e4dcd Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1289) Ability to manage a windows service's user account and password
Title: Message Title Nate McCurdy commented on PUP-1289 Re: Ability to manage a windows service's user account and password This would be a great feature because it would more easily allow people to configure the puppet agent service and what user/password/domain it runs with. I run into this all the time and usually fall back to setting those things at agent install time. Add Comment This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8325) Trusted facts can't be structured data
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-8325
Trusted facts can't be structured data
Change By:
Nate McCurdy
h2. ProblemIt appears to be impossible to have a trusted fact whose value is structured data or any data type other than a String.h2. Desired BehaviorGiven a {{csr_attributes.yaml}} like the below, I'd expect the value of {{pp_product}} to be a hash containing Strings, Booleans, and Arrays.{code:yaml}---extension_requests: pp_role: test pp_product:owner: natename: "A test product"approved: trueis_a_thing: falsetiers: - one - two - blue{code} h2. Actual BehaviorThe value of the trusted fact for {{pp_product}} is stringified as shown in the Puppet Enterprise console:!Bad Fact.png|thumbnail! In code, the $trusted variable also doesn't contain a {{tiers}} array. The errors message implies that pp_product is a String:{code}node default { $pp_product_tiers = $trusted['extensions']['pp_product']['tiers'] notify { $pp_product_tiers: }}{code}{code}[root@pe-201732-agent ~]# puppet agent -tInfo: Using configured environment 'production'Info: Retrieving pluginfactsInfo: Retrieving pluginInfo: Loading factsError: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: A substring operation does not accept a String as a character index. Expected an Integer at /etc/puppetlabs/code/environments/production/manifests/site.pp:4:60 on node pe-201732-agent.puppetdebug.vlanWarning: Not using cache on failed catalogError: Could not retrieve catalog; skipping run{code} Here's a {{puppet cert print}} of that agent's certificate. It looks like it *should* be structured data:{code} X509v3 extensions:Netscape Comment:.(Puppet Ruby/OpenSSL Internal CertificatePuppet Node Role Name:..testPuppet Node Product Name:.s{"owner"=>"nate", "name"=>"A test product", "approved"=>true, "is_a_thing"=>false, "tiers"=>["one", "two", "blue"]}X509v3 Key Usage: criticalDigital Signature, Key Encipherment{code}
Add Comment
Jira (PUP-8325) Trusted facts can't be structured data
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-8325
Trusted facts can't be structured data
Change By:
Nate McCurdy
h2. ProblemIt appears to be impossible to have a trusted fact whose value is structured data or any data type other than a String.h2. Desired BehaviorGiven a {{csr_attributes.yaml}} like the below, I'd expect the value of {{pp_product}} to be a hash containing Strings, Booleans, and Arrays.{code:yaml}---extension_requests: pp_role: test pp_product:owner: natename: "A test product"approved: trueis_a_thing: falsetiers: - one - two - blue{code} h2. Actual BehaviorThe value of the trusted fact for {{pp_product}} is stringified as shown in the Puppet Enterprise console: {code}{ "authenticated" : "remote", "certname" : "pe-201732-agent !Bad Fact . puppetdebug.vlan", png|thumbnail! "domain" : "puppetdebug.vlan", "extensions" : {"pp_product" : "{\"owner\"=>\"nate\", \"name\"=>\"A test product\", \"approved\"=>true, \"is_a_thing\"=>false, \"tiers\"=>[\"one\", \"two\", \"blue\"]}","pp_role" : "test" }, "hostname" : "pe-201732-agent"}{code} In code, the $trusted variable also doesn't contain a {{tiers}} array. The errors message implies that pp_product is a String:{code}node default { $pp_product_tiers = $trusted['extensions']['pp_product']['tiers'] notify { $pp_product_tiers: }}{code}{code}[root@pe-201732-agent ~]# puppet agent -tInfo: Using configured environment 'production'Info: Retrieving pluginfactsInfo: Retrieving pluginInfo: Loading factsError: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: A substring operation does not accept a String as a character index. Expected an Integer at /etc/puppetlabs/code/environments/production/manifests/site.pp:4:60 on node pe-201732-agent.puppetdebug.vlanWarning: Not using cache on failed catalogError: Could not retrieve catalog; skipping run{code}
Add Comment
This message was sent by Atlassian JIRA
Jira (PUP-8325) Trusted facts can't be structured data
Title: Message Title Nate McCurdy updated an issue Puppet / PUP-8325 Trusted facts can't be structured data Change By: Nate McCurdy Attachment: Bad Fact.png Add Comment This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8325) Trusted facts can't be structured data
Title: Message Title Nate McCurdy created an issue Puppet / PUP-8325 Trusted facts can't be structured data Issue Type: Bug Affects Versions: PUP 5.3.3 Assignee: Unassigned Created: 2018/01/05 2:01 PM Priority: Normal Reporter: Nate McCurdy Problem It appears to be impossible to have a trusted fact whose value is structured data or any data type other than a String. Desired Behavior Given a csr_attributes.yaml like the below, I'd expect the value of pp_product to be a hash containing Strings, Booleans, and Arrays. --- extension_requests: pp_role: test
Jira (PDB-3767) fact_contents should be able to return non-leaf values
Title: Message Title Nate McCurdy commented on PDB-3767 Re: fact_contents should be able to return non-leaf values Wyatt Alt Ah yeah, looking back at 2634, they do seem similar. And look's like I went down a slightly different path to discover the same problem. I don't know enough about the PuppetDB internals to know if this should be a duplicate of that ticket though. But, I do feel that there's at least a docs problem here (if it is the same ultimate fix as 2634) because the docs state that fact_contents can return a hash or array, but I've not found that to be the case. Add Comment This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-3767) fact_contents should be able to return non-leaf values
Title: Message Title
Nate McCurdy updated an issue
PuppetDB / PDB-3767
fact_contents should be able to return non-leaf values
Change By:
Nate McCurdy
h1. BackgroundThe fact_contents endpoint can be used to query for structured fact values correlated with certnames. This is useful for reporting. For example, using PQL to get a list of all node names + their os major release version:{code}puppet query 'fact_contents[certname,value] { path ~> ["os","release","major"] }'{code}But, what if I want to see the value of {{os.release}}?The [docs state|https://puppet.com/docs/puppetdb/5.1/api/query/v4/fact-contents.html#paths-and-values] that the value must be a leaf value. But then how can a leaf's value be an array or a hash? Wouldn't those be others other leafs?{quote}A fact path is an array representing a route from the root of the tree to one of the leaf values, with successive keys representing descent through hashes, and integers representing descent through arrays (the integer being the index, starting at 0). Structured fact leaf values may be hashes, arrays, integers, floats, strings, or booleans.{quote}h1. Expected OutcomeHitting the {{fact_contents}} endpoint for a path whose value is structured data (a hash or an array), should return that structured data as the {{value}}.e.g I'd expect to see this:{code}puppet query 'fact_contents[certname,value] { path ~> ["os","release"] }' | jq[{ "certname": "pe-201730-master.puppetdebug.vlan", "value": {"full": "7.2.1511","major": "7","minor": "2" }}]{code}h1. Actual OutcomeSearching against a non-leaf path returns no results.{code}[root@pe-201730-master ~]# puppet query 'fact_contents[certname,value] { path ~> ["os","release","major"] }' | jq[ {"certname": "pe-201730-master.puppetdebug.vlan","value": "7" }][root@pe-201730-master ~]# puppet query 'fact_contents[certname,value] { path ~> ["os","release"] }' | jq[]{code}This also does not work when using AST:{code}[root@pe-201730-master ~]# curl -sX GET 'http://localhost:8080/pdb/query/v4/fact-contents' --data-urlencode 'query=["=", "path", [ "os", "release" ]]' | jq[]{code}I found this problem while playing with a [custom fact that shows the yumrepos|https://github.com/natemccurdy/yumrepos_fact] on a node:{code}[root@pe-201730-master ~]# facter -p yumrepos{ enabled => ["base","epel" ], disabled => ["centosplus","epel-source" ], count => {enabled => 2,disabled => 2,total => 4 }}{code}I'd like to be able to run a query that shows the full value for {{enabled}} , {{disabled}}, or {{count}}. Two of which contain arrays and the third, a hash.Sidenote: You may have noticed that I used {{~>}} instead of {{=}} for those PQL queries. See PDB-3176
Jira (PDB-3767) fact_contents should be able to return non-leaf values
Title: Message Title
Nate McCurdy updated an issue
PuppetDB / PDB-3767
fact_contents should be able to return non-leaf values
Change By:
Nate McCurdy
h1. BackgroundThe fact_contents endpoint can be used to query for structured fact values correlated with certnames. This is useful for reporting. For example, using PQL to get a list of all node names + their os major release version:{code}puppet query 'fact_contents[certname,value] { path ~> ["os","release","major"] }'{code}But, what if I want to see the value of {{os.release}}? The [docs state|https://puppet.com/docs/puppetdb/5.1/api/query/v4/fact-contents.html#paths-and-values] that the value must be a leaf value. But then how can a leaf's value be an array or a hash? Wouldn't those be others leafs?{quote}A fact path is an array representing a route from the root of the tree to one of the leaf values, with successive keys representing descent through hashes, and integers representing descent through arrays (the integer being the index, starting at 0). Structured fact leaf values may be hashes, arrays, integers, floats, strings, or booleans.{quote} h1. Expected OutcomeHitting the {{fact_contents}} endpoint for a path whose value is structured data (a hash or an array), should return that structured data as the {{value}}.e.g I'd expect to see this:{code}puppet query 'fact_contents[certname,value] { path ~> ["os","release"] }' | jq[{ "certname": "pe-201730-master.puppetdebug.vlan", "value": {"full": "7.2.1511","major": "7","minor": "2" }}]{code}h1. Actual OutcomeSearching against a non-leaf path returns no results.{code}[root@pe-201730-master ~]# puppet query 'fact_contents[certname,value] { path ~> ["os","release","major"] }' | jq[ {"certname": "pe-201730-master.puppetdebug.vlan","value": "7" }][root@pe-201730-master ~]# puppet query 'fact_contents[certname,value] { path ~> ["os","release"] }' | jq[]{code}This also does not work when using AST:{code}[root@pe-201730-master ~]# curl -sX GET 'http://localhost:8080/pdb/query/v4/fact-contents' --data-urlencode 'query=["=", "path", [ "os", "release" ]]' | jq[]{code} I found this problem while playing with a [custom fact that shows the yumrepos|https://github.com/natemccurdy/yumrepos_fact] on a node:{code}[root@pe-201730-master ~]# facter -p yumrepos{ enabled => ["base","epel" ], disabled => ["centosplus","epel-source" ], count => {enabled => 2,disabled => 2,total => 4 }}{code}I'd like to be able to run a query that shows the full value for {{enabled}} , {{disabled}}, or {{count}}. Two of which contain arrays and the third, a hash. Sidenote: You may have noticed that I used {{~>}} instead of {{=}} for those PQL queries. See PDB-3176
Jira (PDB-3767) fact_contents should be able to return non-leaf values
Title: Message Title
Nate McCurdy updated an issue
PuppetDB / PDB-3767
fact_contents should be able to return non-leaf values
Change By:
Nate McCurdy
h1. BackgroundThe fact_contents endpoint can be used to query for structured fact values correlated with certnames. This is useful for reporting. For example, using PQL to get a list of all node names + their os major release version:{code}puppet query 'fact_contents[certname,value] { path ~> ["os","release","major"] }'{code}But, what if I want to see the value of {{os.release}}?h1. Expected OutcomeHitting the {{fact_contents}} endpoint for a path whose value is structured data (a hash or an array), should return that structured data as the {{value}}.e.g I'd expect to see this:{code}puppet query 'fact_contents[certname,value] { path ~> ["os","release"] }' | jq[{ "certname": "pe-201730-master.puppetdebug.vlan", "value": {"full": "7.2.1511","major": "7","minor": "2" }}]{code}h1. Actual OutcomeSearching against a non-leaf path returns no results.{code}[root@pe-201730-master ~]# puppet query 'fact_contents[certname,value] { path ~> ["os","release","major"] }' | jq[ {"certname": "pe-201730-master.puppetdebug.vlan","value": "7" }][root@pe-201730-master ~]# puppet query 'fact_contents[certname,value] { path ~> ["os","release"] }' | jq[]{code}This also does not work when using AST:{code}[root@pe-201730-master ~]# curl -sX GET 'http://localhost:8080/pdb/query/v4/fact-contents' --data-urlencode 'query=["=", "path", [ "os", "release" ]]' | jq[]{code} Sidenote: You may have noticed that I used {{~>}} instead of {{=}} for those PQL queries. See PDB-3176
Add Comment
This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db)
Jira (PDB-3767) fact_contents should be able to return non-leaf values
Title: Message Title
Nate McCurdy updated an issue
PuppetDB / PDB-3767
fact_contents should be able to return non-leaf values
Change By:
Nate McCurdy
h1. BackgroundThe fact_contents endpoint can be used to query for structured fact values correlated with certnames. This is useful for reporting. For example, using PQL to get a list of all node names + their os major release version:{code}puppet query 'fact_contents[certname,value] { path ~> ["os","release","major"] }'{code}But, what if I want to see the value of {{os.release}}?h1. Expected OutcomeHitting the {{fact_contents}} endpoint for a path whose value is structured data (a hash or an array), should return that structured data as the {{value}}.e.g I'd expect to see this:{code}puppet query 'fact_contents[certname,value] { path ~> ["os","release"] }' | jq[{ "certname": "pe-201730-master.puppetdebug.vlan", "value": {"full": "7.2.1511","major": "7","minor": "2" }}]{code}h1. Actual OutcomeSearching against a non-leaf path returns no results.{code}[root@pe-201730-master ~]# puppet query 'fact_contents[certname,value] { path ~> ["os","release","major"] }' | jq[ {"certname": "pe-201730-master.puppetdebug.vlan","value": "7" }][root@pe-201730-master ~]# puppet query 'fact_contents[certname,value] { path ~> ["os","release"] }' | jq[]{code} This also does not work when using AST:{code}[root@pe-201730-master ~]# curl -sX GET 'http://localhost:8080/pdb/query/v4/fact-contents' --data-urlencode 'query=["=", "path", [ "os", "release" ]]' | jq[]{code} Sidenote: You may have noticed that I used {{~>}} instead of {{=}} for those PQL queries . See PDB-3176
Add Comment
This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db)
Jira (PDB-3767) fact_contents should be able to return non-leaf values
Title: Message Title
Nate McCurdy created an issue
PuppetDB / PDB-3767
fact_contents should be able to return non-leaf values
Issue Type:
Bug
Affects Versions:
PDB 5.1.1
Assignee:
Unassigned
Created:
2017/11/26 8:15 PM
Priority:
Normal
Reporter:
Nate McCurdy
Background
The fact_contents endpoint can be used to query for structured fact values correlated with certnames. This is useful for reporting.
For example, using PQL to get a list of all node names + their os major release version:
puppet query 'fact_contents[certname,value] { path ~> ["os","release","major"] }'
But, what if I want to see the value of os.release?
Expected Outcome
Hitting the fact_contents endpoint for a path whose value is structured data (a hash or an array), should return that
Jira (PDB-3176) PQL does not support query for fact path equality
Title: Message Title
Nate McCurdy commented on PDB-3176
Re: PQL does not support query for fact path equality
puppet query 'fact_contents[certname,value] { path = ["os","release","major"] }'
Using = seems like it should work based on the docs for fact_contents, but it does not. So, you'll have to use ~> which is not obvious.
puppet query 'fact_contents[certname,value] { path ~> ["os","release","major"] }'
Add Comment
This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit
Jira (PUP-6953) Puppet should give a more direct error when it can't find a 4.x function because of a missing module dependency
Title: Message Title Nate McCurdy commented on PUP-6953 Re: Puppet should give a more direct error when it can't find a 4.x function because of a missing module dependency I'd like to point out that this affects custom types from a module as well. For example, Stdlib::Absolutepath from the stdlib module. This was entirely unexpected behavior and a breaking change that affected many nodes. The fix (removing the empty array of dependencies in metadata.json) was very much not-obvious to find. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6964) Puppet 4.x functions should be available to all modules not just those that declare the containing module as a dependency
Title: Message Title Nate McCurdy commented on PUP-6964 Re: Puppet 4.x functions should be available to all modules not just those that declare the containing module as a dependency I'd like to point out that this affects custom types from a module as well. For example, Stdlib::Absolutepath from the stdlib module. This was entirely unexpected behavior and a breaking change that affected many nodes. The fix (removing the empty array of dependencies in metadata.json) was very much not-obvious to find. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6040) "puppet facts" outputs indirector object instead of simple fact list
Title: Message Title Nate McCurdy commented on PUP-6040 Re: "puppet facts" outputs indirector object instead of simple fact list Will puppet facts be able to show the value of a single fact? It should. puppet facts os.networking for example. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6729) NTFS permissions should be recalculated given SYSTEM is an implicit member of local Administrators
Title: Message Title Nate McCurdy updated an issue Puppet / PUP-6729 NTFS permissions should be recalculated given SYSTEM is an implicit member of local Administrators Change By: Nate McCurdy Attachment: cache ACL after razor install.png Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1916) puppet cert clean cannot remove signing requests
Title: Message Title Nate McCurdy updated an issue Puppet / PUP-1916 puppet cert clean cannot remove signing requests Change By: Nate McCurdy Affects Version/s: PUP 4.10.6 Affects Version/s: PUP 5.0.1 Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-2634) PQL & Hashes: Provide hash projection capability for facts & resource params
Title: Message Title
Nate McCurdy commented on PDB-2634
Re: PQL & Hashes: Provide hash projection capability for facts & resource params
A PQL query that I intuitively thought I could do is this:
puppet query 'facts[certname,value] { name = "os.family" }'
When that didn't work, I tried the next thing that I intuitively thought should work:
puppet query 'inventory[certname, facts.os.family]{ }'
I was bummed when I found that wasn't the case. I'm a big +1 to this feature existing!
Add Comment
This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group
Jira (PUP-7585) Windows group's "members changed" message is misleading
Title: Message Title Nate McCurdy updated an issue Puppet / PUP-7585 Windows group's "members changed" message is misleading Change By: Nate McCurdy Component/s: Windows Component/s: Types and Providers Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-7585) Windows group's "members changed" message is misleading
Title: Message Title Nate McCurdy updated an issue Puppet / PUP-7585 Windows group's "members changed" message is misleading Change By: Nate McCurdy Labels: windows Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-7585) Windows group's "members changed" message is misleading
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-7585
Windows group's "members changed" message is misleading
Change By:
Nate McCurdy
When managing groups and their membership on Windows, the output of the Puppet run is misleading.!misleading 'changed to' message.png|thumbnail!Base on that output, you'd think that Puppet just changed the {{Administrators}} group to contain *only* the members {{bob}} and {{sally}}. But you'd be wrong! Puppet just added {{bob}} and {{sally}} to the group.This is the code that made that was run to generate the screenshot:{code:puppet}group { 'Administrators': ensure => present, members => ['bob', 'sally'], auth_membership => false,}{code}I'd expect that setting {{auth_membership => true}} would show the output from the screenshot. And I'd expect that {{auth_membership => false}} would show the two new members being *added* to the existing members, not replacing them.
Add Comment
This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-7585) Windows groups "members changed" message is misleading
Title: Message Title
Nate McCurdy created an issue
Puppet / PUP-7585
Windows groups "members changed" message is misleading
Issue Type:
Bug
Affects Versions:
PUP 4.8.1
Assignee:
Unassigned
Attachments:
misleading 'changed to' message.png
Created:
2017/05/22 4:13 PM
Priority:
Normal
Reporter:
Nate McCurdy
When managing groups and their membership on Windows, the output of the Puppet run is misleading.
Base on that output, you'd think that Puppet just changed the Administrators group to contain only the members bob and sally. But you'd be wrong! Puppet just added bob and sally to the group.
This is the code that made that was run to generate the screenshot:
group { 'Administrators':
Jira (PUP-7585) Windows group's "members changed" message is misleading
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-7585
Windows group's "members changed" message is misleading
Change By:
Nate McCurdy
When managing groups and their membership on Windows, the output of the Puppet run is misleading.!misleading 'changed to' message.png|thumbnail!Base on that output, you'd think that Puppet just changed the {{Administrators}} group to contain *only* the members {{bob}} and {{sally}}. But you'd be wrong! Puppet just added {{bob}} and {{sally}} to the group.This is the code that made that was run to generate the screenshot:{code:puppet}group { 'Administrators': ensure => present, members => [ 'bob', 'sally'], auth_membership => false,}{code}I'd expect that setting {{auth_membership => true}} would show the output from the screenshot. And I'd expect that {{auth_membership => false}} would show the two new members being *added* to the existing members, not replacing them.
Add Comment
This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-7585) Windows group's "members changed" message is misleading
Title: Message Title Nate McCurdy updated an issue Puppet / PUP-7585 Windows group's "members changed" message is misleading Change By: Nate McCurdy Summary: Windows groups group's "members changed" message is misleading Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
