Jira (FACT-380) Private ipaddress is used as ipaddress fact
Title: Message Title Stefan Lasiewski commented on FACT-380 Re: Private ipaddress is used as ipaddress fact Branan Riley : Are you able to provide information on some workarounds, as you said in January? We just got bit on this, and it's causing some bad behavior on some of our boxes. 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-1334) Empty clientbucket files produce errors
Title: Message Title
Stefan Lasiewski commented on PUP-1334
Re: Empty clientbucket files produce errors
This also happens in Puppet 3.8.7 on RHEL6.
Our manifest for this file is pretty simple:
# $datacenter is a custom fact
file { "/etc/resolv.conf":
owner => 'root',
group => 'root',
mode => 0644,
source => [
"puppet:///modules/MODULE/resolv.conf.$datacenter",
'puppet:///modules/MODULE/resolv.conf.default',
]
}
Jira (PUP-723) Due to prefetching, Yumrepo clobbers any definition that it does not create
Title: Message Title
Stefan Lasiewski commented on PUP-723
Re: Due to prefetching, Yumrepo clobbers any definition that it does not create
For those of you who find this bug, try Augeas as a workaround:
class stefanl::remi (
$ensure = 'latest',
$enabled = true,
$priority = '80',
) {
package { 'remi-release':
ensure => $ensure,
Jira (PUP-723) Due to prefetching, Yumrepo clobbers any definition that it does not create
Title: Message Title Stefan Lasiewski commented on PUP-723 Re: Due to prefetching, Yumrepo clobbers any definition that it does not create This still happens in Puppet 3.8.4. This is actually a pretty serious bug. On my systems, this bug can lead to a cascade of failures and effectively neuters huge parts of my manifest which are not yum related at all. Using code similar to the Epel example above, this bug triggered failures on over 100+ of my systems. Cleanup required that I remove the truncated .repo file from all of these systems. Yuck. Using the Package and Yumrepo types together seems pretty natural, so I imagine a number of people have run into this. Is there a workaround besides "Don't use yumrepo and package together"? Can I tell Yumrepo to NOT prefetch? ``` puppet agent --test 2>&1 | egrep -c "Warning|Error" 94 puppet agent --test 2>&1 | egrep -c "Skipping because of failed dependencies" 61 ``` Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- 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 http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-3613) Add a parameter to the exec resource to support running commands in software collections without always using scl enable
Title: Message Title
Stefan Lasiewski updated an issue
Puppet / PUP-3613
Add a parameter to the exec resource to support running commands in software collections without always using scl enable
Change By:
Stefan Lasiewski
SoftwarecollectionsisanRPMintegratedvendorizationtoolthat'sstartingtogetmoreandmorewidelyused+supported.Torunacommandinthesoftwarecollection(SCL),youneedtorun`sclenablecollectionname'command'`.Forexample,ifyouwanttoinstallagemintoaSCLnamedruby193,you'drun`sclenableruby193'/usr/bin/geminstallsinatra'`.Here'swhatI'mproposing: pre {code} exec{'installsinatra':command='/usr/bin/geminstallsinatra',unless='gemlist|grepsinatra',scl='ruby193'} /pre {code} ThepresenceoftheSCLparametermeansthatalloftheotherparametersthatinvolvesystemcallswouldgetexecutedinsideofasessionintheSCLnamethat'sprovided.
Add Comment
This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c)
--
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 http://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 Stefan Lasiewski updated an issue Puppet / PUP-1916 puppet cert clean cannot remove signing requests Change By: Stefan Lasiewski Affects Version/s: 3.6.2 Add Comment This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- 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 http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-2345) Upgrading from 3.4 to 3.5 causes Puppet to fail with Could not evaluate: uninitialized constant Puppet::FileSystem::File
Title: Message Title Stefan Lasiewski commented on an issue Re: Upgrading from 3.4 to 3.5 causes Puppet to fail with Could not evaluate: uninitialized constant Puppet::FileSystem::File Thanks for the tip. It looks like Ruby gems did install the 'puppet' and 'puppet-lint' gems. I uninstalled both of those using `gem uninstall puppet` and now the error goes away. ``` gem list LOCAL GEMS *** ansi (1.4.3) awesome_print (1.2.0, 1.0.2) clamp (0.6.3, 0.6.2) daemon_controller (1.2.0, 1.1.5) facter (1.7.5) fastercsv (1.5.5, 1.5.4) fastthread (1.0.7) foreman_api (0.1.11) gettext (2.1.0) hammer_cli (0.0.18) hashie (2.0.5) hiera (1.3.2) highline (1.6.21, 1.6.20) json (1.5.5) json_pure (1.8.1) kafo (0.5.2, 0.4.0, 0.3.17) kafo_parsers (0.0.2, 0.0.1) little-plugger (1.1.3) locale (2.0.5) logging (1.8.2, 1.8.1) mime-types (1.16) multi_json (1.9.2, 1.8.2) oauth (0.4.7) passenger (4.0.40, 4.0.5) powerbar (1.0.11) puppet (3.4.3) puppet-lint (0.3.2) rack (1.5.2, 1.1.0) rack-protection (1.5.2) rack-test (0.6.2, 0.5.4) rake (10.1.1, 0.8.7) rdoc (4.1.1, 3.12) rest-client (1.6.7, 1.6.1) rgen (0.6.6) rkerberos (0.1.2) rubyipmi (0.7.0) sinatra (1.4.4, 1.0) table_print (1.5.1, 1.1.5) tilt (1.4.1) # Add Comment Puppet / PUP-2345 Upgrading from 3.4 to 3.5 causes Puppet to fail with Could not evaluate: uninitialized constant
Jira (PUP-2345) Upgrading from 3.4 to 3.5 causes Puppet to fail with Could not evaluate: uninitialized constant Puppet::FileSystem::File
Title: Message Title Stefan Lasiewski commented on an issue Re: Upgrading from 3.4 to 3.5 causes Puppet to fail with Could not evaluate: uninitialized constant Puppet::FileSystem::File I'm not sure, but this might be a duplicate of PUP-1603 : https://tickets.puppetlabs.com/browse/PUP-1603 Add Comment Puppet / PUP-2345 Upgrading from 3.4 to 3.5 causes Puppet to fail with Could not evaluate: uninitialized constant Puppet::FileSystem::File I am running a Scientific Linux 6.x system with Foreman and Puppet 3.4. Yesterday I ran `yum update`. Afterwards, Puppet failed. Downgrading Puppet from 3.5 to 3.4 prevents the error, and is what I am doing for a workaround. Steps to reproduce: 1. Notice that the error doesn't happen with Puppet 3.4 [root@puppetmaster ~]# puppet --version 3 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- 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
