[Puppet - Bug #23379] puppet agent 3.4.0-rc1 and windows 7 Professional (DE edition) - Service 'Puppet Agent' (puppet) could not be installed. Verify that you have sufficient privileges to instal sys

[tickets]

Issue #23379 has been updated by Josh Cooper.


Could you include the output of `systeminfo`? Also do you have a link to the 
ISO you used to install?

Also, I have to ask, are you running with elevated privileges?


Bug #23379: puppet agent 3.4.0-rc1 and windows 7 Professional (DE edition) - 
Service 'Puppet Agent' (puppet) could not be installed. Verify that you have 
sufficient privileges to instal system services.
https://projects.puppetlabs.com/issues/23379#change-101338

* Author: Claudiu Vasadi
* Status: Needs More Information
* Priority: Normal
* Assignee: 
* Category: windows
* Target version: 
* Affected Puppet version: 
* Keywords: windows
* Branch: 

All operations were carried out under the Administrator account. Puppet 3.3.2 
was already installed and running. Reboot did not help and neither did removing 
puppet agent 3.3.2 before installing 3.4.0-rc1.

Windows is a fresh install (no other applications installed) and has no SP.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #7659] puppet doc fails if class contains hash

[tickets]

Issue #7659 has been updated by Josh Cooper.

Target version set to 3.5.0
Branch changed from  https://github.com/puppetlabs/puppet/pull/2045 to 
https://github.com/puppetlabs/puppet/pull/2056


Bug #7659: puppet doc fails if class contains hash
https://projects.puppetlabs.com/issues/7659#change-101340

* Author: Joe Crobak
* Status: In Topic Branch Pending Review
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 3.5.0
* Affected Puppet version: 2.6.8
* Keywords: puppetdoc
* Branch: https://github.com/puppetlabs/puppet/pull/2056

here's my test case:

$ cat doc_test.pp 
# Class: doc_test
# 
# Testing docs for a class with a hash
class doc_test {
  $foo = { bar = baz}
}
$ puppet doc --verbose --all doc_test.pp 
info: scanning: [doc_test.pp]
$ cat doc_test2.pp 
# Class: doc_test2
# 
# Testing docs for a class without a hash
class doc_test {
  $foo = bar
}
$ puppet doc --verbose --all doc_test2.pp 
info: scanning: [doc_test2.pp]
Class: doc_test2
Testing docs for a class without a hash

This might be related to #2364.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #20122] function_create_resources drops docstring

[tickets]

Issue #20122 has been updated by Josh Cooper.

Parent task deleted (#7659)


Bug #20122: function_create_resources drops docstring
https://projects.puppetlabs.com/issues/20122#change-101341

* Author: Sebastian Schmidt
* Status: Duplicate
* Priority: Normal
* Assignee: 
* Category: documentation
* Target version: 
* Affected Puppet version: 3.1.1
* Keywords: puppetdoc
* Branch: 

Hi,

I've noticed puppet doc doesn't output anything at all when the manifest is 
using ensure_resource from stdlib. I could track it down to be a parser issue.

Using this script:
precode class=rubyrequire 'puppet'
Puppet[:manifestdir] = '/etc/puppet/manifests'
p = Puppet::Parser::Parser.new(Puppet::Node::Environment.new)
p.file = ARGV[0]
ret = p.parse
puts ret.to_yaml/code/pre

I've dumped the ASTs of two manifests, one using function_create_resource via 
stdlib's ensure_resource and one using a plain resource:
pre
$ cat 1.pp; echo =; ruby dump_ast.rb 1.pp|grep doc: 
# documentation for class foo
class foo {
ensure_resource('package', 'foo', {
ensure = present,
})
}
=
!ruby/sym doc: 
  doc: 
/pre
pre
$ cat 2.pp; echo =; ruby dump_ast.rb 2.pp|grep doc: 
# documentation for class foo
class foo {
package{'foo':
ensure = present,
}
}
=
!ruby/sym doc: documentation for class foo\n
  doc: 
/pre

As other functions, like join() or prefix() from stdlib don't trigger this 
issue I suspect it has to do with create_resources.

I can reproduce this with 2.7.19 and 3.1.1.

Sebastian


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23141] (Merged - Pending Release) OpenBSD mount(8) does not support 'remounts'; adjust mount{} type accordingly

[tickets]

Issue #23141 has been updated by Jasper Lievisse Adriaanse.

Status changed from Tests Insufficient to Merged - Pending Release
Assignee changed from Jasper Lievisse Adriaanse to Kylo Ginsberg
Target version changed from 3.x to 3.4.0
Branch changed from https://github.com/puppetlabs/puppet/pull/2062 to 
https://github.com/puppetlabs/puppet/pull/2140

It seems it did make it into 3.4.0 as ef2f7413512046b8adc30a3f9b7b5586b0d8b341 
through @kylog.


Bug #23141: OpenBSD mount(8) does not support 'remounts'; adjust mount{} type 
accordingly
https://projects.puppetlabs.com/issues/23141#change-101342

* Author: Jasper Lievisse Adriaanse
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: Kylo Ginsberg
* Category: mount
* Target version: 3.4.0
* Affected Puppet version: 
* Keywords: 
* Branch: https://github.com/puppetlabs/puppet/pull/2140

As per subject, this adds OpenBSD to the exclusion list for the remounts 
parameter.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23403] (In Topic Branch Pending Review) Error: Could not intialize global default settings: undefined method `mode=' for #Puppet::Settings::AutosignSetting:0x7ff361614368

[tickets]

Issue #23403 has been updated by Adrien Thebo.

Status changed from Unreviewed to In Topic Branch Pending Review
Branch set to https://github.com/puppetlabs/puppet/pull/2150

It doesn't look like we're going to cut a new RC for this change alone, but if 
there's another reason to do an RC3 then we'll merge it in then. If it doesn't 
make 3.4.0, then we should have it turned around in 3.4.1.


Bug #23403: Error: Could not intialize global default settings: undefined 
method `mode=' for #Puppet::Settings::AutosignSetting:0x7ff361614368
https://projects.puppetlabs.com/issues/23403#change-101343

* Author: Dominic Cleal
* Status: In Topic Branch Pending Review
* Priority: Normal
* Assignee: 
* Category: settings
* Target version: 
* Affected Puppet version: 3.4.0-rc2
* Keywords: 
* Branch: https://github.com/puppetlabs/puppet/pull/2150

Follow-on from #23349... regression from 3.3.x to 3.4.0-rc2.  This affects all 
Foreman users, since it's the default installer configuration 
(https://github.com/theforeman/puppet-puppet/blob/master/templates/puppet.conf.erb#L21).

With this in puppet.conf:
pre
[main]
autosign   = $confdir/autosign.conf { mode = 664 }
/pre

pre
# puppet --version
Error: Could not intialize global default settings: undefined method `mode=' 
for #lt;Puppet::Settings::AutosignSetting:0x7f4b4ecff440gt;
# rpm -q puppet
puppet-3.4.0-0.1rc2.el6.noarch
/pre

Sorry for not including the full puppet.conf entry in the earlier bug report, 
we could have avoided a round trip.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23414] (Unreviewed) puppet module install - strange behaviour using target-dir

[tickets]

Issue #23414 has been reported by Adrián López.


Bug #23414: puppet module install - strange behaviour using target-dir
https://projects.puppetlabs.com/issues/23414

* Author: Adrián López
* Status: Unreviewed
* Priority: Low
* Assignee: 
* Category: module tool
* Target version: 
* Affected Puppet version: 3.3.2
* Keywords: puppet module install --target-dir
* Branch: 

Using puppet as normal user, if I do
puppet module install puppetlabs/apt
It gets installed in ~/.puppet/modules/apt

But if try to download that module to a different dir
~/test/modules$ puppet module install puppetlabs/apt --target-dir .
Error: Could not install module 'puppetlabs-apt' (best)
  Module 'puppetlabs-apt' (v1.4.0) is already installed
Use `puppet module upgrade` to install a different version
Use `puppet module install --force` to re-install only this module

I expect that I could install the module several times if the target dir is 
different.

In fact, if the order is reversed:
~/test/modules$ puppet module install pdxcat/collectd --target-dir .
And then
~/test/modules$ puppet module install pdxcat/collectd
It works correctly



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23141] OpenBSD mount(8) does not support 'remounts'; adjust mount{} type accordingly

[tickets]

Issue #23141 has been updated by Kylo Ginsberg.

Target version changed from 3.4.0 to 3.5.0

Oops forgot to update the target version.  This will come out in 3.5.0.


Bug #23141: OpenBSD mount(8) does not support 'remounts'; adjust mount{} type 
accordingly
https://projects.puppetlabs.com/issues/23141#change-101351

* Author: Jasper Lievisse Adriaanse
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: Kylo Ginsberg
* Category: mount
* Target version: 3.5.0
* Affected Puppet version: 
* Keywords: 
* Branch: https://github.com/puppetlabs/puppet/pull/2140

As per subject, this adds OpenBSD to the exclusion list for the remounts 
parameter.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #7659] (Merged - Pending Release) puppet doc fails if class contains hash

[tickets]

Issue #7659 has been updated by Josh Cooper.

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

Merged into master in commit 
[44f098d](https://github.com/puppetlabs/puppet/commit/44f098d) to be released 
in 3.5.0


Bug #7659: puppet doc fails if class contains hash
https://projects.puppetlabs.com/issues/7659#change-101353

* Author: Joe Crobak
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 3.5.0
* Affected Puppet version: 2.6.8
* Keywords: puppetdoc
* Branch: https://github.com/puppetlabs/puppet/pull/2056

here's my test case:

$ cat doc_test.pp 
# Class: doc_test
# 
# Testing docs for a class with a hash
class doc_test {
  $foo = { bar = baz}
}
$ puppet doc --verbose --all doc_test.pp 
info: scanning: [doc_test.pp]
$ cat doc_test2.pp 
# Class: doc_test2
# 
# Testing docs for a class without a hash
class doc_test {
  $foo = bar
}
$ puppet doc --verbose --all doc_test2.pp 
info: scanning: [doc_test2.pp]
Class: doc_test2
Testing docs for a class without a hash

This might be related to #2364.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23403] (Merged - Pending Release) Error: Could not intialize global default settings: undefined method `mode=' for #Puppet::Settings::AutosignSetting:0x7ff361614368

[tickets]

Issue #23403 has been updated by Josh Cooper.

Status changed from In Topic Branch Pending Review to Merged - Pending Release
Target version set to 3.4.0

Merged in [d3ed8c0](https://github.com/puppetlabs/puppet/commit/d3ed8c0) to be 
released in 3.4.0


Bug #23403: Error: Could not intialize global default settings: undefined 
method `mode=' for #Puppet::Settings::AutosignSetting:0x7ff361614368
https://projects.puppetlabs.com/issues/23403#change-101366

* Author: Dominic Cleal
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: 
* Category: settings
* Target version: 3.4.0
* Affected Puppet version: 3.4.0-rc2
* Keywords: 
* Branch: https://github.com/puppetlabs/puppet/pull/2150

Follow-on from #23349... regression from 3.3.x to 3.4.0-rc2.  This affects all 
Foreman users, since it's the default installer configuration 
(https://github.com/theforeman/puppet-puppet/blob/master/templates/puppet.conf.erb#L21).

With this in puppet.conf:
pre
[main]
autosign   = $confdir/autosign.conf { mode = 664 }
/pre

pre
# puppet --version
Error: Could not intialize global default settings: undefined method `mode=' 
for #lt;Puppet::Settings::AutosignSetting:0x7f4b4ecff440gt;
# rpm -q puppet
puppet-3.4.0-0.1rc2.el6.noarch
/pre

Sorry for not including the full puppet.conf entry in the earlier bug report, 
we could have avoided a round trip.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #4131] resources using parsedfile providers quietly move resources from default file to target with 'puppet resource'

[tickets]

Issue #4131 has been updated by Steven Post.

Affected Puppet version deleted (3.2.1-rc1)

Hi,

I was investigating a failed mount (options = 'rw,bind') and stumbled on this 
bug, which may be related.
The error I'm seeing is:
Error: Puppet::Util::FileType::FileTypeFlat could not read 
/var/app/web: Is a directory - /var/app/web
Error: Could not prefetch mount provider 'parsed': 
Puppet::Util::FileType::FileTypeFlat could not read /var/app/web: Is a 
directory - /var/app/web

The manifest looks like this:
file { '/appl/web':
ensure  = 'directory',
replace = false,
owner   = 'web',
group   = 'web',
mode= '0664',
require = File['/appl']
}
-
file { '/var/app/web':
ensure  = 'directory',
owner   = 'web',
group   = 'web',
mode= '0664',
}
-
mount { '/appl/web':
ensure  = 'mounted',
atboot  = true,
target  = '/var/app/web',
fstype  = 'none',
options = 'rw,bind',
}

Can someone confirm or deny that this is the same/related bug?
Puppet version is 3.2.4, a side effect is that /etc/fstab gets hosed (not good).

I got this from the puppet agent with the --debug option turned on:
Debug: Prefetching parsed resources for mount
Error: Puppet::Util::FileType::FileTypeFlat could not read 
/var/app/web: Is a directory - /var/app/web
Error: Could not prefetch mount provider 'parsed': 
Puppet::Util::FileType::FileTypeFlat could not read /var/app/web: Is a 
directory - /var/app/web
Notice: 
/Stage[main]/Jboss_eap_standalone::Install/Mount[/var/log/jboss-eap-6.1-dpp]/ensure:
 defined 'ensure' as 'mounted'
Debug: Flushing mount provider target /etc/fstab
Debug: Finishing transaction 70363342174320


Other bind mounts which seem to be setup the same do work correctly.

Best regards,
Steven


Bug #4131: resources using parsedfile providers quietly move resources from 
default file to target with 'puppet resource'
https://projects.puppetlabs.com/issues/4131#change-101310

* Author: Dan Bode
* Status: Needs More Information
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 
* Keywords: 
* Branch: 

use the host resource and puppet resource:

I expect the following to fail:

pre
# puppet resource host test1 ensure=present target=/tmp/host 
host_aliases=alias1
notice: /Host[test1]/ensure: created
err: /Host[test1]: Could not evaluate: ip is a required attribute for hosts
host { 'test1':
host_aliases = ['alias1'],
target = '/tmp/host',
ensure = 'present'
}
/pre

If there is already an entry for this host in /etc/hosts (the default target), 
puppet will use the ip address of that host and move it to the new target 
location.

pre
# echo '127.0.0.2 test1' /etc/hosts
[root@puppet2 puppet_spec]# puppet resource host test1 ensure=present 
target=/tmp/host host_aliases=alias1
notice: /Host[test1]/host_aliases: host_aliases changed '' to 'alias1'
notice: /Host[test1]/target: target changed '/etc/hosts' to '/tmp/host'
host { 'test1':
host_aliases = ['alias1'],
target = '/tmp/host',
ensure = 'present'
}
/pre




-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Feature #23396] (Unreviewed) create_resources should apply the same kind of merge_behavior as hiera does

[tickets]

Issue #23396 has been reported by Igor Galić.


Feature #23396: create_resources should apply the same kind of merge_behavior 
as hiera does
https://projects.puppetlabs.com/issues/23396

* Author: Igor Galić
* Status: Unreviewed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 
* Keywords: 
* Branch: 

create_resources() only does a simple merge over the resources and the supplied 
defaults.
It would be very useful if it had the same kind of merge behaviour as hiera 
does, when :merge_behavior is set.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23349] (Closed) Could not find value for $confdir regression when using $confdir in puppet.conf

[tickets]

Issue #23349 has been updated by Melissa Stone.

Status changed from Merged - Pending Release to Closed

Released in Puppet 3.4.0-rc2


Bug #23349: Could not find value for $confdir regression when using $confdir 
in puppet.conf
https://projects.puppetlabs.com/issues/23349#change-101316

* Author: Dominic Cleal
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: settings
* Target version: 3.4.0
* Affected Puppet version: 
* Keywords: 
* Branch: https://github.com/puppetlabs/puppet/pull/2127

This is a regression from 3.3.x to 3.4.0-rc1.

When puppet.conf contains the following:

pre
[main]
autosign = $confdir/autosign.conf
/pre

All puppet commands fail as the $confdir can't be interpolated.

pre
# puppet --version
3.3.2
# puppet apply --configprint autosign
/etc/puppet/autosign.conf
# yum upgrade --enablerepo=puppetlabs-devel puppet
[snip, updated to 3.4.0-rc1]
# rpm -q puppet
puppet-3.4.0-0.1rc1.el6.noarch
# puppet apply --configprint autosign
Error: Could not intialize global default settings: Error converting value for 
param 'autosign': Could not find value for $confdir
# puppet --version
Error: Could not intialize global default settings: Error converting value for 
param 'autosign': Could not find value for $confdir
/pre


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23366] (Closed) Puppet on Windows can fail to run depending on load order

[tickets]

Issue #23366 has been updated by Melissa Stone.

Status changed from Merged - Pending Release to Closed
Affected Puppet version deleted (3.4.0-rc1)

Released in Puppet 3.4.0-rc2


Bug #23366: Puppet on Windows can fail to run depending on load order 
https://projects.puppetlabs.com/issues/23366#change-101317

* Author: Josh Cooper
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 3.4.0
* Affected Puppet version: 
* Keywords: windows
* Branch: https://github.com/puppetlabs/puppet/pull/2128

The Puppet::Util::Windows::Security module doesn't require 'ffi' before using 
it. The gem is required in other places, though so this seems to be dependent 
on the load order.

pre
$ ssh administra...@josh-ny1po54a0o.solar.lan cmd.exe /c puppet agent  --test
C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util/windows/security.rb:635:in 
`lt;module:API': uninitialized constant 
Puppet::Util::Windows::Security::API::FFI (NameError)
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util/windows/security.rb:634:in 
`lt;module:Security'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util/windows/security.rb:77:in 
`lt;top (required)'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util/windows.rb:6:in 
`lt;module:Windows'
from C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util/windows.rb:1:in 
`lt;top (required)'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util/monkey_patches.rb:190:in 
`lt;top (required)'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util.rb:16:in 
`lt;module:Util'
from C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util.rb:15:in 
`lt;module:Puppet'
from C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util.rb:14:in `lt;top 
(required)'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet.rb:8:in `lt;top 
(required)'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util/command_line.rb:12:in `lt;top 
(required)'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from C:/ruby193/bin/puppet:3:in `lt;main'
/pre

The fix is simple, add `require 'ffi'`


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23369] (Closed) An empty csr_attributes.yaml file fails with undefined method

[tickets]

Issue #23369 has been updated by Melissa Stone.

Status changed from Merged - Pending Release to Closed
Affected Puppet version deleted (3.4.0-rc1)

Released in Puppet 3.4.0-rc2


Bug #23369: An empty csr_attributes.yaml file fails with undefined method
https://projects.puppetlabs.com/issues/23369#change-101318

