[Puppet - Bug #17994] (Unreviewed) Symbolic file modes when creating directories: Wrong permissions

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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.

2012-12-06 Thread tickets

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.

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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()

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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.

2012-12-06 Thread tickets

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.

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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.

2012-12-06 Thread tickets

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.

2012-12-06 Thread tickets

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.

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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

2012-12-06 Thread tickets

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.