Jira (FACT-718) Allow for disabling certain facts within Facter
Title: Message Title Corey Hickey commented on FACT-718 Re: Allow for disabling certain facts within Facter I agree as well. I found out about this ticket when tracking down "suspicious" connection attempts to 169.254.169.254 that turned out to be caused by EC2 detection. Being able to disable known-unwanted functionality would be useful. Thanks, Corey Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- 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-8969) Sensitive parameters are not redacted from reports / agent output when used in templates
Title: Message Title Corey Hickey commented on PUP-8969 Re: Sensitive parameters are not redacted from reports / agent output when used in templates I came upon this ticket because Sensitive didn't behave quite like I expected. 1. I expected Sensitive to behave like a flag rather than a distinct data type; thus, a variable could be declared as Sensitive at any point and then passed to classes, templates, defined types, etc. which didn't necessarily need to know/care whether the value is sensitive. Only the low-level printing/logging functions would redact as necessary. 2. I expected that any evaluation via template, string interpolation, etc. would inherit the Sensitive flag of any Sensitive components. I did not necessarily expect that the result could have mixed sensitive/non-sensitive components recognized during printing, though this would be very nice for viewing diffs of files that only contain some sensitive content. Maybe my expectations were out of line, but that sort of thing does seem like useful behavior. Thanks, Corey 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.262922.1530114614000.4141.1576636080231%40Atlassian.JIRA.
Jira (PUP-10214) Unexpected results on "replace => false" on symlinks
Title: Message Title
Corey Hickey updated an issue
Puppet / PUP-10214
Unexpected results on "replace => false" on symlinks
Change By:
Corey Hickey
*Puppet Version: 5.5.17-1.el7* *Puppet Server Version:5.3.10-1.el7* *OS Name/Version: Centos 7*This is a copy of an old redmine ticket that was never resolved:[https://projects.puppetlabs.com/issues/4872]To summarize, if puppet contains a declaration:{code}file { '/foo':ensure => 'link',target => '/bar'replace => false,}{code}...and '/foo' already exists as a dangling symlink (pointing to a file that does not exist), then puppet will change the symlink to point back to '/bar'.*Desired Behavior:*Puppet should respect {{replace =>}} false and not replace the symlink.*Actual Behavior:*As described above, puppet replaces the symlink. I looked at the code and I think the current behavior is the same in master, though I don't have the means to test it myself. These parts seem relevant:lib/puppet/type/file/target.rb{code} def insync?(currentvalue) if [:nochange, :notlink].include?(self.should) or @resource.recurse?return true elsif ! @resource.replace? and Puppet::FileSystem.exist?(@resource[:path])return true else{code}lib/puppet/file_system.rb{code} # Determines if a file exists by verifying that the file can be stat'd. # Will follow symlinks and verify that the actual target path exists. # # @return [Boolean] true if the named file exists. # # @api public # def self.exist?(path)@impl.exist?(assert_path(path)) end {code}I think that for this functionality, the file resource code should instead use a function that does _not_ follow symlinks. Puppet is supposed to be managing the file symlink , and the target (present or not ) is irrelevant. When creating a symlink, puppet correctly does not care if the target exists . Thanks,Corey
Add Comment
Jira (PUP-10214) Unexpected results on "replace => false" on symlinks
Title: Message Title
Corey Hickey created an issue
Puppet / PUP-10214
Unexpected results on "replace => false" on symlinks
Issue Type:
Bug
Affects Versions:
PUP 5.5.17
Assignee:
Unassigned
Components:
Catalog Application
Created:
2020/01/02 4:17 PM
Priority:
Normal
Reporter:
Corey Hickey
Puppet Version: 5.5.17-1.el7 Puppet Server Version:5.3.10-1.el7 OS Name/Version: Centos 7 This is a copy of an old redmine ticket that was never resolved: https://projects.puppetlabs.com/issues/4872 To summarize, if puppet contains a declaration:
file { '/foo':
ensure => 'link',
target => '/bar'
replace => false,
Jira (PUP-10214) Unexpected results on "replace => false" on symlinks
Title: Message Title Corey Hickey commented on PUP-10214 Re: Unexpected results on "replace => false" on symlinks As a related issue, the creates parameter to the exec resource also follows symlinks, so it breaks when the symlink is dangling. This issue seems to be abandoned as well: https://projects.puppetlabs.com/issues/13126 -Corey 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.340916.1578010636000.11465.1578016320104%40Atlassian.JIRA.
Jira (PUP-10214) Unexpected results on "replace => false" on symlinks
Title: Message Title Corey Hickey commented on PUP-10214 Re: Unexpected results on "replace => false" on symlinks Josh Cooper I thought the links parameter was for how to handle files local to the puppetmaster, but it would seem appropriate to extend the parameter to this case, especially as in your example where the default behavior fixes the bug. Jorie Tappa thanks for your comment. I took a look at PUP-5830 and I think I would characterize that ticket as describing "strange behavior when given pathological parameters", whereas my ticket here is more "incorrect behavior under some circumstances when given appropriate parameters". So, I don't think it would be fair to consider PUP-5830 as precedent. -Corey 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.340916.1578010636000.13690.1578362760259%40Atlassian.JIRA.
Jira (PUP-10214) Unexpected results on "replace => false" on symlinks
Title: Message Title
Corey Hickey commented on PUP-10214
Re: Unexpected results on "replace => false" on symlinks
Thanks Josh Cooper , but I think the two bugs are different. PUP-6998 seems to be more of a logic issue in puppet deciding to manage a file as a symlink rather than as the specified ensure. For this bug, I revisited it on the current main git branch. First, I don't understand your point about the links parameter. I tested that with a simple manifest:
file { '/tmp/foo':
ensure => 'file',
content => "new\n",
links => 'follow',
}
Via:
$ echo orig > /tmp/bar
$ ln -s bar /tmp/foo
$ ls -l /tmp/foo
lrwxrwxrwx 1 chickey chickey 3 2021-06-15 22:59:39 /tmp/foo -> bar
$ RUBYLIB=./lib bin/puppet --version
7.9.0
Jira (PUP-11427) Iterable behavior of Integers not documented?
Title: Message Title Corey Hickey created an issue Puppet / PUP-11427 Iterable behavior of Integers not documented? Issue Type: Improvement Affects Versions: PUP 7.12.1 Assignee: Unassigned Components: Docs Created: 2022/01/05 4:50 PM Priority: Normal Reporter: Corey Hickey I discovered, entirely by accident, that an Integer is an Iterable which expands to the range from zero to one less than the Integer. I can find this in the code and it's clearly an intended behavior: https://github.com/puppetlabs/puppet/blob/7.13.1/lib/puppet/pops/types/iterable.rb#L44 https://github.com/puppetlabs/puppet/blob/7.13.1/lib/puppet/pops/types/iterable.rb#L92 I can't find this documented at all, though. Unless I'm missing something, the closest I can find is references to the Iterable type, though these pages don't enumerate what the type contains: https://puppet.com/docs/puppet/7/functions_iterative.html https://puppet.com/docs/puppet/7/lang_data_abstract.html#iterable-data-type Thanks, Corey Add Comment
Jira (PUP-7409) Knockout prefix does not remove an entire key:value entry from a hash
Title: Message Title Corey Hickey commented on PUP-7409 Re: Knockout prefix does not remove an entire key:value entry from a hash Is this ticket actually done? The resolution is "Done", but I still can't make knockout_prefix remove a hash key with puppet 7.14.0. I seem to end up finding this ticket once a year or so when I go looking for a way to do that... If the actual resolution is "WONTFIX" due to lack of support in the deep_merge gem, then I can understand that, but if so, can you please update the ticket "Resolution" field? I can't see DOC-3150, but I do think the documentation is still unclear: A string prefix to indicate a value should be removed from the final result. If a value is exactly equal to the prefix, it will knockout the entire element. Pertaining to a hash, I don't know what an "element" is; this term is never used in: https://puppet.com/docs/puppet/7/lang_data_hash.html ...so I would tend to guess that "element" means a key/value pair, but that does not match the observed behavior of knockount_prefix only clearing the value but leaving the key remaining. Thanks, Corey 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
Jira (PUP-11427) Iterable behavior of Integers not documented?
Title: Message Title
Corey Hickey commented on PUP-11427
Re: Iterable behavior of Integers not documented?
I'd say the comment is ambiguous; it's hard to know exactly since English doesn't describe ranges very well. I do like the current behavior, though, for what I'm doing. Basically:
class foo (
Integer[1] $num_instances,
) {
$num_instances.each |$instance| {
foo::instance { $instance:
bar => 'baz',
}
}
}
Add Comment
Jira (FACT-3189) facter cannot block some facts
Title: Message Title
Corey Hickey created an issue
Facter / FACT-3189
facter cannot block some facts
Issue Type:
Bug
Affects Versions:
FACT 4.2.14
Assignee:
Unassigned
Components:
Facter 4
Created:
2023/03/01 2:59 PM
Environment:
I'm using facter 4.2.7 on AlmaLinux 8.7. This is also reproducible with facter from recent git (2a75849d7b47baebb05b840a0d5d7a4bf66f0e29 and presumably later as well).
Priority:
Normal
Reporter:
Corey Hickey
Hello, In attempting to block a specific fact, I ran into some inconsistent behavior. I could block some facts, but not others. I opened a thread on the puppet-community slack: https://puppetcommunity.slack.com/archives/C0W298S9G/p1677263313600889 Here are a couple examples of facts that fail to be blocked:
$ echo -e 'facts: { blocklist: [ "blocked" ] }\nfact-groups: { blocked: [ "networking.interfaces.lo" ] }' > facter.conf && facter -j -c facter.conf | jq '.networking.interfaces.lo.ip'
"127.0.0.1"
Jira (FACT-3189) facter cannot block some facts
Title: Message Title
Corey Hickey updated an issue
Facter / FACT-3189
facter cannot block some facts
Change By:
Corey Hickey
Hello,In attempting to block a specific fact, I ran into some inconsistent behavior. I could block some facts, but not others. I opened a thread on the puppet-community slack: [ https://puppetcommunity.slack.com/archives/C0W298S9G/p1677263313600889 ] Here are a couple examples of facts that fail to be blocked:{code} $ echo -e 'facts: { blocklist: [ "blocked" ] }\nfact-groups: { blocked: [ "networking.interfaces.lo" ] }' > facter.conf && facter -j -c facter.conf | jq '.networking.interfaces.lo.ip'"127.0.0.1"$ echo -e 'facts: { blocklist: [ "blocked" ] }\nfact-groups: { blocked: [ "ec2_metadata.managed-ssh-keys.signer-cert" ] }' > facter.conf && facter -j -c facter.conf | jq '.ec2_metadata."managed-ssh-keys"."signer-cert"' | wc -c7067{code} The first example should be more generally broadly testable; the second example requires an AWS EC2 host and shows the fact I was intending to block.[~josh] investigated this and was able to diagnose a bit further.{quote} Implementation-wise there are a few different use-cases:* blocking an entire structured fact, e.g. {{uptime}}* blocking a sub-element of a structured fact, e.g. {{memory.system.available}}* blocking a dynamically generated sub-element, e.g. {{partitions.}}* blocking legacy factsI think all of those work except for the third one, for example, this is using current head of facter:{code} $ echo -e 'facts: { blocklist: [ "blocked" ] }\nfact-groups: { blocked: [ "networking.interfaces.lo" ] }' > facter.conf && bundle exec facter -j -c facter.conf | jq '.networking.interfaces.lo.ip'"127.0.0.1"{code} {quote} Thanks,Corey {quote}
Add Comment
Jira (PUP-11897) 100% usage of a CPU core when an exec command sends EOF
Title: Message Title
Corey Hickey created an issue
Puppet / PUP-11897
100% usage of a CPU core when an exec command sends EOF
Issue Type:
Bug
Affects Versions:
PUP 8.0.1
Assignee:
Unassigned
Components:
Types and Providers
Created:
2023/06/22 2:56 PM
Priority:
Normal
Reporter:
Corey Hickey
Puppet Version:{} Seen in 7.14.0, 7.23.0, and current git 61234be0e4d6. The code originates in d4c1582ed0c2a3e. Puppet Server Version: N/A; reproducible via puppet apply. ** OS Name/Version:{} Seen in AlmaLinux 8.7 and Debian Unstable. This is probably POSIX-specific; the affected code runs under if Puppet.features.posix? Describe your issue in as much detail as possible… When puppet applies an exec resource, and the command run by that exec returns an EOF on the pipe handling stdout and stdterr, puppet ignores the EOF. This results in puppet rapidly looping over these system calls:
1359029 wait4(1359100, 0x7ffce8537cb8, WNOHANG, NULL) = 0
1359029 getpid() = 1359029
1359029 pselect6(7, [6], [], [], {tv_sec=0,
Jira (PUP-11897) 100% usage of a CPU core when an exec command sends EOF
Title: Message Title
Corey Hickey commented on PUP-11897
Re: 100% usage of a CPU core when an exec command sends EOF
There are different ways to construct a command which will return an EOF. Here are several more examples:
$c2 = [
'/bin/bash', '-c',
'exec >/dev/null 2>&1; sleep 10',
]
exec { 'c2':
command => $c2,
}
$c3 = [
'/usr/bin/perl', '-e',
'close(STDOUT); close(STDERR); sleep 10'
]
exec { 'c3':
command => $c3,
Jira (PUP-11897) 100% usage of a CPU core when an exec command sends EOF
Title: Message Title Corey Hickey commented on PUP-11897 Re: 100% usage of a CPU core when an exec command sends EOF PR submitted to: https://github.com/puppetlabs/puppet/pull/9074 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.487522.1687471014000.1269.1687471800021%40Atlassian.JIRA.
Jira (PUP-11897) 100% usage of a CPU core when an exec command sends EOF
Title: Message Title
Corey Hickey updated an issue
Puppet / PUP-11897
100% usage of a CPU core when an exec command sends EOF
Change By:
Corey Hickey
{ * } Puppet Version: { * }{*}{*} Seen in 7.14.0, 7.23.0, and current git 61234be0e4d6.The code originates in d4c1582ed0c2a3e.*Puppet Server Version:*N/A; reproducible via {{{}puppet apply{}}}. ** { * } OS Name/Version: { * }{*}{*} Seen in AlmaLinux 8.7 and Debian Unstable.This is probably POSIX-specific; the affected code runs under {{if Puppet.features.posix?}}*Describe your issue in as much detail as possible…*When puppet applies an {{exec}} resource, and the command run by that exec returns an EOF on the pipe handling stdout and stdterr, puppet ignores the EOF. This results in puppet rapidly looping over these system calls:{code:java} 1359029 wait4(1359100, 0x7ffce8537cb8, WNOHANG, NULL) = 01359029 getpid() = 13590291359029 pselect6(7, [6], [], [], {tv_sec=0, tv_nsec=1}, NULL) = 1 (in [6], left {tv_sec=0, tv_nsec=8955})1359029 fcntl(6, F_GETFL) = 0x800 (flags O_RDONLY|O_NONBLOCK)1359029 read(6, "", 4096) = 0{code}There is no blocking in the loop, so puppet consumes 100% of a CPU core until the child process exits.*Describe steps to reproduce…*Use a manifest like {{/tmp/test.pp}}{code:java} $c1 = [ '/bin/bash', '-c', 'exec /bin/sleep 10 >/dev/null 2>&1',]exec { 'c1': command => $c1,}{code}Then run:{code:java} time puppet apply /tmp/test.pp{code}*Desired Behavior:*The timing output should be like:{code:java} real 0m13.554suser 0m2.857ssys 0m0.516s{code}Real time is expected to be high, due to the 10 second sleep, but user time should be relatively low.*Actual Behavior:*The timing output is:{code:java} real 0m13.486suser 0m11.048ssys 0m2.265s{code}Note the high user time; this is because puppet is busy-looping while the child sleeps for 10 seconds.I will submit a patch for this.
Add Comment