* Author: Josh Cooper
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 3.4.0
* Affected Puppet version: 
* Keywords: 
* Branch: https://github.com/puppetlabs/puppet/pull/2131

See 
https://github.com/jpartlow/puppet/commit/406ca2233dd83700ea688ebc9c7d2980db02a65e


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #21922] Forced to kill and restart Puppet demon after update to 3.2.3

[tickets]

Issue #21922 has been updated by Josh Cooper.

Affected Puppet version changed from 3.3.2 to 3.2.3

We've been looking into this issue, and it is caused when **only** mtime `nsec` 
field changes on an ext4 filesystem. Puppet thinks the file was modified as 
part of the pluginsync, and tries to reload the file. However, that file is 
part of core puppet and should never be reloaded.

We are not sure what is causing **only** the `nsec` field to change.

James, thanks for attaching your facter output. We noticed two important 
differences:

pre
$ diff broken.txt works.txt  | grep -e path -e kernelrelease
 kernelrelease = 2.6.32-358.6.1.el6.x86_64
 kernelrelease = 2.6.32-358.14.1.el6.x86_64
 path = 
/usr/local/rvm/gems/ruby-1.9.3-p194/bin:/usr/local/rvm/gems/ruby-1.9.3-p194@global/bin:/usr/local/rvm/rubies/ruby-1.9.3-p194/bin:/usr/local/rvm/bin:/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/drush:/root/bin
 path = 
 /usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
/pre

The `path` fact returns `ENV['PATH']` so that may not be important. One 
interesting thing is that we're seeing ruby-193 in the path, but facter's 
rubyversion returns 1.8.7.

The `kernelrelease` fact is interesting. Perhaps a kernel bug was fixed between 
those two versions?

Also both systems report using an ext4 filesystem, and that selinux is disabled.

James, could you try upgrading one of your `2.6.32-358.6.1.el6.x86_64` systems 
to `2.6.32-358.14.1.el6.x86_64`?

For anyone else running into this issue, can you:

* attach `facter` output, is there a correlation with `kernelversion`?
* attach `ruby --version` output



Bug #21922: Forced to kill and restart Puppet demon after update to 3.2.3 
https://projects.puppetlabs.com/issues/21922#change-101320

* Author: Vincent Gallissot
* Status: Needs More Information
* Priority: Normal
* Assignee: Vincent Gallissot
* Category: Red Hat
* Target version: 
* Affected Puppet version: 3.2.3
* Keywords: fedora18 puppet3.2.3 class autoload
* Branch: 

I just updated to Puppet 3.2.3-1 using yum.puppetlabs.com as repo. 
It worked fine at the beginning but after a random time, each of my Fedora18 
node became unworking. Here is the error I got in Puppet Dashboard 1.2.23 : 

pre
err Failed to apply catalog: Could not autoload 
puppet/util/instrumentation/listeners/log: Class Log is already defined in 
Puppet::Util::InstrumentationPuppet  2013-07-24 08:12 CEST
err Could not autoload puppet/util/instrumentation/listeners/log: Class Log 
is already defined in Puppet::Util::Instrumentation Puppet  
2013-07-24 08:12 CEST
/pre

It's the same error on every nodes. To repair it, I kill puppet process and 
start it again : systemctl start puppet.service.

The node packages : 

pre
[root@node27 ~]# rpm -qa | egrep (puppet|hiera|facter|ruby)
ruby-1.9.3.448-31.fc18.x86_64
ruby-irb-1.9.3.448-31.fc18.noarch
rubygems-1.8.25-6.fc18.noarch
ruby-libs-1.9.3.448-31.fc18.x86_64
hiera-1.2.1-1.fc18.noarch
ruby-augeas-0.4.1-4.fc18.x86_64
rubygem-io-console-0.3-31.fc18.x86_64
facter-1.7.2-1.fc18.x86_64
libselinux-ruby-2.1.12-7.3.fc18.x86_64
rubygem-json-1.6.8-1.fc18.x86_64
rubygem-rdoc-3.12-6.fc18.noarch
ruby-rgen-0.6.5-1.fc18.noarch
puppet-3.2.3-1.fc18.noarch
ruby-shadow-1.4.1-17.fc18.x86_64
rubygem-bigdecimal-1.1.0-31.fc18.x86_64

OS is Fedora Core 18 x86_64 : 
[root@node27 ~]# uname -r
3.9.6-200.fc18.x86_64
/pre


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Feature #2198] Install multiple package within a single call to the package manager

[tickets]

Issue #2198 has been updated by Zachary Stern.

Keywords changed from communitypatch to communitypatch customer


Feature #2198: Install multiple package within a single call to the package 
manager
https://projects.puppetlabs.com/issues/2198#change-101326

* Author: Stéphan Gorget
* Status: Investigating
* Priority: Normal
* Assignee: 
* Category: transactions
* Target version: 
* Affected Puppet version: 0.25.0
* Keywords: communitypatch customer
* Branch: 
http://github.com/phantez/puppet/commit/51ff88c950c172e6060ae63c1c71968e7898b462

During the configuration applying process the package manager is called for 
each package installation.
It is possible to reduce the number of calls to the package manager by 
gathering package installation and delayed some package installation.
Naturally, this modification should not break the dependency graph.



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #3156] batchable yum and RPM transactions should be batched

[tickets]

Issue #3156 has been updated by Zachary Stern.

Keywords changed from performance yum rpm redhat fedora centos to performance 
yum rpm redhat fedora centos customer


Bug #3156: batchable yum and RPM transactions should be batched
https://projects.puppetlabs.com/issues/3156#change-101324

* Author: Anonymous
* Status: Needs More Information
* Priority: Normal
* Assignee: 
* Category: package
* Target version: 
* Affected Puppet version: 0.25.4
* Keywords: performance yum rpm redhat fedora centos customer
* Branch: 

For users mantaining systems with a lot of managed packages (such as desktop 
configurations), puppet runs can approach 30 minutes plus.

Most of this is due to yum being slow if run multiple times, and it is 
desirable to batch all yum invocations into single yum commands as much as 
possible.

It has been suggested that this also be done for rpmquery so as to not repeat 
it.

We should be able to walk the graph and move the yum/RPM opeartions together in 
a batchable way, and this would help tremendously with run time on 
RHEL/CentOS/Fedora.

(May offer similar savings WRT up2date, though IMHO yum on RHEL4 is a desirable 
practice if you are not a Satellite user.)



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #17014] RHEL 6 Unitialized constant error

[tickets]

Issue #17014 has been updated by Jason Antman.


Just to comment, I'm seeing this same issue on a CentOS 5.5 host where I 
uninstalled PE2.5 and installed puppet open source 3.3.2


Bug #17014: RHEL 6 Unitialized constant error
https://projects.puppetlabs.com/issues/17014#change-101328

* Author: Jared Griffith
* Status: Closed
* Priority: Urgent
* Assignee: 
* Category: agent
* Target version: 
* Affected Puppet version: 3.0.0
* Keywords: RHEL 6, Puppet 3.0
* Branch: 

I have just installed puppet 3.0 agent (with puppetlabs repo and the epel repo) 
on a RHEL6 machine.  Everything installed fine, however when running puppet 
agent -t I get the following error:

pre
WARNING:  #lt;NameError: uninitialized constant Gem::VERSION
# -*- encoding: utf-8 -*-

Gem::Specification.new do |s|
  s.name = %q{json}
  s.version = 1.4.6

  s.required_rubygems_version = Gem::Requirement.new(= 0) if s.respond_to? 
:required_rubygems_version=
  s.authors = [Florian Frank]
  s.date = %q{2010-08-08}
  s.default_executable = %q{edit_json.rb}
  s.description = %q{This is a JSON implementation as a Ruby extension in C.}
  s.email = %q{fl...@ping.de}
  s.executables = [edit_json.rb, prettify_json.rb]
  s.extensions = [ext/json/ext/generator/extconf.rb, 
ext/json/ext/parser/extconf.rb]
  s.extra_rdoc_files = [README]
  s.files = [CHANGES, bin/edit_json.rb, bin/prettify_json.rb, VERSION, 
GPL, TODO, README, benchmarks/ohai.json, 
benchmarks/parser_benchmark.rb, 
benchmarks/data-p4-3GHz-ruby18/ParserBenchmarkPure.log, 
benchmarks/data-p4-3GHz-ruby18/GeneratorBenchmarkComparison.log, 
benchmarks/data-p4-3GHz-ruby18/ParserBenchmarkYAML#parser.dat, 
benchmarks/data-p4-3GHz-ruby18/GeneratorBenchmarkExt#generator_safe.dat, 
benchmarks/data-p4-3GHz-ruby18/ParserBenchmarkExt#parser.dat, 
benchmarks/data-p4-3GHz-ruby18/GeneratorBenchmarkExt#generator_fast.dat, 
benchmarks/data-p4-3GHz-ruby18/GeneratorBenchmarkExt#generator_fast-autocorrelation.dat,
 benchmarks/data-p4-3GHz-ruby18/GeneratorBenchmarkPure.log, 
benchmarks/data-p4-3GHz-ruby18/ParserBenchmarkExt#parser-autocorrelation.dat, 
benchmarks/data-p4-3GHz-ruby18/GeneratorBenchmarkRails#generator-autocorrelation.dat,
 benchmarks/data-p4-3GHz-ruby18/GeneratorBenchmarkExt.log, 
benchmarks/data-p4-3GHz-ruby18/GeneratorBen
 chmarkPure#generator_fast-autocorrelation.dat, 
benchmarks/data-p4-3GHz-ruby18/GeneratorBenchmarkPure#generator_fast.dat, 
benchmarks/data-p4-3GHz-ruby18/ParserBenchmarkRails#parser.dat, 
benchmarks/data-p4-3GHz-ruby18/GeneratorBenchmarkPure#generator_pretty-autocorrelation.dat,
 
benchmarks/data-p4-3GHz-ruby18/ParserBenchmarkPure#parser-autocorrelation.dat,
 benchmarks/data-p4-3GHz-ruby18/GeneratorBenchmarkExt#generator_pretty.dat, 
benchmarks/data-p4-3GHz-ruby18/GeneratorBenchmarkRails.log, 
benchmarks/data-p4-3GHz-ruby18/ParserBenchmarkExt.log, 
benchmarks/data-p4-3GHz-ruby18/ParserBenchmarkRails.log, 
benchmarks/data-p4-3GHz-ruby18/ParserBenchmarkComparison.log, 
benchmarks/data-p4-3GHz-ruby18/GeneratorBenchmarkPure#generator_safe.dat, 
benchmarks/data-p4-3GHz-ruby18/GeneratorBenchmarkRails#generator.dat, 
benchmarks/data-p4-3GHz-ruby18/GeneratorBenchmarkExt#generator_safe-autocorrelation.dat,
 benchmarks/data-p4-3GHz-ruby18/GeneratorBenchmarkPure#generator_p
 retty.dat, benchmarks/data-p4-3GHz-ruby18/ParserBenchmarkYAML.log, 
benchmarks/data-p4-3GHz-ruby18/ParserBenchmarkYAML#parser-autocorrelation.dat,
 
benchmarks/data-p4-3GHz-ruby18/GeneratorBenchmarkExt#generator_pretty-autocorrelation.dat,
 
benchmarks/data-p4-3GHz-ruby18/ParserBenchmarkRails#parser-autocorrelation.dat,
 benchmarks/data-p4-3GHz-ruby18/ParserBenchmarkPure#parser.dat, 
benchmarks/data-p4-3GHz-ruby18/GeneratorBenchmarkPure#generator_safe-autocorrelation.dat,
 benchmarks/generator2_benchmark.rb, benchmarks/generator_benchmark.rb, 
benchmarks/parser2_benchmark.rb, benchmarks/ohai.ruby, 
ext/json/ext/generator/extconf.rb, ext/json/ext/generator/generator.c, 
ext/json/ext/generator/generator.h, ext/json/ext/parser/extconf.rb, 
ext/json/ext/parser/parser.rl, ext/json/ext/parser/parser.h, 
ext/json/ext/parser/parser.c, Rakefile, tools/fuzz.rb, tools/server.rb, 
lib/json.rb, lib/json/json.xpm, lib/json/Key.xpm, lib/json/String.xpm, 
 lib/json/Numeric.xpm, lib/json/Hash.xpm, lib/json/add/rails.rb, 
lib/json/add/core.rb, lib/json/common.rb, lib/json/Array.xpm, 
lib/json/FalseClass.xpm, lib/json/pure/generator.rb, 
lib/json/pure/parser.rb, lib/json/TrueClass.xpm, lib/json/pure.rb, 
lib/json/version.rb, lib/json/ext.rb, lib/json/editor.rb, 
lib/json/NilClass.xpm, data/example.json, data/index.html, 
data/prototype.js, tests/test_json_encoding.rb, 
tests/test_json_addition.rb, tests/fixtures/pass16.json, 
tests/fixtures/fail4.json, tests/fixtures/fail1.json, 
tests/fixtures/fail28.json, tests/fixtures/fail8.json, 
tests/fixtures/fail19.json, tests/fixtures/pass2.json, 
tests/fixtures/pass26.json, tests/fixtures/pass1.json, 

[Puppet] 'Package Management With Dmg Patterns' wiki page has been updated

[tickets]

The 'Package Management With Dmg Patterns' wiki page has been updated by Nick 
Fagerlund.
This info was actually out of date -- the provider no longer works this way. 

Package Management With Dmg Patterns:
https://projects.puppetlabs.com/projects/puppet/wiki/Package_Management_With_Dmg_Patterns
View differences:
https://projects.puppetlabs.com/projects/puppet/wiki/Package_Management_With_Dmg_Patterns/3/diff

-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23379] puppet agent 3.4.0-rc1 and windows 7 Professional (DE edition) - Service 'Puppet Agent' (puppet) could not be installed. Verify that you have sufficient privileges to instal sys

[tickets]

Issue #23379 has been updated by Claudiu Vasadi.


Hi Josh,

Here is the exception:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Could
 not intern from pson: \xE4 on US-ASCII
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/indirector/rest.rb:1
95:in `is_http_200?'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/indirector/rest.rb:1
01:in `find'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/indirector/indirecti
on.rb:201:in `find'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/configurer.rb:256:in
 `block in retrieve_new_catalog'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:327:in `bloc
k in thinmark'
C:/Program Files (x86)/Puppet Labs/Puppet/sys/ruby/lib/ruby/1.9.1/benchmark.rb:2
95:in `realtime'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:326:in `thin
mark'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/configurer.rb:255:in
 `retrieve_new_catalog'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/configurer.rb:69:in
`retrieve_catalog'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/configurer.rb:109:in
 `prepare_and_retrieve_catalog'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/configurer.rb:172:in
 `run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:44:in `bloc
k (4 levels) in run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent/locker.rb:20:i
n `lock'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:44:in `bloc
k (3 levels) in run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:114:in `wit
h_client'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:41:in `bloc
k (2 levels) in run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:79:in `run_
in_fork'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:40:in `bloc
k in run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/application.rb:179:i
n `call'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/application.rb:179:i
n `controlled_run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:38:in `run'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/application/agent.rb
:355:in `onetime'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/application/agent.rb
:321:in `run_command'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/application.rb:364:i
n `block (2 levels) in run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/application.rb:470:i
n `plugin_hook'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/application.rb:364:i
n `block in run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:484:in `exit
_on_fail'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/application.rb:364:i
n `run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util/command_line.rb
:137:in `run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util/command_line.rb
:91:in `execute'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/bin/puppet:4:in `main'
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run


Regarding the COMMON_APPDATA cmd, it completed successfully.

The icacls cmd:
c:\ProgramData\PuppetLabs\puppet\etc\puppet.conf NT-AUTORITÄT\SYSTEM:(I)(F)
 VORDEFINIERT\Administratoren:(I
)(F)
 VORDEFINIERT\Benutzer:(I)(RX)

1 Dateien erfolgreich verarbeitet, bei 0 Dateien ist ein Verarbeitungsfehler auf
getreten.


