[Puppet - Bug #16271] launchd resources don't refresh/restart

[tickets]

Issue #16271 has been updated by Gary Larizza.

Branch set to 
https://github.com/glarizza/puppet-1/tree/bug/master/16271_launchd_restart_action

Filed a pull request --> https://github.com/puppetlabs/puppet/pull/1197

Bug #16271: launchd resources don't refresh/restart
https://projects.puppetlabs.com/issues/16271#change-72161

Author: Clay Caviness
Status: Accepted
Priority: Normal
Assignee: 
Category: OSX
Target version: 
Affected Puppet version: 2.7.18
Keywords: 
Branch: 
https://github.com/glarizza/puppet-1/tree/bug/master/16271_launchd_restart_action


I can't actually recall the last time I verified it was working, but it *was* 
at some point in the past.

Currently it's not, though, at least with puppet 2.7.18 on OS X 10.8.1.

Debug output shows a trigger of a refresh, but no execs are ever run:

[...]
notice: /Stage[main]//Service[com.apple.mDNSResponder]: Triggered 'refresh' 
from 1 events
debug: /Stage[main]//Service[com.apple.mDNSResponder]: The container 
Class[Main] will propagate my refresh event
debug: /Schedule[weekly]: Skipping device resources because running on a host
debug: /Schedule[puppet]: Skipping device resources because running on a host
debug: Class[Main]: The container Stage[main] will propagate my refresh event
debug: Finishing transaction 2223267580
debug: Storing state
debug: Stored state in 0.29 seconds
notice: Finished catalog run in 15.52 seconds



-- 
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 #16271] (Accepted) launchd resources don't refresh/restart

[tickets]

Issue #16271 has been updated by Gary Larizza.

File servicetest.zip added
Status changed from Unreviewed to Accepted

I've attached a module to test this out.  It worked according to how Clay 
reported it.  

Also, I've done the following in the lib/puppet/provider/service/launchd.rb 
file at around line 233:


def restart
  Puppet.debug("A restart has been triggered")
  Puppet.debug("Stopping the service")
  self.stop
  Puppet.debug("Starting the service")
  self.start
end


That seemed to work for me - can you guys confirm?  If so, that's a simple fix 
and I can write out some tests.

Bug #16271: launchd resources don't refresh/restart
https://projects.puppetlabs.com/issues/16271#change-72160

Author: Clay Caviness
Status: Accepted
Priority: Normal
Assignee: 
Category: OSX
Target version: 
Affected Puppet version: 2.7.18
Keywords: 
Branch: 


I can't actually recall the last time I verified it was working, but it *was* 
at some point in the past.

Currently it's not, though, at least with puppet 2.7.18 on OS X 10.8.1.

Debug output shows a trigger of a refresh, but no execs are ever run:

[...]
notice: /Stage[main]//Service[com.apple.mDNSResponder]: Triggered 'refresh' 
from 1 events
debug: /Stage[main]//Service[com.apple.mDNSResponder]: The container 
Class[Main] will propagate my refresh event
debug: /Schedule[weekly]: Skipping device resources because running on a host
debug: /Schedule[puppet]: Skipping device resources because running on a host
debug: Class[Main]: The container Stage[main] will propagate my refresh event
debug: Finishing transaction 2223267580
debug: Storing state
debug: Stored state in 0.29 seconds
notice: Finished catalog run in 15.52 seconds



-- 
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 #16681] (Accepted) Using WMI to resolve user and group SIDs is very slow

[tickets]

Issue #16681 has been reported by Josh Cooper.


Bug #16681: Using WMI to resolve user and group SIDs is very slow
https://projects.puppetlabs.com/issues/16681

Author: Josh Cooper
Status: Accepted
Priority: Normal
Assignee: Josh Cooper
Category: 
Target version: 2.7.x
Affected Puppet version: 2.7.19
Keywords: windows slow performance sid file owner group
Branch: 


Using native code to resolve a local user account into a SID 1000 times takes 
0.25 seconds. Using ruby's WMI code, it takes 33.93 seconds, more than 100 
times slower. We perform these lookups many times for each file when managing 
owner and/or group permissions.

Using native code also handles the case where the username is not qualified, in 
which case it will look for local user accounts first, then the primary domain, 
then trusted domains. This will help resolve issue #15326


-- 
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 #16637] (Merged - Pending Release) Puppet confdir and vardir are wrong when running non-root

[tickets]

Issue #16637 has been updated by Andrew  Parker.

Status changed from In Topic Branch Pending Review to Merged - Pending Release

Merge in 


Bug #16637: Puppet confdir and vardir are wrong when running non-root
https://projects.puppetlabs.com/issues/16637#change-72152

Author: Jeff McCune
Status: Merged - Pending Release
Priority: Normal
Assignee: 
Category: settings
Target version: 3.0.x
Affected Puppet version: 3.0.0
Keywords: telly settings defaults confdir vardir runmode run_mode master system
Branch: https://github.com/puppetlabs/puppet/pull/1194


# Overview

Puppet master should default to confdir of `~/.puppet` and vardir of 
`~/.puppet/var` when running as non-root, instead defaults to `/etc/puppet` and 
`/var/lib/puppet` respectively.

In Puppet 3.0.0, the semantics of the term, "configuration directory" (confdir) 
are as follows:

 1. If `confdir` is explicitly configured, this value wins.
 2. If Puppet is running as root (or the OS equivalent) then use the system 
configuration directory. (e.g. `/etc/puppet` for FOSS or 
`/etc/puppetlabs/puppet` for PE)
 3. In all other situations use `~/.puppet`

These semantics are no longer affected by the specific username when running 
non-root, or the application being run (master, agent, etc...).

This is not actually the case in 3.0.0 though:

# Actual Behavior


$ puppet master --verbose --no-daemonize
Error: Could not set 'directory' on ensure: Permission denied - /etc/puppet
Error: Could not set 'directory' on ensure: Permission denied - 
/etc/puppetWrapped exception:
Permission denied - /etc/puppet
Error: /File[/etc/puppet]/ensure: change from absent to directory failed: Could 
not set 'directory' on ensure: Permission denied - /etc/puppet
/File[/etc/puppet/var.master]: Dependency File[/etc/puppet] has failures: true
Warning: /File[/etc/puppet/var.master]: Skipping because of failed dependencies
/File[/etc/puppet/var.master/bucket]: Dependency File[/etc/puppet] has 
failures: true
Warning: /File[/etc/puppet/var.master/bucket]: Skipping because of failed 
dependencies
/File[/etc/puppet/var.master/log]: Dependency File[/etc/puppet] has failures: 
true
Warning: /File[/etc/puppet/var.master/log]: Skipping because of failed 
dependencies
/File[/etc/puppet/var.master/log/masterhttp.log]: Dependency File[/etc/puppet] 
has failures: true
Warning: /File[/etc/puppet/var.master/log/masterhttp.log]: Skipping because of 
failed dependencies
/File[/etc/puppet/var.master/yaml]: Dependency File[/etc/puppet] has failures: 
true
Warning: /File[/etc/puppet/var.master/yaml]: Skipping because of failed 
dependencies
/File[/etc/puppet/var.master/ssl]: Dependency File[/etc/puppet] has failures: 
true
Warning: /File[/etc/puppet/var.master/ssl]: Skipping because of failed 
dependencies
/File[/etc/puppet/var.master/ssl/public_keys]: Dependency File[/etc/puppet] has 
failures: true
Warning: /File[/etc/puppet/var.master/ssl/public_keys]: Skipping because of 
failed dependencies/File[/etc/puppet/var.master/lib]: Dependency 
File[/etc/puppet] has failures: trueWarning: /File[/etc/puppet/var.master/lib]: 
Skipping because of failed 
dependencies/File[/etc/puppet/var.master/ssl/certificate_requests]: Dependency 
File[/etc/puppet] has failures: true
Warning: /File[/etc/puppet/var.master/ssl/certificate_requests]: Skipping 
because of failed dependencies/File[/etc/puppet/var.master/run]: Dependency 
File[/etc/puppet] has failures: true
Warning: /File[/etc/puppet/var.master/run]: Skipping because of failed 
dependencies/File[/etc/puppet/manifests]: Dependency File[/etc/puppet] has 
failures: trueWarning: /File[/etc/puppet/manifests]: Skipping because of failed 
dependencies
/File[/etc/puppet/var.master/ssl/private]: Dependency File[/etc/puppet] has 
failures: true
Warning: /File[/etc/puppet/var.master/ssl/private]: Skipping because of failed 
dependencies
/File[/etc/puppet/var.master/ssl/private_keys]: Dependency File[/etc/puppet] 
has failures: true
Warning: /File[/etc/puppet/var.master/ssl/private_keys]: Skipping because of 
failed dependencies
/File[/etc/puppet/var.master/rrd]: Dependency File[/etc/puppet] has failures: 
true
Warning: /File[/etc/puppet/var.master/rrd]: Skipping because of failed 
dependencies
/File[/etc/puppet/var.master/ssl/certs]: Dependency File[/etc/puppet] has 
failures: true
Warning: /File[/etc/puppet/var.master/ssl/certs]: Skipping because of failed 
dependencies
/File[/etc/puppet/var.master/reports]: Dependency File[/etc/puppet] has 
failures: true
Warning: /File[/etc/puppet/var.master/reports]: Skipping because of failed 
dependencies
/File[/etc/puppet/var.master/server_data]: Dependency File[/etc/puppet] has 
failures: true
Warning: /File[/etc/puppet/var.master/server_data]: Skipping because of failed 
dependencies
/File[/etc/puppet/var.master/state]: Dependency File[/etc/puppet] has failures: 
true
Warning: /File[/etc/puppet/va

[Puppet - Bug #4224] (Closed) vardir and confdir should be in ~/.puppet if not run as root

[tickets]

Issue #4224 has been updated by Jeff McCune.

Status changed from Needs More Information to Closed

# Closing in favor of 16637

We discussed this in the puppet-dev IRC channel today and we feel we've missed 
the boat for fixing this bug in the 2.7 series.  We do still accept 
responsibility for fixing this issue, but we do not intend to fix it  in 2.7 
because it would likely be an unwelcome surprise.  Instead, we plan to fix it 
in 3.x as soon as possible.


[4:55pm] zaphod42: jmccune: I noticed that #16637 referenced #4224, which seems 
to be the exact same thing but against 2.7.x. What are your thoughts on what 
should be done on #4224?
[4:55pm] gepetto: zaphod42: jmccune: #16637 is 
http://projects.puppetlabs.com/issues/show/16637 "Bug #16637: Puppet confdir 
and vardir are wrong when running non-root - Puppet. It has a status of In 
Topic Branch Pending Review and is assigned to -"
[4:55pm] jmccune: looking
[4:55pm] zaphod42: gepetto doesn't understand me talking about multiple 
bugs #4224
[4:55pm] zaphod42: #4224
[4:55pm] gepetto: zaphod42: #4224 is 
http://projects.puppetlabs.com/issues/show/4224 "Bug #4224: vardir and confdir 
should be in ~/.puppet if not run as root - Puppet. It has a status of Needs 
More Information and is assigned to -"
[4:56pm] jmccune: Yeah
[4:56pm] zaphod42: gepetto--
[4:56pm] jmccune: I ran across that on Saturday and my eyes almost rolled out 
of my head.
[4:56pm] jmccune: I mean, we sort of missed the boat on that one for 2.7
[4:56pm] drewmania joined the chat room.
[4:56pm] zaphod42: that is what I'm thinking
[4:56pm] jmccune: Given that we've carried 20 releases of the master explicitly 
using the system directories.
[4:56pm] derpops joined the chat room.
[4:57pm] zaphod42: I think the 2.7 bug should just be closed
[4:57pm] jmccune: I think it would be an unwelcome surprise for users even if 
we did accept it as a bug over 2 years ago
[4:57pm] jmccune: Yeah
[4:57pm] jmccune: Doing that
[4:57pm] zaphod42: cool


Bug #4224: vardir and confdir should be in ~/.puppet if not run as root
https://projects.puppetlabs.com/issues/4224#change-72150

Author: Matt Robinson
Status: Closed
Priority: Normal
Assignee: 
Category: 
Target version: 2.7.x
Affected Puppet version: 
Keywords: defaults settings
Branch: 


There's currently logic (which_dir) in lib/puppet/util/run_mode.rb that uses 
/var/lib/puppet and /etc/puppet if you're running puppetmaster regardless of if 
you're running it as root.  James agrees this is not correct behavior.  I guess 
the logic at some point was that if you're running puppetmaster you must need 
root.  That seems backwards to me since master doesn't really need root, except 
to maybe switch to run as the puppet user, and if anything this logic should 
apply to the agent, but perhaps not even then.

  def var_dir
which_dir(
  (Puppet.features.microsoft_windows? ? File.join(Dir::WINDOWS, 
"puppet", "var") : "/var/lib/puppet"),
  "~/.puppet/var"
)
  end

  def which_dir( global, user )
#FIXME: we should test if we're user "puppet"
#   there's a comment that suggests that we do that
#   and we currently don't.
expand_path case
  when name == :master; global
  when Puppet.features.root?; global
  else user
end
  end



-- 
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] 'Telly Upgrade Issues' wiki page has been updated

[tickets]

The 'Telly Upgrade Issues' wiki page has been updated by Jeff McCune.


Telly Upgrade Issues:
https://projects.puppetlabs.com/projects/puppet/wiki/Telly_Upgrade_Issues
View differences:
https://projects.puppetlabs.com/projects/puppet/wiki/Telly_Upgrade_Issues/diff/3

-- 
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 #16667] Misleading error message "Not authorized to call find" after upgrading from 2.7 to 3.0

[tickets]

Issue #16667 has been updated by Jeff McCune.


Reference: [commit 4053722](https://github.com/puppetlabs/puppet/commit/4053722)

Bug #16667: Misleading error message "Not authorized to call find" after 
upgrading from 2.7 to 3.0
https://projects.puppetlabs.com/issues/16667#change-72147

Author: Jeff McCune
Status: Unreviewed
Priority: Normal
Assignee: 
Category: error reporting
Target version: 3.0.x
Affected Puppet version: 3.0.0
Keywords: 
Branch: 


# Overview

When we took out the deprecation warning for the modules path element in source 
URI's of file resources, we didn't replace it with a friendly error message.

# Expected behavior

In 2.7 the following manifest worked, but with this friendly message:


# site.pp
node default {
  notify { "Hello World": }

  file { "/tmp/foo.txt":
source => [
  "puppet:///filetest/sshd_config.${::fqdn}",
  "puppet:///filetest/sshd_config",
],
  }
}



notice: DEPRECATION NOTICE: Files found in modules without specifying 'modules' 
in file path
  will be deprecated in the next major release.  Please fix module 'filetest' 
when no 0.24.x
  clients are present


The behavior I expect is that a similarly friendly and informative error 
message is displayed in 3.0.

# Actual Behavior

In 3.0 this is the user's experience:


$ puppet master --verbose --no-daemonize
Starting Puppet master version 3.0.0Info: Inserting default '~ 
^/catalog/([^/]+)$' (auth true) ACL
Info: Inserting default '~ ^/node/([^/]+)$' (auth true) ACLInfo: Inserting 
default '/file' (auth ) ACL
Info: Inserting default '/certificate_revocation_list/ca' (auth true) ACLInfo: 
Inserting default '/report' (auth true) ACL
Info: Inserting default '/certificate/ca' (auth any) ACL
Info: Inserting default '/certificate/' (auth any) ACL
Info: Inserting default '/certificate_request' (auth any) ACLInfo: Inserting 
default '/status' (auth true) ACL
Compiled catalog for mccune.agent in environment production in 0.03 seconds
Error: Not authorized to call find on 
/file_metadata/filetest/sshd_config.mccune.puppetlabs.lan



-- 
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] 'Telly Upgrade Issues' wiki page has been updated

[tickets]

The 'Telly Upgrade Issues' wiki page has been updated by eric sorenson.


Telly Upgrade Issues:
https://projects.puppetlabs.com/projects/puppet/wiki/Telly_Upgrade_Issues
View differences:
https://projects.puppetlabs.com/projects/puppet/wiki/Telly_Upgrade_Issues/diff/2

-- 
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] 'Telly Upgrade Issues' wiki page has been added

[tickets]

The 'Telly Upgrade Issues' wiki page has been added by eric sorenson.


https://projects.puppetlabs.com/projects/puppet/wiki/Telly_Upgrade_Issues

-- 
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] 'Release Notes' wiki page has been updated

