[Puppet - Bug #3010] Crontab entries using special parameter can't be converted to non-special entries
Issue #3010 has been updated by Felix Frank.
Charlie Sharpsteen wrote:
Also, addressing this issue would tie into fixing #4820 which raises the
issue that it is somewhat silly to be able to specify both normal and special
schedules in a cron resource without Puppet raising a fuss.
I had looked into that one before touching on the whole special schedules are
broken thing. I believe that feature request can be implemented by now,
independently of this bug fix.
But it would surely make more sense to do all the fixing first.
That makes sense to me. However, there might be some discussion required to
determine if this would be a big enough break from current behavior to
warrant delaying it for a 4.x release.
Good point! I guess it would be best to first send a simple fix upstream and
allow special = absent. That could close that bug in a point release (or so I
believe).
The behavioral change can well be another branch altogether, which would not
need to be merged into 3.x?
Is versioning going the Mozilla route of increasing the major number with every
feature release? Or are there major reworkings that make the 3-to-4 jump
necessary in the near future?
Bug #3010: Crontab entries using special parameter can't be converted to
non-special entries
https://projects.puppetlabs.com/issues/3010#change-87882
* Author: Jesse Wolfe
* Status: Accepted
* Priority: Normal
* Assignee:
* Category: cron
* Target version: 3.x
* Affected Puppet version: 0.25.2
* Keywords:
* Branch:
A crontab entry created like so:
pre
cron{ test:
command = /bin/echo /tmp/puppet.txt,
special = reboot,
}
/pre
and then changed like so:
pre
cron{ test:
command = /bin/echo /tmp/puppet.txt,
minute = 50
}
/pre
will not change, and will show the notice:
notice: //Cron[test]/minute: defined 'minute' as '50'
on every run.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #19808] Service provider for windows 2003 - does not work
Issue #19808 has been updated by Klavs Klavsen.
Puppet is run from the Start command prompt with puppet shell - that comes
with the MSI. The same issue exists, when the daemon runs.
I have not specified a path setting - I'd expect it to use the system path.
puppet agent --configprint path - says: none
ruby ..ALT_SEPERATOR says: \
running set in the cmdprompt where I run puppet from says the Path equals the
system path - with puppet paths prepended (ie. c:\WINDOWS\system32 is included
in there.
Bug #19808: Service provider for windows 2003 - does not work
https://projects.puppetlabs.com/issues/19808#change-87883
* Author: Klavs Klavsen
* Status: Needs More Information
* Priority: Normal
* Assignee: Klavs Klavsen
* Category:
* Target version:
* Affected Puppet version:
* Keywords: windows
* Branch:
If I define:
service { 'nscp': ensure = running, enable = true }
puppet wants to use init provider.
I then tried to force it to use windows provider - but it fails (according to
--debug) with file net.exe does not exist windows service provider is not
functional on this host.
Yet: net nscp restart works just fine (ie. net works fine :)
Anything I can do to help debug?
I'm running puppet-3.1.1
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Facter - Bug #20017] (Unreviewed) Add virt-what dependency on Debian-based systems
Issue #20017 has been reported by Franz Pletz. Bug #20017: Add virt-what dependency on Debian-based systems https://projects.puppetlabs.com/issues/20017 * Author: Franz Pletz * Status: Unreviewed * Priority: Normal * Assignee: * Category: installation * Target version: 1.6.x * Keywords: * Branch: * Affected Facter version: 1.6.13 Issue #8210 introduced detecting the virtualization type with virt-what, which is much more reliable than facter's own techniques. Since virt-what is included in Debian at least since squeeze and in Ubuntu since lucid and has negligible overhead, I propose to add a dependency for it in the Debian packaging of facter. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Facter - Bug #20017] Add virt-what dependency on Debian-based systems
Issue #20017 has been updated by Franz Pletz. Assignee set to Franz Pletz Bug #20017: Add virt-what dependency on Debian-based systems https://projects.puppetlabs.com/issues/20017#change-87884 * Author: Franz Pletz * Status: Unreviewed * Priority: Normal * Assignee: Franz Pletz * Category: installation * Target version: 1.6.x * Keywords: * Branch: * Affected Facter version: 1.6.13 Issue #8210 introduced detecting the virtualization type with virt-what, which is much more reliable than facter's own techniques. Since virt-what is included in Debian at least since squeeze and in Ubuntu since lucid and has negligible overhead, I propose to add a dependency for it in the Debian packaging of facter. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Facter - Bug #20017] Add virt-what dependency on Debian-based systems
Issue #20017 has been updated by Franz Pletz. Assignee deleted (Franz Pletz) Pull request is at https://github.com/puppetlabs/facter/pull/418 Bug #20017: Add virt-what dependency on Debian-based systems https://projects.puppetlabs.com/issues/20017#change-87885 * Author: Franz Pletz * Status: Unreviewed * Priority: Normal * Assignee: * Category: installation * Target version: 1.6.x * Keywords: * Branch: * Affected Facter version: 1.6.13 Issue #8210 introduced detecting the virtualization type with virt-what, which is much more reliable than facter's own techniques. Since virt-what is included in Debian at least since squeeze and in Ubuntu since lucid and has negligible overhead, I propose to add a dependency for it in the Debian packaging of facter. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #15561] Fix for CVE-2012-3867 is too restrictive
Issue #15561 has been updated by Ben Jones. The patched version works for our use case (inhouse chained CA). Bug #15561: Fix for CVE-2012-3867 is too restrictive https://projects.puppetlabs.com/issues/15561#change-87894 * Author: Dustin Mitchell * Status: Merged - Pending Release * Priority: Urgent * Assignee: * Category: SSL * Target version: 3.2.0 * Affected Puppet version: 2.7.18 * Keywords: certificate * Branch: https://github.com/puppetlabs/puppet/pull/1556 The fix for CVE-2012-3867 involves checking certificate subjects for weird characters. From my read of the CVE entry, this is to filter out characters that would cause the name to display in a manner visually indistinguishable from a valid hostname. However, the check is too restrictive: Could not retrieve catalog from remote server: Certname puppetagain base ca/emailaddress=rele...@mozilla.com/ou=release engineering/o=mozilla, inc. must not contain unprintable or non-ASCII characters In particular, / is a very common character in subjects, and should be allowed. Puppet is seeing this subject on my base CA - I'm using certificate chaining. The fix is one character, so I haven't included a patch, but I'm happy to make a pull req if necessary. Another fix would be to only verify certificate subjects for the leaf certificate, and not any of the certs in its signing chain, but that seems less secure. It's also worth noting that the regex is overly broad, since it downcases the string, then accepts A-Z among other characters. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #7236] Nim Package Provider for AIX Fails to install Packages. Fix included!
Issue #7236 has been updated by Ben Hocker.
Is there any update to this issue? I'm having the same issue as Nick although
I don't see any issue with my puppet module. If I remove the single quotes
from nim.rb, it does seem to correct the issue when installing one package. But
if you need to install multiple in one command, then it won't work.
pre
elsif $::operatingsystem == 'AIX' {
package { $package_list:
ensure = 'latest',
provider = 'nim',
source = $lpp_source,
}
}
/pre
One package:
pre
if $::operatingsystem == 'AIX' {
$package_list = 'mqm.ft.agent'
$lpp = 'aix7101_lpp'
}
/pre
Result:
pre
err: /Stage[main]/Mqfte::Agent::Install/Package[mqm.ft.agent]/ensure: change
from absent to latest failed: Could not update: Execution of
'/usr/sbin/nimclient -o cust -a installp_flags=acgwXY -a lpp_source=aix7101_lpp
-a filesets='mqm.ft.agent'' returned 1:
Pre-installation Failure/Warning Summary
Name Level Pre-installation Failure/Warning
---
'mqm.ft.agent'Not found on the installation media
0042-001 nimclient: processing error encountered on n03audtst:
0042-175 c_script: An unexpected result was returned by the
nim.fpd.cat.com:/export/nim/scripts/n03audtst.script command:
See the log file:
/var/adm/ras/nim.installp
for details or use the showlog operation.
/pre
Long string of packages:
pre
if $::operatingsystem == 'AIX' {
$package_list = 'mqm.base.runtime mqm.jre.rte mqm.java.rte mqm.ft.base
mqm.man.en_US.data mqm.ft.agent'
$lpp = 'aix7101_lpp'
}
/pre
Result:
pre
err: /Stage[main]/Mqfte::Agent::Install/Package[mqm.base.runtime mqm.jre.rte
mqm.java.rte mqm.ft.base mqm.man.en_US.data mqm.ft.agent]/ensure: change from
absent to latest failed: Could not update: Execution of '/usr/sbin/nimclient -o
cust -a installp_flags=acgwXY -a lpp_source=aix7101_lpp -a
filesets='mqm.base.runtime mqm.jre.rte mqm.java.rte mqm.ft.base
mqm.man.en_US.data mqm.ft.agent'' returned 1:
Pre-installation Failure/Warning Summary
Name Level Pre-installation Failure/Warning
---
'mqm.base.runtime Not found on the installation media
mqm.ft.agent' Not found on the installation media
Installation Summary
NameLevel PartEvent Result
---
mqm.base.runtime7.5.0.0 USR APPLY SUCCESS
mqm.base.runtime7.5.0.0 ROOTAPPLY SUCCESS
mqm.man.en_US.data 7.5.0.0 SHARE APPLY SUCCESS
mqm.jre.rte 7.5.0.0 USR APPLY SUCCESS
mqm.java.rte7.5.0.0 USR APPLY SUCCESS
mqm.ft.base 7.5.0.0 USR APPLY SUCCESS
0042-001 nimclient: processing error encountered on n03audtst:
0042-175 c_script: An unexpected result was returned by the
nim.fpd.cat.com:/export/nim/scripts/n03audtst.script command:
See the log file:
/var/adm/ras/nim.installp
for details or use the showlog operation.
/pre
Array of packages:
pre
if $::operatingsystem == 'AIX' {
$package_list = [
'mqm.base.runtime',
'mqm.jre.rte',
'mqm.java.rte',
'mqm.ft.base',
'mqm.man.en_US.data',
'mqm.ft.agent'
]
$lpp = 'aix7101_lpp'
}
/pre
Result:
pre
err: /Stage[main]/Mqfte::Agent::Install/Package[mqm.ft.agent]/ensure: change
from absent to latest failed: Could not update: Execution of
'/usr/sbin/nimclient -o cust -a installp_flags=acgwXY -a lpp_source=aix7101_lpp
-a filesets='mqm.ft.agent'' returned 1:
Pre-installation Failure/Warning Summary
Name Level Pre-installation Failure/Warning
---
'mqm.ft.agent'Not found on the installation media
0042-001 nimclient: processing error encountered on n03audtst:
0042-175 c_script: An unexpected result was returned by the
nim.fpd.cat.com:/export/nim/scripts/n03audtst.script command:
See the log file:
/var/adm/ras/nim.installp
for details or use the showlog operation.
/pre
When I try to install an invalid package from the command line:
pre
root@server
[/opt/freeware/lib/ruby/gems/1.8/gems/puppet-2.6.7/lib/puppet/provider/package]
# /usr/sbin/nimclient -o cust -a installp_flags=acgwXY -a
lpp_source=aix7101_lpp -a filesets='mqm.ft.agent2'
Pre-installation Failure/Warning Summary
[Puppet - Bug #11383] cron type and provider only return resources for ENV[USER] or root, not all users
Issue #11383 has been updated by Charlie Sharpsteen.
This seems related to #3220 as it falls into the category of `resources{
'cron': purge = true}` doesn't clean everything up.
Bug #11383: cron type and provider only return resources for ENV[USER] or
root, not all users
https://projects.puppetlabs.com/issues/11383#change-87899
* Author: Nick Jenkin
* Status: Accepted
* Priority: Normal
* Assignee:
* Category: cron
* Target version:
* Affected Puppet version:
* Keywords:
* Branch:
When using resources { cron: purge = true }, only the root users crontab is
purged.
This works:
pre
cron {foo:
command = ls,
ensure = present,
user = root,
}
/pre
(and then proceed to comment the above out):
`notice: /Cron[foo]/ensure: removed`
This does not work:
pre
cron {bar:
command = ls,
ensure = present,
user = nick,
}
/pre
This crontab will still exist if commented out.
Broken in 2.6 and latest stable.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #3220] cron provider doesn't purge puppet-created cron resources correctly.
Issue #3220 has been updated by eric sorenson.
Felix I'm trying to understand the implications of your fix -- is it intended
to achieve Rob Terhaar's goals in #note-11 ?
More directly: Does it purge all cron jobs without a corresponding crontab
resource?
Bug #3220: cron provider doesn't purge puppet-created cron resources correctly.
https://projects.puppetlabs.com/issues/3220#change-87917
* Author: Rob Terhaar
* Status: Accepted
* Priority: Normal
* Assignee:
* Category: cron
* Target version:
* Affected Puppet version: 0.25.4
* Keywords:
* Branch:
Hello-
Bit of background first, we're using CentOS5 machines with puppet/puppetmaster
25.4 from EPEL packages.
For some reason that I cannot determine, the following code[1] (which works on
our development system) fails[2] on our staging system:
[1]
class crontab::cleaner {
resources { cron: purge = true }
}
Our intent is to remove all non-managed crontab entries.
However, when I run puppetd --test, I receive this error:
err: //crontab::cleaner/Resources[cron]: Failed to generate additional
resources using 'generate': You must specify a name or title for resources
--trace --debug --verbose on puppetmaster and on the puppetd client[3] do not
give any further information about the problem.
[3]
debug: Creating default schedules
debug: Finishing transaction -607717888 with 0 changes
debug: Loaded state in 0.01 seconds
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1054:in `hash2resource'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1888:in `initialize'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1016:in `new'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1016:in `instances'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1006:in `collect'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1006:in `instances'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1005:in `collect'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1005:in `instances'
/usr/lib/ruby/site_ruby/1.8/puppet/type/resources.rb:101:in `generate'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:349:in `send'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:349:in
`generate_additional_resources'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:378:in `generate'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:377:in `each'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:377:in `generate'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:493:in `prepare'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:284:in `evaluate'
/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:142:in `apply'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:169:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:178:in `benchmark'
/usr/lib/ruby/1.8/benchmark.rb:293:in `measure'
/usr/lib/ruby/1.8/benchmark.rb:307:in `realtime'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:177:in `benchmark'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:168:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:53:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:53:in `run'
/usr/lib/ruby/1.8/sync.rb:229:in `synchronize'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:53:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:134:in `with_client'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:51:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application/puppetd.rb:103:in `onetime'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:226:in `send'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:226:in `run_command'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:217:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:306:in `exit_on_fail'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:217:in `run'
/usr/sbin/puppetd:159
err: //crontab::cleaner/Resources[cron]: Failed to generate additional
resources using 'generate': You must specify a name or title for resources
debug: Prefetching parsed resources for sshkey
debug: Prefetching crontab resources for cron
debug: Prefetching yum resources for package
debug: Puppet::Type::Package::ProviderYum: Executing '/bin/rpm --version'
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #10063] cron resource violates resource ordering
Issue #10063 has been updated by Charlie Sharpsteen.
Also, implementing #3220 would provide a workaround to the specific use case
that gave rise to this problem---purging unnamed cron jobs to replace them with
Puppet-managed jobs.
Bug #10063: cron resource violates resource ordering
https://projects.puppetlabs.com/issues/10063#change-87918
* Author: Igor .
* Status: Accepted
* Priority: Normal
* Assignee:
* Category: cron
* Target version:
* Affected Puppet version: 2.7.3
* Keywords: cron ordering parsedfile
* Branch:
Consider the following class
pre
class broken_cron {
cron { 'myjob':
command = /usr/local/sbin/myjob,
user = root,
minute = 22
hour = 5
ensure = present
}
# Try and cleanup crontab -- this is broken in a rather surprising way!
exec { 'crontab -l|grep -v myjob|crontab -':
unless = crontab -l|grep '^# Puppet Name: myjob',
path = /bin:/usr/bin,
before = Cron['myjob']
}
}
/pre
if this applied when crontab already contains myjob but with different time
settings than specified in the cron resource, crontab will end up containing
the job twice. It seems cron type is prefetching the contents of crontab before
the exec runs despite the explicit ordering.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #3010] Crontab entries using special parameter can't be converted to non-special entries
Issue #3010 has been updated by Charlie Sharpsteen.
Felix Frank wrote:
Charlie Sharpsteen wrote:
Also, addressing this issue would tie into fixing #4820 which raises the
issue that it is somewhat silly to be able to specify both normal and
special schedules in a cron resource without Puppet raising a fuss.
I had looked into that one before touching on the whole special schedules
are broken thing. I believe that feature request can be implemented by now,
independently of this bug fix.
But it would surely make more sense to do all the fixing first.
Yep. Seems like all #4820 needs is some logic that throws a warning into the
log so users can see that the situation is occurring. We could think about
upgrading the warning to a fatal error in a future release.
That makes sense to me. However, there might be some discussion required to
determine if this would be a big enough break from current behavior to
warrant delaying it for a 4.x release.
Good point! I guess it would be best to first send a simple fix upstream and
allow special = absent. That could close that bug in a point release (or so
I believe).
The behavioral change can well be another branch altogether, which would not
need to be merged into 3.x?
Is versioning going the Mozilla route of increasing the major number with
every feature release? Or are there major reworkings that make the 3-to-4
jump necessary in the near future?
With the release of 3.0.0, we adopted the Semantic Versioning spec. See
[semver.org](http://semver.org/) for a description of guidelines.
Bug #3010: Crontab entries using special parameter can't be converted to
non-special entries
https://projects.puppetlabs.com/issues/3010#change-87919
* Author: Jesse Wolfe
* Status: Accepted
* Priority: Normal
* Assignee:
* Category: cron
* Target version: 3.x
* Affected Puppet version: 0.25.2
* Keywords:
* Branch:
A crontab entry created like so:
pre
cron{ test:
command = /bin/echo /tmp/puppet.txt,
special = reboot,
}
/pre
and then changed like so:
pre
cron{ test:
command = /bin/echo /tmp/puppet.txt,
minute = 50
}
/pre
will not change, and will show the notice:
notice: //Cron[test]/minute: defined 'minute' as '50'
on every run.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #20027] (Accepted) Puppet ssl_client_ca_auth setting does not behave as documented
Issue #20027 has been reported by Jeff McCune. Bug #20027: Puppet ssl_client_ca_auth setting does not behave as documented https://projects.puppetlabs.com/issues/20027 * Author: Jeff McCune * Status: Accepted * Priority: Normal * Assignee: * Category: SSL * Target version: 3.2.0 * Affected Puppet version: 3.0.0 * Keywords: chaining chain ssl external ca certificate authorization ssl_client_ca_auth * Branch: # Overview In Puppet 3.1.1, the `ssl_client_ca_auth` setting does not affect the behavior of Puppet in the manner described. Specifically, the intent of this setting is, SSL servers will not be considered authentic unless they posses a certificate issued by an authority listed in this file. # Expected behavior When the Puppet agent connects to a master using a SSL certificate that is issued by a CA not listed in this file but is chained to the CA root listed in `localcacert`, the agent refuses to connect with a clear reason why. # Actual behavior The agent happily connects to the master presenting a SSL cert not issued by a CA listed in the file. # Steps to reproduce There is (or will be) an automated acceptance test for this issue at https://github.com/puppetlabs/puppet/pull/1572/files. The manual process is as follows: 1: Create a self-signed Root CA. 2: Create an intermediate CA issued by the Root CA, named For the agents 3: Create a second intermediate CA issued by the Root CA, named For the masters 4: Issue an SSL certificate for master1.example.org from the CA for the agents. 5: Issue an SSL certificate for master1.example.org from the CA for the masters. 6: Configure an Apache virtual host on 8140 using the SSL certificates issued by For the masters This is the good one. 7: Configure another Apache virtual host on 8141 that is identical to 8140 with the only difference being the use of the cert issued by the For the agents CA. This is the rogue master that is using an agent certificate. 8: Place the For the masters CA certificate in a file that is different from the `localcacert` file and configure `ssl_client_ca_auth` to point at this file. When the agent connects to 8140, it should proceed since this master has a certificate issued by a CA listed in the `ssl_client_ca_auth` file. When the agent connects to 8141 it should refuse to continue since this master does not have a certificate issued by a CA listed in the `ssl_client_ca_auth` file. Observe that the agent happily connects to both without error because both servers provide a valid chain of certificates leading to the trusted Root CA. # Impact data This option was added to Puppet 3 in an effort to partially address #3120 and make it easier to fully address in later versions. Since the option has no effect the original problem of trusting all or nothing remains when using CA chaining. -Jeff -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #7236] (Needs More Information) Nim Package Provider for AIX Fails to install Packages. Fix included!
Issue #7236 has been updated by Chris Price.
Status changed from Requires CLA to be signed to Needs More Information
Assignee changed from Parker Johnson to eric sorenson
Eric, I'm not sure what our release plans are around AIX... can you comment?
Bug #7236: Nim Package Provider for AIX Fails to install Packages. Fix included!
https://projects.puppetlabs.com/issues/7236#change-87922
* Author: Parker Johnson
* Status: Needs More Information
* Priority: Normal
* Assignee: eric sorenson
* Category: provider
* Target version:
* Affected Puppet version: development
* Keywords: AIX nimclient nim.rb packages
* Branch:
Found a minor bug in puppet/provider/package/nim.rb. Filesets fail to install.
After removing the single quotes around the filesets argument to nimclient,
works fine. I have been talking with James Turnbull about this and he
suggested I file a bug. See the diff below.
pre
[root@autobuild-m /]# diff
/usr/local/lib/ruby/site_ruby/1.8/puppet/provider/package/nim.rb
/usr/local/lib/ruby/site_ruby/1.8/puppet/provider/package/nim.rb.orig
33c33
nimclient -o, cust, -a, installp_flags=acgwXY, -a,
lpp_source=#{source}, -a, filesets=#{pkg}
---
nimclient -o, cust, -a, installp_flags=acgwXY, -a,
lpp_source=#{source}, -a, filesets='#{pkg}'
[root@autobuild-m /]#
/pre
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #20027] Puppet ssl_client_ca_auth setting does not behave as documented
Issue #20027 has been updated by Jeff McCune. Description updated Bug #20027: Puppet ssl_client_ca_auth setting does not behave as documented https://projects.puppetlabs.com/issues/20027#change-87923 * Author: Jeff McCune * Status: Accepted * Priority: Normal * Assignee: * Category: SSL * Target version: 3.2.0 * Affected Puppet version: 3.0.0 * Keywords: chaining chain ssl external ca certificate authorization ssl_client_ca_auth * Branch: # Overview In Puppet 3.1.1, the `ssl_client_ca_auth` setting does not affect the behavior of Puppet in the manner described. Specifically, the intent of this setting is, SSL servers will not be considered authentic unless they posses a certificate issued by an authority listed in this file. # Expected behavior When the Puppet agent connects to a master using a SSL certificate that is issued by a CA not listed in this file but is chained to the CA root listed in `localcacert`, the agent refuses to connect with a clear reason why. # Actual behavior The agent happily connects to the master presenting a SSL cert not issued by a CA listed in the file. # Steps to reproduce There is (or will be) an automated acceptance test for this issue at https://github.com/puppetlabs/puppet/pull/1572/files. The manual process is as follows: 1. Create a self-signed Root CA. 2. Create an intermediate CA issued by the Root CA, named For the agents 3. Create a second intermediate CA issued by the Root CA, named For the masters 4. Issue an SSL certificate for master1.example.org from the CA for the agents. 5. Issue an SSL certificate for master1.example.org from the CA for the masters. 6. Configure an Apache virtual host on 8140 using the SSL certificates issued by For the masters This is the good one. 7. Configure another Apache virtual host on 8141 that is identical to 8140 with the only difference being the use of the cert issued by the For the agents CA. This is the rogue master that is using an agent certificate. 8. Place the For the masters CA certificate in a file that is different from the `localcacert` file and configure `ssl_client_ca_auth` to point at this file. When the agent connects to 8140, it should proceed since this master has a certificate issued by a CA listed in the `ssl_client_ca_auth` file. When the agent connects to 8141 it should refuse to continue since this master does not have a certificate issued by a CA listed in the `ssl_client_ca_auth` file. Observe that the agent happily connects to both without error because both servers provide a valid chain of certificates leading to the trusted Root CA. # Impact data This option was added to Puppet 3 in an effort to partially address #3120 and make it easier to fully address in later versions. Since the option has no effect the original problem of trusting all or nothing remains when using CA chaining. -Jeff -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #17871] Nagios types creating duplicate entries
Issue #17871 has been updated by eric sorenson.
Description updated
Bug #17871: Nagios types creating duplicate entries
https://projects.puppetlabs.com/issues/17871#change-87930
* Author: Chris Mague
* Status: Investigating
* Priority: Normal
* Assignee:
* Category: nagios
* Target version:
* Affected Puppet version: 3.0.1
* Keywords: nagios
* Branch:
Actual behavior:
When creating a group of nagios resources ( nagios_contactgroups and
nagios_commands were the two types I tested ) puppet writes duplicate entries
in the configuration file.
Expected behavior:
A single entry is created for each resource
Note: I reverted to 2.7.11 and the issue stopped
Repro steps:
1) crate the manifest below
2) run puppet apply contactgroups.pp more than once
example manifest
pre
nagios_contactgroup { 'admins':
ensure = present,
alias = 'Nagios_Admins',
members = 'root, mague',
target = '/tmp/a.cfg',
}
nagios_contactgroup { 'pd_oncall':
ensure = present,
alias = 'PagerDuty_Controlled_Oncall_Group',
members = 'mague',
target = '/tmp/a.cfg',
}
nagios_contactgroup { 'icingaadmin':
ensure = present,
alias = 'Contacts_for_when_Icinga_goes_bad',
members = 'mague, pagerduty',
target = '/tmp/a.cfg',
}
nagios_contactgroup { 'org-contact-oncall':
ensure = present,
alias = 'org_contact_oncall',
members = 'mague, pagerduty',
target = '/tmp/a.cfg',
}
nagios_contactgroup { 'pd_hbase':
ensure = present,
alias = 'Contactgroup_Pagerduty_HBase',
members = 'mague',
target = '/tmp/a.cfg',
}
/pre
example output
pre
[cmague@puppet01:/dev/pts/0 ] /tmp
$ puppet apply contactgroups.pp
/dev/mem: Permission denied
racc/parser.rb:27: warning: already initialized constant Racc_Runtime_Version
racc/parser.rb:28: warning: already initialized constant Racc_Runtime_Revision
racc/parser.rb:30: warning: already initialized constant
Racc_Runtime_Core_Version_R
racc/parser.rb:31: warning: already initialized constant
Racc_Runtime_Core_Revision_R
racc/parser.rb:35: warning: already initialized constant
Racc_Runtime_Core_Revision_C
racc/parser.rb:39: warning: already initialized constant
Racc_Main_Parsing_Routine
racc/parser.rb:40: warning: already initialized constant Racc_YY_Parse_Method
racc/parser.rb:41: warning: already initialized constant
Racc_Runtime_Core_Version
racc/parser.rb:42: warning: already initialized constant
Racc_Runtime_Core_Revision
racc/parser.rb:43: warning: already initialized constant Racc_Runtime_Type
/dev/mem: Permission denied
/Stage[main]//Nagios_contactgroup[org-contact-oncall]/ensure: created
/Stage[main]//Nagios_contactgroup[admins]/ensure: created
/Stage[main]//Nagios_contactgroup[icingaadmin]/ensure: created
/Stage[main]//Nagios_contactgroup[pd_oncall]/ensure: created
/Stage[main]//Nagios_contactgroup[pd_hbase]/ensure: created
Finished catalog run in 0.65 seconds
[cmague@puppet01:/dev/pts/0 ] /tmp
$ puppet apply contactgroups.pp
/dev/mem: Permission denied
racc/parser.rb:27: warning: already initialized constant Racc_Runtime_Version
racc/parser.rb:28: warning: already initialized constant Racc_Runtime_Revision
racc/parser.rb:30: warning: already initialized constant
Racc_Runtime_Core_Version_R
racc/parser.rb:31: warning: already initialized constant
Racc_Runtime_Core_Revision_R
racc/parser.rb:35: warning: already initialized constant
Racc_Runtime_Core_Revision_C
racc/parser.rb:39: warning: already initialized constant
Racc_Main_Parsing_Routine
racc/parser.rb:40: warning: already initialized constant Racc_YY_Parse_Method
racc/parser.rb:41: warning: already initialized constant
Racc_Runtime_Core_Version
racc/parser.rb:42: warning: already initialized constant
Racc_Runtime_Core_Revision
racc/parser.rb:43: warning: already initialized constant Racc_Runtime_Type
/dev/mem: Permission denied
/Stage[main]//Nagios_contactgroup[org-contact-oncall]/ensure: created
Finished catalog run in 0.68 seconds
/pre
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #17278] Double entry when using nagios_host
Issue #17278 has been updated by eric sorenson. Description updated Bug #17278: Double entry when using nagios_host https://projects.puppetlabs.com/issues/17278#change-87931 * Author: Alexandre Angel * Status: Investigating * Priority: Normal * Assignee: * Category: nagios * Target version: 3.x * Affected Puppet version: 3.0.1 * Keywords: nagios * Branch: Hello, Since upgrade to puppet 3, i have a problem with nagios_host used in local. I have a class creating nagios_host type. At first run, it works fine, nagios config file is ok. On the second run, one of them is added a second time to the nagios confif file like puppet failed to see it's already present in the file. If i try to not add that nagios_host, another one i add is added a second time. The bugging nagios_host is always the first in file generated. I guess it miss the first element when checking for existing host. Here is log from puppet agent --debug --verbose --no-daemonize concerning nagios_host : 1st run : pre Debug: /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]/notify: subscribes to Service[nagios3] /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]/ensure: created Info: /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]: Scheduling refresh of Service[nagios3] Debug: /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]: The container Nagios::Switch[sbx908.mydomain.com] will propagate my refresh event Debug: Nagios::Switch[sbx908.mydomain.com]: The container Node[webadmin.mydomain.com] will propagate my refresh event 2nd run : Debug: /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]/notify: subscribes to Service[nagios3] /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]/ensure: created Info: /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]: Scheduling refresh of Service[nagios3] Debug: /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]: The container Nagios::Switch[sbx908.mydomain.com] will propagate my refresh event /Stage[main]/Nagios::Target/Nagios_host[webadmin.mydomain.com]/parents: parents changed ['sbx908.mydomain.com'] to 'sbx908.mydomain.com' Debug: Nagios::Switch[sbx908.mydomain.com]: The container Node[webadmin.mydomain.com] will propagate my refresh event /pre -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Facter - Bug #20017] (Merged - Pending Release) Add virt-what dependency on Debian-based systems
Issue #20017 has been updated by Adrien Thebo. Status changed from Unreviewed to Merged - Pending Release Target version changed from 1.6.x to 1.7.0 Merged into 1.7.x in 6e086f8. Bug #20017: Add virt-what dependency on Debian-based systems https://projects.puppetlabs.com/issues/20017#change-87932 * Author: Franz Pletz * Status: Merged - Pending Release * Priority: Normal * Assignee: * Category: installation * Target version: 1.7.0 * Keywords: * Branch: * Affected Facter version: 1.6.13 Issue #8210 introduced detecting the virtualization type with virt-what, which is much more reliable than facter's own techniques. Since virt-what is included in Debian at least since squeeze and in Ubuntu since lucid and has negligible overhead, I propose to add a dependency for it in the Debian packaging of facter. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #3220] cron provider doesn't purge puppet-created cron resources correctly.
Issue #3220 has been updated by Felix Frank.
eric sorenson wrote:
Felix I'm trying to understand the implications of your fix -- is it intended
to achieve Rob Terhaar's goals in #note-11 ?
Absolutely.
The idea is this: The provider generates an implicit name for each previously
unmanaged cronjob. The name is based on the command.
To keep the provider from bloating crontabs with these pseudo-names, each
record carries an additional marker (:managed) to allow name removal before
flushing.
But it totally makes puppet drop them when purge = true is set ;-)
Note that this does not address the issue that cron will not prefetch (and
hence, purge) all crontabs on a system, unless at least one job is managed in
each of them.
Bug #3220: cron provider doesn't purge puppet-created cron resources correctly.
https://projects.puppetlabs.com/issues/3220#change-87935
* Author: Rob Terhaar
* Status: Accepted
* Priority: Normal
* Assignee:
* Category: cron
* Target version:
* Affected Puppet version: 0.25.4
* Keywords:
* Branch:
Hello-
Bit of background first, we're using CentOS5 machines with puppet/puppetmaster
25.4 from EPEL packages.
For some reason that I cannot determine, the following code[1] (which works on
our development system) fails[2] on our staging system:
[1]
class crontab::cleaner {
resources { cron: purge = true }
}
Our intent is to remove all non-managed crontab entries.
However, when I run puppetd --test, I receive this error:
err: //crontab::cleaner/Resources[cron]: Failed to generate additional
resources using 'generate': You must specify a name or title for resources
--trace --debug --verbose on puppetmaster and on the puppetd client[3] do not
give any further information about the problem.
[3]
debug: Creating default schedules
debug: Finishing transaction -607717888 with 0 changes
debug: Loaded state in 0.01 seconds
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1054:in `hash2resource'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1888:in `initialize'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1016:in `new'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1016:in `instances'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1006:in `collect'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1006:in `instances'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1005:in `collect'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1005:in `instances'
/usr/lib/ruby/site_ruby/1.8/puppet/type/resources.rb:101:in `generate'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:349:in `send'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:349:in
`generate_additional_resources'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:378:in `generate'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:377:in `each'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:377:in `generate'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:493:in `prepare'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:284:in `evaluate'
/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:142:in `apply'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:169:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:178:in `benchmark'
/usr/lib/ruby/1.8/benchmark.rb:293:in `measure'
/usr/lib/ruby/1.8/benchmark.rb:307:in `realtime'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:177:in `benchmark'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:168:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:53:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:53:in `run'
/usr/lib/ruby/1.8/sync.rb:229:in `synchronize'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:53:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:134:in `with_client'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:51:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application/puppetd.rb:103:in `onetime'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:226:in `send'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:226:in `run_command'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:217:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:306:in `exit_on_fail'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:217:in `run'
/usr/sbin/puppetd:159
err: //crontab::cleaner/Resources[cron]: Failed to generate additional
resources using 'generate': You must specify a name or title for resources
debug: Prefetching parsed resources for sshkey
debug: Prefetching crontab resources for cron
debug: Prefetching yum resources for package
debug: Puppet::Type::Package::ProviderYum: Executing '/bin/rpm --version'
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To unsubscribe from this group and stop receiving
[Puppet - Bug #3010] Crontab entries using special parameter can't be converted to non-special entries
Issue #3010 has been updated by Felix Frank.
Charlie Sharpsteen wrote:
With the release of 3.0.0, we adopted the Semantic Versioning spec. See
[semver.org](http://semver.org/) for a description of guidelines.
I see. That makes sense then.
I'll see about implementing the simple addition.
Bug #3010: Crontab entries using special parameter can't be converted to
non-special entries
https://projects.puppetlabs.com/issues/3010#change-87937
* Author: Jesse Wolfe
* Status: Accepted
* Priority: Normal
* Assignee:
* Category: cron
* Target version: 3.x
* Affected Puppet version: 0.25.2
* Keywords:
* Branch:
A crontab entry created like so:
pre
cron{ test:
command = /bin/echo /tmp/puppet.txt,
special = reboot,
}
/pre
and then changed like so:
pre
cron{ test:
command = /bin/echo /tmp/puppet.txt,
minute = 50
}
/pre
will not change, and will show the notice:
notice: //Cron[test]/minute: defined 'minute' as '50'
on every run.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Facter - Bug #14522] invalid byte sequence error for virtual fact on Solaris 10 x86_64
Issue #14522 has been updated by Matthaus Owens. Also seen on facter-1.6.17 and ruby 1.9.3-p392 Bug #14522: invalid byte sequence error for virtual fact on Solaris 10 x86_64 https://projects.puppetlabs.com/issues/14522#change-87949 * Author: Tim Mooney * Status: Accepted * Priority: Low * Assignee: * Category: * Target version: * Keywords: solaris * Branch: * Affected Facter version: This happens with both facter 1.6.6 and facter 2.0.0rc1 I'm using ruby 1.9.3p125 on x86_64-sun-solaris2.10 When I run either version of facter, I get three lines of stderr output: Could not retrieve virtual: invalid byte sequence in US-ASCII Could not retrieve virtual: invalid byte sequence in US-ASCII Could not retrieve virtual: invalid byte sequence in US-ASCII and the is_virtual fact is incorrectly set to true. If I just run facter is_virtual I get Could not retrieve virtual: invalid byte sequence in US-ASCII true -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Facter - Bug #14522] invalid byte sequence error for virtual fact on Solaris 10 x86_64
Issue #14522 has been updated by Matthaus Owens. Found some relevant reading: http://www.ruby-forum.com/topic/163804 Bug #14522: invalid byte sequence error for virtual fact on Solaris 10 x86_64 https://projects.puppetlabs.com/issues/14522#change-87953 * Author: Tim Mooney * Status: Accepted * Priority: Low * Assignee: * Category: * Target version: * Keywords: solaris * Branch: * Affected Facter version: This happens with both facter 1.6.6 and facter 2.0.0rc1 I'm using ruby 1.9.3p125 on x86_64-sun-solaris2.10 When I run either version of facter, I get three lines of stderr output: Could not retrieve virtual: invalid byte sequence in US-ASCII Could not retrieve virtual: invalid byte sequence in US-ASCII Could not retrieve virtual: invalid byte sequence in US-ASCII and the is_virtual fact is incorrectly set to true. If I just run facter is_virtual I get Could not retrieve virtual: invalid byte sequence in US-ASCII true -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Facter - Bug #20053] (Unreviewed) ipaddress6 fact does not work when run independently
Issue #20053 has been reported by Patrick Carlisle. Bug #20053: ipaddress6 fact does not work when run independently https://projects.puppetlabs.com/issues/20053 * Author: Patrick Carlisle * Status: Unreviewed * Priority: Normal * Assignee: * Category: * Target version: 1.7.0 * Keywords: * Branch: * Affected Facter version: 1.7.0-rc1 % facter ipaddress6 Could not retrieve ipaddress6: uninitialized constant Facter::Util::IP -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Facter - Bug #20054] (Unreviewed) virtual facts show error about gsub on nil
Issue #20054 has been reported by Patrick Carlisle. Bug #20054: virtual facts show error about gsub on nil https://projects.puppetlabs.com/issues/20054 * Author: Patrick Carlisle * Status: Unreviewed * Priority: Normal * Assignee: * Category: * Target version: 1.7.0 * Keywords: * Branch: * Affected Facter version: 1.7.0-rc1 On my system, Debian sid, `facter virtual` and `facter is_virtual` display an error % facter virtual Could not retrieve virtual: undefined method `gsub' for nil:NilClass vmware_workstation (I have vmware workstation installed but this system is not virtual so that return value seems wrong.) % facter is_virtual Could not retrieve virtual: undefined method `gsub' for nil:NilClass false -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #3010] Crontab entries using special parameter can't be converted to non-special entries
Issue #3010 has been updated by Felix Frank.
Have a pull :-)
https://github.com/puppetlabs/puppet/pull/1577
See a head-scratcher in the comments there, but either way, this should be fit
for merging.
Bug #3010: Crontab entries using special parameter can't be converted to
non-special entries
https://projects.puppetlabs.com/issues/3010#change-87962
* Author: Jesse Wolfe
* Status: Accepted
* Priority: Normal
* Assignee:
* Category: cron
* Target version: 3.x
* Affected Puppet version: 0.25.2
* Keywords:
* Branch:
A crontab entry created like so:
pre
cron{ test:
command = /bin/echo /tmp/puppet.txt,
special = reboot,
}
/pre
and then changed like so:
pre
cron{ test:
command = /bin/echo /tmp/puppet.txt,
minute = 50
}
/pre
will not change, and will show the notice:
notice: //Cron[test]/minute: defined 'minute' as '50'
on every run.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Feature #746] Create Cron provider for /etc/cron.d entries
Issue #746 has been updated by Felix Frank. Hacking away at a proof of concept, I find myself facing a choice. 1. Make a slick and clean file generator and parser. This would be nice because it can be implemented in a very straight-forward fashion, without all the wiggle room that allowed that ultimately led to the crontab provider being a bug-ridden beast. On the other hand, though, it will clobber existing cron.d files and not only rid them of comments and spacing, but also of additional cronjobs besides the one being declared in the named resource! It will also likely falsely identify environment lines of such victim jobs and merge them with the managed job's environment (except the environment itself is managed as well). 2. Be flexible. Manage environment, schedule and command of what we *assume* is the main cronjob in the cron.d file and try and leave anything else intact. If one would want to go that way, the best way to do it would be to base the cron.d provider on parsedfile, hands down. We could reuse the crontab provider implementation (perhaps inherit it, or create a common base class), which might save some implementation overhead. On the downside, we'd inherit the bugs and implementation complexity. After all, the crontab provider by now contains more code to workaround Parsedfile's limitations than for getting actual work done (or so it feels). I'd personally prefer number 1, if we can live with the radical implications. Feature #746: Create Cron provider for /etc/cron.d entries https://projects.puppetlabs.com/issues/746#change-87964 * Author: Udo Waechter * Status: Accepted * Priority: High * Assignee: * Category: cron * Target version: 3.x * Affected Puppet version: 0.22.1 * Keywords: * Branch: Provide support for managing cron job through /etc/crontab. *Former bug text: *Under darwin, the root user is usually disabled, thus it's crontab does not work. As a work around it is possible to create those jobs in /etc/crontab I did not look into the cron provider, but I guess the change to the code is minimal. thanks. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #3010] (In Topic Branch Pending Review) Crontab entries using special parameter can't be converted to non-special entries
Issue #3010 has been updated by Charlie Sharpsteen.
Status changed from Accepted to In Topic Branch Pending Review
Branch set to https://github.com/puppetlabs/puppet/pull/1577
Thanks a bunch Felix!
Bug #3010: Crontab entries using special parameter can't be converted to
non-special entries
https://projects.puppetlabs.com/issues/3010#change-87966
* Author: Jesse Wolfe
* Status: In Topic Branch Pending Review
* Priority: Normal
* Assignee:
* Category: cron
* Target version: 3.x
* Affected Puppet version: 0.25.2
* Keywords:
* Branch: https://github.com/puppetlabs/puppet/pull/1577
A crontab entry created like so:
pre
cron{ test:
command = /bin/echo /tmp/puppet.txt,
special = reboot,
}
/pre
and then changed like so:
pre
cron{ test:
command = /bin/echo /tmp/puppet.txt,
minute = 50
}
/pre
will not change, and will show the notice:
notice: //Cron[test]/minute: defined 'minute' as '50'
on every run.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #6810] File 'fail' became a lot more fatal in 2.6.0
Issue #6810 has been updated by Charlie Sharpsteen.
Could not reproduce using 3.1.1, 2.7.21 or, strangely enough, 2.6.6. The
following manifest always resulted in the creation of `/tmp/later`:
pre
file { /tmp/foobar:
ensure = directory,
source = puppet:///modules/foo/barba,
recurse = remote,
}
file { /tmp/later:
ensure = file,
content = laterfile,
}
/pre
Bug #6810: File 'fail' became a lot more fatal in 2.6.0
https://projects.puppetlabs.com/issues/6810#change-87967
* Author: eric sorenson
* Status: Accepted
* Priority: Normal
* Assignee: Charlie Sharpsteen
* Category: file
* Target version:
* Affected Puppet version: 2.6.0
* Keywords:
* Branch:
In testing 2.6.6, we found that missing source directories in a recurse=remote
file copy cause puppetd to exit immediately, whereas earlier versions just
cause that particular resource to fail but continue with the rest of the
catalog. Did failures become intentionally more fatal in 2.6.6? I can work
to bisect when this started happening but wondered if it was a known issue.
Stack trace/output:
pre
/usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:171:in
`fail'/usr/lib/ruby/site_ruby/1.8/puppet/type/file/source.rb:156:in
`init_metadata'/usr/lib/ruby/site_ruby/1.8/puppet/util/cacher.rb:106:in `send'
/usr/lib/ruby/site_ruby/1.8/puppet/util/cacher.rb:106:in
`cached_value'/usr/lib/ruby/1.8/monitor.rb:242:in
`synchronize'/usr/lib/ruby/site_ruby/1.8/puppet/util/cacher.rb:98:in
`cached_value'/usr/lib/ruby/site_ruby/1.8/puppet/util/cacher.rb:48:in
`metadata'/usr/lib/ruby/site_ruby/1.8/puppet/type/file/source.rb:109:in
`copy_source_values'
/usr/lib/ruby/site_ruby/1.8/puppet/type/file.rb:622:in
`retrieve'/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:703:in `retrieve_resource'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1874:in `to_trans'
/usr/lib/ruby/site_ruby/1.8/puppet/type/file.rb:691:in `to_trans'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1899:in `to_resource'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:203:in `uniqueness_key'
/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:83:in `add_resource'
/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:72:in `each'
/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:72:in
`add_resource'/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:561:in
`to_catalog'
/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:531:in `each'
/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:468:in `to_ral'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:113:in `convert_catalog'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:108:in `retrieve_catalog'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:139:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
/usr/lib/ruby/1.8/sync.rb:230:in `synchronize'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:103:in `with_client'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:37:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `call'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `controlled_run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:35:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:114:in `onetime'
/usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:88:in `run_command'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:410:in `exit_on_fail'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run'
/usr/sbin/puppetd:4
err: Could not run Puppet configuration client: Could not retrieve information
from source(s) puppet:///async/users/admins/vkoleti/ssh at
/etc/puppet/modules/homes/manifests/init.pp:28
/pre
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #17879] extract cert name properly from subject DN
Issue #17879 has been updated by Jeff McCune.
Just as an update on this bug, we think we've fixed this in #15561
The Puppet 3.2 release will have this fix included.
-Jeff
Bug #17879: extract cert name properly from subject DN
https://projects.puppetlabs.com/issues/17879#change-87970
* Author: Yuri Arabadji
* Status: Duplicate
* Priority: High
* Assignee:
* Category:
* Target version:
* Affected Puppet version:
* Keywords:
* Branch:
You owe me $200 for my time on debugging this. Hi.
---
/usr/local/rvm/gems/ruby-1.9.3-p286@puppet30/gems/puppet-3.0.1/lib/puppet/ssl/base.rb.orig
2012-11-30 10:23:24.531533928 -0500
+++
/usr/local/rvm/gems/ruby-1.9.3-p286@puppet30/gems/puppet-3.0.1/lib/puppet/ssl/base.rb
2012-11-30 10:35:25.653400099 -0500
@@ -49,7 +49,9 @@
# Method to extract a 'name' from the subject of a certificate
def self.name_from_subject(subject)
-subject.to_s.sub(/\/CN=/i, '')
+if triplet = subject.to_a.find {|name, data, type| name == 'CN' }
+ triplet[1]
+end
end
# Create an instance of our Puppet::SSL::* class using a given instance of
the wrapped class
Otherwise subject DN /O=Organization/OU=Something/CN=host.name.com will be
converted into some mess and fail validation with exception being thrown right
in the middle of the code that doesn't expect it.
So don't be shy, make connection.verify_callback block catch the exception and
actually raise SSLError or the like and actually fill in the error message
(class not found, name incorrect and such).
That's all for now, dears.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Facter - Bug #20054] (Accepted) virtual facts show error about gsub on nil
Issue #20054 has been updated by Josh Cooper. Status changed from Unreviewed to Accepted Same on mac osx 10.7. Also I can't get a backtrace using `--trace`: pre $ facter --trace --debug ... Could not retrieve virtual: undefined method `gsub' for nil:NilClass ... /pre Bug #20054: virtual facts show error about gsub on nil https://projects.puppetlabs.com/issues/20054#change-87972 * Author: Patrick Carlisle * Status: Accepted * Priority: Normal * Assignee: * Category: * Target version: 1.7.0 * Keywords: * Branch: * Affected Facter version: 1.7.0-rc1 On my system, Debian sid, `facter virtual` and `facter is_virtual` display an error % facter virtual Could not retrieve virtual: undefined method `gsub' for nil:NilClass vmware_workstation (I have vmware workstation installed but this system is not virtual so that return value seems wrong.) % facter is_virtual Could not retrieve virtual: undefined method `gsub' for nil:NilClass false -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Facter - Bug #20053] (Accepted) ipaddress6 fact does not work when run independently
Issue #20053 has been updated by Josh Cooper. Status changed from Unreviewed to Accepted Same here mac osx: pre $ facter ipaddress 192.168.1.149 $ facter ipaddress6 Could not retrieve ipaddress6: uninitialized constant Facter::Util::IP /pre Bug #20053: ipaddress6 fact does not work when run independently https://projects.puppetlabs.com/issues/20053#change-87973 * Author: Patrick Carlisle * Status: Accepted * Priority: Normal * Assignee: * Category: * Target version: 1.7.0 * Keywords: * Branch: * Affected Facter version: 1.7.0-rc1 % facter ipaddress6 Could not retrieve ipaddress6: uninitialized constant Facter::Util::IP -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Feature #20020] (Needs More Information) Puppet fail on error
Issue #20020 has been updated by Josh Cooper.
Status changed from Unreviewed to Needs More Information
Have you tried running puppet apply in noop mode?
pre
$ puppet help apply
...
* --noop:
Use 'noop' mode where Puppet runs in a no-op or dry-run mode. This
is useful for seeing what changes Puppet will make without actually
executing the changes.
/pre
Feature #20020: Puppet fail on error
https://projects.puppetlabs.com/issues/20020#change-87974
* Author: Geoff Meakin
* Status: Needs More Information
* Priority: Normal
* Assignee:
* Category:
* Target version:
* Affected Puppet version:
* Keywords:
* Branch:
When I'm developing puppet modules/manifests, there is a certain class of error
which is very tricky to debug - that is , some resource that doesn't work, and
then subsequently fixes the cause for the reason it didn't work - (meaning it
works next time round). In order to get a perfect-from-zero puppet run, I have
to spend lots of time checking dependencies and recreating scenarios in order
to get the system into the exact state to see why something didn't work before
fixing it.
It would be really helpful to me (reduce my development time immensely) if you
could do this on any resource
foo_resource { name:
exit_on_error = true
}
So the system would be left in the non-working state and I could see how I
needed to fix it.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