After running the last 2 cmd's and trying to reinstall the agent, I'm still 
presented with the same error as before :(.


Bug #23379: puppet agent 3.4.0-rc1 and windows 7 Professional (DE edition) - 
Service 'Puppet Agent' (puppet) could not be installed. Verify that you have 
sufficient privileges to instal system services.
https://projects.puppetlabs.com/issues/23379#change-101244

* Author: Claudiu Vasadi
* Status: Needs More Information
* Priority: Normal
* Assignee: 
* Category: windows
* Target version: 
* Affected Puppet version: 
* Keywords: windows
* Branch: 

All operations were carried out under the Administrator account. Puppet 3.3.2 
was already installed and running. Reboot did not help and neither did removing 
puppet agent 3.3.2 before installing 3.4.0-rc1.

Windows is a fresh install (no other applications installed) and has no SP.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop 

[Puppet - Bug #22840] Could not intern from pson: “\xE4” on US-ASCII

[tickets]

Issue #22840 has been updated by Claudiu Vasadi.


Hi,

Here is what I get on the server:

Dec 10 10:53:53 monitoring puppet-master[16284]: Could not intern from pson: 
\xE4 on US-ASCII
Dec 10 10:53:53 monitoring puppet-master[16284]: 
/usr/local/lib/ruby/site_ruby/1.9/puppet/external/pson/pure/parser.rb:138:in 
`encode'
Dec 10 10:53:53 monitoring puppet-master[16284]: 
/usr/local/lib/ruby/site_ruby/1.9/puppet/external/pson/pure/parser.rb:138:in 
`convert_encoding'
Dec 10 10:53:53 monitoring puppet-master[16284]: 
/usr/local/lib/ruby/site_ruby/1.9/puppet/external/pson/pure/parser.rb:69:in 
`initialize'
Dec 10 10:53:53 monitoring puppet-master[16284]: 
/usr/local/lib/ruby/site_ruby/1.9/puppet/external/pson/common.rb:133:in `new'
Dec 10 10:53:53 monitoring puppet-master[16284]: 
/usr/local/lib/ruby/site_ruby/1.9/puppet/external/pson/common.rb:133:in `parse'
Dec 10 10:53:53 monitoring puppet-master[16284]: 
/usr/local/lib/ruby/site_ruby/1.9/puppet/network/formats.rb:122:in `intern'
Dec 10 10:53:53 monitoring puppet-master[16284]: 
/usr/local/lib/ruby/site_ruby/1.9/puppet/network/format_support.rb:11:in 
`convert_from'
Dec 10 10:53:53 monitoring puppet-master[16284]: 
/usr/local/lib/ruby/site_ruby/1.9/puppet/indirector/catalog/compiler.rb:27:in 
`block in extract_facts_from_request'
Dec 10 10:53:53 monitoring puppet-master[16284]: 
/usr/local/lib/ruby/site_ruby/1.9/puppet/util/profiler/none.rb:6:in `profile'
Dec 10 10:53:53 monitoring puppet-master[16284]: 
/usr/local/lib/ruby/site_ruby/1.9/puppet/util/profiler.rb:26:in `profile'
Dec 10 10:53:53 monitoring puppet-master[16284]: 
/usr/local/lib/ruby/site_ruby/1.9/puppet/indirector/catalog/compiler.rb:20:in 
`extract_facts_from_request'
Dec 10 10:53:53 monitoring puppet-master[16284]: 
/usr/local/lib/ruby/site_ruby/1.9/puppet/indirector/catalog/compiler.rb:41:in 
`find'
Dec 10 10:53:53 monitoring puppet-master[16284]: 
/usr/local/lib/ruby/site_ruby/1.9/puppet/indirector/indirection.rb:197:in `find'
Dec 10 10:53:53 monitoring puppet-master[16284]: 
/usr/local/lib/ruby/site_ruby/1.9/puppet/network/http/handler.rb:140:in 
`do_find'
Dec 10 10:53:53 monitoring puppet-master[16284]: 
/usr/local/lib/ruby/site_ruby/1.9/puppet/network/http/handler.rb:97:in `block 
in process'
Dec 10 10:53:53 monitoring puppet-master[16284]: 
/usr/local/lib/ruby/site_ruby/1.9/puppet/util/profiler/none.rb:6:in `profile'
Dec 10 10:53:53 monitoring puppet-master[16284]: 
/usr/local/lib/ruby/site_ruby/1.9/puppet/util/profiler.rb:26:in `profile'
Dec 10 10:53:53 monitoring puppet-master[16284]: 
/usr/local/lib/ruby/site_ruby/1.9/puppet/network/http/handler.rb:91:in `process'
Dec 10 10:53:53 monitoring puppet-master[16284]: 
/usr/local/lib/ruby/site_ruby/1.9/puppet/network/http/webrick/rest.rb:31:in 
`service'
Dec 10 10:53:53 monitoring puppet-master[16284]: 
/usr/local/lib/ruby/1.9/webrick/httpserver.rb:138:in `service'
Dec 10 10:53:53 monitoring puppet-master[16284]: 
/usr/local/lib/ruby/1.9/webrick/httpserver.rb:94:in `run'
Dec 10 10:53:53 monitoring puppet-master[16284]: 
/usr/local/lib/ruby/site_ruby/1.9/puppet/network/http/webrick.rb:35:in `block 
(3 levels) in listen'
Dec 10 10:53:53 monitoring puppet-master[16284]: 
/usr/local/lib/ruby/1.9/webrick/server.rb:191:in `call'
Dec 10 10:53:53 monitoring puppet-master[16284]: 
/usr/local/lib/ruby/1.9/webrick/server.rb:191:in `block in start_thread'


Bug #22840: Could not intern from pson: “\xE4” on US-ASCII
https://projects.puppetlabs.com/issues/22840#change-101245

* Author: Claudiu Vasadi
* Status: Needs More Information
* Priority: Normal
* Assignee: Claudiu Vasadi
* Category: 
* Target version: 
* Affected Puppet version: 
* Keywords: windows
* Branch: 

Puppet master and agent version 3.3.1. The agent is running on a German edition 
of Windows 7 Professional SP1 x64 and the master is running on FreeBSD 9.2 
amd64.

I am getting the following errors from puppet agent console on windows (same 
errors are recorded to the eventlog): 
pre
Error: Could not retrieve catalog from remote server: 
Error 400 on SERVER: Could not intern from pson: “\xE4” on US-ASCII 
Warning: Not using cache on failed catalog 
Error: Could not retrieve catalog; skopping run
/pre

The master reports: 
pre
Could not intern from pson: “\x84” on US-ASCII 
Could not intern from pson: “\xE4” on US-ASCII
/pre

puppet.conf: 
pre
pluginsource = puppet://puppet.local/plugins 
reports = store, http 
reporturl = http://puppet.local:3000/reports/upload
/pre

Trace from puppet agent:
pre
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Could not intern from pson: \xE4 on US-ASCII
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/indirector/rest.rb:194:in `is_http_200?'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/indirector/rest.rb:100:in `find'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/indirector/indirection.rb:197:in `find'

[Puppet - Bug #16840] Default setting for pluginsource problematic for deployments using SRV records

[tickets]

Issue #16840 has been updated by Andrew Rankin.


I've also hit this bug.  I had to defined pluginsource = puppet:///plugins in 
my puppet.conf in order to not get:

[root@puppet0 puppet]# puppet agent --test
Info: Retrieving plugin
Error: /File[/var/lib/puppet/lib]: Failed to generate additional resources 
using 'eval_generate': Connection timed out - connect(2)
Error: Could not retrieve plugin: execution expired

When using SRV records.

Andrew


Bug #16840: Default setting for pluginsource problematic for deployments using 
SRV records
https://projects.puppetlabs.com/issues/16840#change-101260

* Author: Shane Madden
* Status: Investigating
* Priority: Normal
* Assignee: eric sorenson
* Category: 
* Target version: 
* Affected Puppet version: 3.0.0
* Keywords: srv
* Branch: 

The current default for the `pluginsource` setting is 
`puppet://$server/plugins`.  This works well with a `server` set, but in 
deployments that utilize 3.0's SRV record feature, the `server` setting is 
likely not utilized at all for communication with a master, and will often be 
unset.

If SRV records are in use the `pluginsource` still gets filled in with the 
contents of the `server` setting - and if it's unset, then the default is 
`puppet`.  This causes failure of the pluginsync process, which is a non-fatal 
error for the agent run:

Error: /File[/var/lib/puppet/lib]: Failed to generate additional resources 
using 'eval_generate: getaddrinfo: Name or service not known
Error: /File[/var/lib/puppet/lib]: Could not evaluate: getaddrinfo: Name or 
service not known Could not retrieve file metadata for puppet://puppet/plugins: 
getaddrinfo: Name or service not known

I believe that changing the default setting for `pluginsource` from 
`puppet://$server/plugins` to `puppet:///plugins` is functionally equivalent 
for 'normal' deployments not running `use_srv_records`, while it will cause the 
pluginsync process to find a working master in cases where `use_srv_records` is 
utilized.

Simply setting `pluginsource = puppet:///plugins` is an effective workaround 
for SRV record deployments in the interim.



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23219] Windows service doesn't accept extra arguments properly

[tickets]

Issue #23219 has been updated by Rob Reynolds.


I'm actually having trouble starting the service with your changes in 
place...attempting to evaluate why that is now.


Bug #23219: Windows service doesn't accept extra arguments properly
https://projects.puppetlabs.com/issues/23219#change-101266

* Author: Luis Fernandez
* Status: In Topic Branch Pending Review
* Priority: Normal
* Assignee: Luis Fernandez
* Category: windows
* Target version: 
* Affected Puppet version: 3.2.2
* Keywords: windows service
* Branch: https://github.com/puppetlabs/puppet/pull/2094

Checking the code responsible of managing the windows service, there is an 
option to pass extra arguments to the puppet run. 

However, when I try to pass additional parameters (like --masterport=, 
etc), the options are not properly parsed by the service.rb class.

After taking a look to the code, it appears to be easy to fix, so I'll post a 
possible solution for this 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 unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23219] Windows service doesn't accept extra arguments properly

[tickets]

Issue #23219 has been updated by Luis Fernandez.


What kind of problems? I'm using this patch in 3.2.2 and the daemon is working 
fine and I'm able to pass parameters.


Bug #23219: Windows service doesn't accept extra arguments properly
https://projects.puppetlabs.com/issues/23219#change-101268

* Author: Luis Fernandez
* Status: In Topic Branch Pending Review
* Priority: Normal
* Assignee: Luis Fernandez
* Category: windows
* Target version: 
* Affected Puppet version: 3.2.2
* Keywords: windows service
* Branch: https://github.com/puppetlabs/puppet/pull/2094

Checking the code responsible of managing the windows service, there is an 
option to pass extra arguments to the puppet run. 

However, when I try to pass additional parameters (like --masterport=, 
etc), the options are not properly parsed by the service.rb class.

After taking a look to the code, it appears to be easy to fix, so I'll post a 
possible solution for this 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 unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23392] (Unreviewed) No way to set default tags for exported ressources

[tickets]

Issue #23392 has been reported by Laurent Bigonville.


Bug #23392: No way to set default tags for exported ressources
https://projects.puppetlabs.com/issues/23392

* Author: Laurent Bigonville
* Status: Unreviewed
* Priority: Normal
* Assignee: 
* Category: exported resources
* Target version: 
* Affected Puppet version: 3.3.1
* Keywords: 
* Branch: 

Hi,

In our manifest, we are trying to set a default tag for all our Nagios_host, 
to achieve this we are adding the following code in the site.pp:

pre
Nagios_host {
  tag = 'local',
}
/pre

And the somewhere else in our code, we are exporting the resources and the 
trying to collect them using the tag:

pre
@@nagios_host{'foo': params}

Nagios_host | tag == 'local' |
/pre

The problem here is that, nothing is realized because the tag is not exported 
properly, querying puppetdb directly shows the following:

pre
# curl localhost:8080/v3/resources/Nagios_host
[ {
  parameters : {
statusmap_image : os/Ubuntu.png,
action_url : /pnp4nagios/graph?host=$HOSTNAME$,
notifications_enabled : 1,
target : /etc/icinga/objects/hosts/host-mon2.example.com.cfg,
check_command : check-host-alive,
address : 192.168.3.129,
icon_image : os/Ubuntu.png,
notification_period : 24x7,
max_check_attempts : 4,
tag : local,
hostgroups : default,
ensure : present,
icon_image_alt : Ubuntu
  },
  line : 78,
  file : /etc/puppet/environments/prod/modules/icinga/manifests/collect.pp,
  exported : true,
  tags : [ example, default, node, mon2.example.com, icingaclient, 
example::icingaclient, collect, nagios_host, icinga::collect, class, 
icinga ],
  title : mon2.example.com,
  type : Nagios_host,
  resource : 806ed13544851d4ede203cbe3a9eceed6964c5ab,
  certname : mon2.example.com
} ]
/pre

As you can see, the local tag is only present in the parameters part and 
not it tags

If I'm explicitly adding the tag to the resource that will be exported, the tag 
is present in both tag and tags and the resources are properly realized.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #16840] (Accepted) Default setting for pluginsource problematic for deployments using SRV records

[tickets]

Issue #16840 has been updated by Josh Cooper.

Status changed from Investigating to Accepted

That should be trivial to fix by changing defaults.rb, so that it doesn't 
reference `$server`:

pre
:pluginsource = {
  :default= puppet://$server/plugins,
  ...
},
:pluginfactsource = {
  :default  = puppet://$server/pluginfacts,
  ...
/pre



Bug #16840: Default setting for pluginsource problematic for deployments using 
SRV records
https://projects.puppetlabs.com/issues/16840#change-101269

* Author: Shane Madden
* Status: Accepted
* Priority: Normal
* Assignee: eric sorenson
* Category: 
* Target version: 
* Affected Puppet version: 3.0.0
* Keywords: srv
* Branch: 

The current default for the `pluginsource` setting is 
`puppet://$server/plugins`.  This works well with a `server` set, but in 
deployments that utilize 3.0's SRV record feature, the `server` setting is 
likely not utilized at all for communication with a master, and will often be 
unset.

If SRV records are in use the `pluginsource` still gets filled in with the 
contents of the `server` setting - and if it's unset, then the default is 
`puppet`.  This causes failure of the pluginsync process, which is a non-fatal 
error for the agent run:

Error: /File[/var/lib/puppet/lib]: Failed to generate additional resources 
using 'eval_generate: getaddrinfo: Name or service not known
Error: /File[/var/lib/puppet/lib]: Could not evaluate: getaddrinfo: Name or 
service not known Could not retrieve file metadata for puppet://puppet/plugins: 
getaddrinfo: Name or service not known

I believe that changing the default setting for `pluginsource` from 
`puppet://$server/plugins` to `puppet:///plugins` is functionally equivalent 
for 'normal' deployments not running `use_srv_records`, while it will cause the 
pluginsync process to find a working master in cases where `use_srv_records` is 
utilized.

Simply setting `pluginsource = puppet:///plugins` is an effective workaround 
for SRV record deployments in the interim.



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23379] puppet agent 3.4.0-rc1 and windows 7 Professional (DE edition) - Service 'Puppet Agent' (puppet) could not be installed. Verify that you have sufficient privileges to instal sys

[tickets]

Issue #23379 has been updated by Josh Cooper.


Thanks for the info. So the `Could not intern from pson` error is filed as 
#22840. When you say, I'm still presented with the same error as before is 
that the intern from pson error or the Verify you have sufficient privileges 
to install system services error? Assuming it's the latter, could you try 
deleting the `C:\ProgramData\PuppetLabs\puppet` directory and reinstalling. 
Also check the application and system event log to see if there is additional 
information.


Bug #23379: puppet agent 3.4.0-rc1 and windows 7 Professional (DE edition) - 
Service 'Puppet Agent' (puppet) could not be installed. Verify that you have 
sufficient privileges to instal system services.
https://projects.puppetlabs.com/issues/23379#change-101283

* Author: Claudiu Vasadi
* Status: Needs More Information
* Priority: Normal
* Assignee: 
* Category: windows
* Target version: 
* Affected Puppet version: 
* Keywords: windows
* Branch: 

All operations were carried out under the Administrator account. Puppet 3.3.2 
was already installed and running. Reboot did not help and neither did removing 
puppet agent 3.3.2 before installing 3.4.0-rc1.

Windows is a fresh install (no other applications installed) and has no SP.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23311] vardir default in 3.3.2

[tickets]

Issue #23311 has been updated by Felix Frank.


Apparently I was Doing It Wrong.

I now reproduce with both $vardir and $confdir, in either ~/.puppet.conf or 
/etc/puppet/puppet.conf. Bug is triggered with command line arguments as well.


Bug #23311: vardir default in 3.3.2
https://projects.puppetlabs.com/issues/23311#change-101288

* Author: James Eckersall
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 
* Keywords: 
* Branch: 

Hi,

I'm suffering from what looks to be the same or related bug 
http://projects.puppetlabs.com/issues/16637

I have an infrastructure of approximately 500 nodes managed by Puppet.  They 
were all running 2.7.22 and today I've come to upgrade them all to 3.3.2.

The boxes are a mix of CentOS and RedHat, EL5 and EL6.

We manage Puppet with Puppet, so today I updated the manifest to point to the 
updated rpm's in the repo and let it rip.

Most of my nodes are now failing to even start Puppet with the following error:

Error: Could not intialize global default settings: Error converting value for 
param 'factpath': Could not find value for $vardir

If I add the below line to /etc/puppet/puppet.conf, all is good with the world.
vardir = /var/lib/puppet

That line did not previously exist in the puppet.conf file, so it looks like 
the upgrade to 3.3.2 has introduced this bug.

Now I'm faced with the unpleasant task of manually deploying a script to each 
node to insert that line as Puppet now refuses to start on my nodes.

I can easily replicate this.  Remove that line from puppet.conf and the agent 
will not start (service puppet start or puppet agent --test as root).

J


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23349] Could not find value for $confdir regression when using $confdir in puppet.conf

[tickets]

Issue #23349 has been updated by Felix Frank.

Affected Puppet version deleted (3.4.0-rc1)

Ach! Guys, this is a duplicate of 23311. Way to make a man fear for his sanity 
after a pull ;-p


Bug #23349: Could not find value for $confdir regression when using $confdir 
in puppet.conf
https://projects.puppetlabs.com/issues/23349#change-101299

* Author: Dominic Cleal
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: 
* Category: settings
* Target version: 3.4.0
* Affected Puppet version: 
* Keywords: 
* Branch: https://github.com/puppetlabs/puppet/pull/2127

This is a regression from 3.3.x to 3.4.0-rc1.

When puppet.conf contains the following:

pre
[main]
autosign = $confdir/autosign.conf
/pre

All puppet commands fail as the $confdir can't be interpolated.

pre
# puppet --version
3.3.2
# puppet apply --configprint autosign
/etc/puppet/autosign.conf
# yum upgrade --enablerepo=puppetlabs-devel puppet
[snip, updated to 3.4.0-rc1]
# rpm -q puppet
puppet-3.4.0-0.1rc1.el6.noarch
# puppet apply --configprint autosign
Error: Could not intialize global default settings: Error converting value for 
param 'autosign': Could not find value for $confdir
# puppet --version
Error: Could not intialize global default settings: Error converting value for 
param 'autosign': Could not find value for $confdir
/pre


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23311] (Duplicate) vardir default in 3.3.2

[tickets]

Issue #23311 has been updated by Felix Frank.

Status changed from Accepted to Duplicate
Target version set to 3.4.0

Turns out the duplicate #23349 has been created in the meantime and already 
solved. The fix will be released with 3.4.0.

Trying to mark this as a duplicate, although it's technically not true.


Bug #23311: vardir default in 3.3.2
https://projects.puppetlabs.com/issues/23311#change-101300

* Author: James Eckersall
* Status: Duplicate
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 3.4.0
* Affected Puppet version: 
* Keywords: 
* Branch: 

Hi,

I'm suffering from what looks to be the same or related bug 
http://projects.puppetlabs.com/issues/16637

I have an infrastructure of approximately 500 nodes managed by Puppet.  They 
were all running 2.7.22 and today I've come to upgrade them all to 3.3.2.

The boxes are a mix of CentOS and RedHat, EL5 and EL6.

We manage Puppet with Puppet, so today I updated the manifest to point to the 
updated rpm's in the repo and let it rip.

Most of my nodes are now failing to even start Puppet with the following error:

Error: Could not intialize global default settings: Error converting value for 
param 'factpath': Could not find value for $vardir

If I add the below line to /etc/puppet/puppet.conf, all is good with the world.
vardir = /var/lib/puppet

That line did not previously exist in the puppet.conf file, so it looks like 
the upgrade to 3.3.2 has introduced this bug.

Now I'm faced with the unpleasant task of manually deploying a script to each 
node to insert that line as Puppet now refuses to start on my nodes.

I can easily replicate this.  Remove that line from puppet.conf and the agent 
will not start (service puppet start or puppet agent --test as root).

J


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23379] (Unreviewed) puppet agent 3.4.0-rc1 and windows 7 Professional (DE edition) - Service 'Puppet Agent' (puppet) could not be installed. Verify that you have sufficient privileges

[tickets]

Issue #23379 has been reported by Claudiu Vasadi.


Bug #23379: puppet agent 3.4.0-rc1 and windows 7 Professional (DE edition) - 
Service 'Puppet Agent' (puppet) could not be installed. Verify that you have 
sufficient privileges to instal system services.
https://projects.puppetlabs.com/issues/23379

* Author: Claudiu Vasadi
* Status: Unreviewed
* Priority: Normal
* Assignee: 
* Category: windows
* Target version: 
* Affected Puppet version: 
* Keywords: 
* Branch: 

All operations were carried out under the Administrator account. Puppet 3.3.2 
was already installed and running. Reboot did not help and neither did removing 
puppet agent 3.3.2 before installing 3.4.0-rc1.