[tickets]

The 'Release Notes' wiki page has been updated by eric sorenson.


Release Notes:
https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes
View differences:
https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes/diff/213

-- 
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 #16676] (Unreviewed) End of line comments in puppet.conf are not treated as comments

[tickets]

Issue #16676 has been reported by Jeff McCune.


Bug #16676: End of line comments in puppet.conf are not treated as comments
https://projects.puppetlabs.com/issues/16676

Author: Jeff McCune
Status: Unreviewed
Priority: Normal
Assignee: 
Category: settings
Target version: 3.0.x
Affected Puppet version: 3.0.0
Keywords: settings comment puppet.conf configuration conffile conf
Branch: 


# Overview

In Puppet 3.0.0 comments in `puppet.conf` that exist at the end of the line are 
not handled correctly.

# Steps to reproduce

Use this configuration file:


# puppet.conf
[main]
certname = mccune.local

[agent]
certname = mccune.agent # different from master


# Expected behavior

The agent certname should be "mccune.agent"

# Actual behavior


$ puppet agent --test
Info: Creating a new SSL key for mccune.agent # foo
^CCancelling startup


# References

 * [Puppet Users - More Puppet 3.0 upgrade issues: rest.rb and runinterval 
?](https://groups.google.com/d/topic/puppet-users/sJzQMYEbzPc/discussion)


-- 
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 #16675] (Unreviewed) Issue with puppetlabs-firewall and puppet 3.0

[tickets]

Issue #16675 has been reported by Jason Hancock.


Bug #16675: Issue with puppetlabs-firewall and puppet 3.0
https://projects.puppetlabs.com/issues/16675

Author: Jason Hancock
Status: Unreviewed
Priority: Normal
Assignee: Ken Barber
Category: 
Target version: 
Affected Puppet version: 3.0.0
Keywords: firewall provider params
Branch: 


Platform information:

* OS: CentOS 6.3
* ruby-1.8.7.352-7.el6_2.x86_64
* puppet-3.0.0-1.el6.noarch
* facter-1.6.10-1.el6.x86_64

I'm using the puppetlabs-firewall module version 0.0.4. The problem I'm having 
is that if the port changes for a firewall rule, I end up getting an error. 
Doesn't happen on puppet 2.7.x.

Start with an empty set of rules:

[root@localhost tmp]# iptables -F


site.pp:

node default {
  firewall { '100 allow sshd':
state  => 'NEW',
dport  => 22,
proto  => 'tcp',
action => 'accept',
  }
}


Output (it's fine):

[root@localhost tmp]# /usr/bin/puppet agent --onetime --no-daemonize --verbose 
--no-splay
Info: Retrieving plugin
Info: Loading facts in /var/lib/puppet/lib/facter/iptables.rb
Info: Caching catalog for node.example.com
Info: Applying configuration version '1349129193'
/Firewall[100 allow sshd]/ensure: created
Finished catalog run in 0.22 seconds


Verify the rule was created:

[root@localhost tmp]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source   destination 
ACCEPT tcp  --  anywhere anywheremultiport dports 
ssh /* 100 allow sshd */ state NEW 

Chain FORWARD (policy ACCEPT)
target prot opt source   destination 

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination 


Update site.pp, change dport to some other port...

node default {
  firewall { '100 allow sshd':
state  => 'NEW',
dport  => 1022,
proto  => 'tcp',
action => 'accept',
  }
}


And notice the error message:

[root@localhost tmp]# /usr/bin/puppet agent --onetime --no-daemonize --verbose 
--no-splay
Info: Retrieving plugin
Info: Loading facts in /var/lib/puppet/lib/facter/iptables.rb
Info: Caching catalog for node.example.com
Info: Applying configuration version '1349129242'
Error: The iptables provider can not handle attribute dport
Error: /Firewall[100 allow sshd]/dport: change from 22 to 1022 failed: The 
iptables provider can not handle attribute dport
Finished catalog run in 0.15 seconds


On a 2.7.19 puppet client on the same machine, this same test yields the 
following result:

[root@localhost tmp]# /usr/bin/puppet agent --onetime --no-daemonize --verbose 
--no-splay 
info: Retrieving plugin
info: Loading facts in /var/lib/puppet/lib/facter/iptables.rb
info: Caching catalog for node.example.com
info: Applying configuration version '1349129242'
notice: /Firewall[100 allow sshd]/dport: dport changed ['22'] to '1022'
notice: Firewall[100 allow sshd](provider=iptables): Properties changed - 
updating rule
notice: Finished catalog run in 0.30 seconds



-- 
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 #16672] Puppet comments generate errors if not at ^beginning of line

[tickets]

Issue #16672 has been updated by Forrest Aldrich.


Here are the error messages that the above will generage:

Oct  1 16:55:46 central puppet-agent[26980]: Could not autoload 
puppet/indirector/certificate/rest: Invalid duration format '"900 # 15 mins"' 
for parameter: runinterval
Oct  1 16:55:46 central puppet-agent[26980]: Could not prepare for 
execution: Could not autoload puppet/indirector/certificate/rest: Invalid 
duration format '"900 # 15 mins"' for parameter: runinterval



Bug #16672: Puppet comments generate errors if not at ^beginning of line
https://projects.puppetlabs.com/issues/16672#change-72129

Author: Forrest Aldrich
Status: Unreviewed
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: puppet.conf comments 
Branch: 


Unlike previous versions, the ability to add a comment in Puppet 3.0 to 
puppet.conf appears restricted to single line entry, which prevents comments 
like:


runinterval = 500 # comment


where during the upgrade this causes the client to choke and exit with an error 
that points to rest.rb.  This is the fix:
 

# comment
runinterval = 500


Puppet should be able to parse out comments at the end of a line, after the 
position of a hash tag.  Since this behavior appears to have changed, I presume 
it was introduced during the refactoring of 3.0 and thus should probably be 
fixed.



-- 
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 #16672] (Unreviewed) Puppet comments generate errors if not at ^beginning of line

[tickets]

Issue #16672 has been reported by Forrest Aldrich.


Bug #16672: Puppet comments generate errors if not at ^beginning of line
https://projects.puppetlabs.com/issues/16672

Author: Forrest Aldrich
Status: Unreviewed
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: puppet.conf comments 
Branch: 


Unlike previous versions, the ability to add a comment in Puppet 3.0 to 
puppet.conf appears restricted to single line entry, which prevents comments 
like:


runinterval = 500 # comment


where during the upgrade this causes the client to choke and exit with an error 
that points to rest.rb.  This is the fix:
 

# comment
runinterval = 500


Puppet should be able to parse out comments at the end of a line, after the 
position of a hash tag.  Since this behavior appears to have changed, I presume 
it was introduced during the refactoring of 3.0 and thus should probably be 
fixed.



-- 
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 #16665] [windows] wrong ipaddress with locale != en

[tickets]

Issue #16665 has been updated by Josh Cooper.

Description updated



Bug #16665: [windows] wrong ipaddress with locale != en
https://projects.puppetlabs.com/issues/16665#change-72122

Author: Sebastian Lehn
Status: Accepted
Priority: Normal
Assignee: 
Category: windows
Target version: 
Keywords: windows, ipaddress, netmask, ipaddress6
Branch: 
Affected Facter version: 1.6.11


Within module Facter::Util::IP


   # A map of all the different regexes that work for
   # a given platform or set of platforms.
   REGEX_MAP = {
:windows => {
  :ipaddress  => /\s+IP Address:\s+([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)/,
  :ipaddress6 => /Address 
((?![fe80|::1])(?>[0-9,a-f,A-F]*\:{1,2})+[0-9,a-f,A-F]{0,4})/,
  :netmask  => /\s+Subnet Prefix:\s+\S+\s+\(mask 
([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)\)/
}
   }


Regex contains english strings. That's why facter returns no ip address for 
interfaces and no netmask.



-- 
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] 'Release Notes' wiki page has been updated

[tickets]

The 'Release Notes' wiki page has been updated by Moses Mendoza.


Release Notes:
https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes
View differences:
https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes/diff/212

-- 
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 #16665] (Accepted) [windows] wrong ipaddress with locale != en

[tickets]

Issue #16665 has been updated by Josh Cooper.

Status changed from Unreviewed to Accepted

Thanks for the report Sebastian. Can you provide the output of:


netsh.exe interface ip show interface
netsh.exe interface ipv6 show interface


And


netsh.exe interface ipv6 show address ""
netsh.exe interface ip show address ""


For example, the german equivalent of `netsh.exe interface ipv6 show address 
"Local Area Connection"`

Bug #16665: [windows] wrong ipaddress with locale != en
https://projects.puppetlabs.com/issues/16665#change-72121

Author: Sebastian Lehn
Status: Accepted
Priority: Normal
Assignee: 
Category: windows
Target version: 
Keywords: windows, ipaddress, netmask, ipaddress6
Branch: 
Affected Facter version: 1.6.11


# Within module Facter::Util::IP #

   # A map of all the different regexes that work for
   # a given platform or set of platforms.
   REGEX_MAP = {
:windows => {
  :ipaddress  => /\s+IP Address:\s+([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)/,
  :ipaddress6 => /Address 
((?![fe80|::1])(?>[0-9,a-f,A-F]*\:{1,2})+[0-9,a-f,A-F]{0,4})/,
  :netmask  => /\s+Subnet Prefix:\s+\S+\s+\(mask 
([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)\)/
}
   }


Regex contains english strings. That's why facter returns no ip address for 
interfaces and no netmask.



-- 
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] 'Release Notes' wiki page has been updated

[tickets]

The 'Release Notes' wiki page has been updated by Moses Mendoza.


Release Notes:
https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes
View differences:
https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes/diff/211

-- 
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 #16665] [windows] wrong ipaddress with locale != en

[tickets]

Issue #16665 has been updated by Sebastian Lehn.


Maybe related ticket: #16668

Used system: Windows Server 2008 R2 Enterprise (German)

Bug #16665: [windows] wrong ipaddress with locale != en
https://projects.puppetlabs.com/issues/16665#change-72120

Author: Sebastian Lehn
Status: Unreviewed
Priority: Normal
Assignee: 
Category: windows
Target version: 
Keywords: windows, ipaddress, netmask, ipaddress6
Branch: 
Affected Facter version: 1.6.11


# Within module Facter::Util::IP #

   # A map of all the different regexes that work for
   # a given platform or set of platforms.
   REGEX_MAP = {
:windows => {
  :ipaddress  => /\s+IP Address:\s+([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)/,
  :ipaddress6 => /Address 
((?![fe80|::1])(?>[0-9,a-f,A-F]*\:{1,2})+[0-9,a-f,A-F]{0,4})/,
  :netmask  => /\s+Subnet Prefix:\s+\S+\s+\(mask 
([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)\)/
}
   }


Regex contains english strings. That's why facter returns no ip address for 
interfaces and no netmask.



-- 
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 #16668] (Unreviewed) [windows] ipaddress fact reports hostname

[tickets]

Issue #16668 has been reported by Sebastian Lehn.


Bug #16668: [windows] ipaddress fact reports hostname
https://projects.puppetlabs.com/issues/16668

Author: Sebastian Lehn
Status: Unreviewed
Priority: Normal
Assignee: 
Category: windows
Target version: 
Keywords: ipaddress, windows, locale
Branch: 
Affected Facter version: 1.6.11


Something is wrong with the ipaddress fact. Fact ipaddress reports hostname and 
not an ipaddress! More surprising is, if i call facter with the name of the 
fact ipaddress the value is correct.

See the following shell output:

C:\Program Files (x86)\Puppet Labs\Puppet\bin>facter.bat | find "ipaddress 
=>"
ipaddress => dc1
C:\Program Files (x86)\Puppet Labs\Puppet\bin>
C:\Program Files (x86)\Puppet Labs\Puppet\bin>facter.bat ipaddress
172.16.96.161
C:\Program Files (x86)\Puppet Labs\Puppet\bin>


Maybe related ticket: #16665

System: Windows Server 2008 R2 Enterprise (German)


-- 
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 #16376] (Merged - Pending Release) Inventory service fails on fact search with `undefined method `has_fact_with_value' for #`

[tickets]

Issue #16376 has been updated by Michael Stahnke.

Status changed from In Topic Branch Pending Review to Merged - Pending Release

merged at 

 

Bug #16376: Inventory service fails on fact search with `undefined method 
`has_fact_with_value' for #`
https://projects.puppetlabs.com/issues/16376#change-72119

Author: Matthaus Owens
Status: Merged - Pending Release
Priority: Normal
Assignee: Matthaus Owens
Category: 
Target version: 2.7.20
Affected Puppet version: 2.7.14
Keywords: 
Branch: 



Sep 12 10:17:10 rhel5-latest-x86-64 puppet-master[10906]: Starting Puppet 
master version 2.7.19 (Puppet Enterprise 2.6.0rc0-19-g515dd42)
Sep 12 10:17:10 rhel5-latest-x86-64 puppet-master[10906]: undefined method 
`has_fact_with_value' for #


Looks like the problem is in lib/puppet/rails/inventory_node.rb and the rails 3 
compatibility layer.


-- 
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 #16667] Misleading error message "Not authorized to call find" after upgrading from 2.7 to 3.0

[tickets]

Issue #16667 has been updated by Jeff McCune.

Subject changed from Misleading error message after upgrading from 2.7 to 3.0 
to Misleading error message "Not authorized to call find" after upgrading from 
2.7 to 3.0



Bug #16667: Misleading error message "Not authorized to call find" after 
upgrading from 2.7 to 3.0
https://projects.puppetlabs.com/issues/16667#change-72117

Author: Jeff McCune
Status: Unreviewed
Priority: Normal
Assignee: 
Category: error reporting
Target version: 3.0.x
Affected Puppet version: 3.0.0
Keywords: 
Branch: 


# Overview

When we took out the deprecation warning for the modules path element in source 
URI's of file resources, we didn't replace it with a friendly error message.

# Expected behavior

In 2.7 the following manifest worked, but with this friendly message:


# site.pp
node default {
  notify { "Hello World": }

  file { "/tmp/foo.txt":
source => [
  "puppet:///filetest/sshd_config.${::fqdn}",
  "puppet:///filetest/sshd_config",
],
  }
}



notice: DEPRECATION NOTICE: Files found in modules without specifying 'modules' 
in file path
  will be deprecated in the next major release.  Please fix module 'filetest' 
when no 0.24.x
  clients are present


The behavior I expect is that a similarly friendly and informative error 
message is displayed in 3.0.

# Actual Behavior

In 3.0 this is the user's experience:


$ puppet master --verbose --no-daemonize
Starting Puppet master version 3.0.0Info: Inserting default '~ 
^/catalog/([^/]+)$' (auth true) ACL
Info: Inserting default '~ ^/node/([^/]+)$' (auth true) ACLInfo: Inserting 
default '/file' (auth ) ACL
Info: Inserting default '/certificate_revocation_list/ca' (auth true) ACLInfo: 
Inserting default '/report' (auth true) ACL
Info: Inserting default '/certificate/ca' (auth any) ACL
Info: Inserting default '/certificate/' (auth any) ACL
Info: Inserting default '/certificate_request' (auth any) ACLInfo: Inserting 
default '/status' (auth true) ACL
Compiled catalog for mccune.agent in environment production in 0.03 seconds
Error: Not authorized to call find on 
/file_metadata/filetest/sshd_config.mccune.puppetlabs.lan



-- 
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 #16667] Misleading error message after upgrading from 2.7 to 3.0

[tickets]

Issue #16667 has been updated by Jeff McCune.


(Originally reported to me by bosszaru on the IRC channel.)

Bug #16667: Misleading error message after upgrading from 2.7 to 3.0
https://projects.puppetlabs.com/issues/16667#change-72116

Author: Jeff McCune
Status: Unreviewed
Priority: Normal
Assignee: 
Category: error reporting
Target version: 3.0.x
Affected Puppet version: 3.0.0
Keywords: 
Branch: 


# Overview

When we took out the deprecation warning for the modules path element in source 
URI's of file resources, we didn't replace it with a friendly error message.

# Expected behavior

In 2.7 the following manifest worked, but with this friendly message:


# site.pp
node default {
  notify { "Hello World": }

  file { "/tmp/foo.txt":
source => [
  "puppet:///filetest/sshd_config.${::fqdn}",
  "puppet:///filetest/sshd_config",
],
  }
}



notice: DEPRECATION NOTICE: Files found in modules without specifying 'modules' 
in file path
  will be deprecated in the next major release.  Please fix module 'filetest' 
when no 0.24.x
  clients are present


The behavior I expect is that a similarly friendly and informative error 
message is displayed in 3.0.

# Actual Behavior

In 3.0 this is the user's experience:


$ puppet master --verbose --no-daemonize
Starting Puppet master version 3.0.0Info: Inserting default '~ 
^/catalog/([^/]+)$' (auth true) ACL
Info: Inserting default '~ ^/node/([^/]+)$' (auth true) ACLInfo: Inserting 
default '/file' (auth ) ACL
Info: Inserting default '/certificate_revocation_list/ca' (auth true) ACLInfo: 
Inserting default '/report' (auth true) ACL
Info: Inserting default '/certificate/ca' (auth any) ACL
Info: Inserting default '/certificate/' (auth any) ACL
Info: Inserting default '/certificate_request' (auth any) ACLInfo: Inserting 
default '/status' (auth true) ACL
Compiled catalog for mccune.agent in environment production in 0.03 seconds
Error: Not authorized to call find on 
/file_metadata/filetest/sshd_config.mccune.puppetlabs.lan



-- 
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 #16667] Misleading error message after upgrading from 2.7 to 3.0

[tickets]

Issue #16667 has been updated by Jeff McCune.

Description updated



Bug #16667: Misleading error message after upgrading from 2.7 to 3.0
https://projects.puppetlabs.com/issues/16667#change-72114

Author: Jeff McCune
Status: Unreviewed
Priority: Normal
Assignee: 
Category: error reporting
Target version: 3.0.x
Affected Puppet version: 3.0.0
Keywords: 
Branch: 


# Overview

When we took out the deprecation warning for the modules path element in source 
URI's of file resources, we didn't replace it with a friendly error message.

# Expected behavior

In 2.7 the following manifest worked, but with this friendly message:


# site.pp
node default {
  notify { "Hello World": }

  file { "/tmp/foo.txt":
source => [
  "puppet:///filetest/sshd_config.${::fqdn}",
  "puppet:///filetest/sshd_config",
],
  }
}



notice: DEPRECATION NOTICE: Files found in modules without specifying 'modules' 
in file path
  will be deprecated in the next major release.  Please fix module 'filetest' 
when no 0.24.x
  clients are present


The behavior I expect is that a similarly friendly and informative error 
message is displayed in 3.0.

# Actual Behavior

In 3.0 this is the user's experience:


$ puppet master --verbose --no-daemonize
Starting Puppet master version 3.0.0Info: Inserting default '~ 
^/catalog/([^/]+)$' (auth true) ACL
Info: Inserting default '~ ^/node/([^/]+)$' (auth true) ACLInfo: Inserting 
default '/file' (auth ) ACL
Info: Inserting default '/certificate_revocation_list/ca' (auth true) ACLInfo: 
Inserting default '/report' (auth true) ACL
Info: Inserting default '/certificate/ca' (auth any) ACL
Info: Inserting default '/certificate/' (auth any) ACL
Info: Inserting default '/certificate_request' (auth any) ACLInfo: Inserting 
default '/status' (auth true) ACL
Compiled catalog for mccune.agent in environment production in 0.03 seconds
Error: Not authorized to call find on 
/file_metadata/filetest/sshd_config.mccune.puppetlabs.lan



-- 
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 #16667] (Unreviewed) Misleading error message after upgrading from 2.7 to 3.0

[tickets]

Issue #16667 has been reported by Jeff McCune.


Bug #16667: Misleading error message after upgrading from 2.7 to 3.0
https://projects.puppetlabs.com/issues/16667

Author: Jeff McCune
Status: Unreviewed
Priority: Normal
Assignee: 
Category: error reporting
Target version: 3.0.x
Affected Puppet version: 3.0.0
Keywords: 
Branch: 


# Overview

When we took out the deprecation warning for the modules path element in source 
URI's of file resources, we didn't replace it with a friendly error message.

# Expected behavior

In 2.7 the following manifest worked, but with this friendly message:


# site.pp
node default {
  notify { "Hello World": }

  file { "/tmp/foo.txt":
source => [
  "puppet:///filetest/sshd_config.${::fqdn}",
  "puppet:///filetest/sshd_config",
],
  }
}



notice: DEPRECATION NOTICE: Files found in modules without specifying 'modules' 
in file path
  will be deprecated in the next major release.  Please fix module 'filetest' 
when no 0.24.x
  clients are present


# Actual Behavior

In 3.0 this is the user's experience:


$ puppet master --verbose --no-daemonize
Starting Puppet master version 3.0.0Info: Inserting default '~ 
^/catalog/([^/]+)$' (auth true) ACL
Info: Inserting default '~ ^/node/([^/]+)$' (auth true) ACLInfo: Inserting 
default '/file' (auth ) ACL
Info: Inserting default '/certificate_revocation_list/ca' (auth true) ACLInfo: 
Inserting default '/report' (auth true) ACL
Info: Inserting default '/certificate/ca' (auth any) ACL
Info: Inserting default '/certificate/' (auth any) ACL
Info: Inserting default '/certificate_request' (auth any) ACLInfo: Inserting 
default '/status' (auth true) ACL
Compiled catalog for mccune.agent in environment production in 0.03 seconds
Error: Not authorized to call find on 
/file_metadata/filetest/sshd_config.mccune.puppetlabs.lan



-- 
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 #16665] (Unreviewed) [windows] wrong ipaddress with locale != en

[tickets]

Issue #16665 has been reported by Sebastian Lehn.


Bug #16665: [windows] wrong ipaddress with locale != en
https://projects.puppetlabs.com/issues/16665

Author: Sebastian Lehn
Status: Unreviewed
Priority: Normal
Assignee: 
Category: windows
Target version: 
Keywords: windows, ipaddress, netmask, ipaddress6
Branch: 
Affected Facter version: 1.6.11


# Within module Facter::Util::IP #

   # A map of all the different regexes that work for
   # a given platform or set of platforms.
   REGEX_MAP = {
:windows => {
  :ipaddress  => /\s+IP Address:\s+([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)/,
  :ipaddress6 => /Address 
((?![fe80|::1])(?>[0-9,a-f,A-F]*\:{1,2})+[0-9,a-f,A-F]{0,4})/,
  :netmask  => /\s+Subnet Prefix:\s+\S+\s+\(mask 
([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)\)/
}
   }


Regex contains english strings. That's why facter returns no ip address for 
interfaces and no netmask.



-- 
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] 'Downloading Puppet' wiki page has been updated

[tickets]

The 'Downloading Puppet' wiki page has been updated by Moses Mendoza.


Downloading Puppet:
https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet
View differences:
https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet/diff/208

-- 
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 #16645] (Accepted) puppet module tool fails to resolve dependencies

[tickets]

Issue #16645 has been updated by Ryan Coleman.

Status changed from Unreviewed to Accepted
Assignee set to Ryan Coleman

mrepo expresses its dependency on the puppetlabs apache module like 
'puppetlabs-apache' when it should be 'puppetlabs/apache'. This causes the tool 
to fail.

Short-term fix: Adjust the mrepo 
[[modulefile]https://github.com/puppetlabs/puppetlabs-mrepo/blob/master/Modulefile#L11].
  
Long-term fix: Fix the tool to be forgiving or offer feedback when syntax is 
wrong (no ticket yet). 

Bug #16645: puppet module tool fails to resolve dependencies
https://projects.puppetlabs.com/issues/16645#change-72102

Author: William Van Hevelingen
Status: Accepted
Priority: Normal
Assignee: Ryan Coleman
Category: module tool
Target version: 
Affected Puppet version: 2.7.19
Keywords: 
Branch: 


root@marauder:~# puppet module install puppetlabs-mrepo
Preparing to install into /etc/puppet/modules ...
Downloading from http://forge.puppetlabs.com ...
Error: Could not install module 'puppetlabs-mrepo' (latest: v1.0.0)
  No version of 'puppetlabs-apache' will satisfy dependencies
'puppetlabs-mrepo' (v1.0.0) requires 'puppetlabs-apache' (>= 0.0.3)
Use `puppet module install --ignore-dependencies` to install only this 
module
root@marauder:~# puppet --version
2.7.19



-- 
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 #16274] static compiler doesn't work when a file resource has more than one source URL

[tickets]

Issue #16274 has been updated by Jeff McCune.


# Community update

In an effort to clearly communicate our intentions regarding this bug, here's 
what we're going to do:

In the 3.x series, we'll be addressing "themes" for each of the feature 
releases.  We're almost 100% certain that 3.1 will have the theme of "clean up 
the settings subsystem," but we aren't yet sure what that will exactly entail.  
I am confident, however, that this particular bug will not be included in the 
3.0.x or 3.1.x feature releases.

Regarding the existing pull request, I'm going to close it but reference it 
here: .  Closing the pull 
request does not mean we will not fix this bug, just that the code is 
insufficient to fix the core design problems with the static compiler.

Bug #16274: static compiler doesn't work when a file resource has more than one 
source URL
https://projects.puppetlabs.com/issues/16274#change-72096

Author: Daniel Pittman
Status: Accepted
Priority: Normal
Assignee: 
Category: compiler
Target version: 3.x
Affected Puppet version: 2.6.0
Keywords: 
Branch: 


The static compiler ignores - and, so, uses non-static sourcing for - file 
resources with more than one source:

file { "/tmp/example.txt": source => ["puppet:///foo", "puppet:///bar"] }

It isn't clear to me what the most correct behaviour is:

Should we replace *all* those URL references with content references?  Works 
fine for both `sourceselect => all` and `sourceselect => first`, but may result 
in putting more data in the bucket than is required.  Also, makes it more 
likely that a future change that did more to sync bucket content to agents 
might reveal *more* than should be shown to the machine.  (eg: if we treat 
everything we make static as "target node can access this" we reveal both foo 
and bar, even if only foo should be available.)

Should we try and emulate the file type behaviour?  That works, I guess, but it 
leads to the odd situation where the static compiler and the file type have to 
agree on their behaviour - otherwise we end of diverging between the two.  
Which isn't awesome.  It does mean that we do a static, compilation time 
evaluation of the decision point in the resource, though, which seems like a 
win.

Do we try and defer this until we only have the static compiler (or do it 
preemptively), and allow types to add behaviour that supports this?  (eg: the 
file type has the "can make myself static" feature, and takes ownership of 
doing all this work.)  That has the advantage that any type can be able to be 
made static, not just file.  It has the drawback that it makes more more 
complexity in the type being able to massage itself.

Do we simply force the file type to handle this internally, without cooperation 
from the compiler?  There is no technical reason that can't happen, but it 
means that any other type that wants to be static has to do the same thing.

My personal feeling is that we make the type responsible for "becoming static", 
and adapt the static compiler to respect that.


-- 
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 #16659] (Unreviewed) Namespace segments of custom tags match with the == operator in resource collectors

[tickets]

Issue #16659 has been reported by Nick Chappell.


Bug #16659: Namespace segments of custom tags match with the == operator in 
resource collectors
https://projects.puppetlabs.com/issues/16659

Author: Nick Chappell
Status: Unreviewed
Priority: Normal
Assignee: 
Category: tags
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


If a resource is tagged with a custom tag that has multiple namespace segments 
('tag::specific::more-specific'), individual parts of it are matched with the 
== operator when used in a <| |> resource collector.

Apparently, the intentional behavior of the == operator in resource collectors 
where it matches individual namespace segments from a longer resource or class 
name also gets applied to custom tags that are added by the user.

Just filing a bug report for evaluation by engineering whether this behavior 
will be changed.


-- 
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 #16657] (Unreviewed) puppet cert clean does not work for CSRs with DNS alt names

[tickets]

Issue #16657 has been reported by Ruth Linehan.


Bug #16657: puppet cert clean does not work for CSRs with DNS alt names
https://projects.puppetlabs.com/issues/16657

Author: Ruth Linehan
Status: Unreviewed
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 2.7.19
Keywords: 
Branch: 


On my puppet master on 2.7.19 (PE 2.6.0), if I try to run ``puppet cert clean`` 
on a pending CSR with DNS alt names I get the error 

err: Could not call revoke: Could not find a serial number for node01
Could not find a serial number for node01

On 2.7.12 (PE 2.5.2) I got the same error, but it would still remove the CSR:

err: Could not call revoke: Could not find a serial number for node01
notice: Removing file Puppet::SSL::CertificateRequest node01 at 
'/etc/puppetlabs/puppet/ssl/ca/requests/node01.pem'

This only happens with If it is signed first, then it can be cleaned. 

Furthermore, (thanks nfagerlund for this) it works fine if the CSR was 
submitted by a puppet agent process
using the same ssldir as the puppet master, but it blows up if the CSR came 
from a different node.


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

[tickets]

Issue #16651 has been updated by Jeff McCune.

Keywords set to faces node face subcommand cloud_provisioner



Bug #16651: Installing the cloud provisioner module breaks the node subcommand
https://projects.puppetlabs.com/issues/16651#change-72088

Author: Jeff McCune
Status: Unreviewed
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


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


# 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 #16651] Installing the cloud provisioner module breaks the node subcommand

[tickets]

Issue #16651 has been updated by Jeff McCune.


# Trace


root@pe-centos6:~# puppet help node --trace
Error: Could not autoload puppet/face/node/classify: no such file to load -- 
puppet/cloudpack
/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in 
`gem_original_require'
/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
/etc/puppet/modules/cloud_provisioner/lib/puppet/face/node/classify.rb:1
/usr/lib/ruby/site_ruby/1.8/puppet/util/autoload.rb:68:in `load'
/usr/lib/ruby/site_ruby/1.8/puppet/util/autoload.rb:68:in `load_file'
/usr/lib/ruby/site_ruby/1.8/puppet/util/autoload.rb:83:in `loadall'
/usr/lib/ruby/site_ruby/1.8/puppet/util/autoload.rb:81:in `each'
/usr/lib/ruby/site_ruby/1.8/puppet/util/autoload.rb:81:in `loadall'
/usr/lib/ruby/site_ruby/1.8/puppet/util/autoload.rb:214:in `loadall'
/usr/lib/ruby/site_ruby/1.8/puppet/interface.rb:108:in `load_actions'
/usr/lib/ruby/site_ruby/1.8/puppet/interface.rb:45:in `define'
/usr/lib/ruby/site_ruby/1.8/puppet/face/node.rb:2
/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in 
`gem_original_require'
/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
/usr/lib/ruby/site_ruby/1.8/puppet/interface/face_collection.rb:103:in 
`safely_require'
/usr/lib/ruby/site_ruby/1.8/puppet/interface/face_collection.rb:59:in 
`load_face'
/usr/lib/ruby/site_ruby/1.8/puppet/interface/face_collection.rb:20:in `[]'
/usr/lib/ruby/site_ruby/1.8/puppet/interface.rb:58:in `[]'
/usr/lib/ruby/site_ruby/1.8/puppet/face/help.rb:90:in `load_face_help'
/usr/lib/ruby/site_ruby/1.8/puppet/face/help.rb:84:in `render_face_help'
/usr/lib/ruby/site_ruby/1.8/puppet/face/help.rb:74:in `help implementation, 
required on Ruby 1.8'
/usr/lib/ruby/site_ruby/1.8/puppet/interface/action.rb+eval[wrapper]:210:in 
`__send__'
/usr/lib/ruby/site_ruby/1.8/puppet/interface/action.rb+eval[wrapper]:210:in 
`help'
/usr/lib/ruby/site_ruby/1.8/puppet/application/face_base.rb:229:in `send'
/usr/lib/ruby/site_ruby/1.8/puppet/application/face_base.rb:229:in `main'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:354:in `run_command'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:438:in `plugin_hook'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:500:in `exit_on_fail'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:76:in `execute'
/usr/bin/puppet:10
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"

/usr/lib/ruby/site_ruby/1.8/puppet/face/help.rb:92:in `load_face_help'
/usr/lib/ruby/site_ruby/1.8/puppet/face/help.rb:84:in `render_face_help'
/usr/lib/ruby/site_ruby/1.8/puppet/face/help.rb:74:in `help implementation, 
required on Ruby 1.8'
/usr/lib/ruby/site_ruby/1.8/puppet/interface/action.rb+eval[wrapper]:210:in 
`__send__'
/usr/lib/ruby/site_ruby/1.8/puppet/interface/action.rb+eval[wrapper]:210:in 
`help'
/usr/lib/ruby/site_ruby/1.8/puppet/application/face_base.rb:229:in `send'
/usr/lib/ruby/site_ruby/1.8/puppet/application/face_base.rb:229:in `main'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:354:in `run_command'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:438:in `plugin_hook'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:500:in `exit_on_fail'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:76:in `execute'
/usr/bin/puppet:10
Error: Try 'puppet help help help' for usage


Bug #16651: Installing the cloud provisioner module breaks the node subcommand
https://projects.puppetlabs.com/issues/16651#change-72087

Author: Jeff McCune
Status: Unreviewed
Priority: Normal
Assignee: 
Category: Faces
Target version: 3.0.x
Affected Puppet version: 3.0.0
Keywords: 
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


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


# 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 

[Puppet - Bug #16651] Installing the cloud provisioner module breaks the node subcommand

[tickets]

Issue #16651 has been updated by Jeff McCune.


I've also filed #16651 which specifically calls out the bug we've introduced 
(or rather failed to fix?) in 3.0.0.

I think a new bug is warranted because we're explicitly breaking existing 
functionality on the node subcommand, which is a subtlety not captured in 
#7316, #4248, #14073 or #3947

Bug #16651: Installing the cloud provisioner module breaks the node subcommand
https://projects.puppetlabs.com/issues/16651#change-72086

Author: Jeff McCune
Status: Unreviewed
Priority: Normal
Assignee: 
Category: Faces
Target version: 3.0.x
Affected Puppet version: 3.0.0
Keywords: 
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


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


# 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 #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

[tickets]

Issue #7316 has been updated by Jeff McCune.


I've also filed #16651 which specifically calls out the bug we've introduced 
(or rather failed to fix?) in 3.0.0.

I think a new bug is warranted because we're explicitly breaking existing 
functionality on the node subcommand, which is a subtlety not captured in 
#7316, #4248, #14073 or #3947

Bug #7316: puppet face applications (subcommands) delivered via pluginsync and 
as modules should work
https://projects.puppetlabs.com/issues/7316#change-72085

Author: Dan Bode
Status: In Topic Branch Pending Review
Priority: Normal
Assignee: 
Category: Faces
Target version: 3.0.x
Affected Puppet version: 3.0.0
Keywords: face faces subcommand application module plugin pluginsync
Branch: https://github.com/puppetlabs/puppet/pull/571


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 #16651] (Unreviewed) Installing the cloud provisioner module breaks the node subcommand

[tickets]

Issue #16651 has been reported by Jeff McCune.


Bug #16651: Installing the cloud provisioner module breaks the node subcommand
https://projects.puppetlabs.com/issues/16651

Author: Jeff McCune
Status: Unreviewed
Priority: Normal
Assignee: 
Category: Faces
Target version: 3.0.x
Affected Puppet version: 3.0.0
Keywords: 
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


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


# 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 #7316] (In Topic Branch Pending Review) puppet face applications (subcommands) delivered via pluginsync and as modules should work

[tickets]

Issue #7316 has been updated by Jeff McCune.

Status changed from Re-opened to In Topic Branch Pending Review
Assignee deleted (eric sorenson)
Priority changed from Urgent to Normal
Target version changed from 3.0.0 to 3.0.x
Affected Puppet version set to 3.0.0

We missed the boat for this working for 3.0.0.

Re-targeting against 3.0.x and putting back into a status that reflects reality.

Current pull request:  

There is also a root cause analysis scheduled today for 2PM to 4PM to figure 
out why some of this code has been reverted at least 3 times leading up to the 
3.0.0 release.

Bug #7316: puppet face applications (subcommands) delivered via pluginsync and 
as modules should work
https://projects.puppetlabs.com/issues/7316#change-72081

Author: Dan Bode
Status: In Topic Branch Pending Review
Priority: Normal
Assignee: 
Category: Faces
Target version: 3.0.x
Affected Puppet version: 3.0.0
Keywords: face faces subcommand application module plugin pluginsync
Branch: https://github.com/puppetlabs/puppet/pull/571


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 - Feature #16647] Client-side soft alternative to fail()

[tickets]

Issue #16647 has been updated by Nigel Kersten.


Thinking about this, it doesn't have to require client-side functions.

We could have a function that inserted a resource that always fails into the 
graph at the relevant spot.

Feature #16647: Client-side soft alternative to fail()
https://projects.puppetlabs.com/issues/16647#change-72075

Author: Dan Carley
Status: Needs Decision
Priority: Normal
Assignee: eric sorenson
Category: functions
Target version: 
Affected Puppet version: 
Keywords: soft fail immutable
Branch: 


It would be useful to have a softer alternative to `fail()` which could 
client-side fail individual resources and those that depend on them, rather 
than server-side aborting the entire catalog compilation.

An example use case could be a parameterised class that validates the values it 
receives. If given invalid values then you would want to generate a real error 
and prevent the resources (plus reverse dependencies) from being created or 
modified. But you wouldn't necessarily want to stop the rest of the catalog 
from being enforced in the meantime.


-- 
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 #16647] (Needs Decision) Client-side soft alternative to fail()

[tickets]

Issue #16647 has been updated by Nigel Kersten.

Category set to functions
Status changed from Unreviewed to Needs Decision
Assignee set to eric sorenson



Feature #16647: Client-side soft alternative to fail()
https://projects.puppetlabs.com/issues/16647#change-72071

Author: Dan Carley
Status: Needs Decision
Priority: Normal
Assignee: eric sorenson
Category: functions
Target version: 
Affected Puppet version: 
Keywords: soft fail immutable
Branch: 


It would be useful to have a softer alternative to `fail()` which could 
client-side fail individual resources and those that depend on them, rather 
than server-side aborting the entire catalog compilation.

An example use case could be a parameterised class that validates the values it 
receives. If given invalid values then you would want to generate a real error 
and prevent the resources (plus reverse dependencies) from being created or 
modified. But you wouldn't necessarily want to stop the rest of the catalog 
from being enforced in the meantime.


-- 
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 #16568] (Rejected) Modules added to modulepath aren't recognized until service restart

[tickets]

Issue #16568 has been updated by Jeff McCune.

Status changed from Unreviewed to Rejected

I just tried this on my CentOS 6.2 system with Puppet 3.0.0 from the official 
RPM and it worked exactly as I expected it to.

I followed the steps to reproduce exactly and MediWiki was immediately 
configured.  I didn't get any `Puppet::Parser::AST::Resource` issues.

Let's close this issue and re-open it if anyone runs across this specific 
`Puppet::Parser::AST::Resource` issue after installing a module.

So to be clear, I'm not rejecting this outright, just rejecting it as "unable 
to reproduce" for the time being.  The goal is to reliably reproduce this issue.

-Jeff

Bug #16568: Modules added to modulepath aren't recognized until service restart
https://projects.puppetlabs.com/issues/16568#change-72069

Author: Ryan Coleman
Status: Rejected
Priority: Normal
Assignee: 
Category: 
Target version: 3.0.0
Affected Puppet version: 3.0.0-rc8
Keywords: 
Branch: 


Recreating my working environment (in this specific order):

* Use CentOS 6.0
* Install puppet-server 3.0.0-rc7 from puppetlabs-devel yum repository on 
master, puppet 3.0.0-rc7 on agent
* Install puppetdb module -- `puppet module install puppetlabs-puppetdb`
* Start the puppetmaster service
* Declare puppetdb & puppetdb::master::config class on master and run puppet) 
* Install mediawiki module -- `puppet module install martasd-mediawiki`

Declare the mediawiki class for your agent node, 

class { 'mediawiki':
  server_name  => 'wiki.puppetlabs.vm',
  admin_email  => 'r...@puppetlabs.com',
  db_root_password => 'really_long_password',
  doc_root => '/var/www',
  max_memory   => '1024'
}


* Run Puppet on your agent

I expect you'll run into the error I received. 

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Puppet::Parser::AST::Resource failed with error ArgumentError: Could not find 
declared class mediawiki at /etc/puppet/manifests/site.pp:9 on node 
wiki1.puppetlabs.vm
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run


Additional info:

[root@master modules]# puppet module list
/etc/puppet/modules
├── cprice404-inifile (v0.0.3)
├── inkling-postgresql (v0.3.0)
├── mediawiki (???)
├── puppet-haproxy (v0.0.2)
├── puppetlabs-apache (v0.4.0)
├── puppetlabs-firewall (v0.0.4)
├── puppetlabs-mysql (v0.5.0)
├── puppetlabs-puppetdb (v1.0.3)
├── puppetlabs-stdlib (v3.0.1)
├── ripienaar-concat (v0.2.0)
├── saz-memcached (v2.0.2)
└── stahnma-epel (v0.0.2)
/usr/share/puppet/modules (no modules installed)
[root@master modules]# puppet config print modulepath
/etc/puppet/modules:/usr/share/puppet/modules


Problem is resolved by restarting the puppetmaster service. No amount of 
waiting seems to resolve the issue. 



-- 
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 #16647] Client-side soft alternative to fail()

[tickets]

Issue #16647 has been updated by Dan Carley.


I guess this would require a new attribute being added to resources in the 
catalog.

Feature #16647: Client-side soft alternative to fail()
https://projects.puppetlabs.com/issues/16647#change-72064

Author: Dan Carley
Status: Unreviewed
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: soft fail immutable
Branch: 


It would be useful to have a softer alternative to `fail()` which could 
client-side fail individual resources and those that depend on them, rather 
than server-side aborting the entire catalog compilation.

An example use case could be a parameterised class that validates the values it 
receives. If given invalid values then you would want to generate a real error 
and prevent the resources (plus reverse dependencies) from being created or 
modified. But you wouldn't necessarily want to stop the rest of the catalog 
from being enforced in the meantime.


-- 
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 #16647] (Unreviewed) Client-side soft alternative to fail()

[tickets]

Issue #16647 has been reported by Dan Carley.


Feature #16647: Client-side soft alternative to fail()
https://projects.puppetlabs.com/issues/16647

Author: Dan Carley
Status: Unreviewed
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: soft fail immutable
Branch: 


It would be useful to have a softer alternative to `fail()` which could 
client-side fail individual resources and those that depend on them, rather 
than server-side aborting the entire catalog compilation.

An example use case could be a parameterised class that validates the values it 
receives. If given invalid values then you would want to generate a real error 
and prevent the resources (plus reverse dependencies) from being created or 
modified. But you wouldn't necessarily want to stop the rest of the catalog 
from being enforced in the meantime.


-- 
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 #4022] Crontab environment variables

[tickets]

Issue #4022 has been updated by Justin Ellison.


I've got what I think is an excellent use case for this.

I have several (10+) cron jobs that are java applications.  These cronjobs are 
setup via many different modules.  Usually, these jobs are ran as the same user.

It's nice to be able to set JAVA_HOME=/path/to/java at the top of the crontab 
for the user, and test out new JVM's on all of our jobs with one config change. 
 While we could specify a java_home per job, that seems a bit against DRY.  We 
could also use cron.d, but it's always been our policy to put user-defined 
cronjobs in that user's crontab, so that they can edit them if need be.

Currently, we just drop JAVA_HOME=/path/to/vm at the top of the users crontab, 
and puppet doesn't overwrite it, but it would be a "nice to have" if we could 
manage that with puppet as well.

Feature #4022: Crontab environment variables
https://projects.puppetlabs.com/issues/4022#change-72060

Author: Oliver Hookins
Status: Closed
Priority: Normal
Assignee: Nigel Kersten
Category: cron
Target version: 
Affected Puppet version: 0.25.5
Keywords: 
Branch: 


It would be very useful to be able to specify cron environment variables in the 
Puppet-managed per-user crontabs.

For example:

MAILTO="some...@example.com"

It is possible to add this by hand and Puppet doesn't mess with it, but it 
should be possible to manage this aspect as well with a built in type (rather 
than by Augeas for example).


-- 
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.