[Puppet - Bug #17994] (Unreviewed) Symbolic file modes when creating directories: Wrong permissions
Issue #17994 has been reported by Daniel Grafe. Bug #17994: Symbolic file modes when creating directories: Wrong permissions https://projects.puppetlabs.com/issues/17994 Author: Daniel Grafe Status: Unreviewed Priority: Normal Assignee: Category: Target version: Affected Puppet version: 2.7.19 Keywords: Branch: Using symbolic modes when creating directories gives an additional sticky bit on the directory: testcase: pre file { /tmp/testdir: ensure = directory, mode = u=rwx,go=x } /pre Result: pre rm -rf /tmp/testdir/ puppet /tmp/symbolic_mode_test.pp warning: Implicit invocation of 'puppet apply' by passing files (or flags) directly to 'puppet' is deprecated, and will be removed in the 2.8 series. Please invoke 'puppet apply' directly in the future. notice: /Stage[main]//File[/tmp/testdir]/ensure: created notice: Finished catalog run in 0.50 seconds ls -la /tmp/ | grep testdir drwx-T 2 root root 4096 6. Dez 09:36 testdir /pre The method for converting symbolic file modes to octals is expecting an octal as second parameter. But when creating directories a numeric with base 10 is passed. Prefixing this value with a '0' specifying an octal would fix the bug. In lib/puppet/type/file/ensure.pp: pre Dir.mkdir(@resource[:path], symbolic_mode_to_int(mode, 755, true)) ^ |- changing to 0755 will fix the problem /pre I'm filing this against 2.7.19. But since the relevant code has not been changed the reported bug should also be reproducable on 3.x -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #17371] Setting owner, group, mode for files specified in puppet.conf no longer seems to work
Issue #17371 has been updated by Dominic Cleal. Branch changed from https://github.com/puppetlabs/puppet/pull/1278 to https://github.com/puppetlabs/puppet/pull/1316 I've rebased it onto master and submitted a new PR. Bug #17371: Setting owner, group, mode for files specified in puppet.conf no longer seems to work https://projects.puppetlabs.com/issues/17371#change-78293 Author: Andreas Ntaflos Status: In Topic Branch Pending Review Priority: Normal Assignee: Dominic Cleal Category: settings Target version: 3.1.0 Affected Puppet version: 3.0.0 Keywords: settings mode permissions run_mode Branch: https://github.com/puppetlabs/puppet/pull/1316 It seems that setting owner, group and mode for files in puppet.conf by using the following method, as explained in the configuration guide, no longer works in Puppet 3.0 (using Puppet 3.0.1 here on Ubuntu 12.04): /etc/puppet/puppet.conf: [master] ... autosign = /etc/puppet/autosign.conf { owner = puppet, group = puppet, mode = 0664 } The settings specified in the curly braces do not get applied to the file. Instead, after changing the mode manually (`chmod 0664 /etc/puppet/autosign.conf`) it is reset to 0644 after a request to the puppetmaster comes in. Interestingly it seems that when manually changing the owner of the file it stays changed, even after a request comes in that triggers the manually changed mode to be reset. And as nfagerlund observed on IRC it seems that specifying an owner keeps the mode setting from working. Setting a mode alone, i.e. `autosign = /etc/puppet/autosign.conf { mode = 0664 }` works. -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #17995] Package is being reinstalled every time when using debian backports
Issue #17995 has been updated by Matthaus Owens. Project changed from Puppet Community Package Repository to Puppet Moving to the main Puppet project as this isn't a packaging issue. Bug #17995: Package is being reinstalled every time when using debian backports https://projects.puppetlabs.com/issues/17995#change-78297 Author: Danny Van der Meulen Status: Unreviewed Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: Branch: I'm using the squeeze-backports repository on our machines in puppet : package { 'rsyslog': ensure = 'present', name= 'rsyslog/squeeze-backports'; } IMHO this is the cleanest way to select targets in debian/puppet. This works okay, but every time when a puppet run runs it want to reinstall the package. Quite logical because the dpkg.rb provider uses : dpkg-query -W --showformat '${Status} ${Package} ${Version}\\n', @resource[:name] @resource[:name] evaluates to 'rsyslog/squeeze-backports' and dpkg-query will return with exit code 1 ( package not found ). Why not change the query into : dpkg-query -W --showformat '${Status} ${Package} ${Version}\\n', @resource[:name].split('/')[0] Which will select the correct package name and solves my problem. -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #16651] Installing the cloud provisioner module breaks the node subcommand
Issue #16651 has been updated by Josh Cooper. The fix in progress for #7136 adds the current environment's modulepath to the $LOAD_PATH prior to requiring the face. This enables the face application to require utility code (require 'puppet/cloudpack'). However, we are now running into #13898, which prevents a face from defining options that conflict with global puppet options, in this case `--tags`. So to resolve this particular issue, we either need to revert #13898 (and address whatever issue it was trying to fix, perhaps just warn?), or fix cloud pack to use different options. Bug #16651: Installing the cloud provisioner module breaks the node subcommand https://projects.puppetlabs.com/issues/16651#change-78314 Author: Jeff McCune Status: Accepted Priority: Normal Assignee: Category: Faces Target version: 3.0.x Affected Puppet version: 3.0.0 Keywords: faces node face subcommand cloud_provisioner Branch: # Overview In Puppet 3.0.0, installing the official `puppetlabs-cloud_provisioner` module from the forge breaks the `puppet node` subcommand. # Expected behavior Installing the cloud_provisioner module should not breaking any existing functionality of Puppet core. # Actual Behavior pre root@pe-centos6:~# puppet help node Error: Could not autoload puppet/face/node/classify: no such file to load -- puppet/cloudpack Error: Could not load help for the face node. Please check the error logs for more information. Detail: Could not autoload puppet/face/node/classify: no such file to load -- puppet/cloudpack Error: Try 'puppet help help help' for usage /pre # Steps to reproduce 1. Install Puppet 3.0.0 from official release RPM's on CentOS 6.3: `yum install --enablerepo=puppetlabs-devel puppet puppet-server` 1. Install the cloud provisoner module: `puppet module install puppetlabs-cloud_provisioner` At this point, the node subcommand shows up as having errors in `puppet help`. `puppet help node` is totally broken as well. -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #18013] (Unreviewed) Support for Microsoft .msu packages
Issue #18013 has been reported by Luis Mayorga. Feature #18013: Support for Microsoft .msu packages https://projects.puppetlabs.com/issues/18013 Author: Luis Mayorga Status: Unreviewed Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: Branch: Hi, I had to download a .msu package to include Powershell 3.0 on my Windows 7 Machine. Is there any support with Puppet using the Package Resource Type? -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #16804] scheduled_task : add support for every X minutes or hours mode
Issue #16804 has been updated by Matthaus Owens. Project changed from Puppet Enterprise (Public) to Puppet Moving to the Puppet project, as this is not a PE feature, but rather a Puppet feature. Feature #16804: scheduled_task : add support for every X minutes or hours mode https://projects.puppetlabs.com/issues/16804#change-78318 Author: Pascal Sartoretti Status: Unreviewed Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: Branch: As stated in the Puppet documentation (http://docs.puppetlabs.com/windows/writing.html#scheduledtaskscheduledtask), the scheduled_task resource type does not support repetition modes such as every X minutes. It is a pity, because such tasks are very commonly used in Windows servers (and maybe less on Windows clients), making scheduled_task not so useful. It is true that the configuration of Windows scheduled task is complicated (as opposed to crontab...); we may not need all the features available in the Windows GUI (like Until, Duration or If the task is still running, stop it at this time), I guess it would be enough to support every X minutes and every Y hours. -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Facter - Bug #17925] Could not retrieve ec2_userdata: 404 Not Found
Issue #17925 has been updated by Jeff McCune. Project changed from Puppet to Facter Bug #17925: Could not retrieve ec2_userdata: 404 Not Found https://projects.puppetlabs.com/issues/17925#change-78320 Author: Banio Carpenter Status: Accepted Priority: Normal Assignee: Category: Target version: Keywords: ec2 Branch: Affected Facter version: # puppet agent --version 3.0.1 # facter --version 1.6.16 # ruby --version ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux] When puppet agent -t is run on my ec2 instances, it outputs on stderr: Could not retrieve ec2_userdata: 404 Not Found This appears to be due to the ec2_userdata function in: /usr/lib/ruby/site_ruby/1.8/facter/ec2.rb When I comment the function I no longer get the error. -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #17879] extract cert name properly from subject DN
Issue #17879 has been updated by Yuri Arabadji. Related. pre Ignoring --listen on onetime run /usr/local/rvm/rubies/ruby-1.9.3-p327/lib/ruby/1.9.1/net/http.rb:799: warning: exception in verify_callback is ignored Warning: Unable to fetch my node definition, but the agent run will continue: Warning: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [] Info: Retrieving plugin /usr/local/rvm/rubies/ruby-1.9.3-p327/lib/ruby/1.9.1/net/http.rb:799: warning: exception in verify_callback is ignored Error: /File[/var/lib/puppet/lib]: Failed to generate additional resources using 'eval_generate: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [] /usr/local/rvm/rubies/ruby-1.9.3-p327/lib/ruby/1.9.1/net/http.rb:799: warning: exception in verify_callback is ignored Error: /File[/var/lib/puppet/lib]: Could not evaluate: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [] Could not retrieve file metadata for puppet://dev2.xxx/plugins: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [] Info: Loading facts in /var/lib/puppet/lib/facter/stage_level.rb Info: Loading facts in /var/lib/puppet/lib/facter/mc_server.rb Info: Loading facts in /var/lib/puppet/lib/facter/snmpd.rb Info: Loading facts in /var/lib/puppet/lib/facter/php_settings.rb Info: Loading facts in /var/lib/puppet/lib/facter/mc_client.rb /usr/local/rvm/rubies/ruby-1.9.3-p327/lib/ruby/1.9.1/net/http.rb:799: warning: exception in verify_callback is ignored Error: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [] Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run /usr/local/rvm/rubies/ruby-1.9.3-p327/lib/ruby/1.9.1/net/http.rb:799: warning: exception in verify_callback is ignored Error: Could not send report: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [] /pre Bug #17879: extract cert name properly from subject DN https://projects.puppetlabs.com/issues/17879#change-78322 Author: Yuri Arabadji Status: Unreviewed 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #15496] Puppet incorrectly determining offset for certain timezones
Issue #15496 has been updated by Sean Millichamp. The timezone we are using is America/Caracas: http://www.timeanddate.com/worldclock/city.html?n=58 As you can see from that link, the current UTC offset is -04:30 but the timestamps in the Puppet report, generated during a /opt/puppet/bin/puppet agent --test --debug run are being sent back with -05:30 still: - !ruby/object:Puppet::Util::Log level: !ruby/sym info message: Retrieving plugin source: Puppet tags: - info time: 2012-12-06 14:42:40.583399 -05:30 However, if, on the same client system, I run irb: # /opt/puppet/bin/irb irb(main):001:0 a = Time.now() = Thu Dec 06 14:58:43 -0430 2012 irb(main):002:0 require 'yaml' = true irb(main):003:0 a.to_yaml = --- 2012-12-06 14:58:43.140804 -04:30\n BUT, if I do this, in the same session: irb(main):004:0 require 'puppet' = true irb(main):005:0 a.to_yaml = --- 2012-12-06 14:58:43.140804 -05:30 irb(main):006:0 Now we are seeing -05:30. Something about loading 'puppet', and all the modules it loads, is causing the timezone offset to be changed. I originally saw this on PE 2.5.1, but this is PE 2.7.0: # rpm -qa 'pe-*' pe-augeas-libs-0.10.0-3.pe.el6.x86_64 pe-ruby-libs-1.8.7.370-1.pe.el6.x86_64 pe-facter-1.6.10-1.pe.el6.noarch pe-augeas-0.10.0-3.pe.el6.x86_64 pe-ruby-shadow-1.4.1-8.pe.el6.x86_64 pe-puppet-enterprise-release-2.7.0-1.pe.el6.noarch pe-ruby-1.8.7.370-1.pe.el6.x86_64 pe-ruby-rdoc-1.8.7.370-1.pe.el6.x86_64 pe-puppet-2.7.19-6.pe.el6.noarch pe-ruby-augeas-0.4.1-1.pe.el6.x86_64 pe-ruby-irb-1.8.7.370-1.pe.el6.x86_64 pe-rubygems-1.5.3-1.pe.el6.noarch Hope that helps... Bug #15496: Puppet incorrectly determining offset for certain timezones https://projects.puppetlabs.com/issues/15496#change-78327 Author: Ken Johnson Status: Needs More Information Priority: Normal Assignee: Sean Millichamp Category: Target version: Affected Puppet version: Keywords: Branch: One of our customers reports this: I believe I have just discovered a bug in PE's timezone handling that seems to impact at least reporting, but may be more widespread. We have a few systems in our environment that have their timezone set to VET - Venezuela Standard Time. The offset for VET is -04:30 all year round (no DST observance). If you run date -R and date -Ru on the systems it shows the correct time offset: # date -R ; date -uR Thu, 12 Jul 2012 11:45:30 -0430 Thu, 12 Jul 2012 16:15:30 + However, I noticed that this group of systems was always listed first on the PE console and, more than that, their report time is always in the future. I have tried the PE console at both UTC and adjusted to display in US/Eastern. Doing some more digging, it appears that the problem is client-side during the Puppet report generation. If you look at the /var/opt/lib/pe-puppet/state/last_run_report.yaml file the offset reported is wrong: logs: - !ruby/object:Puppet::Util::Log level: !ruby/sym notice message: Finished catalog run in 0.07 seconds source: Puppet tags: - notice time: 2012-07-12 11:29:43.143028 -05:30 If Puppet (or Ruby) is determining the offset is incorrectly -05:30 instead of -04:30 I believe that this would account for the difference. The PE Console shows the run occuring at 16:59 UTC. However, /var/log/messages on the client concurs that the Puppet agent run ran at 11:29 local time (VET), which is the reported -5:30 offset, not the expected -4:30 offset. I am seeing the correct behavior for more common timezones such as US/Eastern, US/Pacific, etc. At the moment this appears limited only to systems in VET. The client systems in question are running PE 2.5.1 on RHEL 5.7, 64-bit. 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #15496] Puppet incorrectly determining offset for certain timezones
Issue #15496 has been updated by Sean Millichamp. Assignee changed from Sean Millichamp to eric sorenson Bug #15496: Puppet incorrectly determining offset for certain timezones https://projects.puppetlabs.com/issues/15496#change-78329 Author: Ken Johnson Status: Needs More Information Priority: Normal Assignee: eric sorenson Category: Target version: Affected Puppet version: Keywords: Branch: One of our customers reports this: I believe I have just discovered a bug in PE's timezone handling that seems to impact at least reporting, but may be more widespread. We have a few systems in our environment that have their timezone set to VET - Venezuela Standard Time. The offset for VET is -04:30 all year round (no DST observance). If you run date -R and date -Ru on the systems it shows the correct time offset: # date -R ; date -uR Thu, 12 Jul 2012 11:45:30 -0430 Thu, 12 Jul 2012 16:15:30 + However, I noticed that this group of systems was always listed first on the PE console and, more than that, their report time is always in the future. I have tried the PE console at both UTC and adjusted to display in US/Eastern. Doing some more digging, it appears that the problem is client-side during the Puppet report generation. If you look at the /var/opt/lib/pe-puppet/state/last_run_report.yaml file the offset reported is wrong: logs: - !ruby/object:Puppet::Util::Log level: !ruby/sym notice message: Finished catalog run in 0.07 seconds source: Puppet tags: - notice time: 2012-07-12 11:29:43.143028 -05:30 If Puppet (or Ruby) is determining the offset is incorrectly -05:30 instead of -04:30 I believe that this would account for the difference. The PE Console shows the run occuring at 16:59 UTC. However, /var/log/messages on the client concurs that the Puppet agent run ran at 11:29 local time (VET), which is the reported -5:30 offset, not the expected -4:30 offset. I am seeing the correct behavior for more common timezones such as US/Eastern, US/Pacific, etc. At the moment this appears limited only to systems in VET. The client systems in question are running PE 2.5.1 on RHEL 5.7, 64-bit. 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Facter - Feature #7559] Fact for identifying Amazon VPC instances.
Issue #7559 has been updated by Josh Cooper. Ryan Coleman wrote: Would it help to make this fact a module that is distributed through the Puppet Forge instead of making a part of core Facter? Those running in EC2 can install the module and pluginsync the fact to their agents. It would for puppet, but facter runs in environments without puppet... Feature #7559: Fact for identifying Amazon VPC instances. https://projects.puppetlabs.com/issues/7559#change-78330 Author: Nigel Kersten Status: Accepted Priority: Normal Assignee: Category: library Target version: Keywords: vpc ec2 arp Branch: Affected Facter version: 1.6.10 (From the list) I ran into a buglet in facter 1.5.9rc6 (from tmz repo). In normal AWS instances it works great. In VPC instances if doesn't work. This seems to be because VPC instances don't use the fe:ff:ff:... MAC addresses. pre /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 02:67:4E:E1:26:30 inet addr:172.17.129.24 ... /sbin/arp Address HWtype HWaddress Flags Mask Iface 169.254.169.253 ether 02:67:4E:C0:00:01 C eth0 172.17.128.1 ether 02:67:4E:C0:00:01 C eth0 /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 02:67:4E:DA:58:16 inet addr:172.17.128.126 /sbin/arp Address HWtype HWaddress Flags Mask Iface 169.254.169.253 ether 02:67:4E:C0:00:01 C eth0 172.17.128.1 ether 02:67:4E:C0:00:01 C eth0 /pre Of the two VPC EC2 instances I've seen, the MAC address always start with 02:67:4E. I have only seen two instances, both in the same VPC, so I don't know if this holds for every VPC instance, YMMV. in ec2.rb , the following seemed to work: pre def has_euca_mac? !!(Facter.value(:macaddress) =~ %r{^02:67:4[eE]:}) end /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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Facter - Feature #7559] Fact for identifying Amazon VPC instances.
Issue #7559 has been updated by Justin Lambert. Ryan Coleman wrote: Would it help to make this fact a module that is distributed through the Puppet Forge instead of making a part of core Facter? Those running in EC2 can install the module and pluginsync the fact to their agents. It would also mean puppet first runs would not have the correct ec2 information. Feature #7559: Fact for identifying Amazon VPC instances. https://projects.puppetlabs.com/issues/7559#change-78332 Author: Nigel Kersten Status: Accepted Priority: Normal Assignee: Category: library Target version: Keywords: vpc ec2 arp Branch: Affected Facter version: 1.6.10 (From the list) I ran into a buglet in facter 1.5.9rc6 (from tmz repo). In normal AWS instances it works great. In VPC instances if doesn't work. This seems to be because VPC instances don't use the fe:ff:ff:... MAC addresses. pre /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 02:67:4E:E1:26:30 inet addr:172.17.129.24 ... /sbin/arp Address HWtype HWaddress Flags Mask Iface 169.254.169.253 ether 02:67:4E:C0:00:01 C eth0 172.17.128.1 ether 02:67:4E:C0:00:01 C eth0 /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 02:67:4E:DA:58:16 inet addr:172.17.128.126 /sbin/arp Address HWtype HWaddress Flags Mask Iface 169.254.169.253 ether 02:67:4E:C0:00:01 C eth0 172.17.128.1 ether 02:67:4E:C0:00:01 C eth0 /pre Of the two VPC EC2 instances I've seen, the MAC address always start with 02:67:4E. I have only seen two instances, both in the same VPC, so I don't know if this holds for every VPC instance, YMMV. in ec2.rb , the following seemed to work: pre def has_euca_mac? !!(Facter.value(:macaddress) =~ %r{^02:67:4[eE]:}) end /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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #16804] (Accepted) scheduled_task : add support for every X minutes or hours mode
Issue #16804 has been updated by Josh Cooper. Status changed from Unreviewed to Accepted Keywords set to windows Unfortunately, we can't support every X minutes because Windows scheduled tasks (version 1) don't support it. The newer v2 APIs for creating scheduled tasks do support it, but aren't supported on 2003. Feature #16804: scheduled_task : add support for every X minutes or hours mode https://projects.puppetlabs.com/issues/16804#change-78335 Author: Pascal Sartoretti Status: Accepted Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: windows Branch: As stated in the Puppet documentation (http://docs.puppetlabs.com/windows/writing.html#scheduledtaskscheduledtask), the scheduled_task resource type does not support repetition modes such as every X minutes. It is a pity, because such tasks are very commonly used in Windows servers (and maybe less on Windows clients), making scheduled_task not so useful. It is true that the configuration of Windows scheduled task is complicated (as opposed to crontab...); we may not need all the features available in the Windows GUI (like Until, Duration or If the task is still running, stop it at this time), I guess it would be enough to support every X minutes and every Y hours. -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #18013] (Accepted) Support for Microsoft .msu packages
Issue #18013 has been updated by Josh Cooper. Status changed from Unreviewed to Accepted Keywords set to windows Hi Luis, can you update the ticket with the commands you use to install and uninstall an msu package? Feature #18013: Support for Microsoft .msu packages https://projects.puppetlabs.com/issues/18013#change-78336 Author: Luis Mayorga Status: Accepted Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: windows Branch: Hi, I had to download a .msu package to include Powershell 3.0 on my Windows 7 Machine. Is there any support with Puppet using the Package Resource Type? -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Facter - Bug #17925] Could not retrieve ec2_userdata: 404 Not Found
Issue #17925 has been updated by Jeff McCune. I believe this problem is caused by Facter not accounting for the situation where the EC2 metadata server returns a 404 if there is no user-data set for the instance. I'm going to write a small patch to take this scenario into account which should fix the problem. pre $ ruby -r 'open-uri' -e 'open http://169.254.169.254/latest/user-data;' /usr/lib/ruby/1.8/open-uri.rb:277:in `open_http': 404 Not Found (OpenURI::HTTPError) from /usr/lib/ruby/1.8/open-uri.rb:616:in `buffer_open' from /usr/lib/ruby/1.8/open-uri.rb:164:in `open_loop' from /usr/lib/ruby/1.8/open-uri.rb:162:in `catch' from /usr/lib/ruby/1.8/open-uri.rb:162:in `open_loop' from /usr/lib/ruby/1.8/open-uri.rb:132:in `open_uri' from /usr/lib/ruby/1.8/open-uri.rb:518:in `open' from /usr/lib/ruby/1.8/open-uri.rb:30:in `open' from -e:1 /pre Bug #17925: Could not retrieve ec2_userdata: 404 Not Found https://projects.puppetlabs.com/issues/17925#change-78338 Author: Banio Carpenter Status: Accepted Priority: Normal Assignee: Category: cloud - ec2 Target version: 1.6.x Keywords: ec2 Branch: Affected Facter version: 1.6.16 # puppet agent --version 3.0.1 # facter --version 1.6.16 # ruby --version ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux] When puppet agent -t is run on my ec2 instances, it outputs on stderr: Could not retrieve ec2_userdata: 404 Not Found This appears to be due to the ec2_userdata function in: /usr/lib/ruby/site_ruby/1.8/facter/ec2.rb When I comment the function I no longer get the error. -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #17880] When master is not a CA
Issue #17880 has been updated by Yuri Arabadji. disregard err: Could not retrieve catalog; skipping run error, that was from old puppet 2.6.x. Now, with puppet 3.0.1, with `hostcrl` setting pointing to non-existent file, it spits out pre Warning: Unable to fetch my node definition, but the agent run will continue: Warning: Error 400 on SERVER: this master is not a CA /pre When hostcrl is pointing to correct CRL (non-empty, openssl crl parsable), no such message is shown. I propose either notifying about incorrect host crl or disabling crl validation altogether. Please note, that all this time `certificate_revocation` was `false`. Bug #17880: When master is not a CA https://projects.puppetlabs.com/issues/17880#change-78341 Author: Yuri Arabadji Status: Unreviewed Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: Branch: When master is not a CA, but actually has all certificates in place (because they were issued by external corporate CA), some strange things happen: * When agent has `pluginsync = false`: pre # puppet agent --server dev2.xx --test --noop notice: Ignoring --listen on onetime run err: Could not retrieve catalog from remote server: Error 400 on SERVER: this master is not a CA warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run # on master: Nov 30 11:11:31 dev2 puppet-master[25944]: Handling request: GET /development/certificate_revocation_list/ca Nov 30 11:11:31 dev2 puppet-master[25944]: this master is not a CA /pre * When agent has `pluginsync = true`: pre # puppet agent --server dev2.xxx --test --noop notice: Ignoring --listen on onetime run info: Retrieving plugin err: /File[/var/lib/puppet/lib]: Failed to generate additional resources using 'eval_generate': Error 400 on SERVER: this master is not a CA err: /File[/var/lib/puppet/lib]: Could not evaluate: Could not retrieve information from source(s) puppet://dev2.xx/plugins info: Caching catalog for xx info: Applying configuration version '1354291767' notice: /Stage[main]//Node[default]/Notify[I'm the DEFAULT!]/message: current_value absent, should be I'm the DEFAULT! (noop) notice: Finished catalog run in 0.09 seconds # on master: Nov 30 11:33:43 dev2 puppet-master[25944]: Handling request: GET /development/certificate_revocation_list/ca Nov 30 11:33:43 dev2 puppet-master[25944]: this master is not a CA Nov 30 11:33:43 dev2 puppet-master[25944]: Handling request: GET /development/file_metadata/plugins Nov 30 11:33:43 dev2 puppet-master[25944]: Could not find file_metadata for 'plugins' /pre Why is this happening and can we remove/fix those warnings, please? 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #15496] Puppet incorrectly determining offset for certain timezones
Issue #15496 has been updated by eric sorenson. We implement yaml with zaml, and which incorrectly handles fractional negative tz offsets: pre lib/puppet/util/zaml.rb 375 class Time 376 def to_zaml(z) 377 # 2008-12-06 10:06:51.373758 -07:00 378 ms = (%0.6f % (usec * 1e-6))[2..-1] 379 offset = %+0.2i:%0.2i % [utc_offset / 3600, (utc_offset / 60) % 60] 380 z.emit(self.strftime(%Y-%m-%d %H:%M:%S.#{ms} #{offset})) 381 end 382 end eric@glitch.local .../puppet/spec/unit/provider/package]% export TZ=America/Caracas [eric@glitch.local .../puppet/spec/unit/provider/package]% irb irb(main):001:0 a = Time.now.utc_offset = -16200 irb(main):003:0 (a / 3600) = -5 /pre Ruby is helpfully rounding down since the hours offset ends up with a remainder. If we coerce that result to a float it shows the actual result: pre irb(main):004:0 (a / 3600.0) = -4.5 /pre And then the printf formatting works properly: pre irb(main):005:0 %+0.2i % (a / 3600.0) = -04 /pre So this diff fixes the problem: pre -offset = %+0.2i:%0.2i % [utc_offset / 3600, (utc_offset / 60) % 60] +offset = %+0.2i:%0.2i % [utc_offset / 3600.0, (utc_offset / 60) % 60] /pre I have a branch up here if you want to try it out: https://github.com/ahpook/puppet/tree/15496-incorrect-zaml-utc-offset Andy asked for tests so I'll write some and turn it into a pull request after lunch. Bug #15496: Puppet incorrectly determining offset for certain timezones https://projects.puppetlabs.com/issues/15496#change-78342 Author: Ken Johnson Status: Needs More Information Priority: Normal Assignee: eric sorenson Category: Target version: Affected Puppet version: Keywords: Branch: One of our customers reports this: I believe I have just discovered a bug in PE's timezone handling that seems to impact at least reporting, but may be more widespread. We have a few systems in our environment that have their timezone set to VET - Venezuela Standard Time. The offset for VET is -04:30 all year round (no DST observance). If you run date -R and date -Ru on the systems it shows the correct time offset: # date -R ; date -uR Thu, 12 Jul 2012 11:45:30 -0430 Thu, 12 Jul 2012 16:15:30 + However, I noticed that this group of systems was always listed first on the PE console and, more than that, their report time is always in the future. I have tried the PE console at both UTC and adjusted to display in US/Eastern. Doing some more digging, it appears that the problem is client-side during the Puppet report generation. If you look at the /var/opt/lib/pe-puppet/state/last_run_report.yaml file the offset reported is wrong: logs: - !ruby/object:Puppet::Util::Log level: !ruby/sym notice message: Finished catalog run in 0.07 seconds source: Puppet tags: - notice time: 2012-07-12 11:29:43.143028 -05:30 If Puppet (or Ruby) is determining the offset is incorrectly -05:30 instead of -04:30 I believe that this would account for the difference. The PE Console shows the run occuring at 16:59 UTC. However, /var/log/messages on the client concurs that the Puppet agent run ran at 11:29 local time (VET), which is the reported -5:30 offset, not the expected -4:30 offset. I am seeing the correct behavior for more common timezones such as US/Eastern, US/Pacific, etc. At the moment this appears limited only to systems in VET. The client systems in question are running PE 2.5.1 on RHEL 5.7, 64-bit. 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #18013] Support for Microsoft .msu packages
Issue #18013 has been updated by Luis Mayorga. I wish i know :). I guess is documented here http://support.microsoft.com/kb/934307. My question is if i can use the windows provider on Puppet for Windows. Feature #18013: Support for Microsoft .msu packages https://projects.puppetlabs.com/issues/18013#change-78345 Author: Luis Mayorga Status: Accepted Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: windows Branch: Hi, I had to download a .msu package to include Powershell 3.0 on my Windows 7 Machine. Is there any support with Puppet using the Package Resource Type? -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #17989] (Closed) Cannot install Puppet on Red Hat Enterprise Linux Server release 6.3 (Santiago) due to rubygem-json
Issue #17989 has been updated by Phoenix Zeus. Status changed from Unreviewed to Closed Assignee set to Phoenix Zeus As no one else had a chance to look at it, here is how I solved and found a work around. The issue was the rubygems rpm which is part of rhel-x86_64-server-optional-6 channel, that my servers were not subscribed to. Either enabling the channel, or installing that rpm would resolve it. Bug #17989: Cannot install Puppet on Red Hat Enterprise Linux Server release 6.3 (Santiago) due to rubygem-json https://projects.puppetlabs.com/issues/17989#change-78350 Author: Phoenix Zeus Status: Closed Priority: Normal Assignee: Phoenix Zeus Category: installation Target version: 3.1.0 Affected Puppet version: 3.0.1 Keywords: bug, puppet, rubygem-json, ruby Branch: pre $ cat /etc/*release Red Hat Enterprise Linux Server release 6.3 (Santiago) Red Hat Enterprise Linux Server release 6.3 (Santiago) $ sudo yum repolist Loaded plugins: presto, refresh-packagekit, rhnplugin repo id repo name status mon_chkpt-rhel-x86_64-server-6 Monthly Checkpoint Red Hat Enterprise Linux Server (v. 6 for 64-bit x86_64) 8,541 puppetlabs-deps Puppet Labs Dependencies El 6 - x86_64 29 puppetlabs-products Puppet Labs Products El 6 - x86_64 142 repolist: 8,712 /pre After installing ruby, ruby-libs, ruby-shadow and facter using yum when I try to install puppet into brand new system I run into following issues. pre $ sudo yum install puppet Loaded plugins: presto, refresh-packagekit, rhnplugin Setting up Install Process Resolving Dependencies -- Running transaction check --- Package puppet.noarch 0:3.0.1-1.el6 will be installed -- Processing Dependency: hiera = 1.0.0 for package: puppet-3.0.1-1.el6.noarch -- Processing Dependency: ruby(selinux) for package: puppet-3.0.1-1.el6.noarch -- Processing Dependency: ruby-augeas for package: puppet-3.0.1-1.el6.noarch -- Running transaction check --- Package hiera.noarch 0:1.1.1-1.el6 will be installed -- Processing Dependency: rubygem-json for package: hiera-1.1.1-1.el6.noarch --- Package libselinux-ruby.x86_64 0:2.0.94-5.3.el6 will be installed --- Package ruby-augeas.x86_64 0:0.4.1-1.el6 will be installed -- Running transaction check --- Package rubygem-json.x86_64 0:1.4.6-2.el6 will be installed -- Processing Dependency: rubygems for package: rubygem-json-1.4.6-2.el6.x86_64 -- Finished Dependency Resolution Error: Package: rubygem-json-1.4.6-2.el6.x86_64 (puppetlabs-deps) Requires: rubygems You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest /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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #15329] Puppet lacks a proper undefined value
Issue #15329 has been updated by Reid Vandewiele. Thanks for clarifying. Everything is starting to make more sense now. :-) I understand the use case for `undef` when used as I described. When using the DSL I've actually never thought to try and use undef to override a defined resource default by passing in `undef` as a nothing value, since in my mind undef very clearly means its mnemonic, which is to undefine a setting, thus reverting to the default. Can you indicate an example use case for wanting to pass in an explicit nothing parameter in the DSL in order to override a default, and describe the benefit (or draw/motivation) for doing so along with a pseudo-DSL sample (e.g. using a hypothetical nothing keyword)? I think a concrete example would further clarify a lot of the discussion in this thread. Bug #15329: Puppet lacks a proper undefined value https://projects.puppetlabs.com/issues/15329#change-78355 Author: Pieter van de Bruggen Status: Accepted Priority: Normal Assignee: Henrik Lindberg Category: Target version: Affected Puppet version: Keywords: backlog Branch: $y = undef notice($y == ) # true notice($x == $y) # true notice($x == ) # true Recent changes in the Puppet DSL made equality commutative (good!), but in doing so broke work-arounds for actually testing for the difference between an undefined and empty value. The most logical fix would be to equate Puppet's `undef` with Ruby's `nil`. -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #18021] (Unreviewed) daemontools service provider ignores restart command
Issue #18021 has been reported by Amos Shapira. Bug #18021: daemontools service provider ignores restart command https://projects.puppetlabs.com/issues/18021 Author: Amos Shapira Status: Unreviewed Priority: Normal Assignee: Category: provider Target version: Affected Puppet version: 2.7.20 Keywords: daemontools Branch: Hello, (I submitted this on puppet-users Google group without response and think that I found a bug, so I'm copying here): Hello, Using Puppet 2.7(.20), I'm trying to override the restart command of a service controlled by daemontools provider using: service { 'bamboo-agent': hasrestart = false, provider = 'daemontools', restart = '/bin/touch /var/run/needs-restart', ... } And ... notify = Service['bamboo-agent'] ... But the service keeps being restarted using svc -t ... As far as I follow the documents this is supposed to work (http://docs.puppetlabs.com/references/2.7.latest/type.html#service) but as far as I follow the code in puppet-2.7.20/lib/puppet/provider/service/daemontools.rb it's not supported: def restart svc -t, self.service end (i.e. not looking at restartcmd) Am I missing something or is it a bug? How can I get it to work with Puppet 2.7? -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #17616] Package update via Gem provider fails when running Puppet via bundler
Issue #17616 has been updated by Josh Nichols. I've run into this too. Basically, bundler 'infects' the environment to make sure any rubygems things go through bundler, so if the gem isn't in the Gemfile, `gem install` won't see it. To get around that, Bundler has a `Bundler.with_clean_env` method to run anything inside it's block without those environment variables. I admit it was awhile ago that I tried and I was trying to monkeypatch puppet after it was loaded, but I wasn't able to find the right place to put the `Bundler.with_clean_env`. Hopefully will take another stab at it soon, but I'm thinking the gem provider should be updated to wrap `execute` calls with `Bundler.with_clean_env` if the Bundler constant is defined. Bug #17616: Package update via Gem provider fails when running Puppet via bundler https://projects.puppetlabs.com/issues/17616#change-78360 Author: Björn Albers Status: Accepted Priority: Normal Assignee: Category: package Target version: Affected Puppet version: 2.6.10 Keywords: gem, bundler, bundle, package, provider Branch: Given a rubygem / package with dependencies to other package. When I try do manage that package with Puppet all is fine. But when I apply the same manifest with Puppet executed via Bundler then I get an error (Installing a package w/o dependencies, i.e. rake, works). To my understanding installing Puppet with bundler is best practice when developing testing modules, so this might have some relevance. Here's my TPS report: # Bad: $ sudo bin/puppet apply --verbose --no-report foreground.pp info: Applying configuration version '1352903073' err: /Stage[main]//Package[foreground]/ensure: change from absent to latest failed: Could not update: Execution of '/usr/bin/gem install --include-dependencies --no-rdoc --no-ri foreground' returned 1: ERROR: Error installing foreground: foreground requires mixlib-cli (~ 1.2.2) INFO: `gem install -y` is now default and will be removed INFO: use --ignore-dependencies to install only the gems you list at /Users/bjoern/Documents/puppet-zabbix_osx/foreground.pp:4 notice: Finished catalog run in 78.69 seconds $ bin/puppet --version 2.7.19 # Good: $ sudo puppet apply --verbose --no-report foreground.pp info: Applying configuration version '1352903176' notice: Finished catalog run in 3.82 seconds $ puppet --version 2.7.19 # Context: $ ruby --version ruby 1.8.7 (2011-12-28 patchlevel 357) [universal-darwin11.0] $ bundle --version Bundler version 1.2.1 $ cat foreground.pp package { 'foreground': ensure = latest, provider = gem, } $ sw_vers ProductName:Mac OS X ProductVersion: 10.7.4 BuildVersion: 11E53 $ gem --version 1.8.24 PS: This might be a bug in bundler / rubygems / whatever, but I think it should at least be documented here. -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #16804] scheduled_task : add support for every X minutes or hours mode
Issue #16804 has been updated by Josh Cooper. I meant to say we don't currently support as opposed to can't support. We could create a new scheduled_task provider to support these capabilities and confine it to Vista or later. There are a variety of ways to accomplish this (schtasks.exe, API, XML) http://msdn.microsoft.com/en-us/library/windows/desktop/aa382153(v=vs.85).aspx Feature #16804: scheduled_task : add support for every X minutes or hours mode https://projects.puppetlabs.com/issues/16804#change-78361 Author: Pascal Sartoretti Status: Accepted Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: windows Branch: As stated in the Puppet documentation (http://docs.puppetlabs.com/windows/writing.html#scheduledtaskscheduledtask), the scheduled_task resource type does not support repetition modes such as every X minutes. It is a pity, because such tasks are very commonly used in Windows servers (and maybe less on Windows clients), making scheduled_task not so useful. It is true that the configuration of Windows scheduled task is complicated (as opposed to crontab...); we may not need all the features available in the Windows GUI (like Until, Duration or If the task is still running, stop it at this time), I guess it would be enough to support every X minutes and every Y hours. -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #17305] puppet module build fails with Error: undefined method `downcase' for nil:NilClass
Issue #17305 has been updated by Josh Cooper. I'm not able to reproduce this with 3.0.0 or later. I think it is a dup of #13070, but Jeff can you confirm? Bug #17305: puppet module build fails with Error: undefined method `downcase' for nil:NilClass https://projects.puppetlabs.com/issues/17305#change-78362 Author: Jeff McCune Status: Needs More Information Priority: Normal Assignee: Jeff McCune Category: module tool Target version: 3.1.0 Affected Puppet version: 3.0.0 Keywords: module Branch: mccune # Overview This appears to be a regression of #13070 and [GH-677](https://github.com/puppetlabs/puppet/pull/677) and [GH-950](https://github.com/puppetlabs/puppet/pull/950). Trying to build the [mount_providers]() module, the following exception is raised: pre $ git describe 3.0.0-37-g38f975f $ puppet module build --trace Error: undefined method `downcase' for nil:NilClass /workspace/puppet-3.x/src/puppet/lib/puppet/type.rb:1353:in `block in providify' /workspace/puppet-3.x/src/puppet/lib/puppet/util/classgen.rb:117:in `class_eval' /workspace/puppet-3.x/src/puppet/lib/puppet/util/classgen.rb:117:in `genthing' /workspace/puppet-3.x/src/puppet/lib/puppet/util/classgen.rb:28:in `genclass' /workspace/puppet-3.x/src/puppet/lib/puppet/type.rb:226:in `newparam' /workspace/puppet-3.x/src/puppet/lib/puppet/type.rb:1347:in `providify' /workspace/puppet-3.x/src/puppet/lib/puppet/metatype/manager.rb:94:in `newtype' /workspace/puppet-3.x/modules/mount_providers/lib/puppet/type/mountpoint.rb:1:in `top (required)' /Users/jeff/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require' /Users/jeff/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require' /workspace/puppet-3.x/src/puppet/lib/puppet/module_tool/contents_description.rb:34:in `block in data' /workspace/puppet-3.x/src/puppet/lib/puppet/module_tool/contents_description.rb:33:in `each' /workspace/puppet-3.x/src/puppet/lib/puppet/module_tool/contents_description.rb:33:in `data' /workspace/puppet-3.x/src/puppet/lib/puppet/module_tool/contents_description.rb:15:in `annotate' /workspace/puppet-3.x/src/puppet/lib/puppet/module_tool/applications/application.rb:44:in `metadata' /workspace/puppet-3.x/src/puppet/lib/puppet/module_tool/applications/application.rb:59:in `load_modulefile!' /workspace/puppet-3.x/src/puppet/lib/puppet/module_tool/applications/builder.rb:14:in `run' /workspace/puppet-3.x/src/puppet/lib/puppet/module_tool/applications/application.rb:11:in `run' /workspace/puppet-3.x/src/puppet/lib/puppet/face/module/build.rb:55:in `block (3 levels) in top (required)' /workspace/puppet-3.x/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:210:in `build' /workspace/puppet-3.x/src/puppet/lib/puppet/application/face_base.rb:229:in `main' /workspace/puppet-3.x/src/puppet/lib/puppet/application.rb:354:in `run_command' /workspace/puppet-3.x/src/puppet/lib/puppet/application.rb:346:in `block (2 levels) in run' /workspace/puppet-3.x/src/puppet/lib/puppet/application.rb:438:in `plugin_hook' /workspace/puppet-3.x/src/puppet/lib/puppet/application.rb:346:in `block in run' /workspace/puppet-3.x/src/puppet/lib/puppet/util.rb:500:in `exit_on_fail' /workspace/puppet-3.x/src/puppet/lib/puppet/application.rb:346:in `run' /workspace/puppet-3.x/src/puppet/lib/puppet/util/command_line.rb:87:in `execute' /workspace/puppet-3.x/src/puppet/bin/puppet:4:in `main' /pre # Steps to reproduce pre $ rake voltron * puppet 3.0.x 3.0.1-27-gf9d70b5 f9d70b5 * facter fix/2.x/cleanup_ec2_facts 1.6.14-rc1-306-g1034b82 1034b82 * hiera1.x 1.0.0rc4-6-g3b89fbe 3b89fbe * rspec-puppet masterv0.1.5 695b9a4 * puppetlabs_spec_helper master0.3.0-3-gdf3b021 df3b021 * fog 0.7.2 v0.7.2 c7ec7c9 * rbvmomi masterN/A 5dc0ca3 * stdlib 3.x 3.1.1-7-g6f0c1e2 6f0c1e2 * hiera_puppet v0.3.0v0.3.0 06e70f3 * mount_providers master0.0.2 233e3f6 * pe_mcollective master0.0.45-2-g64c6523 64c6523 * pe_accounts master1.0.3 0725c16 * pe_compliancemaster0.0.5 dddc001 * cloud_provisionermaster1.0.5-6-gd69f962 d69f962 * cloud_provisioner_vmware masterv1.0.0-5-g6eaab64 6eaab64 * hiera_puppet v0.3.0v0.3.0 06e70f3 * json gem 1.5.4 N/A *
[Puppet - Feature #4248] Load library plugins that are used by multiple puppet functions and delivered via pluginsync
Issue #4248 has been updated by Josh Cooper. The proposed fix for #7316 will ensure an application can require custom facts, types, providers, applications, faces and actions from the modulepath or gem, and that code can in turn require utility code, also from the modulepath or gem. However, the proposed fix won't fix this particular issue, trying to require utility code from a function. Also true for report processors. Additional changes will be required to the compiler to ensure code does not leak across environments, likely fork (but not exec) a child to do the compile. Feature #4248: Load library plugins that are used by multiple puppet functions and delivered via pluginsync https://projects.puppetlabs.com/issues/4248#change-78366 Author: R.I. Pienaar Status: Accepted Priority: Normal Assignee: Category: plumbing Target version: 2.7.x Affected Puppet version: 0.25.5 Keywords: autoloader Branch: Because we do not add all module lib directories to Ruby's search path, ruby classes that exist only in the modules (because they have not yet been synced via pluginsync) cannot be found. The autoloader correctly loads files from the modules, but ruby itself can't load supporting classes. Old description: At present we can copy parser functions, types and providers out with plugins sync, this works fine. It seems though we cannot copy out Puppet::Util::* classes - useful for code accessed by various parser functions for example. I need to do something like: pre require File.dirname(__FILE__) + '/../../util/foo.rb' /pre from a parser function since: pre require 'puppet/util/foo' /pre doesnt work. I am also keen to be able to copy out new application classes that will tie into the puppet single executable thing, i guess these 2 features might be in the same realm. -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #16651] Installing the cloud provisioner module breaks the node subcommand
Issue #16651 has been updated by Josh Cooper. And the trace: pre Error: Could not autoload puppet/face/node_aws/bootstrap: --tags=: already defined in puppet /Users/josh/work/puppet/lib/puppet/interface/option.rb:31:in `initialize' /Users/josh/work/puppet/lib/puppet/interface/option.rb:13:in `each' /Users/josh/work/puppet/lib/puppet/interface/option.rb:13:in `initialize' /Users/josh/work/puppet/lib/puppet/interface/option_builder.rb:13:in `new' /Users/josh/work/puppet/lib/puppet/interface/option_builder.rb:13:in `initialize' /Users/josh/work/puppet/lib/puppet/interface/option_builder.rb:7:in `new' /Users/josh/work/puppet/lib/puppet/interface/option_builder.rb:7:in `build' /Users/josh/work/puppet/lib/puppet/interface/action_builder.rb:30:in `option' /private/tmp/modules/user/cloud_provisioner/lib/puppet/cloudpack.rb:109:in `add_tags_option' /private/tmp/modules/user/cloud_provisioner/lib/puppet/cloudpack.rb:100:in `add_create_options' /private/tmp/modules/user/cloud_provisioner/lib/puppet/cloudpack.rb:256:in `add_bootstrap_options' /private/tmp/modules/user/cloud_provisioner/lib/puppet/face/node_aws/bootstrap.rb:12 /Users/josh/work/puppet/lib/puppet/interface/action_builder.rb:76:in `instance_eval' /Users/josh/work/puppet/lib/puppet/interface/action_builder.rb:76:in `initialize' /Users/josh/work/puppet/lib/puppet/interface/action_builder.rb:9:in `new' /Users/josh/work/puppet/lib/puppet/interface/action_builder.rb:9:in `build' /Users/josh/work/puppet/lib/puppet/interface/action_manager.rb:11:in `action' /private/tmp/modules/user/cloud_provisioner/lib/puppet/face/node_aws/bootstrap.rb:5 /Users/josh/work/puppet/lib/puppet/interface.rb:48:in `instance_eval' /Users/josh/work/puppet/lib/puppet/interface.rb:48:in `define' /private/tmp/modules/user/cloud_provisioner/lib/puppet/face/node_aws/bootstrap.rb:4 /Users/josh/work/puppet/lib/puppet/util/autoload.rb:68:in `load' /Users/josh/work/puppet/lib/puppet/util/autoload.rb:68:in `load_file' /Users/josh/work/puppet/lib/puppet/util/autoload.rb:83:in `loadall' /Users/josh/work/puppet/lib/puppet/util/autoload.rb:81:in `each' /Users/josh/work/puppet/lib/puppet/util/autoload.rb:81:in `loadall' /Users/josh/work/puppet/lib/puppet/util/autoload.rb:214:in `loadall' /Users/josh/work/puppet/lib/puppet/interface.rb:109:in `load_actions' /Users/josh/work/puppet/lib/puppet/interface.rb:45:in `define' /private/tmp/modules/user/cloud_provisioner/lib/puppet/face/node_aws.rb:3 ... /pre Bug #16651: Installing the cloud provisioner module breaks the node subcommand https://projects.puppetlabs.com/issues/16651#change-78368 Author: Jeff McCune Status: Accepted Priority: Normal Assignee: Category: Faces Target version: 3.0.x Affected Puppet version: 3.0.0 Keywords: faces node face subcommand cloud_provisioner Branch: # Overview In Puppet 3.0.0, installing the official `puppetlabs-cloud_provisioner` module from the forge breaks the `puppet node` subcommand. # Expected behavior Installing the cloud_provisioner module should not breaking any existing functionality of Puppet core. # Actual Behavior pre root@pe-centos6:~# puppet help node Error: Could not autoload puppet/face/node/classify: no such file to load -- puppet/cloudpack Error: Could not load help for the face node. Please check the error logs for more information. Detail: Could not autoload puppet/face/node/classify: no such file to load -- puppet/cloudpack Error: Try 'puppet help help help' for usage /pre # Steps to reproduce 1. Install Puppet 3.0.0 from official release RPM's on CentOS 6.3: `yum install --enablerepo=puppetlabs-devel puppet puppet-server` 1. Install the cloud provisoner module: `puppet module install puppetlabs-cloud_provisioner` At this point, the node subcommand shows up as having errors in `puppet help`. `puppet help node` is totally broken as well. -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #16753] Need the ability to list all nodes
Issue #16753 has been updated by Andrew Parker. Branch changed from https://github.com/puppetlabs/puppet/pull/1305 to https://github.com/puppetlabs/puppet/pull/1317 Fixed a few issues in Henrik's changes. New pull request submitted. Bug #16753: Need the ability to list all nodes https://projects.puppetlabs.com/issues/16753#change-78378 Author: James Turnbull Status: In Topic Branch Pending Review Priority: High Assignee: Henrik Lindberg Category: indirector Target version: 3.1.0 Affected Puppet version: 3.0.0 Keywords: backlog Branch: https://github.com/puppetlabs/puppet/pull/1317 In Puppet 3.0 we've disabled the default YAML node cache (see https://github.com/puppetlabs/puppet/commit/5a79d9abd96e73ff166527cdee69a30da8ab0f87). I use this code (and a number of others in the community use similar) to return a list of nodes: pre Puppet[:clientyamldir] = Puppet[:yamldir] if Puppet::Node.respond_to? :terminus_class Puppet::Node.terminus_class = :yaml nodes = Puppet::Node.search(*) else Puppet::Node.indirection.terminus_class = :yaml nodes = Puppet::Node.indirection.search(*) end /pre This now doesn't work. We need a method of returning the current list of nodes the master knows about. Currently available is: pre puppet node find 'hostname' /pre If we had: pre puppet node search '*' /pre That would meet my needs. -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #16426] Publish API documentation automatically
Issue #16426 has been updated by eric sorenson. Keywords changed from documentation, docs, yard, API to documentation docs yard API backlog Feature #16426: Publish API documentation automatically https://projects.puppetlabs.com/issues/16426#change-78390 Author: Andrew Parker Status: Investigating Priority: Normal Assignee: Andrew Parker Category: API Target version: Affected Puppet version: Keywords: documentation docs yard API backlog Branch: At the moment there is no generated documentation that we automatically publish. This limits our ability to document and publish the public API for using puppet as a library or accessing supported features when writing extensions. There have been some attempts in the past to generate YARD docs and publish them to github as gh-pages, but that effort bit-rotted. We need to come up with a way of creating and maintaining these kinds of docs. -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #18023] (Accepted) Puppet needs a public, clearly-defined Ruby API
Issue #18023 has been reported by eric sorenson. Bug #18023: Puppet needs a public, clearly-defined Ruby API https://projects.puppetlabs.com/issues/18023 Author: eric sorenson Status: Accepted Priority: Normal Assignee: eric sorenson Category: Target version: 3.x Affected Puppet version: Keywords: backlog Branch: One of the problems people run into using Puppet as part of an infrastructure ecosystem is that there isn't a clearly defined Ruby API for it. There are REST endpoints that expose some functionality over the network, but they do not cover much of the total surface area of what Puppet can do, and things that are important for third parties aee probably never going to be exposed over the network. (A real-world use case: Foreman wants access to puppet master's configuration settings so it can integrate with the CA auth/issuance code). Today, people poke directly at internal methods, which both makes it difficult to change method signatures and control flow AND provides a crappy experience for tool authors. So Puppet should have a real, public, published (see #16426) API that the development team commits to and the outside world can trust. -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #18024] (Unreviewed) Make a shorthand alias for scope.lookupvar()
Issue #18024 has been reported by Yuri Arabadji. Feature #18024: Make a shorthand alias for scope.lookupvar() https://projects.puppetlabs.com/issues/18024 Author: Yuri Arabadji Status: Unreviewed Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: Branch: Tired of writing scope.lookupvar() in my templates. Gepetto doesn't have working auto-completion, sadly, so I have to ask here for a solution. That function is the most used in templates, assuming you've got hierarchy of defines/classes and there's an intermediary class between the defined resource and template. pre class a { $thevar = 123 whatever { 'yy': tmpl = 'xx'} } define whatever($tmpl) { file { /xxx: content = template($tmpl) } } xx.erb: %= scope.lookupvar('a::thevar') % /pre Maybe you could make a short alias for it, for ex.: sl or slv. 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #17305] (Duplicate) puppet module build fails with Error: undefined method `downcase' for nil:NilClass
Issue #17305 has been updated by Jeff McCune. Status changed from Needs More Information to Duplicate Assignee deleted (Jeff McCune) Josh Cooper wrote: I'm not able to reproduce this with 3.0.0 or later. I think it is a dup of #13070, but Jeff can you confirm? Confirmed. -Jeff Bug #17305: puppet module build fails with Error: undefined method `downcase' for nil:NilClass https://projects.puppetlabs.com/issues/17305#change-78397 Author: Jeff McCune Status: Duplicate Priority: Normal Assignee: Category: module tool Target version: 3.1.0 Affected Puppet version: 3.0.0 Keywords: module Branch: mccune # Overview This appears to be a regression of #13070 and [GH-677](https://github.com/puppetlabs/puppet/pull/677) and [GH-950](https://github.com/puppetlabs/puppet/pull/950). Trying to build the [mount_providers]() module, the following exception is raised: pre $ git describe 3.0.0-37-g38f975f $ puppet module build --trace Error: undefined method `downcase' for nil:NilClass /workspace/puppet-3.x/src/puppet/lib/puppet/type.rb:1353:in `block in providify' /workspace/puppet-3.x/src/puppet/lib/puppet/util/classgen.rb:117:in `class_eval' /workspace/puppet-3.x/src/puppet/lib/puppet/util/classgen.rb:117:in `genthing' /workspace/puppet-3.x/src/puppet/lib/puppet/util/classgen.rb:28:in `genclass' /workspace/puppet-3.x/src/puppet/lib/puppet/type.rb:226:in `newparam' /workspace/puppet-3.x/src/puppet/lib/puppet/type.rb:1347:in `providify' /workspace/puppet-3.x/src/puppet/lib/puppet/metatype/manager.rb:94:in `newtype' /workspace/puppet-3.x/modules/mount_providers/lib/puppet/type/mountpoint.rb:1:in `top (required)' /Users/jeff/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require' /Users/jeff/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require' /workspace/puppet-3.x/src/puppet/lib/puppet/module_tool/contents_description.rb:34:in `block in data' /workspace/puppet-3.x/src/puppet/lib/puppet/module_tool/contents_description.rb:33:in `each' /workspace/puppet-3.x/src/puppet/lib/puppet/module_tool/contents_description.rb:33:in `data' /workspace/puppet-3.x/src/puppet/lib/puppet/module_tool/contents_description.rb:15:in `annotate' /workspace/puppet-3.x/src/puppet/lib/puppet/module_tool/applications/application.rb:44:in `metadata' /workspace/puppet-3.x/src/puppet/lib/puppet/module_tool/applications/application.rb:59:in `load_modulefile!' /workspace/puppet-3.x/src/puppet/lib/puppet/module_tool/applications/builder.rb:14:in `run' /workspace/puppet-3.x/src/puppet/lib/puppet/module_tool/applications/application.rb:11:in `run' /workspace/puppet-3.x/src/puppet/lib/puppet/face/module/build.rb:55:in `block (3 levels) in top (required)' /workspace/puppet-3.x/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:210:in `build' /workspace/puppet-3.x/src/puppet/lib/puppet/application/face_base.rb:229:in `main' /workspace/puppet-3.x/src/puppet/lib/puppet/application.rb:354:in `run_command' /workspace/puppet-3.x/src/puppet/lib/puppet/application.rb:346:in `block (2 levels) in run' /workspace/puppet-3.x/src/puppet/lib/puppet/application.rb:438:in `plugin_hook' /workspace/puppet-3.x/src/puppet/lib/puppet/application.rb:346:in `block in run' /workspace/puppet-3.x/src/puppet/lib/puppet/util.rb:500:in `exit_on_fail' /workspace/puppet-3.x/src/puppet/lib/puppet/application.rb:346:in `run' /workspace/puppet-3.x/src/puppet/lib/puppet/util/command_line.rb:87:in `execute' /workspace/puppet-3.x/src/puppet/bin/puppet:4:in `main' /pre # Steps to reproduce pre $ rake voltron * puppet 3.0.x 3.0.1-27-gf9d70b5 f9d70b5 * facter fix/2.x/cleanup_ec2_facts 1.6.14-rc1-306-g1034b82 1034b82 * hiera1.x 1.0.0rc4-6-g3b89fbe 3b89fbe * rspec-puppet masterv0.1.5 695b9a4 * puppetlabs_spec_helper master0.3.0-3-gdf3b021 df3b021 * fog 0.7.2 v0.7.2 c7ec7c9 * rbvmomi masterN/A 5dc0ca3 * stdlib 3.x 3.1.1-7-g6f0c1e2 6f0c1e2 * hiera_puppet v0.3.0v0.3.0 06e70f3 * mount_providers master0.0.2 233e3f6 * pe_mcollective master0.0.45-2-g64c6523 64c6523 * pe_accounts master1.0.3 0725c16 * pe_compliancemaster0.0.5 dddc001 * cloud_provisionermaster1.0.5-6-gd69f962 d69f962 * cloud_provisioner_vmware masterv1.0.0-5-g6eaab64 6eaab64 * hiera_puppet v0.3.0v0.3.0
[Puppet - Bug #17156] Regression: Can't restrict the plugins loaded by puppet doc with --modulepath in 3.0.1
Issue #17156 has been updated by Josh Cooper. I'm digging into this issue as it relates to #7316. I'm actually having trouble reproducing the problem, see comments below: Nick Fagerlund wrote: In 3.0.0, puppet doc would ONLY load plugins from the modulepath; the contents of the agent’s libdir had no effect, and changing the modulepath swapped out the entire set of plugins available. The doc application uses an InstanceLoader when generating reference documentation. The InstanceLoader delegates to Autoload(er)s, one per reference type (function, report, etc). In 3.0.0, the Autoloader's search path always includes the current environment's modulepath and the libdir. However, in 3.0.0, when running in `master` run_mode, libdir will refer to the one in /etc/puppet/var/lib, even when not running as root. For example, I see the autoloader using my modulepaths and system libdir: pre /tmp/modules/user/cloud_provisioner/lib, /tmp/modules/user/mod1/lib, /tmp/modules/user/mod2/lib, /var/lib/puppet/lib, /pre In 3.0.1, puppet doc loads plugins from both the modulepath AND the libdir. So if puppet agent has ever run, puppet doc will keep loading plugins until you delete the libdir. In 3.0.1, the run_mode no longer affects which vardir (and libdir) is used. Instead, it's solely based on whether you're running as root or not. As a result, I see it using my user's libdir: pre /tmp/modules/user/cloud_provisioner/lib, /tmp/modules/user/mod1/lib, /tmp/modules/user/mod2/lib, /Users/josh/.puppet/var/lib, /pre So it's not that it started using the libdir, just that it started using a different one than in 3.0.0. So I've thought about this a little more. Principles: * Puppet doc, in its reference mode, should only document components that are **installed.** That makes sense. So in conclusion: * Having puppet doc read plugins from the **agent's** libdir is wrong. * Having it read plugins from the **master's** libdir is right. In 3.0.1 and above, there is not distinction between master and agent libdir. It's solely based on whether you're running as root or not. * Obviously the results will be stupid if the agent and the master share a libdir, just like everything else gets stupid. * And what it's probably actually doing is using the libdir from the `[user]` config block, which is approximately as wrong as using the agent's libdir. So given that... I suspect it makes sense to switch puppet doc to master run mode. That way, the theoretical users who're generating docs for their custom types and functions will get the correct behavior pretty much no matter what. The doc application currently runs in master run_mode. ... Does that sound right? Also I may be overthinking this, as we're probably the only ones who use reference mode. :/ If you only want to generate a reference for **core** types, etc, ignoring installed modules and pluginsync'ed libdir, you could do: pre $ puppet doc --reference [..] --libdir /dev/null --modulepath /dev/null /pre If you want to generate a reference for **installed** types, excluding libdir: pre $ puppet doc --reference [..] --libdir /dev/null /pre If you want to generate a reference for **installed** types, **including** those in the libdir (on the master): pre $ puppet doc --reference [..] /pre All of this assumes you are running `puppet doc` as the same user as you ran `puppet module install`, which I think is what people would expect. Using 3.0.2, and a puppet.conf of: pre [master] modulepath=/tmp/modules/user /pre If I install a module: pre $ puppet module install puppetlabs-stdlib Notice: Preparing to install into /tmp/modules/user ... /pre And then I can generate documentation for it, including the module I just installed: pre $ puppet doc --reference function ... abs bool2num .. /pre Does that make sense? Bug #17156: Regression: Can't restrict the plugins loaded by puppet doc with --modulepath in 3.0.1 https://projects.puppetlabs.com/issues/17156#change-78401 Author: Nick Fagerlund Status: Accepted Priority: Normal Assignee: Category: settings Target version: 3.x Affected Puppet version: 3.0.1 Keywords: regression settings Branch: The docs team uses `puppet doc --reference` to generate certain docs for the site, and we have to use `--modulepath /tmp/nothing` or something to exclude non-core resource types and functions from our personal modules. This worked through 3.0.0 and broke in 3.0.1. The changed behavior: * In 3.0.0, puppet doc would ONLY load plugins from the modulepath; the contents of the agent's libdir had no effect, and changing the modulepath swapped out the entire set of plugins available. * In 3.0.1, puppet doc loads plugins from both the modulepath AND the libdir. So if puppet agent has ever run, puppet doc will keep loading plugins until you delete the libdir. Git bisect tracks the change to
[Puppet - Bug #16753] Need the ability to list all nodes
Issue #16753 has been updated by Andrew Parker. The new implementation can be turned off by doing the following in puppet.conf. pre [master] node_cache_terminus = /pre The code given in the original report should work, but you can also use the `puppet node` subcommand by creating a routes file routes.yaml pre --- node: node: terminus: yaml cache: yaml /pre and then execute pre puppet node search '*' --route_file routes.yaml --clientyamldir `puppet master --configprint yamldir` /pre Using this approach is more likely to continue working than setting the terminus directly since the test that was written for this validates using the `puppet node search` command. I don't think that the structure of that data is actually documented anywhere, and so relying on anything beyond the `name` element in the top of each hash is probably as far as can be guaranteed at the moment. Bug #16753: Need the ability to list all nodes https://projects.puppetlabs.com/issues/16753#change-78402 Author: James Turnbull Status: In Topic Branch Pending Review Priority: High Assignee: Henrik Lindberg Category: indirector Target version: 3.1.0 Affected Puppet version: 3.0.0 Keywords: backlog Branch: https://github.com/puppetlabs/puppet/pull/1317 In Puppet 3.0 we've disabled the default YAML node cache (see https://github.com/puppetlabs/puppet/commit/5a79d9abd96e73ff166527cdee69a30da8ab0f87). I use this code (and a number of others in the community use similar) to return a list of nodes: pre Puppet[:clientyamldir] = Puppet[:yamldir] if Puppet::Node.respond_to? :terminus_class Puppet::Node.terminus_class = :yaml nodes = Puppet::Node.search(*) else Puppet::Node.indirection.terminus_class = :yaml nodes = Puppet::Node.indirection.search(*) end /pre This now doesn't work. We need a method of returning the current list of nodes the master knows about. Currently available is: pre puppet node find 'hostname' /pre If we had: pre puppet node search '*' /pre That would meet my needs. -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Facter - Feature #7559] Fact for identifying Amazon VPC instances.
Issue #7559 has been updated by Ryan Coleman. Josh Cooper wrote: Ryan Coleman wrote: Would it help to make this fact a module that is distributed through the Puppet Forge instead of making a part of core Facter? Those running in EC2 can install the module and pluginsync the fact to their agents. It would for puppet, but facter runs in environments without puppet... Ok, fair enough but it would solve a part of the problem without preventing other parts from being solved, right? I'm trying to fight the feeling I have that we're all aiming for a solution that's just a bit too perfect. Feature #7559: Fact for identifying Amazon VPC instances. https://projects.puppetlabs.com/issues/7559#change-78404 Author: Nigel Kersten Status: Accepted Priority: Normal Assignee: Category: library Target version: Keywords: vpc ec2 arp Branch: Affected Facter version: 1.6.10 (From the list) I ran into a buglet in facter 1.5.9rc6 (from tmz repo). In normal AWS instances it works great. In VPC instances if doesn't work. This seems to be because VPC instances don't use the fe:ff:ff:... MAC addresses. pre /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 02:67:4E:E1:26:30 inet addr:172.17.129.24 ... /sbin/arp Address HWtype HWaddress Flags Mask Iface 169.254.169.253 ether 02:67:4E:C0:00:01 C eth0 172.17.128.1 ether 02:67:4E:C0:00:01 C eth0 /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 02:67:4E:DA:58:16 inet addr:172.17.128.126 /sbin/arp Address HWtype HWaddress Flags Mask Iface 169.254.169.253 ether 02:67:4E:C0:00:01 C eth0 172.17.128.1 ether 02:67:4E:C0:00:01 C eth0 /pre Of the two VPC EC2 instances I've seen, the MAC address always start with 02:67:4E. I have only seen two instances, both in the same VPC, so I don't know if this holds for every VPC instance, YMMV. in ec2.rb , the following seemed to work: pre def has_euca_mac? !!(Facter.value(:macaddress) =~ %r{^02:67:4[eE]:}) end /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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Facter - Feature #7559] Fact for identifying Amazon VPC instances.
Issue #7559 has been updated by Ryan Coleman. Justin Lambert wrote: Ryan Coleman wrote: Would it help to make this fact a module that is distributed through the Puppet Forge instead of making a part of core Facter? Those running in EC2 can install the module and pluginsync the fact to their agents. It would also mean puppet first runs would not have the correct ec2 information. I don't believe that to be true. Pluginsync would occur during a Puppet run before your intended Puppet run, syncing the fact from your Puppet Master to your agent. You may try this out for yourself with the puppetlabs-stdlib module, which provides three facts. [fact source code on GitHub](https://github.com/puppetlabs/puppetlabs-stdlib/tree/master/lib/facter) [module on Forge, for easy install](https://forge.puppetlabs.com/puppetlabs/stdlib) Feature #7559: Fact for identifying Amazon VPC instances. https://projects.puppetlabs.com/issues/7559#change-78405 Author: Nigel Kersten Status: Accepted Priority: Normal Assignee: Category: library Target version: Keywords: vpc ec2 arp Branch: Affected Facter version: 1.6.10 (From the list) I ran into a buglet in facter 1.5.9rc6 (from tmz repo). In normal AWS instances it works great. In VPC instances if doesn't work. This seems to be because VPC instances don't use the fe:ff:ff:... MAC addresses. pre /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 02:67:4E:E1:26:30 inet addr:172.17.129.24 ... /sbin/arp Address HWtype HWaddress Flags Mask Iface 169.254.169.253 ether 02:67:4E:C0:00:01 C eth0 172.17.128.1 ether 02:67:4E:C0:00:01 C eth0 /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 02:67:4E:DA:58:16 inet addr:172.17.128.126 /sbin/arp Address HWtype HWaddress Flags Mask Iface 169.254.169.253 ether 02:67:4E:C0:00:01 C eth0 172.17.128.1 ether 02:67:4E:C0:00:01 C eth0 /pre Of the two VPC EC2 instances I've seen, the MAC address always start with 02:67:4E. I have only seen two instances, both in the same VPC, so I don't know if this holds for every VPC instance, YMMV. in ec2.rb , the following seemed to work: pre def has_euca_mac? !!(Facter.value(:macaddress) =~ %r{^02:67:4[eE]:}) end /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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #16753] Need the ability to list all nodes
Issue #16753 has been updated by Andrew Parker. Turns out that the routes file isn't needed at all. The same thing can be achieved by using the `--node_terminus` parameter. pre puppet node search '*' --node_terminus yaml --clientyamldir `puppet master --configprint yamldir` /pre Bug #16753: Need the ability to list all nodes https://projects.puppetlabs.com/issues/16753#change-78406 Author: James Turnbull Status: In Topic Branch Pending Review Priority: High Assignee: Henrik Lindberg Category: indirector Target version: 3.1.0 Affected Puppet version: 3.0.0 Keywords: backlog Branch: https://github.com/puppetlabs/puppet/pull/1317 In Puppet 3.0 we've disabled the default YAML node cache (see https://github.com/puppetlabs/puppet/commit/5a79d9abd96e73ff166527cdee69a30da8ab0f87). I use this code (and a number of others in the community use similar) to return a list of nodes: pre Puppet[:clientyamldir] = Puppet[:yamldir] if Puppet::Node.respond_to? :terminus_class Puppet::Node.terminus_class = :yaml nodes = Puppet::Node.search(*) else Puppet::Node.indirection.terminus_class = :yaml nodes = Puppet::Node.indirection.search(*) end /pre This now doesn't work. We need a method of returning the current list of nodes the master knows about. Currently available is: pre puppet node find 'hostname' /pre If we had: pre puppet node search '*' /pre That would meet my needs. -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #16753] (Merged - Pending Release) Need the ability to list all nodes
Issue #16753 has been updated by Andrew Parker. Status changed from In Topic Branch Pending Review to Merged - Pending Release Assignee deleted (Henrik Lindberg) Merged in https://github.com/puppetlabs/puppet/commit/86f7e5e4106e00d2b87f7f385a4a65815dae61fd Bug #16753: Need the ability to list all nodes https://projects.puppetlabs.com/issues/16753#change-78409 Author: James Turnbull Status: Merged - Pending Release Priority: High Assignee: Category: indirector Target version: 3.1.0 Affected Puppet version: 3.0.0 Keywords: backlog Branch: https://github.com/puppetlabs/puppet/pull/1317 In Puppet 3.0 we've disabled the default YAML node cache (see https://github.com/puppetlabs/puppet/commit/5a79d9abd96e73ff166527cdee69a30da8ab0f87). I use this code (and a number of others in the community use similar) to return a list of nodes: pre Puppet[:clientyamldir] = Puppet[:yamldir] if Puppet::Node.respond_to? :terminus_class Puppet::Node.terminus_class = :yaml nodes = Puppet::Node.search(*) else Puppet::Node.indirection.terminus_class = :yaml nodes = Puppet::Node.indirection.search(*) end /pre This now doesn't work. We need a method of returning the current list of nodes the master knows about. Currently available is: pre puppet node find 'hostname' /pre If we had: pre puppet node search '*' /pre That would meet my needs. -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Facter - Feature #7559] Fact for identifying Amazon VPC instances.
Issue #7559 has been updated by Jeff McCune. The course we plan to pursue is: 1. Confine the metadata API availability check to `virtual = xenu` in an effort to limit this network call to a subset of Facter users. 2. Confine the metadata API check to a x millisecond timeout. Amazon says the metadata server responds quickly so let's take their word for it. We'll compute x by sampling these response times on some EC2 instances in various regions. If x turns out to be 20ms then we're probably not going to take this approach. because it would negatively impact everyone running Facter on Xen hypervisors. 3. Check to see if http://169.254.169.254/latest/meta-data/ responds with a header of Server: EC2ws 4. If so, define a fact indicating we're inside of EC2. 5. Confine all of the meta-data and user-data facts to the fact set in 4. Baring any major objections I'll implement this soon. Thoughts? -Jeff Feature #7559: Fact for identifying Amazon VPC instances. https://projects.puppetlabs.com/issues/7559#change-78410 Author: Nigel Kersten Status: Accepted Priority: Normal Assignee: Category: library Target version: Keywords: vpc ec2 arp Branch: Affected Facter version: 1.6.10 (From the list) I ran into a buglet in facter 1.5.9rc6 (from tmz repo). In normal AWS instances it works great. In VPC instances if doesn't work. This seems to be because VPC instances don't use the fe:ff:ff:... MAC addresses. pre /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 02:67:4E:E1:26:30 inet addr:172.17.129.24 ... /sbin/arp Address HWtype HWaddress Flags Mask Iface 169.254.169.253 ether 02:67:4E:C0:00:01 C eth0 172.17.128.1 ether 02:67:4E:C0:00:01 C eth0 /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 02:67:4E:DA:58:16 inet addr:172.17.128.126 /sbin/arp Address HWtype HWaddress Flags Mask Iface 169.254.169.253 ether 02:67:4E:C0:00:01 C eth0 172.17.128.1 ether 02:67:4E:C0:00:01 C eth0 /pre Of the two VPC EC2 instances I've seen, the MAC address always start with 02:67:4E. I have only seen two instances, both in the same VPC, so I don't know if this holds for every VPC instance, YMMV. in ec2.rb , the following seemed to work: pre def has_euca_mac? !!(Facter.value(:macaddress) =~ %r{^02:67:4[eE]:}) end /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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Facter - Feature #7559] Fact for identifying Amazon VPC instances.
Issue #7559 has been updated by James Turnbull. Looks good. Will 3. be faster than can_connect? Thanks Jeff! Feature #7559: Fact for identifying Amazon VPC instances. https://projects.puppetlabs.com/issues/7559#change-78412 Author: Nigel Kersten Status: Accepted Priority: Normal Assignee: Category: library Target version: Keywords: vpc ec2 arp Branch: Affected Facter version: 1.6.10 (From the list) I ran into a buglet in facter 1.5.9rc6 (from tmz repo). In normal AWS instances it works great. In VPC instances if doesn't work. This seems to be because VPC instances don't use the fe:ff:ff:... MAC addresses. pre /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 02:67:4E:E1:26:30 inet addr:172.17.129.24 ... /sbin/arp Address HWtype HWaddress Flags Mask Iface 169.254.169.253 ether 02:67:4E:C0:00:01 C eth0 172.17.128.1 ether 02:67:4E:C0:00:01 C eth0 /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 02:67:4E:DA:58:16 inet addr:172.17.128.126 /sbin/arp Address HWtype HWaddress Flags Mask Iface 169.254.169.253 ether 02:67:4E:C0:00:01 C eth0 172.17.128.1 ether 02:67:4E:C0:00:01 C eth0 /pre Of the two VPC EC2 instances I've seen, the MAC address always start with 02:67:4E. I have only seen two instances, both in the same VPC, so I don't know if this holds for every VPC instance, YMMV. in ec2.rb , the following seemed to work: pre def has_euca_mac? !!(Facter.value(:macaddress) =~ %r{^02:67:4[eE]:}) end /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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Facter - Feature #7559] Fact for identifying Amazon VPC instances.
Issue #7559 has been updated by Michael Arnold. Jeff McCune wrote: Thoughts? Does item 3 break on openstack or eucalyptus? Otherwise, outside of any issues with the timeout, I think this is an acceptable solution. Feature #7559: Fact for identifying Amazon VPC instances. https://projects.puppetlabs.com/issues/7559#change-78413 Author: Nigel Kersten Status: Accepted Priority: Normal Assignee: Category: library Target version: Keywords: vpc ec2 arp Branch: Affected Facter version: 1.6.10 (From the list) I ran into a buglet in facter 1.5.9rc6 (from tmz repo). In normal AWS instances it works great. In VPC instances if doesn't work. This seems to be because VPC instances don't use the fe:ff:ff:... MAC addresses. pre /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 02:67:4E:E1:26:30 inet addr:172.17.129.24 ... /sbin/arp Address HWtype HWaddress Flags Mask Iface 169.254.169.253 ether 02:67:4E:C0:00:01 C eth0 172.17.128.1 ether 02:67:4E:C0:00:01 C eth0 /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 02:67:4E:DA:58:16 inet addr:172.17.128.126 /sbin/arp Address HWtype HWaddress Flags Mask Iface 169.254.169.253 ether 02:67:4E:C0:00:01 C eth0 172.17.128.1 ether 02:67:4E:C0:00:01 C eth0 /pre Of the two VPC EC2 instances I've seen, the MAC address always start with 02:67:4E. I have only seen two instances, both in the same VPC, so I don't know if this holds for every VPC instance, YMMV. in ec2.rb , the following seemed to work: pre def has_euca_mac? !!(Facter.value(:macaddress) =~ %r{^02:67:4[eE]:}) end /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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #8974] class variable access from toplevel warnings in bsd service
Issue #8974 has been updated by Josh Cooper. Branch set to https://github.com/puppetlabs/puppet/pull/444 Bug #8974: class variable access from toplevel warnings in bsd service https://projects.puppetlabs.com/issues/8974#change-78414 Author: Max Lincoln Status: In Topic Branch Pending Review Priority: Normal Assignee: Brett Bender Category: ruby19 Target version: Affected Puppet version: 2.7.1 Keywords: Branch: https://github.com/puppetlabs/puppet/pull/444 Running puppet 2.7.1 on: * Rackspace * RHEL 5.6 I get these warnings: pre /usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.1/lib/puppet/provider/service/freebsd.rb:8: warning: class variable access from toplevel /usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.1/lib/puppet/provider/service/freebsd.rb:9: warning: class variable access from toplevel /usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.1/lib/puppet/provider/service/freebsd.rb:10: warning: class variable access from toplevel /usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.1/lib/puppet/provider/service/bsd.rb:11: warning: class variable access from toplevel /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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #17713] (Accepted) upstart service provider throws warning: class variable access from toplevel
Issue #17713 has been updated by Josh Cooper. Description updated Status changed from Unreviewed to Accepted Hi Andrew, thanks for patch, but that means we'll check the version for each upstart package, since each package resource has it's own provider instance. I think we probably want to do what was suggested in #8974, as this is an issue with some versions of ruby. Bug #17713: upstart service provider throws warning: class variable access from toplevel https://projects.puppetlabs.com/issues/17713#change-78415 Author: Andrew Regner Status: Accepted Priority: Normal Assignee: Category: agent Target version: Affected Puppet version: 3.0.1 Keywords: Branch: running `puppet agent --test` on my puppetmaster causes this warning to appear a bunch of times, even when no changes are happening: pre root@app1:~# puppet agent --test Info: Retrieving plugin Info: Loading facts in /etc/puppet/modules/stdlib/lib/facter/facter_dot_d.rb Info: Loading facts in /etc/puppet/modules/stdlib/lib/facter/puppet_vardir.rb Info: Loading facts in /etc/puppet/modules/stdlib/lib/facter/root_home.rb Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb Info: Caching catalog for app1 Info: Applying configuration version '1353302633' /usr/local/rvm/gems/ruby-1.9.3-p194/gems/puppet-3.0.1/lib/puppet/provider/service/upstart.rb:67: warning: class variable access from toplevel /usr/local/rvm/gems/ruby-1.9.3-p194/gems/puppet-3.0.1/lib/puppet/provider/service/upstart.rb:67: warning: class variable access from toplevel /usr/local/rvm/gems/ruby-1.9.3-p194/gems/puppet-3.0.1/lib/puppet/provider/service/upstart.rb:67: warning: class variable access from toplevel /usr/local/rvm/gems/ruby-1.9.3-p194/gems/puppet-3.0.1/lib/puppet/provider/service/upstart.rb:67: warning: class variable access from toplevel /usr/local/rvm/gems/ruby-1.9.3-p194/gems/puppet-3.0.1/lib/puppet/provider/service/upstart.rb:67: warning: class variable access from toplevel /usr/local/rvm/gems/ruby-1.9.3-p194/gems/puppet-3.0.1/lib/puppet/provider/service/upstart.rb:67: warning: class variable access from toplevel /usr/local/rvm/gems/ruby-1.9.3-p194/gems/puppet-3.0.1/lib/puppet/provider/service/upstart.rb:67: warning: class variable access from toplevel /usr/local/rvm/gems/ruby-1.9.3-p194/gems/puppet-3.0.1/lib/puppet/provider/service/upstart.rb:67: warning: class variable access from toplevel /usr/local/rvm/gems/ruby-1.9.3-p194/gems/puppet-3.0.1/lib/puppet/provider/service/upstart.rb:67: warning: class variable access from toplevel /usr/local/rvm/gems/ruby-1.9.3-p194/gems/puppet-3.0.1/lib/puppet/provider/service/upstart.rb:67: warning: class variable access from toplevel /usr/local/rvm/gems/ruby-1.9.3-p194/gems/puppet-3.0.1/lib/puppet/provider/service/upstart.rb:67: warning: class variable access from toplevel /usr/local/rvm/gems/ruby-1.9.3-p194/gems/puppet-3.0.1/lib/puppet/provider/service/upstart.rb:67: warning: class variable access from toplevel Finished catalog run in 5.86 seconds /pre As you can see I am using Ruby 1.9.3 and Puppet 3.0.1. This is all on Ubuntu 11.10, but ruby is compiled from source ala RVM and puppet is from gem install. This doesn't seem to be causing any problems that I can see, but it is annoying. My other nodes are all stock-ruby and puppet 2.7 packages from the puppetlabs repo. They don't throw this warning. My puppetmaster never threw this warning either before I upgraded it to 3.0.1. (I upgraded to ruby 1.9.3 at the same time, for the record.) -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #18021] daemontools service provider ignores restart command
Issue #18021 has been updated by Amos Shapira. I've created a pull request with a suggested fix: https://github.com/puppetlabs/puppet/pull/1318 It was tested with puppet 2.7.20 installed from gem on fedora 15 Bug #18021: daemontools service provider ignores restart command https://projects.puppetlabs.com/issues/18021#change-78416 Author: Amos Shapira Status: Unreviewed Priority: Normal Assignee: Category: provider Target version: Affected Puppet version: 2.7.20 Keywords: daemontools Branch: Hello, (I submitted this on puppet-users Google group without response and think that I found a bug, so I'm copying here): Hello, Using Puppet 2.7(.20), I'm trying to override the restart command of a service controlled by daemontools provider using: service { 'bamboo-agent': hasrestart = false, provider = 'daemontools', restart = '/bin/touch /var/run/needs-restart', ... } And ... notify = Service['bamboo-agent'] ... But the service keeps being restarted using svc -t ... As far as I follow the documents this is supposed to work (http://docs.puppetlabs.com/references/2.7.latest/type.html#service) but as far as I follow the code in puppet-2.7.20/lib/puppet/provider/service/daemontools.rb it's not supported: def restart svc -t, self.service end (i.e. not looking at restartcmd) Am I missing something or is it a bug? How can I get it to work with Puppet 2.7? -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #7316] (In Topic Branch Pending Review) puppet face applications (subcommands) delivered via modules should work
Issue #7316 has been updated by Josh Cooper. Status changed from Code Insufficient to In Topic Branch Pending Review Branch set to https://github.com/puppetlabs/puppet/pull/1319 Bug #7316: puppet face applications (subcommands) delivered via modules should work https://projects.puppetlabs.com/issues/7316#change-78417 Author: Dan Bode Status: In Topic Branch Pending Review Priority: High Assignee: Andrew Parker Category: Faces Target version: 3.1.0 Affected Puppet version: 3.0.0 Keywords: face faces subcommand application module plugin pluginsync backlog Branch: https://github.com/puppetlabs/puppet/pull/1319 If you deliver a new face that consists of: * application * face * action for face via pluginsync, then the application isn't actually found, and worse, it taunts you by showing it to you in the list of available subcommands. -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #17951] (Needs More Information) Windows package provider does not re-run installation when subscription updates
Issue #17951 has been updated by Josh Cooper. Status changed from Unreviewed to Needs More Information Hi Andrew, the windows package provider will consider the resource to be insync if the package with that name is installed. So for example, if your package name doesn't contain a version string, e.g. VMware Tools, it wil not recognize that the package needs updating. To ensure that your specific MSI is installed, you can specify the MSI PackageCode as the name of the package. See http://projects.puppetlabs.com/issues/11868#note-11 for more details about this. Let me know if that resolves the issues you are seeing. Bug #17951: Windows package provider does not re-run installation when subscription updates https://projects.puppetlabs.com/issues/17951#change-78418 Author: Andrew Dunkman Status: Needs More Information Priority: Normal Assignee: Category: windows Target version: Affected Puppet version: 3.0.1 Keywords: windows msi Branch: I have a directory of MSIs that are copied to nodes and run to install products; newer versions of MSIs install cleanly over older versions. What I would like to do is install the product either 1. when the product is not yet installed or 2. when the source file changes. The first point is easy with the windows package provider, the second point seems impossible using the windows package provider. The provider seems to ignore its subscriptions. file { 'c:/packages/myinstaller.msi': ensure = 'file', mode = '1777', owner = 'administrator', group = 'Administrators', source = 'puppet:///...', notify = Package['My Product'], } package { 'My Product': ensure = installed, source = 'c:\\packages\\myinstaller.msi', } -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #16804] scheduled_task : add support for every X minutes or hours mode
Issue #16804 has been updated by Pascal Sartoretti. Maybe support for Windows Server 2003 is not required, as this OS is already in Extended Support phase (no more in Mainstream Support phase), and will be terminated in 2015. Feature #16804: scheduled_task : add support for every X minutes or hours mode https://projects.puppetlabs.com/issues/16804#change-78419 Author: Pascal Sartoretti Status: Accepted Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: windows Branch: As stated in the Puppet documentation (http://docs.puppetlabs.com/windows/writing.html#scheduledtaskscheduledtask), the scheduled_task resource type does not support repetition modes such as every X minutes. It is a pity, because such tasks are very commonly used in Windows servers (and maybe less on Windows clients), making scheduled_task not so useful. It is true that the configuration of Windows scheduled task is complicated (as opposed to crontab...); we may not need all the features available in the Windows GUI (like Until, Duration or If the task is still running, stop it at this time), I guess it would be enough to support every X minutes and every Y hours. -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.