Windows is a fresh install (no other applications installed) and has no SP.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Feature #23316] Add support for 'held' ensure value to Yum provider by using yum-versionlock.

[tickets]

Issue #23316 has been updated by Gavin Williams.

Branch set to https://github.com/puppetlabs/puppet/pull/2137

Pull request submitted. 


Feature #23316: Add support for 'held' ensure value to Yum provider by using 
yum-versionlock. 
https://projects.puppetlabs.com/issues/23316#change-101188

* Author: Gavin Williams
* Status: Unreviewed
* Priority: Normal
* Assignee: 
* Category: provider
* Target version: 
* Affected Puppet version: 
* Keywords: yum, package, provider, versionlock, held
* Branch: https://github.com/puppetlabs/puppet/pull/2137

Add support for holding packages using `ensure = held` on the Yum package 
provider by utilising the 'yum-versionlock' plugin. 


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23372] FreeBSD: Puppet triggers loading of ZFS module

[tickets]

Issue #23372 has been updated by Remko Catersels.

Category set to FreeBSD


Bug #23372: FreeBSD: Puppet triggers loading of ZFS module
https://projects.puppetlabs.com/issues/23372#change-101189

* Author: Remko Catersels
* Status: Unreviewed
* Priority: Normal
* Assignee: 
* Category: FreeBSD
* Target version: 
* Affected Puppet version: 3.3.1
* Keywords: 
* Branch: 

When puppet starts the puppet ZFS provider issues the zfs command. On FreeBSD 
this automatically loads the ZFS kernel module. Even when ZFS is not used on 
that host. The provider should first check if ZFS is enabled or not. If it's 
not enabled it shouldn't execute any zpool or zfs commands as those will 
trigger the automatic load of the kernel module. 


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #3118] (Rejected) Default node definition should not be required when ENC returns a node definition.

[tickets]

Issue #3118 has been updated by Andrew Parker.

Status changed from Accepted to Rejected

As Alex says, this ticket has been open for a long time. This is behavior that 
is wanted by some and unwanted by others; however, I don't see us changing this 
any time soon.


Bug #3118: Default node definition should not be required when ENC returns a 
node definition.
https://projects.puppetlabs.com/issues/3118#change-101195

* Author: Markus Roberts
* Status: Rejected
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 0.24.8
* Keywords: 
* Branch: 

This behavior is surprising, but not new.

Given the external node tool:

pre
#!/usr/bin/env ruby
print %q{
---
classes:
  - foo
}
exit 0
/pre

And site.pp:

pre
class foo {
notice foo
}

class bar {
notice bar
}

node default {
include bar
}
/pre

The following results are seen:

pre
info: Caching node for host-246-104.pubnet.pdx.edu
notice: Scope(Class[bar]): bar
notice: Scope(Class[foo]): foo
notice: Compiled catalog for host-246-104.pubnet.pdx.edu in 0.01 seconds
/pre

The same results are seen with 0.24.8 and 0.25.4rc3.

This appears to break the assumption that default is only applied for nodes 
that aren't otherwise defined.  The same is seen with an explicit node instead 
of just default in site.pp




-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Feature #23373] Command line manipulation of puppet.conf

[tickets]

Issue #23373 has been updated by Josh Partlow.


First PR https://github.com/puppetlabs/puppet/pull/2138


Feature #23373: Command line manipulation of puppet.conf
https://projects.puppetlabs.com/issues/23373#change-101197

* Author: Andrew Parker
* Status: Accepted
* Priority: Normal
* Assignee: Andrew Parker
* Category: 
* Target version: 3.5.0
* Affected Puppet version: 
* Keywords: 
* Branch: 

In order to more easily support setting up new agents, it would be useful to 
have a simple command which could be used to configure the agent.
Something like `puppet config set server=puppet.example.com` would work great. 
The big open question with it is how to support sections in the presence of run 
modes. The simplest seems to be to just ignore run modes (since they don't have 
a bidirectional mapping with sections) and provide an explicit `--section` flag 
(probably with a default of `main`).
The end goal is to be able to easily build an agent install script which looks 
something like this:

pre
yum install -y puppet
puppet config set certname=$(hostname -f)
puppet config set server=puppet.example.com
puppet config set environment=test
puppet resource service puppet ensure=running enable=true
/pre


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter] 'Wiki' wiki page has been updated

[tickets]

The 'Wiki' wiki page has been updated by Nick Fagerlund.
Move release notes into main docs

Wiki:
https://projects.puppetlabs.com/projects/facter/wiki/Wiki
View differences:
https://projects.puppetlabs.com/projects/facter/wiki/Wiki/68/diff

-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter - Bug #23384] (Merged - Pending Release) Man pages are missing in Debian lucid and older

[tickets]

Issue #23384 has been reported by Josh Cooper.


Bug #23384: Man pages are missing in Debian lucid and older
https://projects.puppetlabs.com/issues/23384

* Author: Josh Cooper
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 1.7.4
* Keywords: 
* Branch: https://github.com/puppetlabs/facter/pull/565
* Affected Facter version: 




-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter - Bug #23384] Man pages are missing in Debian lucid and older

[tickets]

Issue #23384 has been updated by Josh Cooper.


See FACT-104


Bug #23384: Man pages are missing in Debian lucid and older
https://projects.puppetlabs.com/issues/23384#change-101198

* Author: Josh Cooper
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 1.7.4
* Keywords: 
* Branch: https://github.com/puppetlabs/facter/pull/565
* Affected Facter version: 




-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Feature #23373] (Merged - Pending Release) Command line manipulation of puppet.conf

[tickets]

Issue #23373 has been updated by Rob Reynolds.

Status changed from Accepted to Merged - Pending Release

Merged in 
[c038342](https://github.com/puppetlabs/puppet/commit/c038342d5c75986034dc5d662622157938befbae)


Feature #23373: Command line manipulation of puppet.conf
https://projects.puppetlabs.com/issues/23373#change-101199

* Author: Andrew Parker
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: Andrew Parker
* Category: 
* Target version: 3.5.0
* Affected Puppet version: 
* Keywords: 
* Branch: 

In order to more easily support setting up new agents, it would be useful to 
have a simple command which could be used to configure the agent.
Something like `puppet config set server=puppet.example.com` would work great. 
The big open question with it is how to support sections in the presence of run 
modes. The simplest seems to be to just ignore run modes (since they don't have 
a bidirectional mapping with sections) and provide an explicit `--section` flag 
(probably with a default of `main`).
The end goal is to be able to easily build an agent install script which looks 
something like this:

pre
yum install -y puppet
puppet config set certname=$(hostname -f)
puppet config set server=puppet.example.com
puppet config set environment=test
puppet resource service puppet ensure=running enable=true
/pre


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Feature #23373] Command line manipulation of puppet.conf

[tickets]

Issue #23373 has been updated by Rob Reynolds.

Branch set to https://github.com/puppetlabs/puppet/pull/2138


Feature #23373: Command line manipulation of puppet.conf
https://projects.puppetlabs.com/issues/23373#change-101201

* Author: Andrew Parker
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: Andrew Parker
* Category: 
* Target version: 3.5.0
* Affected Puppet version: 
* Keywords: 
* Branch: https://github.com/puppetlabs/puppet/pull/2138

In order to more easily support setting up new agents, it would be useful to 
have a simple command which could be used to configure the agent.
Something like `puppet config set server=puppet.example.com` would work great. 
The big open question with it is how to support sections in the presence of run 
modes. The simplest seems to be to just ignore run modes (since they don't have 
a bidirectional mapping with sections) and provide an explicit `--section` flag 
(probably with a default of `main`).
The end goal is to be able to easily build an agent install script which looks 
something like this:

pre
yum install -y puppet
puppet config set certname=$(hostname -f)
puppet config set server=puppet.example.com
puppet config set environment=test
puppet resource service puppet ensure=running enable=true
/pre


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23385] (Unreviewed) ec2_userdata not useable in confine

[tickets]

Issue #23385 has been reported by Daniel Kasen.


Bug #23385: ec2_userdata not useable in confine
https://projects.puppetlabs.com/issues/23385

* Author: Daniel Kasen
* Status: Unreviewed
* Priority: Normal
* Assignee: 
* Category: facter
* Target version: 3.3.2
* Affected Puppet version: 3.3.2
* Keywords: 
* Branch: 

facter ec2_userdata returns the user string passed when the instance was 
brought up, but trying to use confine :ec2_userdata = type seems to always 
return false so one cannot generate another custom fact based off of that 
value. I have tried replacing the confine with other facts and it works fine. I 
have also tried creating a new value using Facter::Util::Resolution.exec(echo 
$(facter ec2_userdata)) and passing that to the confine and it will work as 
expected. I am assuming there is some odd hidden characters messing up the 
check, but cannot verify. This is on a centos 6.4 HVM machine in AWS.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23379] puppet agent 3.4.0-rc1 and windows 7 Professional (DE edition) - Service 'Puppet Agent' (puppet) could not be installed. Verify that you have sufficient privileges to instal sys

[tickets]

Issue #23379 has been updated by Andrew Parker.

Affected Puppet version set to 3.4.0-rc1


Bug #23379: puppet agent 3.4.0-rc1 and windows 7 Professional (DE edition) - 
Service 'Puppet Agent' (puppet) could not be installed. Verify that you have 
sufficient privileges to instal system services.
https://projects.puppetlabs.com/issues/23379#change-101209

* Author: Claudiu Vasadi
* Status: Unreviewed
* Priority: Normal
* Assignee: 
* Category: windows
* Target version: 
* Affected Puppet version: 3.4.0-rc1
* Keywords: 
* Branch: 

All operations were carried out under the Administrator account. Puppet 3.3.2 
was already installed and running. Reboot did not help and neither did removing 
puppet agent 3.3.2 before installing 3.4.0-rc1.

Windows is a fresh install (no other applications installed) and has no SP.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23379] (Needs More Information) puppet agent 3.4.0-rc1 and windows 7 Professional (DE edition) - Service 'Puppet Agent' (puppet) could not be installed. Verify that you have sufficient

[tickets]

Issue #23379 has been updated by Josh Cooper.

Status changed from Unreviewed to Needs More Information

Hi Claudiu,

Can you try installing 3.4.0-rc1, and when the dialog box appears that says, 
Service 'Puppet Agent' (puppet) could not be installed, don't click OK. Then 
open a command prompt, go to `C:\Program Files (x86)\Puppet Labs\Puppet\bin` 
and try running `puppet agent --test --debug --trace`? If you see an exception, 
please paste that into the ticket.

Another option is that the `win32-dir` gem is having difficulty resolving the 
COMMON_APPDATA directory on your system, e.g. 
https://projects.puppetlabs.com/issues/23185#note-5. To verify if this is the 
problem, do the following (while the dialog box above is still visible):

pre
C:\Program Files (x86)\Puppet Labs\Puppet\sys\ruby\binruby -e require 
'win32/dir'; puts Dir::COMMON_APPDATA
/pre

Another possibility is that the service is not able to access the 
files/directories within the `COMMON_APPDATA` directory. Could you try running 
the following and pasting the output in the ticket:

pre
C:\icacls C:\ProgramData\PuppetLabs\puppet\etc\puppet.conf
/pre

Next, when running as an Administrator, can you try executing:

pre
C:\takeown /f c:\programdata\puppetlabs\puppet /r
C:\icacls c:\programdata\puppetlabs\puppet /reset /t
/pre

Then try installing puppet 3.4.0-rc1 again.


Bug #23379: puppet agent 3.4.0-rc1 and windows 7 Professional (DE edition) - 
Service 'Puppet Agent' (puppet) could not be installed. Verify that you have 
sufficient privileges to instal system services.
https://projects.puppetlabs.com/issues/23379#change-101210

* Author: Claudiu Vasadi
* Status: Needs More Information
* Priority: Normal
* Assignee: 
* Category: windows
* Target version: 
* Affected Puppet version: 3.4.0-rc1
* Keywords: 
* Branch: 

All operations were carried out under the Administrator account. Puppet 3.3.2 
was already installed and running. Reboot did not help and neither did removing 
puppet agent 3.3.2 before installing 3.4.0-rc1.

Windows is a fresh install (no other applications installed) and has no SP.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter - Bug #22619] (Closed) Error when NetConnectionId is missing on NetworkAdapter

[tickets]

Issue #22619 has been updated by Melissa Stone.

Status changed from Merged - Pending Release to Closed

Release in Facter 1.7.4-rc1


Bug #22619: Error when NetConnectionId is missing on NetworkAdapter
https://projects.puppetlabs.com/issues/22619#change-101222

* Author: Rob Reynolds
* Status: Closed
* Priority: Normal
* Assignee: Rob Reynolds
* Category: 
* Target version: 1.7.4
* Keywords: windows
* Branch: https://github.com/puppetlabs/facter/pull/537
* Affected Facter version: 1.7.3

When someone has a network configuration that has IPEnabled set to true, it 
doesn't necessarily mean the Network Adapter behind it also has NetEnabled set 
to true. The latest release of facter (1.7.3) introduced a bug that causes 
puppet to error when gathering facts about the interfaces if someone has such a 
configuration on their system.

Output from WMI queries on an affected system:  

 - https://gist.github.com/anonymous/15c1e09eca5b7c42e29e
 - https://gist.github.com/anonymous/810f922a3a40bfbe863f

Match each of them up by Index (as we do here: 
https://github.com/puppetlabs/facter/blob/stable/lib/facter/util/ip/windows.rb#L46-L47
 )

 - Index=7 (Server_LAN)
 - Index=12 (Replication)
 - Index=14 (Backup-LAN)
 - Index=16 (no NetConnectionID) (the network config has IPEnabled, but the 
adapter does not have NetEnabled)

The offender is Microsoft Failover Cluster Virtual Adapter

pre
C:\puppet\binpuppet agent --test --debug --trace 
Error: Could not retrieve local facts: undefined method `gsub' for nil:NilClass
C:/puppet/facter/lib/facter/util/ip.rb:39:in `alphafy'
C:/puppet/facter/lib/facter/interfaces.rb:35:in `block (2 levels) in top 
(required)'
C:/puppet/facter/lib/facter/interfaces.rb:34:in `each'
C:/puppet/facter/lib/facter/interfaces.rb:34:in `block in top (required)'
C:/puppet/facter/lib/facter/interfaces.rb:29:in `each'
C:/puppet/facter/lib/facter/interfaces.rb:29:in `top (required)'
C:/puppet/facter/lib/facter/util/loader.rb:95:in `load'
C:/puppet/facter/lib/facter/util/loader.rb:95:in `load_file'
C:/puppet/facter/lib/facter/util/loader.rb:46:in `block (2 levels) in load_all'
C:/puppet/facter/lib/facter/util/loader.rb:41:in `each'
C:/puppet/facter/lib/facter/util/loader.rb:41:in `block in load_all'
C:/puppet/facter/lib/facter/util/loader.rb:38:in `each'
C:/puppet/facter/lib/facter/util/loader.rb:38:in `load_all'
C:/puppet/facter/lib/facter/util/collection.rb:114:in `load_all'
C:/puppet/facter/lib/facter.rb:248:in `loadfacts'
C:/puppet/puppet/lib/puppet/indirector/facts/facter.rb:11:in `reload_facter'
C:/puppet/puppet/lib/puppet/indirector/facts/facter.rb:53:in `find'
C:/puppet/puppet/lib/puppet/indirector/indirection.rb:197:in `find'
C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:15:in `find_facts'
C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:31:in 
`facts_for_uploading'
C:/puppet/puppet/lib/puppet/configurer.rb:101:in `get_facts'
C:/puppet/puppet/lib/puppet/configurer.rb:164:in `run'
C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (5 levels) in run'
C:/puppet/puppet/lib/puppet/agent/locker.rb:20:in `lock'
C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (4 levels) in run'
C:/puppet/sys/ruby/lib/ruby/1.9.1/sync.rb:227:in `sync_synchronize'
C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (3 levels) in run'
C:/puppet/puppet/lib/puppet/agent.rb:119:in `with_client'
C:/puppet/puppet/lib/puppet/agent.rb:42:in `block (2 levels) in run'
C:/puppet/puppet/lib/puppet/agent.rb:84:in `run_in_fork'
C:/puppet/puppet/lib/puppet/agent.rb:41:in `block in run'
C:/puppet/puppet/lib/puppet/application.rb:179:in `call'
C:/puppet/puppet/lib/puppet/application.rb:179:in `controlled_run'
C:/puppet/puppet/lib/puppet/agent.rb:39:in `run'
C:/puppet/puppet/lib/puppet/application/agent.rb:360:in `onetime'
C:/puppet/puppet/lib/puppet/application/agent.rb:326:in `run_command'
C:/puppet/puppet/lib/puppet/application.rb:364:in `block (2 levels) in run'
C:/puppet/puppet/lib/puppet/application.rb:457:in `plugin_hook'
C:/puppet/puppet/lib/puppet/application.rb:364:in `block in run'
C:/puppet/puppet/lib/puppet/util.rb:511:in `exit_on_fail'
C:/puppet/puppet/lib/puppet/application.rb:364:in `run'
C:/puppet/puppet/lib/puppet/util/command_line.rb:132:in `run'
C:/puppet/puppet/lib/puppet/util/command_line.rb:86:in `execute'
C:/puppet/puppet/bin/puppet:4:in `lt;main'
Error: Failed to apply catalog: Could not retrieve local facts: undefined 
method `gsub' for nil:NilClass
C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:26:in `rescue in 
find_facts'
C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:14:in `find_facts'
C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:31:in 
`facts_for_uploading'
C:/puppet/puppet/lib/puppet/configurer.rb:101:in `get_facts'
C:/puppet/puppet/lib/puppet/configurer.rb:164:in `run'
C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (5 levels) in run'
C:/puppet/puppet/lib/puppet/agent/locker.rb:20:in 

