Jira (PUP-6494) exec resources leak the command string when execution fails
Title: Message Title Brian Conner commented on PUP-6494 Re: exec resources leak the command string when execution fails John Duarte my mistake, Peter Huene, thanks for the work! I just saw you update the Fix Version, so it seems that answers my other question about which release this will go into. Haha we're typing at the same time, no apologies needed! 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-6494) exec resources leak the command string when execution fails
Title: Message Title Brian Conner commented on PUP-6494 Re: exec resources leak the command string when execution fails Great work John Duarte! Will it be redacted like that in the agent's /opt/puppetlabs/puppet/cache/client_data/catalog/*.json also? Which Puppet release will this be planned for? Appreciate it! 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-6494) exec resources leak the command string when execution fails
Title: Message Title Brian Conner commented on PUP-6494 Re: exec resources leak the command string when execution fails Josh, that is a possibility, however, won't the password still be on the agent catalog, which isn't desired? Thomas, the command that prompted this ticket was adcli join, with the password. Any failing exec where the password has to be passed inline as a variable(eyaml or not) will do this. Henrik, I like this idea. Perhaps that could be further implemented on the agent side as well so that the password is a harmless hash on the stored catalog? I believe conjur does something along these lines, I did see it discussed elsewhere in the Puppet tickets. 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-6482) Puppet logging information leaks
Title: Message Title Brian Conner commented on PUP-6482 Re: Puppet logging information leaks If an exec is run as an inline sh script with an eyaml'd password variable, the password will get logged in plaintext on the console and agent if it fails. loglevel and logoutput don't do anything in this situation, as it's the command that's being displayed, not the output of the command. It was suggested to make the command into a script and run it that way, but that presents putting the password plaintext in the script, not a viable long-term solution. Having the exec's inline sh script executed in this manner presents another issue. The same data is present in the cached catalog on agents in /opt/puppetlabs/puppet/cache/client_data/catalog/*.json. I imagine this issue is caught somewhere in https://tickets.puppetlabs.com/browse/PUP-1974. Just an idea to branch off of the "sensitive" resource type mentioned in PUP-1974: Most passwords and sensitve data will be coming from an eyaml'd variable(at least, in our scenario). If there were a setting in puppet.conf that would mark all eyaml data as "sensitive", hashing or masking it in logs and cached catalogs, that might take care of the lion's share of sensitive information leaks. This would be in addition to being able "to give manifest/module authors the ability to specify resource properties (such as attributes or titles) which are sensitive". 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-6462) Re-enable links to filebucket diffs in the console
Title: Message Title Brian Conner commented on PUP-6462 Re: Re-enable links to filebucket diffs in the console Thank you Erik Hansen. To be clear, we'd like the hashes under "changed from" and "changed to" to be clickable to see both the before and after if possible. 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-6334) ProviderInit returns false with Puppet 4.5; on the same system it returns true with Puppet 4.4.2 (CentOS 6.x)
Title: Message Title
Brian Conner commented on PUP-6334
Re: ProviderInit returns false with Puppet 4.5; on the same system it returns true with Puppet 4.4.2 (CentOS 6.x)
Thanks all, it now works for CentOS 6 using
provider => 'redhat'
. Unfortunately, now we're having issues with CentOS 7:
This error was actually for CloudPassage, I was advised to use iptables originally as that would be something everyone would have. Init had been used because
provider => systemd
was acting up when the code was written(Puppet 3.8).
class cloudpassage::service {
service { "${cloudpassage::params::servicename}" :
ensure => running,
enable => true,
provider => 'redhat',
Jira (PUP-6334) ProviderInit returns false with Puppet 4.5; on the same system it returns true with Puppet 4.4.2 (CentOS 6.x)
Title: Message Title
Brian Conner updated an issue
Puppet / PUP-6334
ProviderInit returns false with Puppet 4.5; on the same system it returns true with Puppet 4.4.2 (CentOS 6.x)
Change By:
Brian Conner
"Provider init is not functional on this host" is returned when executing {code}puppet resource service iptables provider=init --debug{code} in 4.5.0. Note that the Service resource is using: {code}provider => 'init',{code}.On a 4.4.2 machine, the same command returns ok. This is on CentOS 6.x , masterless puppet .
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-6334) ProviderInit returns false with Puppet 4.5; on the same system it returns true with Puppet 4.4.2 (CentOS 6.x)
Title: Message Title Brian Conner updated an issue Puppet / PUP-6334 ProviderInit returns false with Puppet 4.5; on the same system it returns true with Puppet 4.4.2 (CentOS 6.x) Change By: Brian Conner "Provider init is not functional on this host" is returned when executing puppet resource service cphalod iptables provider=init --debug in 4.5.0. This class is using:provider => 'init', On a 4.4.2 machine, the same command returns ok. This is on CentOS 6.x. 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-6334) ProviderInit returns false with Puppet 4.5; on the same system it returns true with Puppet 4.4.2 (CentOS 6.x)
Title: Message Title Brian Conner created an issue Puppet / PUP-6334 ProviderInit returns false with Puppet 4.5; on the same system it returns true with Puppet 4.4.2 (CentOS 6.x) Issue Type: Bug Affects Versions: PUP 4.5.0 Assignee: Unassigned Components: Breaking Change Created: 2016/05/20 11:06 AM Fix Versions: PUP 4.4.2 Priority: Critical Reporter: Brian Conner "Provider init is not functional on this host" is returned when executing puppet resource service cphalod provider=init --debug in 4.5.0. This class is using: provider => 'init', On a 4.4.2 machine, the same command returns ok. This is on CentOS 6.x.