[Facter - Bug #16081] (Closed) Facter reports bogus arch on AIX

[tickets]

Issue #16081 has been updated by Melissa Stone.

Status changed from Merged - Pending Release to Closed

Release in Facter 1.7.4-rc1


Bug #16081: Facter reports bogus arch on AIX
https://projects.puppetlabs.com/issues/16081#change-101214

* Author: Matthaus Owens
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: library
* Target version: 1.7.4
* Keywords: 
* Branch: https://github.com/puppetlabs/facter/pull/532
* Affected Facter version: 

root@l488pp139_pub[/software/pe-aix/init]  /opt/puppet/bin/facter
architecture = IBM,9179-MHB


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter - Bug #20739] (Closed) processorX facts fail on HP superdome servers

[tickets]

Issue #20739 has been updated by Melissa Stone.

Status changed from Merged - Pending Release to Closed

Release in Facter 1.7.4-rc1


Bug #20739: processorX facts fail on HP superdome servers
https://projects.puppetlabs.com/issues/20739#change-101216

* Author: Anonymous
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: hpux
* Target version: 1.7.4
* Keywords: 
* Branch: https://github.com/puppetlabs/facter/pull/368
* Affected Facter version: 1.7.1

This was originally ticket #17894, creating a new ticket for it since the old 
one was deleted but we still need to resolve this issue.

We had a pull request for this at one point, but it seems to be gone from 
GitHub, so I'll mark this as Code Insufficient.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter - Bug #20994] (Closed) memoryfree and memorysize facts are set to 0 on AIX

[tickets]

Issue #20994 has been updated by Melissa Stone.

Status changed from Merged - Pending Release to Closed

Release in Facter 1.7.4-rc1


Bug #20994: memoryfree and memorysize facts are set to 0 on AIX
https://projects.puppetlabs.com/issues/20994#change-101217

* Author: Aran Cox
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: library
* Target version: 1.7.4
* Keywords: AIX
* Branch: https://github.com/puppetlabs/facter/pull/448
* Affected Facter version: development

Previous versions of facter 1.6.8 simply didn't have memoryfree and memorysize 
facts for AIX.
Starting with 1.7.1 (or possibly some other intermediate vesion) the memoryfree 
and memorysize variables are being set to 0, which is worse than not having 
them.

This also affects the head of the master branch.  It does not matter if facter 
is run as root or not, the result is the same:

# uname;oslevel;facter --puppet memoryfree memoryfree_mb memorysize 
memorysize_mb memorytotal
AIX
6.1.0.0
memoryfree = 0.00 MB
memoryfree_mb = 0.00
memorysize = 0.00 MB
memorysize_mb = 0.00
memorytotal = 0.00 MB



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter - Bug #12504] (Closed) operatingsystemrelease doesn't work for Ubuntu LTS 12.04

[tickets]

Issue #12504 has been updated by Melissa Stone.

Status changed from Merged - Pending Release to Closed

Release in Facter 1.7.4-rc1


Bug #12504: operatingsystemrelease doesn't work for Ubuntu LTS 12.04
https://projects.puppetlabs.com/issues/12504#change-101212

* Author: Ken Barber
* Status: Closed
* Priority: Low
* Assignee: 
* Category: library
* Target version: 1.7.4
* Keywords: 
* Branch: 
* Affected Facter version: 1.6.5

As mentioned in #11658, /etc/issue seems to have changed so now 
operatingsystemrelease doesn't seem to work any more on Ubuntu LTS 12.04.

We'll need to confirm the details, but it looks like this is real.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter - Bug #15586] (Closed) 'facter --help' does not work with Ruby 1.9.3

[tickets]

Issue #15586 has been updated by Melissa Stone.

Status changed from Merged - Pending Release to Closed

Release in Facter 1.7.4-rc1


Bug #15586: 'facter --help' does not work with Ruby 1.9.3
https://projects.puppetlabs.com/issues/15586#change-101213

* Author: Anonymous
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: settings
* Target version: 1.7.4
* Keywords: 
* Branch: https://github.com/puppetlabs/facter/pull/522
* Affected Facter version: 1.7.0

When using Ruby 1.9.3: 

pre
$ facter --help
No help available unless your RDoc has RDoc.usage
/pre


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter - Bug #22944] (Closed) External facts are evaluated many times

[tickets]

Issue #22944 has been updated by Melissa Stone.

Status changed from Merged - Pending Release to Closed

Release in Facter 1.7.4-rc1


Bug #22944: External facts are evaluated many times
https://projects.puppetlabs.com/issues/22944#change-101227

* Author: Matthias Baur
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 1.7.4
* Keywords: 
* Branch: https://github.com/puppetlabs/facter/pull/570
* Affected Facter version: 1.7.3

** Reproduction **

* Drop script /etc/facter/facts.d/test.sh:
pre
#!/bin/bash
echo SCRIPT CALLED 2
echo test=value
/pre
* Make script executeable
pre
chmod +x /etc/facter/facts.d/test.sh
/pre
* Call 'facter', the following output is shown:
pre
root@puppet:~# facter
SCRIPT CALLED
SCRIPT CALLED
SCRIPT CALLED
SCRIPT CALLED
SCRIPT CALLED
SCRIPT CALLED
...
Regular facter output
...
/pre

I don't see a reason why the script is called 6 times.

System information

* Ubuntu 12.04.3
* Facter 1.7.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 unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter - Bug #22322] (Closed) facter should suppress stderr from swap commands on Solaris

[tickets]

Issue #22322 has been updated by Melissa Stone.

Status changed from Merged - Pending Release to Closed

Release in Facter 1.7.4-rc1


Bug #22322: facter should suppress stderr from swap commands on Solaris
https://projects.puppetlabs.com/issues/22322#change-101220

* Author: Lee Lowder
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: solaris
* Target version: 1.7.4
* Keywords: solaris swap stderr
* Branch: https://github.com/puppetlabs/facter/pull/530
* Affected Facter version: 

[ from a customer ]

facter should suppress stderr from swap commands on Solaris (2/dev/null) as 
this causes the pe-mcollective-metadata cron job to spew out many unnecessary 
emails to root on a system with no swap device.

This cron entry causes output (and conversely, an email to root every time it 
runs):

# Puppet Name: pe-mcollective-metadata
0,15,30,45 * * * * /opt/puppet/sbin/refresh-mcollective-metadata

Here's the junk from facter, when you do not have swap devices configured.   
Facter no longer errors when there's no swap device, however it shouldn't 
output any message (the swap command actually does this, so it needs to be 
redirected to null --- 2/dev/null)

root@mndevadm02 puppetlabs # /opt/puppet/sbin/refresh-mcollective-metadata
No swap devices configured
No swap devices configured
No swap devices configured
No swap devices configured



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter - Bug #18215] (Closed) processorcount counting CPU cores on Solaris

[tickets]

Issue #18215 has been updated by Melissa Stone.

Status changed from Merged - Pending Release to Closed

Release in Facter 1.7.4-rc1


Bug #18215: processorcount counting CPU cores on Solaris
https://projects.puppetlabs.com/issues/18215#change-101215

* Author: Alex Harvey
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: solaris
* Target version: 1.7.4
* Keywords: 
* Branch: https://github.com/puppetlabs/facter/pull/438
* Affected Facter version: 

The processorcount fact on Solaris is counting CPU cores -

pre
myhost# facter |grep proc
physicalprocessorcount = 1
processor0 = SPARC64-VII
processor1 = SPARC64-VII
processor2 = SPARC64-VII
processor3 = SPARC64-VII
processor4 = SPARC64-VII
processor5 = SPARC64-VII
processor6 = SPARC64-VII
processor7 = SPARC64-VII
processorcount = 4
/pre

- but on linux is counting CPU threads -

pre
myotherhost# facter |grep proc
physicalprocessorcount = 1
processor0 = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
processor1 = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
processor2 = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
processor3 = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
processor4 = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
processor5 = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
processor6 = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
processor7 = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
processorcount = 8
/pre

This is a single 4-core CPU with 8 threads similar to the Solaris example above.

A patch here should also provide a processorcorecount fact that preserves the 
existing behaviour of processorcount on Solaris.

See discussions in puppet users 
https://groups.google.com/forum/?fromgroups=pli=1#!topic/puppet-users/rOj9OszhlQM

And puppet developers
https://groups.google.com/forum/?fromgroups=pli=1#!topic/puppet-dev/payc4ToNcGQ


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter - Bug #23384] (Closed) Man pages are missing in Debian lucid and older

[tickets]

Issue #23384 has been updated by Melissa Stone.

Status changed from Merged - Pending Release to Closed

Release in Facter 1.7.4-rc1


Bug #23384: Man pages are missing in Debian lucid and older
https://projects.puppetlabs.com/issues/23384#change-101230

* Author: Josh Cooper
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 1.7.4
* Keywords: 
* Branch: https://github.com/puppetlabs/facter/pull/565
* Affected Facter version: 




-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter - Bug #22622] (Closed) Puppet fails when facter loads a script based external fact that doesn't return any output

[tickets]

Issue #22622 has been updated by Melissa Stone.

Status changed from Merged - Pending Release to Closed

Release in Facter 1.7.4-rc1


Bug #22622: Puppet fails when facter loads a script based external fact that 
doesn't return any output
https://projects.puppetlabs.com/issues/22622#change-101223

* Author: Martijn Grendelman
* Status: Closed
* Priority: Normal
* Assignee: Martijn Grendelman
* Category: 
* Target version: 1.7.4
* Keywords: windows
* Branch: https://github.com/puppetlabs/facter/pull/567
* Affected Facter version: 1.7.3

After upgrading Puppet agent on a Windows Server 2003 instance to 3.3.0 (from 
Puppetlabs-supplied puppet-3.3.0.msi), both Facter and Puppet did no longer 
work:

Facter:

Running Facter on demand ...
Failed to load feature test for root: undefined method `each_line' for 
nil:NilClass
Error: undefined method `each_line' for nil:NilClass

Puppet:

Running Puppet agent on demand ...
Failed to load feature test for root: undefined method `each_line' for 
nil:NilClass
C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/parser.rb:73:in `parse': undefined method 
`each_line' for nil:NilClass (NoMethodError)
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/parser.rb:120:in `results'
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/directory_loader.rb:61:in `block in load'
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/directory_loader.rb:55:in `each'
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/directory_loader.rb:55:in `load'
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/composite_loader.rb:10:in `block in load'
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/composite_loader.rb:10:in `each'
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/composite_loader.rb:10:in `load'
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/collection.rb:109:in `load'
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/collection.rb:84:in `fact'
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/collection.rb:139:in `value'
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter.rb:112:in `block (2 levels) in singletonclass'
from C:/Program Files/Puppet 
Labs/Puppet/puppet/lib/puppet/defaults.rb:4:in `default_diffargs'
from C:/Program Files/Puppet 
Labs/Puppet/puppet/lib/puppet/defaults.rb:183:in `module:Puppet'
from C:/Program Files/Puppet 
Labs/Puppet/puppet/lib/puppet/defaults.rb:1:in `top (required)'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in 
`require'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in 
`require'
from C:/Program Files/Puppet 
Labs/Puppet/puppet/lib/puppet.rb:109:in `module:Puppet'
from C:/Program Files/Puppet 
Labs/Puppet/puppet/lib/puppet.rb:29:in `top (required)'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in 
`require'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in 
`require'
from C:/Program Files/Puppet 
Labs/Puppet/puppet/lib/puppet/util/command_line.rb:12:in `top (required)'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in 
`require'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in 
`require'
from C:/Program Files/Puppet 
Labs/Puppet/puppet/bin/puppet:3:in `main'

Downgrading to 3.2.4 fixed the problem and restored functionality. The problem 
does not occur on Windows Server 2008 with Puppet 3.3.0.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For 

[Facter - Bug #22238] (Closed) Remove Fedora 17 from build_defaults.yaml

[tickets]

Issue #22238 has been updated by Melissa Stone.

Status changed from Merged - Pending Release to Closed

Release in Facter 1.7.4-rc1


Bug #22238: Remove Fedora 17 from build_defaults.yaml
https://projects.puppetlabs.com/issues/22238#change-101219

* Author: Melissa Stone
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 1.7.4
* Keywords: 
* Branch: https://github.com/puppetlabs/facter/pull/521
* Affected Facter version: 

Since Fedora 17 is EOL, it's time to remove it from our mock list


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter - Bug #23368] (Closed) Script based external facts fail on Windows 2003

[tickets]

Issue #23368 has been updated by Melissa Stone.

Status changed from Merged - Pending Release to Closed

Release in Facter 1.7.4-rc1


Bug #23368: Script based external facts fail on Windows 2003
https://projects.puppetlabs.com/issues/23368#change-101229

* Author: Josh Cooper
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 1.7.4
* Keywords: windows
* Branch: https://github.com/puppetlabs/facter/pull/569
* Affected Facter version: 1.7.0

Facter's ScriptParser will execute external facts with extensions (bat, cmd, 
com, exe) using ruby's `%x{ }`. On 2003, the path to these files will contain a 
space, e.g. `C:\Documents and Settings\All Users\Application 
Data\PuppetLabs\facter\facts.d`. Since the command is not quoted, it will fail 
(it's interpreted as the command `C:\Documents` with arguments `and`, 
`Settings\All`, etc.

It is not an issue on 2008 and later, because the path to the script does not 
typically contain a space, `C:\ProgramData\PuppetLabs\facter\facts.d`.

It is not an issue with Powershell scripts, because there is a powershell 
specific parser that executes `powershell -File 'path/to/file.ps1'`

It is not an issue for text based external facts, because `File.read` does not 
require the path to be quoted.

The fix is simple, make sure the path is quoted if it contains spaces.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter - Bug #23135] (Closed) Update Facter Master Windows/Solaris jobs to use vcloud.

[tickets]

Issue #23135 has been updated by Melissa Stone.

Status changed from Merged - Pending Release to Closed

Release in Facter 1.7.4-rc1


Bug #23135: Update Facter Master Windows/Solaris jobs to use vcloud.
https://projects.puppetlabs.com/issues/23135#change-101228

* Author: Branan Purvine-Riley
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 1.7.4
* Keywords: 
* Branch: https://github.com/puppetlabs/facter/pull/556
* Affected Facter version: 




-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter - Bug #21604] (Closed) Virtual fact is not working properly for VM

[tickets]

Issue #21604 has been updated by Melissa Stone.

Status changed from Merged - Pending Release to Closed

Release in Facter 1.7.4-rc1


Bug #21604: Virtual fact is not working properly for VM
https://projects.puppetlabs.com/issues/21604#change-101218

* Author: Lorenzo Cubero
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: virtual
* Target version: 1.7.4
* Keywords: windows
* Branch: https://github.com/puppetlabs/facter/pull/495
* Affected Facter version: 

Hi,

Facter says $virtual = physical for Windows Server 2008 R2 VM on Xen.

It also returns the hardware processor model.

The machine has puppet 3.2.2 installed.

Thks.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter - Bug #22844] (Closed) The 'virtual' and 'is_virtual' facts are incorrect for Windows guests hosted on kvm

[tickets]

Issue #22844 has been updated by Melissa Stone.

Status changed from Merged - Pending Release to Closed

Release in Facter 1.7.4-rc1


Bug #22844: The 'virtual' and 'is_virtual' facts are incorrect for Windows 
guests hosted on kvm
https://projects.puppetlabs.com/issues/22844#change-101226

* Author: Karl Davis
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 1.7.4
* Keywords: windows
* Branch: https://github.com/puppetlabs/facter/pull/549
* Affected Facter version: 1.7.2

I've got a Windows Server 2012 VM that's hosted on kvm. I get the following 
output from the Puppet v3.2.4 (open source) command prompt:
 facter --version
1.7.2
 facter virtual
physical
 facter is_virtual
false

Unfortunately, this has led to Puppet trying to push configs to the VM that it 
shouldn't, e.g. ntp.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter - Bug #22789] (Closed) is_virtual incorrectly shows true for vserver_host

[tickets]

Issue #22789 has been updated by Melissa Stone.

Status changed from Merged - Pending Release to Closed

Release in Facter 1.7.4-rc1


Bug #22789: is_virtual incorrectly shows true for vserver_host
https://projects.puppetlabs.com/issues/22789#change-101225

* Author: Theo Chatzimichos
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: virtual
* Target version: 1.7.4
* Keywords: 
* Branch: https://github.com/puppetlabs/facter/pull/547
* Affected Facter version: 1.7.3

As stated in the subject, a Linux-VServer host is incorrectly shown as virtual 
in facter. Output of facter:

# facter is_virtual
true
# facter virtual
vserver_host

I will submit a PR in Github.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter - Bug #22349] (Closed) Facter fails to run as a non-root user when /etc/facter/facts.d is not readable

[tickets]

Issue #22349 has been updated by Melissa Stone.

Status changed from Merged - Pending Release to Closed

Release in Facter 1.7.4-rc1


Bug #22349: Facter fails to run as a non-root user when /etc/facter/facts.d is 
not readable
https://projects.puppetlabs.com/issues/22349#change-101221

* Author: Andrew Parker
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 1.7.4
* Keywords: 
* Branch: https://github.com/puppetlabs/facter/pull/531
* Affected Facter version: 1.7.0

If the `/etc/facter/facts.d` directory is available, but not readable, then 
facter, when run as a non-root user will still try to read from it and fail.

pre
[vagrant@localhost ~]$ ls -l /etc/facter
total 4 
drwxr-x--- 2 root root 4096 Aug 29 19:25 facts.d
[vagrant@localhost ~]$ facter
Error: Permission denied - /etc/facter/facts.d
/pre

If that directory is made readable, then facter will work.

pre
[vagrant@localhost ~]$ sudo chmod o+r /etc/facter/facts.d
[vagrant@localhost ~]$ ls -l /etc/facter
total 4
drwxr-xr-- 2 root root 4096 Aug 29 19:25 facts.d
[vagrant@localhost ~]$ facter
architecture = x86_64
augeasversion = 0.9.0
/pre

As of Puppet 3.0.0, puppet will now look in ~/.puppet for its configuration 
information (#16637); however, facter, when it got external facts (#2157) and 
suddenly had the ability to read from a specific directory, did not take into 
account what user it was running as. This causes the problem above, which 
prevents facter from running for a non-root user, but also stops puppet from 
running as non-root.

Facter needs to follow puppet's lead and use a user-local directory when it 
isn't running as root.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter - Refactor #22651] (Closed) add fixture access methods for example /proc/cpuinfo files

[tickets]

Issue #22651 has been updated by Melissa Stone.

Status changed from Merged - Pending Release to Closed

Release in Facter 1.7.4-rc1


Refactor #22651: add fixture access methods for example /proc/cpuinfo files
https://projects.puppetlabs.com/issues/22651#change-101224

* Author: Joshua Hoblitt
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: testing
* Target version: 1.7.4
* Keywords: fixtures rspec
* Branch: 
* Affected Facter version: 

Based on the discussion of #22649 on #puppet with Adrien, it was recommended 
that we add a `FacterSpec::Cpuinfo` or similar module to house the 
`/proc/cpuinfo` example fixture access methods I am propossing.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter - Bug #22334] (Closed) Facter outputs information to stderr irrespective of whether --debug is enabled

[tickets]

Issue #22334 has been updated by Melissa Stone.

Status changed from Merged - Pending Release to Closed
Affected Facter version deleted (1.7.3-rc1)

Released in Facter 1.7.4-rc1


Bug #22334: Facter outputs information to stderr irrespective of whether 
--debug is enabled
https://projects.puppetlabs.com/issues/22334#change-101231

* Author: Andrew Parker
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 1.7.4
* Keywords: 
* Branch: https://github.com/puppetlabs/facter/pull/529
* Affected Facter version: 

When a fact resolution raises an error, Facter will output a message of the 
format `Could not retrieve %s: %s % [self.name, details]`. This message is 
output using ruby's native `warn` method instead of Facter's `warn` method 
which is controlled by `--debug`. This same method is used when a fact file 
fails to load, and when a fact takes too long. At the very least Facter needs 
to be using its own logging system in order to avoid outputting to stderr when 
it shouldn't.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23202] (Rejected) Running puppet on Windows XP on a fat32 formatted disk fails

[tickets]

Issue #23202 has been updated by Josh Cooper.

Status changed from Unreviewed to Rejected

Hi Armindo, we don't support windows xp, see 
http://docs.puppetlabs.com/guides/platforms.html#windows


Bug #23202: Running puppet on Windows XP on a fat32 formatted disk fails
https://projects.puppetlabs.com/issues/23202#change-101232

* Author: Armindo Silva
* Status: Rejected
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 3.3.2
* Keywords: 
* Branch: 

The first time puppet agent runs it fails with the following error. This 
happens before applying any of my manifests - the machine's certificates are 
not even created.
The machine is running Windows XP (Embedded Edition 2009 to be more precise) 
and it has the C:\ formatted in Fat32 (I know NTFS exists but unfortunately we 
can not change this - client's machine).

Running Puppet agent on demand ...
Error: Could not create resources for managing Puppet's files and directories in
sections [:main, :agent, :ssl]: Validation of File[C:/Documents and Settings/Al
l Users/Application Data/PuppetLabs/puppet/var/log] failed: Can only manage owne
r, group, and mode on filesystems that support Windows ACLs, such as NTFS
Wrapped exception:
Can only manage owner, group, and mode on filesystems that support Windows ACLs,
such as NTFS
Error: Could not prepare for execution: Could not create resources for managing
Puppet's files and directories in sections [:main, :agent, :ssl]: Validation of
File[C:/Documents and Settings/All Users/Application Data/PuppetLabs/puppet/var/
log] failed: Can only manage owner, group, and mode on filesystems that support
Windows ACLs, such as NTFS
Validation of File[C:/Documents and Settings/All Users/Application Data/PuppetLa
bs/puppet/var/log] failed: Can only manage owner, group, and mode on filesystems
that support Windows ACLs, such as NTFS
Wrapped exception:
Can only manage owner, group, and mode on filesystems that support Windows ACLs,
such as NTFS
Press any key to continue . . .


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23202] Running puppet on Windows XP on a fat32 formatted disk fails

[tickets]

Issue #23202 has been updated by Josh Cooper.

Description updated


Bug #23202: Running puppet on Windows XP on a fat32 formatted disk fails
https://projects.puppetlabs.com/issues/23202#change-101233

* Author: Armindo Silva
* Status: Rejected
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 3.3.2
* Keywords: 
* Branch: 

The first time puppet agent runs it fails with the following error. This 
happens before applying any of my manifests - the machine's certificates are 
not even created.
The machine is running Windows XP (Embedded Edition 2009 to be more precise) 
and it has the C:\ formatted in Fat32 (I know NTFS exists but unfortunately we 
can not change this - client's machine).

pre
Running Puppet agent on demand ...
Error: Could not create resources for managing Puppet's files and directories 
in sections [:main, :agent, :ssl]: 
Validation of File[C:/Documents and Settings/All Users/Application 
Data/PuppetLabs/puppet/var/log] failed: Can only manage owner, group, and mode 
on filesystems that support Windows ACLs, such as NTFS
Wrapped exception:
Can only manage owner, group, and mode on filesystems that support Windows 
ACLs, such as NTFS
Error: Could not prepare for execution: Could not create resources for managing 
Puppet's files and directories in sections [:main, :agent, :ssl]:
Validation of File[C:/Documents and Settings/All Users/Application 
Data/PuppetLabs/puppet/var/log] failed: Can only manage owner, group, and mode 
on filesystems that support Windows ACLs, such as NTFS
Validation of File[C:/Documents and Settings/All Users/Application 
Data/PuppetLabs/puppet/var/log] failed: Can only manage owner, group, and mode 
on filesystems that support Windows ACLs, such as NTFS
Wrapped exception:
Can only manage owner, group, and mode on filesystems that support Windows 
ACLs, such as NTFS
Press any key to continue . . .
/pre


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #22973] (Accepted) service does not implement custom start / stop commands on windows

[tickets]

Issue #22973 has been updated by Josh Cooper.

Status changed from Unreviewed to Accepted

Thanks Kees! Could you submit a pull request for this issue, see 
https://github.com/puppetlabs/puppet/blob/master/CONTRIBUTING.md for more 
information.


Bug #22973: service does not implement custom start / stop commands on windows
https://projects.puppetlabs.com/issues/22973#change-101234

* Author: Kees van Vloten
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: service
* Target version: 
* Affected Puppet version: 2.7.22
* Keywords: 
* Branch: 

The provider for service does not have support for explicit start and stop 
commands, however the documentation does not mention that limitation.

Example (taken from the mcollective module):
precode
  service { $mc_service_name:
ensure= running,
enable= true,
hasstatus = true,
start = $mc_service_start,
stop  = $mc_service_stop,
  }
/code/pre
Windows will still run the default command, which is:

* C:\Windows\System32\net.exe $mc_service_name start
* C:\Windows\System32\net.exe $mc_service_name stop

In stead of the specified start and stop commands.


The fix could be a simple as this:
precode
--- lib\puppet\provider\service\windows-orig.rb 2013-06-17 17:23:16 +0200
+++ lib\puppet\provider\service\windows.rb  2013-10-25 11:57:42 +0200
@@ -73,13 +73,21 @@
   end
 end
 
-net(:start, @resource[:name])
+if @resource[:start]
+  system(@resource[:start])
+else
+  net(:start, @resource[:name])
+   end
   rescue Puppet::ExecutionFailure = detail
 raise Puppet::Error.new(Cannot start #{@resource[:name]}, error was: 
#{detail} )
   end
 
   def stop
-net(:stop, @resource[:name])
+if @resource[:stop]
+  system(@resource[:stop])
+else
+  net(:stop, @resource[:name])
+   end
   rescue Puppet::ExecutionFailure = detail
 raise Puppet::Error.new(Cannot stop #{@resource[:name]}, error was: 
#{detail} )
   end
/code/pre


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23249] (In Topic Branch Pending Review) Tidy causes 'Cannot alias' ArgumentError exception on Windows

[tickets]

Issue #23249 has been updated by Josh Cooper.

Status changed from Unreviewed to In Topic Branch Pending Review
Target version set to 3.5.0
Branch set to https://github.com/puppetlabs/puppet/pull/2141


Bug #23249: Tidy causes 'Cannot alias' ArgumentError exception on Windows
https://projects.puppetlabs.com/issues/23249#change-101235

* Author: C Lang
* Status: In Topic Branch Pending Review
* Priority: Normal
* Assignee: 
* Category: tidy
* Target version: 3.5.0
* Affected Puppet version: 2.7.23
* Keywords: 
* Branch: https://github.com/puppetlabs/puppet/pull/2141

This example:
pre
class puppet-bug {

  file { 'C:\bug':
ensure = directory,
  }

  tidy { 'C:\bug':
recurse = true,
backup  = false
  }

  file { 'C:\bug\test.txt':
content = 'Look, a bug!'
  }

}
/pre

Causes this error:

pre
err: Got an uncaught exception of type ArgumentError: Cannot alias 
File[C:\bug/test.txt] to [C:/bug/test.txt]; resource [File, 
C:/bug/test.txt] already declared at 
/etc/puppet/modules/puppet-bug/manifests/init.pp:14
/pre

It appears to be due to the way slashes are handled on Windows. If you change 
the tidy to 'C:/bug' it all works just fine and the duplicate resource is 
detected and excluded from the tidy as expected.  

That might be an acceptable fix, except when you're using variables for File 
resources that are also used as msiexec parameters and thus can't have Unix 
slashes. :)




-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23249] Tidy causes 'Cannot alias' ArgumentError exception on Windows

[tickets]

Issue #23249 has been updated by Josh Cooper.

Keywords set to windows


Bug #23249: Tidy causes 'Cannot alias' ArgumentError exception on Windows
https://projects.puppetlabs.com/issues/23249#change-101236

* Author: C Lang
* Status: In Topic Branch Pending Review
* Priority: Normal
* Assignee: 
* Category: tidy
* Target version: 3.5.0
* Affected Puppet version: 2.7.23
* Keywords: windows
* Branch: https://github.com/puppetlabs/puppet/pull/2141

This example:
pre
class puppet-bug {

  file { 'C:\bug':
ensure = directory,
  }

  tidy { 'C:\bug':
recurse = true,
backup  = false
  }

  file { 'C:\bug\test.txt':
content = 'Look, a bug!'
  }

}
/pre

Causes this error:

pre
err: Got an uncaught exception of type ArgumentError: Cannot alias 
File[C:\bug/test.txt] to [C:/bug/test.txt]; resource [File, 
C:/bug/test.txt] already declared at 
/etc/puppet/modules/puppet-bug/manifests/init.pp:14
/pre

It appears to be due to the way slashes are handled on Windows. If you change 
the tidy to 'C:/bug' it all works just fine and the duplicate resource is 
detected and excluded from the tidy as expected.  

That might be an acceptable fix, except when you're using variables for File 
resources that are also used as msiexec parameters and thus can't have Unix 
slashes. :)




-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #22973] service does not implement custom start / stop commands on windows

[tickets]

Issue #22973 has been updated by Josh Cooper.

Keywords set to windows


Bug #22973: service does not implement custom start / stop commands on windows
https://projects.puppetlabs.com/issues/22973#change-101237

* Author: Kees van Vloten
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: service
* Target version: 
* Affected Puppet version: 2.7.22
* Keywords: windows
* Branch: 

The provider for service does not have support for explicit start and stop 
commands, however the documentation does not mention that limitation.

Example (taken from the mcollective module):
precode
  service { $mc_service_name:
ensure= running,
enable= true,
hasstatus = true,
start = $mc_service_start,
stop  = $mc_service_stop,
  }
/code/pre
Windows will still run the default command, which is:

* C:\Windows\System32\net.exe $mc_service_name start
* C:\Windows\System32\net.exe $mc_service_name stop

In stead of the specified start and stop commands.


The fix could be a simple as this:
precode
--- lib\puppet\provider\service\windows-orig.rb 2013-06-17 17:23:16 +0200
+++ lib\puppet\provider\service\windows.rb  2013-10-25 11:57:42 +0200
@@ -73,13 +73,21 @@
   end
 end
 
-net(:start, @resource[:name])
+if @resource[:start]
+  system(@resource[:start])
+else
+  net(:start, @resource[:name])
+   end
   rescue Puppet::ExecutionFailure = detail
 raise Puppet::Error.new(Cannot start #{@resource[:name]}, error was: 
#{detail} )
   end
 
   def stop
-net(:stop, @resource[:name])
+if @resource[:stop]
+  system(@resource[:stop])
+else
+  net(:stop, @resource[:name])
+   end
   rescue Puppet::ExecutionFailure = detail
 raise Puppet::Error.new(Cannot stop #{@resource[:name]}, error was: 
#{detail} )
   end
/code/pre


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23379] puppet agent 3.4.0-rc1 and windows 7 Professional (DE edition) - Service 'Puppet Agent' (puppet) could not be installed. Verify that you have sufficient privileges to instal sys

[tickets]

Issue #23379 has been updated by Josh Cooper.

Affected Puppet version deleted (3.4.0-rc1)
Keywords set to windows


Bug #23379: puppet agent 3.4.0-rc1 and windows 7 Professional (DE edition) - 
Service 'Puppet Agent' (puppet) could not be installed. Verify that you have 
sufficient privileges to instal system services.
https://projects.puppetlabs.com/issues/23379#change-101238

* Author: Claudiu Vasadi
* Status: Needs More Information
* Priority: Normal
* Assignee: 
* Category: windows
* Target version: 
* Affected Puppet version: 
* Keywords: windows
* Branch: 

All operations were carried out under the Administrator account. Puppet 3.3.2 
was already installed and running. Reboot did not help and neither did removing 
puppet agent 3.3.2 before installing 3.4.0-rc1.

Windows is a fresh install (no other applications installed) and has no SP.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23219] Windows service doesn't accept extra arguments properly

[tickets]

Issue #23219 has been updated by Josh Cooper.

Branch set to https://github.com/puppetlabs/puppet/pull/2094


Bug #23219: Windows service doesn't accept extra arguments properly
https://projects.puppetlabs.com/issues/23219#change-101239

* Author: Luis Fernandez
* Status: In Topic Branch Pending Review
* Priority: Normal
* Assignee: Luis Fernandez
* Category: windows
* Target version: 
* Affected Puppet version: 3.2.2
* Keywords: windows service
* Branch: https://github.com/puppetlabs/puppet/pull/2094

Checking the code responsible of managing the windows service, there is an 
option to pass extra arguments to the puppet run. 

However, when I try to pass additional parameters (like --masterport=, 
etc), the options are not properly parsed by the service.rb class.

After taking a look to the code, it appears to be easy to fix, so I'll post a 
possible solution for this 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 unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Feature #22701] (Accepted) Support for Microsoft .msu packages

[tickets]

Issue #22701 has been updated by Josh Cooper.

Status changed from Unreviewed to Accepted


Feature #22701: Support for Microsoft .msu packages
https://projects.puppetlabs.com/issues/22701#change-101240

* Author: Celia Cottle
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 
* Keywords: windows customer
* Branch: 

[ED: SO SORRY, hit the wrong button and deleted the whole thread instead of my 
comment.]

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?


Related to Puppet - Feature #16991: Puppet should support *.msp upgrade 
packages on Windows Accepted
History

#1 UPDATED BY JOSH COOPER 10 MONTHS AGO
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?

#2 UPDATED BY LUIS MAYORGA 10 MONTHS AGO
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.

#3 UPDATED BY LUIS MAYORGA 10 MONTHS AGO
class ps3{
file{ 'ps3':
name = 'C:\Temp\WMF30.msu',
ensure = present,
source = 'puppet:///puppetfs/WMF30.msu'
} 
exec { 'ps3':
command = 'C:\Windows\System32\wusa.exe C:\Temp\WMF30.msu /quiet /norestart 
/log C:\Temp\Poweshellv3.htm',
require = [File[ps3],Class[netfx45]]
}
}
#4 UPDATED BY JOSH COOPER 9 MONTHS AGO
Luis Mayorga wrote:

command = 'C:\Windows\System32\wusa.exe C:\Temp\WMF30.msu /quiet /norestart 
/log C:\Temp\Poweshellv3.htm',
Thanks Luis, how about the uninstall command? Can you uninstall a specific msu? 
Or only the product that the msu was applied to?



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #22840] Could not intern from pson: “\xE4” on US-ASCII

[tickets]

Issue #22840 has been updated by Josh Cooper.


The error is originating on the server (Error 400 on SERVER). Most likely the 
German agent is sending its facts (timezone = 'Mitteleuropäische Zeit') and 
the master is unable to parse the fact. Can you run the puppet master with 
`--debug --trace`, either in config.ru if using passenger, or 
/etc/init.d/puppetmaster if using webrick.


Bug #22840: Could not intern from pson: “\xE4” on US-ASCII
https://projects.puppetlabs.com/issues/22840#change-101241

* Author: Claudiu Vasadi
* Status: Unreviewed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 
* Keywords: windows
* Branch: 

Puppet master and agent version 3.3.1. The agent is running on a German edition 
of Windows 7 Professional SP1 x64 and the master is running on FreeBSD 9.2 
amd64.

I am getting the following errors from puppet agent console on windows (same 
errors are recorded to the eventlog): 
pre
Error: Could not retrieve catalog from remote server: 
Error 400 on SERVER: Could not intern from pson: “\xE4” on US-ASCII 
Warning: Not using cache on failed catalog 
Error: Could not retrieve catalog; skopping run
/pre

The master reports: 
pre
Could not intern from pson: “\x84” on US-ASCII 
Could not intern from pson: “\xE4” on US-ASCII
/pre

puppet.conf: 
pre
pluginsource = puppet://puppet.local/plugins 
reports = store, http 
reporturl = http://puppet.local:3000/reports/upload
/pre

Trace from puppet agent:
pre
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Could not intern from pson: \xE4 on US-ASCII
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/indirector/rest.rb:194:in `is_http_200?'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/indirector/rest.rb:100:in `find'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/indirector/indirection.rb:197:in `find'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/configurer.rb:254:in `block in 
retrieve_new_catalog'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:354:in 
`block in thinmark'
C:/Program Files (x86)/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/1.9.1/benchmark.rb:295:in `realtime'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:353:in 
`thinmark'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/configurer.rb:253:in `retrieve_new_catalog'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/configurer.rb:69:in`retrieve_catalog'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/configurer.rb:109:in 
`prepare_and_retrieve_catalog'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/configurer.rb:170:in `run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:45:in 
`block (5 levels) in run'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/agent/locker.rb:20:in `lock'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:45:in 
`block (4 levels) in run'
C:/Program Files (x86)/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/1.9.1/sync.rb:227:in `sync_synchronize'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:45:in 
`block (3 levels) in run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:119:in 
`with_client'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:42:in 
`block (2 levels) in run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:84:in 
`run_in_fork'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:41:in 
`block in run'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application.rb:179:in `call'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application.rb:179:in `controlled_run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:39:in `run'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application/agent.rb:360:in `onetime'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application/agent.rb:326:in `run_command'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application.rb:364:in `block (2 levels) in run'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application.rb:457:in `plugin_hook'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application.rb:364:in `block in run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:511:in 
`exit_on_fail'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application.rb:364:in `run'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/util/command_line.rb:132:in `run'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/util/command_line.rb:86:in `execute'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/bin/puppet:4:in `main'
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
/pre

Can anyone reproduce 

[Puppet - Bug #22840] (Needs More Information) Could not intern from pson: “\xE4” on US-ASCII

[tickets]

Issue #22840 has been updated by Josh Cooper.

Status changed from Unreviewed to Needs More Information
Assignee set to Claudiu Vasadi


Bug #22840: Could not intern from pson: “\xE4” on US-ASCII
https://projects.puppetlabs.com/issues/22840#change-101242

* Author: Claudiu Vasadi
* Status: Needs More Information
* Priority: Normal
* Assignee: Claudiu Vasadi
* Category: 
* Target version: 
* Affected Puppet version: 
* Keywords: windows
* Branch: 

Puppet master and agent version 3.3.1. The agent is running on a German edition 
of Windows 7 Professional SP1 x64 and the master is running on FreeBSD 9.2 
amd64.

I am getting the following errors from puppet agent console on windows (same 
errors are recorded to the eventlog): 
pre
Error: Could not retrieve catalog from remote server: 
Error 400 on SERVER: Could not intern from pson: “\xE4” on US-ASCII 
Warning: Not using cache on failed catalog 
Error: Could not retrieve catalog; skopping run
/pre

The master reports: 
pre
Could not intern from pson: “\x84” on US-ASCII 
Could not intern from pson: “\xE4” on US-ASCII
/pre

puppet.conf: 
pre
pluginsource = puppet://puppet.local/plugins 
reports = store, http 
reporturl = http://puppet.local:3000/reports/upload
/pre

Trace from puppet agent:
pre
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Could not intern from pson: \xE4 on US-ASCII
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/indirector/rest.rb:194:in `is_http_200?'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/indirector/rest.rb:100:in `find'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/indirector/indirection.rb:197:in `find'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/configurer.rb:254:in `block in 
retrieve_new_catalog'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:354:in 
`block in thinmark'
C:/Program Files (x86)/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/1.9.1/benchmark.rb:295:in `realtime'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:353:in 
`thinmark'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/configurer.rb:253:in `retrieve_new_catalog'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/configurer.rb:69:in`retrieve_catalog'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/configurer.rb:109:in 
`prepare_and_retrieve_catalog'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/configurer.rb:170:in `run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:45:in 
`block (5 levels) in run'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/agent/locker.rb:20:in `lock'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:45:in 
`block (4 levels) in run'
C:/Program Files (x86)/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/1.9.1/sync.rb:227:in `sync_synchronize'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:45:in 
`block (3 levels) in run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:119:in 
`with_client'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:42:in 
`block (2 levels) in run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:84:in 
`run_in_fork'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:41:in 
`block in run'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application.rb:179:in `call'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application.rb:179:in `controlled_run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:39:in `run'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application/agent.rb:360:in `onetime'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application/agent.rb:326:in `run_command'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application.rb:364:in `block (2 levels) in run'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application.rb:457:in `plugin_hook'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application.rb:364:in `block in run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:511:in 
`exit_on_fail'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application.rb:364:in `run'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/util/command_line.rb:132:in `run'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/util/command_line.rb:86:in `execute'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/bin/puppet:4:in `main'
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
/pre

Can anyone reproduce this?


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

[Puppet - Bug #22972] (Accepted) Windows Puppet Agent Service gracefully terminates after succesfully being put into a Paused state

[tickets]

Issue #22972 has been updated by Josh Cooper.

Status changed from Unreviewed to Accepted
Target version set to 3.5.0
Affected Puppet version set to 2.7.12
Branch set to https://github.com/puppetlabs/puppet/pull/2021

Thanks for the patch Glenn! I've added a link to your PR, it would be great if 
you could resubmit with the changes we talked about.


Bug #22972: Windows Puppet Agent Service gracefully terminates after 
succesfully being put into a Paused state
https://projects.puppetlabs.com/issues/22972#change-101243

* Author: Glenn Sarti
* Status: Accepted
* Priority: Low
* Assignee: 
* Category: 
* Target version: 3.5.0
* Affected Puppet version: 2.7.12
* Keywords: windows service agent
* Branch: https://github.com/puppetlabs/puppet/pull/2021

If you successfully pause the Windows Puppet Agent Server, then after a period 
of time the Puppet Agent service will gracefully stop.  This does not appear to 
be appropriate behaviour.  The service should remain in a paused state until a 
Continue or Stop message is sent to the service.

It looks like it's to do with the following lines;

while running? do
  return if state != RUNNING

According to ruby doco [1] running? is defined as the service is in a RUNNING, 
PAUSED or IDLE state, but the following line terminates the main loop if the 
service is not in the running state.
It seems that the return if state != RUNNING line is not really required

[1] http://rubydoc.info/gems/win32-service/0.8.2/frames


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #3118] Default node definition should not be required when ENC returns a node definition.

[tickets]

Issue #3118 has been updated by Alex Harvey.


This bug has been open for a long time and the result is that our documentation 
contradicts the actual behavior.  I am aware of sites using this behavior (i.e. 
relying on default node always being applied) as a feature as Jeff suggested 
above.  I would vote to update docs to match the actual behavior and close this 
bug.  Either way it would be good to resolve it one way or another.


Bug #3118: Default node definition should not be required when ENC returns a 
node definition.
https://projects.puppetlabs.com/issues/3118#change-101185

* Author: Markus Roberts
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 0.24.8
* Keywords: 
* Branch: 

This behavior is surprising, but not new.

Given the external node tool:

pre
#!/usr/bin/env ruby
print %q{
---
classes:
  - foo
}
exit 0
/pre

And site.pp:

pre
class foo {
notice foo
}

class bar {
notice bar
}

node default {
include bar
}
/pre

The following results are seen:

pre
info: Caching node for host-246-104.pubnet.pdx.edu
notice: Scope(Class[bar]): bar
notice: Scope(Class[foo]): foo
notice: Compiled catalog for host-246-104.pubnet.pdx.edu in 0.01 seconds
/pre

The same results are seen with 0.24.8 and 0.25.4rc3.

This appears to break the assumption that default is only applied for nodes 
that aren't otherwise defined.  The same is seen with an explicit node instead 
of just default in site.pp




-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23311] (Accepted) vardir default in 3.3.2

[tickets]

Issue #23311 has been updated by Felix Frank.

Status changed from Unreviewed to Accepted

Pretty sure about this one now. Easily reproduced, and looking at the code it 
Should Not Happen.


Bug #23311: vardir default in 3.3.2
https://projects.puppetlabs.com/issues/23311#change-101186

* Author: James Eckersall
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 
* Keywords: 
* Branch: 

Hi,

I'm suffering from what looks to be the same or related bug 
http://projects.puppetlabs.com/issues/16637

I have an infrastructure of approximately 500 nodes managed by Puppet.  They 
were all running 2.7.22 and today I've come to upgrade them all to 3.3.2.

The boxes are a mix of CentOS and RedHat, EL5 and EL6.

We manage Puppet with Puppet, so today I updated the manifest to point to the 
updated rpm's in the repo and let it rip.

Most of my nodes are now failing to even start Puppet with the following error:

Error: Could not intialize global default settings: Error converting value for 
param 'factpath': Could not find value for $vardir

If I add the below line to /etc/puppet/puppet.conf, all is good with the world.
vardir = /var/lib/puppet

That line did not previously exist in the puppet.conf file, so it looks like 
the upgrade to 3.3.2 has introduced this bug.

Now I'm faced with the unpleasant task of manually deploying a script to each 
node to insert that line as Puppet now refuses to start on my nodes.

I can easily replicate this.  Remove that line from puppet.conf and the agent 
will not start (service puppet start or puppet agent --test as root).

J


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23378] (Unreviewed) Zypper package provider needs $HOME set to access username/password-protected repos

[tickets]

Issue #23378 has been reported by Pieter Hollants.


Bug #23378: Zypper package provider needs $HOME set to access 
username/password-protected repos
https://projects.puppetlabs.com/issues/23378

* Author: Pieter Hollants
* Status: Unreviewed
* Priority: High
* Assignee: 
* Category: provider
* Target version: 3.3.2
* Affected Puppet version: 3.3.1
* Keywords: zypper package provider
* Branch: 

zypper, the command used to install packages on SUSE distributions, supports 
package repositories that requires a username and a password to be accessed. 
Unlike other comparable utilities for other distributions, zypper stores such 
credentials information in a file in $HOME, $HOME/.zypp/credentials.cat to be 
precisely. However, this requires the environment variable $HOME to be set, 
which is currently not the case, rendering the zypper package provider unable 
to access a required password.

The attached patch fixes this by explicitly defining a HOME environment 
variable set to /root. This is correct, because the zypper command requires 
root permissions for both configuring software repositories and installing 
software.




-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23311] vardir default in 3.3.2

[tickets]

Issue #23311 has been updated by Felix Frank.


OK, so this seems to fix this (specs have not run yet)

pre
--- a/lib/puppet.rb
+++ b/lib/puppet.rb
@@ -145,9 +145,9 @@ module Puppet
   # private helper method to provide the implementation details of 
initializing for a run mode,
   #  but allowing us to control where the deprecation warning is issued
   def self.do_initialize_settings_for_run_mode(run_mode, args)
-Puppet.settings.initialize_global_settings(args)
 run_mode = Puppet::Util::RunMode[run_mode]
 
Puppet.settings.initialize_app_defaults(Puppet::Settings.app_defaults_for_run_mode(run_mode))
+Puppet.settings.initialize_global_settings(args)
   end
   private_class_method :do_initialize_settings_for_run_mode
 
/pre

There are still some weird things I don't get though: This is reproducible when 
running the agent as root and removing vardir= from the conf file but using 
$vardir there. bBut/b it's not reproducible when doing the same in a 
regular user's conf.

Currently, the issue can be worked around by not using $vardir in puppet.conf 
(but at least the default one in the Debian package does just that).


Bug #23311: vardir default in 3.3.2
https://projects.puppetlabs.com/issues/23311#change-101187

* Author: James Eckersall
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 
* Keywords: 
* Branch: 

Hi,

I'm suffering from what looks to be the same or related bug 
http://projects.puppetlabs.com/issues/16637

I have an infrastructure of approximately 500 nodes managed by Puppet.  They 
were all running 2.7.22 and today I've come to upgrade them all to 3.3.2.

The boxes are a mix of CentOS and RedHat, EL5 and EL6.

We manage Puppet with Puppet, so today I updated the manifest to point to the 
updated rpm's in the repo and let it rip.

Most of my nodes are now failing to even start Puppet with the following error:

Error: Could not intialize global default settings: Error converting value for 
param 'factpath': Could not find value for $vardir

If I add the below line to /etc/puppet/puppet.conf, all is good with the world.
vardir = /var/lib/puppet

That line did not previously exist in the puppet.conf file, so it looks like 
the upgrade to 3.3.2 has introduced this bug.

Now I'm faced with the unpleasant task of manually deploying a script to each 
node to insert that line as Puppet now refuses to start on my nodes.

I can easily replicate this.  Remove that line from puppet.conf and the agent 
will not start (service puppet start or puppet agent --test as root).

J


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #15735] Deprecate 'puppet kick' run mode

[tickets]

Issue #15735 has been updated by Markus Joosten.


I can only agree to what Nikita said.
Mcollective has such a huge overhead, since it is relies on ActiveMQ which is a 
Java application after all.
Most of our systems do not have Java installed (for several purposes, security 
being only one of those reasons!) and with the current puppet kick 
functionality we can at least trigger our puppet agents to run.

Just out of curiosity, why do you guys want to deprecate the kick functionality?
Is it to hard to maintain code-wise? Does it lack some critical features? 
Security issues?


Bug #15735: Deprecate 'puppet kick' run mode
https://projects.puppetlabs.com/issues/15735#change-101119

* Author: eric sorenson
* Status: Re-opened
* Priority: High
* Assignee: eric sorenson
* Category: agent
* Target version: 3.x
* Affected Puppet version: 
* Keywords: telly_deprecation
* Branch: https://github.com/puppetlabs/puppet/pull/1129

People interested in `puppet kick` functionality should set up mcollective. 
Supporting it causes problems like #10418. Let's consider removing it for Telly.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter - Bug #22622] (Merged - Pending Release) Puppet fails when facter loads a script based external fact that doesn't return any output

[tickets]

Issue #22622 has been updated by Josh Cooper.

Status changed from Accepted to Merged - Pending Release
Branch changed from https://github.com/puppetlabs/facter/pull/564 to 
https://github.com/puppetlabs/facter/pull/567

Merged in commit [3bdc0bf](https://github.com/puppetlabs/facter/commit/3bdc0bf) 
to be released in 1.7.4


Bug #22622: Puppet fails when facter loads a script based external fact that 
doesn't return any output
https://projects.puppetlabs.com/issues/22622#change-101120

* Author: Martijn Grendelman
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: Martijn Grendelman
* Category: 
* Target version: 1.7.4
* Keywords: windows
* Branch: https://github.com/puppetlabs/facter/pull/567
* Affected Facter version: 1.7.3

After upgrading Puppet agent on a Windows Server 2003 instance to 3.3.0 (from 
Puppetlabs-supplied puppet-3.3.0.msi), both Facter and Puppet did no longer 
work:

Facter:

Running Facter on demand ...
Failed to load feature test for root: undefined method `each_line' for 
nil:NilClass
Error: undefined method `each_line' for nil:NilClass

Puppet:

Running Puppet agent on demand ...
Failed to load feature test for root: undefined method `each_line' for 
nil:NilClass
C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/parser.rb:73:in `parse': undefined method 
`each_line' for nil:NilClass (NoMethodError)
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/parser.rb:120:in `results'
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/directory_loader.rb:61:in `block in load'
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/directory_loader.rb:55:in `each'
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/directory_loader.rb:55:in `load'
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/composite_loader.rb:10:in `block in load'
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/composite_loader.rb:10:in `each'
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/composite_loader.rb:10:in `load'
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/collection.rb:109:in `load'
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/collection.rb:84:in `fact'
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/collection.rb:139:in `value'
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter.rb:112:in `block (2 levels) in singletonclass'
from C:/Program Files/Puppet 
Labs/Puppet/puppet/lib/puppet/defaults.rb:4:in `default_diffargs'
from C:/Program Files/Puppet 
Labs/Puppet/puppet/lib/puppet/defaults.rb:183:in `module:Puppet'
from C:/Program Files/Puppet 
Labs/Puppet/puppet/lib/puppet/defaults.rb:1:in `top (required)'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in 
`require'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in 
`require'
from C:/Program Files/Puppet 
Labs/Puppet/puppet/lib/puppet.rb:109:in `module:Puppet'
from C:/Program Files/Puppet 
Labs/Puppet/puppet/lib/puppet.rb:29:in `top (required)'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in 
`require'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in 
`require'
from C:/Program Files/Puppet 
Labs/Puppet/puppet/lib/puppet/util/command_line.rb:12:in `top (required)'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in 
`require'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in 
`require'
from C:/Program Files/Puppet 
Labs/Puppet/puppet/bin/puppet:3:in `main'

Downgrading to 3.2.4 fixed the problem and restored functionality. The problem 
does not occur on Windows Server 2008 with Puppet 3.3.0.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving 

[Puppet - Bug #23369] (Accepted) An empty csr_attributes.yaml file fails with undefined method

[tickets]

Issue #23369 has been reported by Josh Cooper.


Bug #23369: An empty csr_attributes.yaml file fails with undefined method
https://projects.puppetlabs.com/issues/23369

* Author: Josh Cooper
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 3.4.0
* Affected Puppet version: 3.4.0-rc1
* Keywords: 
* Branch: 

See 
https://github.com/jpartlow/puppet/commit/406ca2233dd83700ea688ebc9c7d2980db02a65e


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23318] Invalid YAML (hiera) file and automatic param binding fails in vague errors

[tickets]

Issue #23318 has been updated by Henrique Rodrigues.


I have the exact same problem, but using CentOS 64-bit, Puppet 3.3.2, Hiera 
1.2.1 and the normal Puppet parser (not future).


Bug #23318: Invalid YAML (hiera) file and automatic param binding fails in 
vague errors
https://projects.puppetlabs.com/issues/23318#change-101121

* Author: Dolf Schimmel
* Status: Unreviewed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 3.3.2
* Keywords: hiera, automatic parameter binding
* Branch: 

Hi,

In my chain of hiera files I have an empty file. My manifests look as follows:
pre
blockquote

node 'example.com' {
  
  include role::vps::hypervisor

}


class role::vps::hypervisor inherits role::vps {
}


class role::vps inherits role {
  
}


class role {

  include profile::base

}

class profile::base (
  $firewall = params_lookup('firewall', 'global' ),
  $manage_networking = true
) {
  
  # Some code here

}
/pre
/blockquote

This results in the following error:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
undefined method `empty?' for false:FalseClass at role.pp:2 on node example.com

Once I remove the parameters in the profile::base class, the error changes in 
to the little bit more helpful message:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Data 
retrieved from /etc/puppet/hieradata/vps.yaml is String not Hash at 
/etc/puppet/modules/profile/manifests/base.pp:13 on node example.com.

Two issues:ulli
I think an empty or invalid Hiera file should not result in an error at 
all./lili
If, for whatever reason, automatic parameter binding fails, a reasonable error 
should be displayed. In the past I've seen (and reported) several issues where 
the binding failed, and resulted in some vague issues which are hard to debug.
/li/ul
Parser: future (not sure if relevant)br /
br /
Hiera version: 1.3.0br /
Puppet version: 3.3.2br /
OS: Debian 7, 64 bitbr /
Env: Passengerbr /

I wouldn't classify the priority of this issue as low, because it's easy to 
trigger, and really hard to find the cause off the given error message.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23318] Invalid YAML (hiera) file and automatic param binding fails in vague errors

[tickets]

Issue #23318 has been updated by Henrique Rodrigues.


Looks like a duplicate of #23273.


Bug #23318: Invalid YAML (hiera) file and automatic param binding fails in 
vague errors
https://projects.puppetlabs.com/issues/23318#change-101124

* Author: Dolf Schimmel
* Status: Unreviewed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 3.3.2
* Keywords: hiera, automatic parameter binding
* Branch: 

Hi,

In my chain of hiera files I have an empty file. My manifests look as follows:
pre
blockquote

node 'example.com' {
  
  include role::vps::hypervisor

}


class role::vps::hypervisor inherits role::vps {
}


class role::vps inherits role {
  
}


class role {

  include profile::base

}

class profile::base (
  $firewall = params_lookup('firewall', 'global' ),
  $manage_networking = true
) {
  
  # Some code here

}
/pre
/blockquote

This results in the following error:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
undefined method `empty?' for false:FalseClass at role.pp:2 on node example.com

Once I remove the parameters in the profile::base class, the error changes in 
to the little bit more helpful message:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Data 
retrieved from /etc/puppet/hieradata/vps.yaml is String not Hash at 
/etc/puppet/modules/profile/manifests/base.pp:13 on node example.com.

Two issues:ulli
I think an empty or invalid Hiera file should not result in an error at 
all./lili
If, for whatever reason, automatic parameter binding fails, a reasonable error 
should be displayed. In the past I've seen (and reported) several issues where 
the binding failed, and resulted in some vague issues which are hard to debug.
/li/ul
Parser: future (not sure if relevant)br /
br /
Hiera version: 1.3.0br /
Puppet version: 3.3.2br /
OS: Debian 7, 64 bitbr /
Env: Passengerbr /

I wouldn't classify the priority of this issue as low, because it's easy to 
trigger, and really hard to find the cause off the given error message.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23372] (Unreviewed) FreeBSD: Puppet triggers loading of ZFS module

[tickets]

Issue #23372 has been reported by Remko Catersels.


Bug #23372: FreeBSD: Puppet triggers loading of ZFS module
https://projects.puppetlabs.com/issues/23372

* Author: Remko Catersels
* Status: Unreviewed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 
* Keywords: 
* Branch: 

When puppet starts the puppet ZFS provider issues the zfs command. On FreeBSD 
this automatically loads the ZFS kernel module. Even when ZFS is not used on 
that host. The provider should first check if ZFS is enabled or not. If it's 
not enabled it shouldn't execute any zpool or zfs commands as those will 
trigger the automatic load of the kernel module. 


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23372] FreeBSD: Puppet triggers loading of ZFS module

[tickets]

Issue #23372 has been updated by Remko Catersels.

Affected Puppet version set to 3.3.1

Forgot to add the affected puppet version.


Bug #23372: FreeBSD: Puppet triggers loading of ZFS module
https://projects.puppetlabs.com/issues/23372#change-101128

* Author: Remko Catersels
* Status: Unreviewed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 3.3.1
* Keywords: 
* Branch: 

When puppet starts the puppet ZFS provider issues the zfs command. On FreeBSD 
this automatically loads the ZFS kernel module. Even when ZFS is not used on 
that host. The provider should first check if ZFS is enabled or not. If it's 
not enabled it shouldn't execute any zpool or zfs commands as those will 
trigger the automatic load of the kernel module. 


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Feature #23373] (Accepted) Command line manipulation of puppet.conf

[tickets]

Issue #23373 has been reported by Andrew Parker.


Feature #23373: Command line manipulation of puppet.conf
https://projects.puppetlabs.com/issues/23373

* Author: Andrew Parker
* Status: Accepted
* Priority: Normal
* Assignee: Andrew Parker
* Category: 
* Target version: 3.5.0
* Affected Puppet version: 
* Keywords: 
* Branch: 

In order to more easily support setting up new agents, it would be useful to 
have a simple command which could be used to configure the agent.
Something like `puppet config set server=puppet.example.com` would work great. 
The big open question with it is how to support sections in the presence of run 
modes. The simplest seems to be to just ignore run modes (since they don't have 
a bidirectional mapping with sections) and provide an explicit `--section` flag 
(probably with a default of `main`).
The end goal is to be able to easily build an agent install script which looks 
something like this:

pre
yum install -y puppet
puppet config set certname=$(hostname -f)
puppet config set server=puppet.example.com
puppet config set environment=test
puppet resource service puppet ensure=running enable=true
/pre


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23374] (Unreviewed) Ports provider is buggy and lacks several crucial features

[tickets]

Issue #23374 has been reported by Paweł Tomulik.


Bug #23374: Ports provider is buggy and lacks several crucial features
https://projects.puppetlabs.com/issues/23374

* Author: Paweł Tomulik
* Status: Unreviewed
* Priority: High
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 
* Keywords: freebsd ports package
* Branch: 

Hi,

I was trying to use puppet on FreeBSD with more or less success. One of the 
biggest problem was the `ports` package provider, which appears to be buggy and 
lacks some important features. I'm not able to describe in depth all the issues 
I had, so I'll just leave a short list and provide link to description here.

Some of the issues with current ports provider:

  * no way to define *build options* for a package - normally FreeBSD packages 
are first configured by user with `make config`, then compiled + installed. 
Current `ports` provider has no way to configure packages. Without this feature 
it is a little bit useless,
  * to identify packages it uses internally *portnames* instead of *port 
origins*, *portnames* are ambiguous and cause lot of problems (two packages 
with same *portname* may be installed at same time, and puppet is not able to 
handle them correctly),
  * it claims it has `upgradeable` feature, but this doesn't work (what worse - 
it may approach to downgrade in some situations, fortunatelly without luck),
  * to list installed packages it uses `pkg_info`, which is a part of the old 
*pkg* toolstack. FreeBSD is now transitioning to new *pkgng* tools,
  * once installed a package, the provider is unable to uninstall it in most 
cases (dependency problems, when other packages depend on it) - this could be 
easilly mitigated with `uninstall_options`
  * output of `puppet resource package` is ususally wrong,
  * no `install_options` feature,
  * no `uninstall_options` feature,
  * finally, there seems to be no tests (neither system, nor unit) for this 
provider

I've reimplemented the provider. Currently it's available as a standalone 
puppet module for installation, but I would like to propose it to be included 
in puppet core (PR on the way). Most of the issues I've found are resolved the 
new implementation. They're described here: 
https://github.com/ptomulik/puppet-packagex#resolved-issues

For trying and testing, the standalone module is available at 
http://forge.puppetlabs.com/ptomulik/packagex
Repo available at github: https://github.com/ptomulik/puppet-packagex

The PR I'm preparing is simply the `ptomulik-packagex` module converted by a 
shell script to fit to puppet source tree.




-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter - Bug #23368] Script based external facts fail on Windows 2003

[tickets]

Issue #23368 has been updated by Ethan Brown.


* Merged to stable in 
[8eba83858b7ffb3e778c374a1d5b1bdb6e14c819](https://github.com/puppetlabs/facter/commit/8eba83858b7ffb3e778c374a1d5b1bdb6e14c819)
* Merged to master in 
[7130e3acc5f320d8ef7accb6b5d6fae92e833d66](https://github.com/puppetlabs/facter/commit/7130e3acc5f320d8ef7accb6b5d6fae92e833d66)


Bug #23368: Script based external facts fail on Windows 2003
https://projects.puppetlabs.com/issues/23368#change-101129

* Author: Josh Cooper
* Status: In Topic Branch Pending Review
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 1.7.4
* Keywords: windows
* Branch: https://github.com/puppetlabs/facter/pull/569
* Affected Facter version: 1.7.0

Facter's ScriptParser will execute external facts with extensions (bat, cmd, 
com, exe) using ruby's `%x{ }`. On 2003, the path to these files will contain a 
space, e.g. `C:\Documents and Settings\All Users\Application 
Data\PuppetLabs\facter\facts.d`. Since the command is not quoted, it will fail 
(it's interpreted as the command `C:\Documents` with arguments `and`, 
`Settings\All`, etc.

It is not an issue on 2008 and later, because the path to the script does not 
typically contain a space, `C:\ProgramData\PuppetLabs\facter\facts.d`.

It is not an issue with Powershell scripts, because there is a powershell 
specific parser that executes `powershell -File 'path/to/file.ps1'`

It is not an issue for text based external facts, because `File.read` does not 
require the path to be quoted.

The fix is simple, make sure the path is quoted if it contains spaces.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter - Bug #23368] (Merged - Pending Release) Script based external facts fail on Windows 2003

[tickets]

Issue #23368 has been updated by Ethan Brown.

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


Bug #23368: Script based external facts fail on Windows 2003
https://projects.puppetlabs.com/issues/23368#change-101130

* Author: Josh Cooper
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 1.7.4
* Keywords: windows
* Branch: https://github.com/puppetlabs/facter/pull/569
* Affected Facter version: 1.7.0

Facter's ScriptParser will execute external facts with extensions (bat, cmd, 
com, exe) using ruby's `%x{ }`. On 2003, the path to these files will contain a 
space, e.g. `C:\Documents and Settings\All Users\Application 
Data\PuppetLabs\facter\facts.d`. Since the command is not quoted, it will fail 
(it's interpreted as the command `C:\Documents` with arguments `and`, 
`Settings\All`, etc.

It is not an issue on 2008 and later, because the path to the script does not 
typically contain a space, `C:\ProgramData\PuppetLabs\facter\facts.d`.

It is not an issue with Powershell scripts, because there is a powershell 
specific parser that executes `powershell -File 'path/to/file.ps1'`

It is not an issue for text based external facts, because `File.read` does not 
require the path to be quoted.

The fix is simple, make sure the path is quoted if it contains spaces.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23369] (In Topic Branch Pending Review) An empty csr_attributes.yaml file fails with undefined method

[tickets]

Issue #23369 has been updated by Josh Cooper.

Status changed from Accepted to In Topic Branch Pending Review
Branch set to https://github.com/puppetlabs/puppet/pull/2131


Bug #23369: An empty csr_attributes.yaml file fails with undefined method
https://projects.puppetlabs.com/issues/23369#change-101131

* Author: Josh Cooper
* Status: In Topic Branch Pending Review
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 3.4.0
* Affected Puppet version: 3.4.0-rc1
* Keywords: 
* Branch: https://github.com/puppetlabs/puppet/pull/2131

See 
https://github.com/jpartlow/puppet/commit/406ca2233dd83700ea688ebc9c7d2980db02a65e


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23369] (Merged - Pending Release) An empty csr_attributes.yaml file fails with undefined method

[tickets]

Issue #23369 has been updated by Adrien Thebo.

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

Merged into stable in 710e167; this should be released in 3.4.0.


Bug #23369: An empty csr_attributes.yaml file fails with undefined method
https://projects.puppetlabs.com/issues/23369#change-101132

* Author: Josh Cooper
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 3.4.0
* Affected Puppet version: 3.4.0-rc1
* Keywords: 
* Branch: https://github.com/puppetlabs/puppet/pull/2131

See 
https://github.com/jpartlow/puppet/commit/406ca2233dd83700ea688ebc9c7d2980db02a65e


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Feature #22363] (Merged - Pending Release) Implement new evaluator for future parser

[tickets]

Issue #22363 has been updated by Josh Partlow.

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

Merged into master in 8a93b72


Feature #22363: Implement new evaluator for future parser
https://projects.puppetlabs.com/issues/22363#change-101135

* Author: Henrik Lindberg
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: Henrik Lindberg
* Category: language
* Target version: 3.5.0
* Affected Puppet version: 
* Keywords: language parser evaluation
* Branch: https://github.com/puppetlabs/puppet/pull/2123

The future parser currently performs evaluation by transforming the future 
(nick named pops) AST model into the old (3.x) AST and
evaluates the transformed result.

The purpose of this evaluator is to untangle the currently nested evaluation 
behavior (in AST and various other classes) to improve
separation of concerns (leading to robustness and code that is easier to work 
with, debug and extend).

Since evaluation of the pops model currently involves transformation to the 
current AST it is also slow and removal of this step
should boost the performance.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #22365] (Merged - Pending Release) All errors created by future parser ast_transformer lack line numbers

[tickets]

Issue #22365 has been updated by Josh Partlow.

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

Merged into master in 8a93b72


Bug #22365: All errors created by future parser ast_transformer lack line 
numbers
https://projects.puppetlabs.com/issues/22365#change-101136

* Author: Erik Dalén
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: Henrik Lindberg
* Category: parser
* Target version: 3.5.0
* Affected Puppet version: 3.2.4
* Keywords: future_parser
* Branch: https://github.com/puppetlabs/puppet/pull/2123

Errors created by the ast transformer in the future parser have the wrong type, 
so they lack line numbers. An example is:

puppet apply --parser=future -e 'File|| ? {default=foo}'


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #22366] (Merged - Pending Release) The future parser validator doesn't catch using bad resource types in collection queries

[tickets]

Issue #22366 has been updated by Josh Partlow.

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

Merged into master in 8a93b72


Bug #22366: The future parser validator doesn't catch using bad resource types 
in collection queries
https://projects.puppetlabs.com/issues/22366#change-101137

* Author: Erik Dalén
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: Henrik Lindberg
* Category: parser
* Target version: 3.5.0
* Affected Puppet version: 3.2.4
* Keywords: 
* Branch: https://github.com/puppetlabs/puppet/pull/2123

For example:

puppet apply --parser=future -e '1||'
Error: Resource type #puppet::pops::model::literalnumber:0x007f822724c1c8 
doesn't exist on node dalen


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #22454] (Merged - Pending Release) match variables are only partially shadowed

[tickets]

Issue #22454 has been updated by Josh Partlow.

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

Merged into master in 8a93b72


Bug #22454: match variables are only partially shadowed
https://projects.puppetlabs.com/issues/22454#change-101138

* Author: Henrik Lindberg
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: 
* Category: language
* Target version: 3.5.0
* Affected Puppet version: 
* Keywords: language
* Branch: https://github.com/puppetlabs/puppet/pull/2123

Match expressions have the side effect of setting `$0`-`$n` numerical variables 
to the matched, and each matched capture. 
As many variables as there are captures are set.

The implementation in scope creates a new ephemeral scope-level for each match 
expression. As an example:

if 'foobar' =~ /(f)(o)(o)(b)(a)(r)/ and 'foo' =~ /(f)(o)(o)/ {
  notice $4
}

Outputs b since the second match did not have a $4.

This is surprising. The most nested ephemeral scope should be responsible for 
returning all numeric variables (i.e. from the last successful match).

This behavior have been in place for quite some time.





-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #15735] Deprecate 'puppet kick' run mode

[tickets]

Issue #15735 has been updated by Jo Rhett.


You only need java and activemq on a single system, not every system.  Unless 
you have tens of thousands of systems (wherein you wouldn't be arguing for 
puppet kick anyway) activemq's resource consumption will be neglible. For less 
than a thousand systems IMHO you can safely stick this on any other host in 
your puppet architecture: puppetmaster, dashboard, puppetdb, etc.  It has 
near-zero I/O requirements except on the network interface.

Seriously:
pre
$ ps -U activemq -u activemq -o cp,pcpu,pmem,rss,stat,f,etime,cputime,cmd
 CP %CPU %MEM   RSS STAT F ELAPSED TIME CMD
  0  0.0  0.0   1268 Sl  1 16-13:31:12 00:04:19 /usr/sbin/tanukiwrapper 
/usr/share/activemq/conf/activemq-wrapper.conf wrapper.syslog.ident=activemq 
wrapper.pidfile=/var/run/activemq/activemq.pid wrapper.daemonize=TRUE
  1  0.1  1.2 204968 Sl  0 16-13:31:12 00:25:55 java 
-Dactivemq.home=/usr/share/activemq -Dactivemq.base=/usr/share/activemq 
-Dcom.sun.management.jmxremote 
-Dorg.apache.activemq.UseDedicatedTaskRunner=true -Xmx512m -Dja
/pre


Bug #15735: Deprecate 'puppet kick' run mode
https://projects.puppetlabs.com/issues/15735#change-101139

* Author: eric sorenson
* Status: Re-opened
* Priority: High
* Assignee: eric sorenson
* Category: agent
* Target version: 3.x
* Affected Puppet version: 
* Keywords: telly_deprecation
* Branch: https://github.com/puppetlabs/puppet/pull/1129

People interested in `puppet kick` functionality should set up mcollective. 
Supporting it causes problems like #10418. Let's consider removing it for Telly.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23366] (Merged - Pending Release) Puppet on Windows can fail to run depending on load order

[tickets]

Issue #23366 has been updated by Josh Cooper.

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

Merged into stable in 
[541eb25b3](https://github.com/puppetlabs/puppet/commit/541eb25b321fafcae822b9c76e56ea841ca01a68)
 to be released in 3.4.0


Bug #23366: Puppet on Windows can fail to run depending on load order 
https://projects.puppetlabs.com/issues/23366#change-101140

* Author: Josh Cooper
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 3.4.0
* Affected Puppet version: 3.4.0-rc1
* Keywords: windows
* Branch: https://github.com/puppetlabs/puppet/pull/2128

The Puppet::Util::Windows::Security module doesn't require 'ffi' before using 
it. The gem is required in other places, though so this seems to be dependent 
on the load order.

pre
$ ssh administra...@josh-ny1po54a0o.solar.lan cmd.exe /c puppet agent  --test
C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util/windows/security.rb:635:in 
`lt;module:API': uninitialized constant 
Puppet::Util::Windows::Security::API::FFI (NameError)
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util/windows/security.rb:634:in 
`lt;module:Security'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util/windows/security.rb:77:in 
`lt;top (required)'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util/windows.rb:6:in 
`lt;module:Windows'
from C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util/windows.rb:1:in 
`lt;top (required)'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util/monkey_patches.rb:190:in 
`lt;top (required)'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util.rb:16:in 
`lt;module:Util'
from C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util.rb:15:in 
`lt;module:Puppet'
from C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util.rb:14:in `lt;top 
(required)'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet.rb:8:in `lt;top 
(required)'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util/command_line.rb:12:in `lt;top 
(required)'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from C:/ruby193/bin/puppet:3:in `lt;main'
/pre

The fix is simple, add `require 'ffi'`


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Facter - Bug #22944] (Merged - Pending Release) External facts are evaluated many times

[tickets]

Issue #22944 has been updated by Ethan Brown.

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

Merged to stable in 
[e0bdf2873c8ade9d7a06878d66e6bca902417515](https://github.com/puppetlabs/facter/commit/e0bdf2873c8ade9d7a06878d66e6bca902417515)
Merged to master in 
[20b0ee56b1c35c9ca75b98c58d66c93ec61834fc](https://github.com/puppetlabs/facter/commit/20b0ee56b1c35c9ca75b98c58d66c93ec61834fc)


Bug #22944: External facts are evaluated many times
https://projects.puppetlabs.com/issues/22944#change-101145

* Author: Matthias Baur
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 1.7.4
* Keywords: 
* Branch: https://github.com/puppetlabs/facter/pull/570
* Affected Facter version: 1.7.3

** Reproduction **

* Drop script /etc/facter/facts.d/test.sh:
pre
#!/bin/bash
echo SCRIPT CALLED 2
echo test=value
/pre
* Make script executeable
pre
chmod +x /etc/facter/facts.d/test.sh
/pre
* Call 'facter', the following output is shown:
pre
root@puppet:~# facter
SCRIPT CALLED
SCRIPT CALLED
SCRIPT CALLED
SCRIPT CALLED
SCRIPT CALLED
SCRIPT CALLED
...
Regular facter output
...
/pre

I don't see a reason why the script is called 6 times.

System information

* Ubuntu 12.04.3
* Facter 1.7.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 unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23375] (Unreviewed) more verbosity in thing-not-found debug logs

[tickets]

Issue #23375 has been reported by Christopher Wood.


Bug #23375: more verbosity in thing-not-found debug logs
https://projects.puppetlabs.com/issues/23375

* Author: Christopher Wood
* Status: Unreviewed
* Priority: Low
* Assignee: 
* Category: error reporting
* Target version: 
* Affected Puppet version: 3.3.2
* Keywords: 
* Branch: 

Doing something like this to reproduce a file system permissions issue I had:

chmod 000 /etc/puppet/environments/production/modules/puppet

And then doing:

puppet master --environment production --config /etc/puppet/puppetmaster.conf 
--debug --verbose --no-daemonize

Leads to a message like this in the debug output when trying to do an agent run 
:

Error: Could not find class puppet::agent for a1.cw on node a1.cw
Error: Could not find class puppet::agent for a1.cw on node a1.cw
Error: Could not find class puppet::agent for a1.cw on node a1.cw

But from the strace output, we see that actually it was looking for a specific 
thing, and couldn't access that thing:

lstat(/etc/puppet/environments/production/modules/puppet/manifests/agent.pp, 
0x7fff1616b580) = -1 EACCES (Permission denied)

Could we please have the reason (File not found, Permission denied, etc.) 
and the path that the master was looking for also in the debug output following 
the Could not find class line? For example:

Error: Class puppet::agent should be in 
/etc/puppet/environments/production/modules/puppet/manifests/agent.pp but 
stat said Permission denied.

Assuming the same situation might be the case for templates and similar items, 
could we please have similar detailed error logging for those too?

(I searched for my error and couldn't find similar bugs, my apologies if I 
missed one.)


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.