[Puppet - Bug #16106] incorrect command displayed when agent is disabled

[tickets]

Issue #16106 has been updated by Garrett Honeycutt.


What's the next step toward getting this sorted?

Bug #16106: incorrect command displayed when agent is disabled
https://projects.puppetlabs.com/issues/16106#change-80598

Author: Garrett Honeycutt
Status: Accepted
Priority: Normal
Assignee: 
Category: error reporting
Target version: 
Affected Puppet version: 2.7.12
Keywords: errors
Branch: 



[root@system:~]# puppet  agent -t
notice: Skipping run of Puppet configuration client; administratively disabled; 
use 'puppet Puppet configuration client --enable' to re-enable.

[root@system:~]# puppet Puppet configuration client --enable
Error: Unknown Puppet subcommand 'Puppet'
See 'puppet help' for help on available puppet subcommands


The correct command is

[root@system:~]# puppet agent --enable



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #17295] Puppet not honouring --digest

[tickets]

Issue #17295 has been updated by Alex Harvey.

Keywords changed from solaris openssl to solaris openssl hpux

This affects HP-UX as well.

Bug #17295: Puppet not honouring --digest
https://projects.puppetlabs.com/issues/17295#change-80597

Author: Greg Boug
Status: Accepted
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 3.0.1
Keywords: solaris openssl hpux
Branch: 


Am trying to get Puppet 3.0.1 running on Solaris (Previously had 2.7 running no 
problems and have encountered an issue with the SSL digest. 

I'm guessing it was relating to updating the certificates to use SHA256 to be a 
bit more secure, but it means that if the OpenSSL library isn't capable of 
SHA256 then it won't work - even if you tell it to use a different digest. 

For example:


# puppet agent --digest MD5 --verbose --no-daemonize 
Info: Creating a new SSL certificate request for test1
Error: Could not request certificate: uninitialized constant 
OpenSSL::Digest::SHA256


(--debug doesn't give any extra information to help here unfortunately). 

Puppet is using the Solaris-provided OpenSSL as part of the Ruby install in 
this case, which runs version 0.9.7 with patches and doesn't support sha256. I 
don't mind the idea of compiling 1.0.x but the issue still seems to stand that 
you can't choose the digest method anymore - there is an apparent use of SHA256 
regardless of what option you choose. 


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #18023] (Merged - Pending Release) Puppet needs a public, clearly-defined Ruby API

[tickets]

Issue #18023 has been updated by Andrew Parker.

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

Merged in commit 


Bug #18023: Puppet needs a public, clearly-defined Ruby API
https://projects.puppetlabs.com/issues/18023#change-80586

Author: eric sorenson
Status: Merged - Pending Release
Priority: Immediate
Assignee: 
Category: 
Target version: 3.1.0
Affected Puppet version: 
Keywords: backlog
Branch: https://github.com/puppetlabs/puppet/pull/1370


One of the problems people run into using Puppet as part of an infrastructure 
ecosystem is that there isn't a clearly defined Ruby API for it. There are REST 
endpoints that expose some functionality over the network, but they do not 
cover much of the total surface area of what Puppet can do, and things that are 
important for third parties aee probably never going to be exposed over the 
network. (A real-world use case: Foreman wants access to puppet master's 
configuration settings so it can integrate with the CA auth/issuance code). 
Today, people poke directly at internal methods, which both makes it difficult 
to change method signatures and control flow AND provides a crappy experience 
for tool authors. 

So Puppet should have a real, public, published (see #16426) API that the 
development team commits to and the outside world can trust.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #18023] (In Topic Branch Pending Review) Puppet needs a public, clearly-defined Ruby API

[tickets]

Issue #18023 has been updated by Andrew Parker.

Status changed from Accepted to In Topic Branch Pending Review
Assignee deleted (eric sorenson)
Branch set to https://github.com/puppetlabs/puppet/pull/1370



Bug #18023: Puppet needs a public, clearly-defined Ruby API
https://projects.puppetlabs.com/issues/18023#change-80585

Author: eric sorenson
Status: In Topic Branch Pending Review
Priority: Immediate
Assignee: 
Category: 
Target version: 3.1.0
Affected Puppet version: 
Keywords: backlog
Branch: https://github.com/puppetlabs/puppet/pull/1370


One of the problems people run into using Puppet as part of an infrastructure 
ecosystem is that there isn't a clearly defined Ruby API for it. There are REST 
endpoints that expose some functionality over the network, but they do not 
cover much of the total surface area of what Puppet can do, and things that are 
important for third parties aee probably never going to be exposed over the 
network. (A real-world use case: Foreman wants access to puppet master's 
configuration settings so it can integrate with the CA auth/issuance code). 
Today, people poke directly at internal methods, which both makes it difficult 
to change method signatures and control flow AND provides a crappy experience 
for tool authors. 

So Puppet should have a real, public, published (see #16426) API that the 
development team commits to and the outside world can trust.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Facter - Bug #18392] (Unreviewed) virtual.rb facter bug for "vmware -v"

[tickets]

Issue #18392 has been reported by hai wu.


Bug #18392: virtual.rb facter bug for "vmware -v"
https://projects.puppetlabs.com/issues/18392

Author: hai wu
Status: Unreviewed
Priority: High
Assignee: 
Category: 
Target version: 
Keywords: 
Branch: 
Affected Facter version: 


After doing the following in RHEL6 with "facter-1.6.17-1.el6.x86_64":

export PATH=/usr/local/bin:$PATH

mkdir /usr/local/bin/vmware

Then run:

facter -p

You would get this error message:

/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31: command not found: 
/usr/local/bin/vmware -v

This should not occur in the first place. Sounds like security relevant issue. 


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #17887] Failure during property sync results in "Puppet::Util::Log requires a message"

[tickets]

Issue #17887 has been updated by Andrew Parker.

Target version changed from 3.0.x to 3.x

As the 3.0.x line is winding down with the impending release of 3.1.0, I am 
removing the target at 3.0.x from tickets in the system and targeting them at 
3.x instead.

Bug #17887: Failure during property sync results in "Puppet::Util::Log requires 
a message"
https://projects.puppetlabs.com/issues/17887#change-80570

Author: Dominic Cleal
Status: In Topic Branch Pending Review
Priority: Normal
Assignee: Dominic Cleal
Category: transactions
Target version: 3.x
Affected Puppet version: development
Keywords: resource harness, transaction
Branch: https://github.com/puppetlabs/puppet/pull/1358


During provider development and testing with rspec+mocha and using a test 
catalog, an expectation failure can cause the following log message:

Could not evaluate: Puppet::Util::Log requires a message

This occurs if the property sync calls a method that has a mocha expectation 
set, but has reached the max call count or similar.

When testing a catalog from a test, the `Puppet::Transaction::ResourceHarness` 
calls `apply_parameter` for a given parameter, which then calls 
`property.sync`.  If the mocha expectation fails inside this sync, the `rescue` 
block is never called (it isn't an exception) but the `ensure` block is still 
run.  This calls `send_log` on the event, but the message is uninitialised at 
that point so the logging fails with the above error.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #17522] Augeas load warnings printed when less specific context used

[tickets]

Issue #17522 has been updated by Andrew Parker.

Target version changed from 3.0.x to 3.x

As the 3.0.x line is winding down with the impending release of 3.1.0, I am 
removing the target at 3.0.x from tickets in the system and targeting them at 
3.x instead.

Bug #17522: Augeas load warnings printed when less specific context used
https://projects.puppetlabs.com/issues/17522#change-80568

Author: Dominic Cleal
Status: In Topic Branch Pending Review
Priority: Low
Assignee: Dominic Cleal
Category: agent
Target version: 3.x
Affected Puppet version: 3.0.0
Keywords: augeas warning
Branch: https://github.com/puppetlabs/puppet/pull/1280


open_augeas in the Augeas provider tries to optimise (#14136) if the context is 
given.  It also prints a warning if there are load errors while the 
optimisation's in use (since it should only load files you care about, then 
errors are useful) but otherwise at debug level.

The second part of this if statement shouldn't be setting the "restricted" 
variable to true, only in the inner branch.  I think it ended up on the wrong 
line during merging and caused #15569 at the time.


  restricted = false
  if resource[:incl]
aug.set("/augeas/load/Xfm/lens", resource[:lens])
aug.set("/augeas/load/Xfm/incl", resource[:incl])
restricted = true
  elsif glob_avail and opt_ctx
restricted = true
# Optimize loading if the context is given, requires the glob function
# from Augeas 0.8.2 or up
ctx_path = resource[:context].sub(/^\/files(.*?)\/?$/, '\1/')
load_path = "/augeas/load/*['%s' !~ glob(incl) + regexp('/.*')]" % 
ctx_path

if aug.match(load_path).size < aug.match("/augeas/load/*").size
  aug.rm(load_path)
  restricted = true
else
  # This will occur if the context is less specific than any glob
  debug("Unable to optimize files loaded by context path, no glob 
matches")
end
  end



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #17959] File Evaluation not functioning correctly

[tickets]

Issue #17959 has been updated by Andrew Parker.

Target version changed from 3.0.x to 3.x

As the 3.0.x line is winding down with the impending release of 3.1.0, I am 
removing the target at 3.0.x from tickets in the system and targeting them at 
3.x instead.

Bug #17959: File Evaluation not functioning correctly
https://projects.puppetlabs.com/issues/17959#change-80571

Author: Lee Briggs
Status: Needs More Information
Priority: Normal
Assignee: Lee Briggs
Category: 
Target version: 3.x
Affected Puppet version: 3.0.1
Keywords: 
Branch: 


I'm having a strange problem with file evaluation on Puppet 3.0.1.

I have a file stanza like so:


file { "/opt/path/to/file/script.pl":
owner => user,
group => user,
mode  => 755,
ensure => present,
source => "puppet:///modules/modulename/script.pl"
}

I have around 9 or 10 of these files. For each puppet run, it takes 5s to 
evaluate the file.

Info: /Stage[main]/class::class/File[/opt/path/to/file/script.pl]: Evaluated in 
5.07 seconds

md5's of the file match. The problem persists in both a master running on 
webrick and passenger. How can I determine what the cause of this is?


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #17768] bundle install does not install racc

[tickets]

Issue #17768 has been updated by Andrew Parker.

Target version changed from 3.0.x to 3.x

As the 3.0.x line is winding down with the impending release of 3.1.0, I am 
removing the target at 3.0.x from tickets in the system and targeting them at 
3.x instead.

Bug #17768: bundle install does not install racc
https://projects.puppetlabs.com/issues/17768#change-80569

Author: Richard Soderberg
Status: Accepted
Priority: Normal
Assignee: 
Category: 
Target version: 3.x
Affected Puppet version: 3.0.0
Keywords: 
Branch: 


The README indicates that 'bundle install' installs the developer dependencies:

README_DEVELOPER.md:To install the dependencies run: `bundle install` to 
install the dependencies.

However, 'bundle install' does not install 'racc', which is required for 
gen_parser:


$ rake
rake -T
...
rake gen_parser # Generate the parser


I was able to resolve this with 'gem install racc'.


# DO NOT MODIFY
# This file is automatically generated by Racc 1.4.9
# from Racc grammer file "".


As of commit 06ba7d5f81d43b2fd08fe6c101708cb4856d023c.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #17486] Augeas provider warns on parse errors in other files handled by same lens

[tickets]

Issue #17486 has been updated by Andrew Parker.

Target version changed from 3.0.x to 3.x

As the 3.0.x line is winding down with the impending release of 3.1.0, I am 
removing the target at 3.0.x from tickets in the system and targeting them at 
3.x instead.

Bug #17486: Augeas provider warns on parse errors in other files handled by 
same lens
https://projects.puppetlabs.com/issues/17486#change-80567

Author: Linux Bami
Status: Accepted
Priority: Low
Assignee: 
Category: augeas
Target version: 3.x
Affected Puppet version: 3.0.1
Keywords: augeas, provider
Branch: 


Greetings,

we are evaluating Puppet 3.0. At the moment we are getting errors from the 
augeas provider:
Warning: Augeas[xx](provider=augeas): Loading failed for one or more files, 
see debug for /augeas//error output

$ rpm -qa|grep puppet
puppet-server-3.0.1-1.el6.noarch
puppet-3.0.1-1.el6.noarch
puppetdb-terminus-1.0.2-1.el6.noarch
puppet-dashboard-1.2.12-1.el6.noarch
$ rpm -qa|grep augeas
augeas-libs-0.9.0-1.el6.x86_64
augeas-0.9.0-1.el6.x86_64
augeas-devel-0.9.0-1.el6.x86_64
ruby-augeas-0.4.1-1.el6.x86_64

The file manipulation of the files via augtool and the provider works fine but 
we always get the warning.

Same modules works fine with puppet 2.7 without any warnings



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #17278] Double entry when using nagios_host

[tickets]

Issue #17278 has been updated by Andrew Parker.

Target version changed from 3.0.x to 3.x

As the 3.0.x line is winding down with the impending release of 3.1.0, I am 
removing the target at 3.0.x from tickets in the system and targeting them at 
3.x instead.

Bug #17278: Double entry when using nagios_host
https://projects.puppetlabs.com/issues/17278#change-80566

Author: Alexandre Angel
Status: Investigating
Priority: Normal
Assignee: 
Category: nagios
Target version: 3.x
Affected Puppet version: 3.0.1
Keywords: nagios
Branch: 


Hello,

Since upgrade to puppet 3, i have a problem with nagios_host used in local.

I have a class creating nagios_host type.
At first run, it works fine, nagios config file is ok.
On the second run, one of them is added a second time to the nagios confif file 
like puppet failed to see it's already present in the file.
If i try to not add that nagios_host, another one i add is added a second time.

The bugging nagios_host is always the first in file generated. I guess it miss 
the first element when checking for existing host.

Here is log from puppet agent --debug --verbose --no-daemonize concerning 
nagios_host :

1st run :
Debug: 
/Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]/notify:
 subscribes to Service[nagios3]
/Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]/ensure:
 created
Info: 
/Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]:
 Scheduling refresh of Service[nagios3]
Debug: 
/Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]:
 The container Nagios::Switch[sbx908.mydomain.com] will propagate my refresh 
event
Debug: Nagios::Switch[sbx908.mydomain.com]: The container 
Node[webadmin.mydomain.com] will propagate my refresh event

2nd run :
Debug: 
/Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]/notify:
 subscribes to Service[nagios3]
/Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]/ensure:
 created
Info: 
/Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]:
 Scheduling refresh of Service[nagios3]
Debug: 
/Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]:
 The container Nagios::Switch[sbx908.mydomain.com] will propagate my refresh 
event
/Stage[main]/Nagios::Target/Nagios_host[webadmin.mydomain.com]/parents: parents 
changed ['sbx908.mydomain.com'] to 'sbx908.mydomain.com'
Debug: Nagios::Switch[sbx908.mydomain.com]: The container 
Node[webadmin.mydomain.com] will propagate my refresh event




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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #17033] Unpacker should force mv when extracting module to install dir

[tickets]

Issue #17033 has been updated by Andrew Parker.

Target version changed from 3.0.x to 3.x

As the 3.0.x line is winding down with the impending release of 3.1.0, I am 
removing the target at 3.0.x from tickets in the system and targeting them at 
3.x instead.

Bug #17033: Unpacker should force mv when extracting module to install dir
https://projects.puppetlabs.com/issues/17033#change-80564

Author: Dick Olsson
Status: In Topic Branch Pending Review
Priority: Normal
Assignee: Ryan Coleman
Category: module tool
Target version: 3.x
Affected Puppet version: 
Keywords: simplefix
Branch: https://github.com/puppetlabs/puppet/pull/1226


When the Unpacker tries to extract a module containing a broken symlink to its 
install dir the `FileUtils::mv` command fails for some reason. I'm not sure 
why, because moving a directly with broken symlinks is normally ok. But doing a 
force move fixes the problem.

It fails with the following error:

Error executing puppet module install:
puppet module install --debug --verbose --target-dir 
'/etc/puppet/manifests/.tmp/librarian/cache/source/puppet/forge/3792e516e3ff92a0ef9f5e827f8e76eb/puppetlabs/apache/version/9eac01120a372609e0afa3b236d9ed2d'
 --modulepath 
'/etc/puppet/manifests/.tmp/librarian/cache/source/puppet/forge/3792e516e3ff92a0ef9f5e827f8e76eb/puppetlabs/apache/version/9eac01120a372609e0afa3b236d9ed2d'
 --ignore-dependencies 'puppetlabs/apache'
Error: No such file or directory - 
/etc/puppet/manifests/.tmp/librarian/cache/source/puppet/forge/3792e516e3ff92a0ef9f5e827f8e76eb/puppetlabs/apache/version/9eac01120a372609e0afa3b236d9ed2d/apache/spec/fixtures/modules/apache

In my case, it happens to be `librarian-puppet` that's executing `puppet module 
install`, which fails. The broken symlink is coming from the apache module, 
which tries to self reference itself in the `fixtures` folder. This in itself 
might be a bug in the `puppetlabs-apache` module. But still, I think `Unpacker` 
should be able to handle cases like this.

For reference, here's the broken symlink in the `puppetlabs-apache` module:

me@laptop:/tmp/puppetlabs-apache-0.4.0/spec/fixtures/modules# ls -l
lrwxrwxrwx 1 me me  50 Aug 24 23:31 apache -> 
/Users/hunner/Documents/work/git/puppetlabs-apache

Note that the symlink is pointing to a broken place, probably on 
[hunner](https://github.com/hunner)'s computer.
I guess the broken symlink is coming from here: 
https://github.com/puppetlabs/puppetlabs-apache/blob/master/.fixtures.yml#L6

My environment:  
* Ubuntu 12.04  
* Ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]  
* Puppet: 3.0.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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #17105] Hiera booleans are broken -- explicit false value registers as lookup failure

[tickets]

Issue #17105 has been updated by Andrew Parker.

Target version changed from 3.0.x to 3.x

As the 3.0.x line is winding down with the impending release of 3.1.0, I am 
removing the target at 3.0.x from tickets in the system and targeting them at 
3.x instead.

Bug #17105: Hiera booleans are broken -- explicit false value registers as 
lookup failure
https://projects.puppetlabs.com/issues/17105#change-80565

Author: Nick Fagerlund
Status: Accepted
Priority: Normal
Assignee: 
Category: databinding
Target version: 3.x
Affected Puppet version: 3.0.1
Keywords: 
Branch: 


`/var/lib/hiera/common.yaml:`

---
ntp::disabled: false

`fake_classes.pp:`

class ntp ($disabled) { }
include ntp

This explodes! Although a `hiera ntp::disabled` call from the command line 
returns the correct result, Puppet registers this as a failed lookup and bails 
compilation with `Error: Must pass disabled to Class[Ntp]`. This doesn't happen 
with `true`, just `false`.

I assume we're just doing an `if returned_value` or something somewhere, which 
will fail on both `nil` (value not found) and `false` (explicit false value 
found). We can't do that -- booleans are a core data type and Puppet should 
definitely accept them from Hiera.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #17010] win32-dir gem returns a string whose encoding is not `ascii_compatible?`

[tickets]

Issue #17010 has been updated by Andrew Parker.

Target version changed from 3.0.x to 3.x

As the 3.0.x line is winding down with the impending release of 3.1.0, I am 
removing the target at 3.0.x from tickets in the system and targeting them at 
3.x instead.

Bug #17010: win32-dir gem returns a string whose encoding is not 
`ascii_compatible?`
https://projects.puppetlabs.com/issues/17010#change-80563

Author: Ed Sumerfield
Status: Accepted
Priority: Normal
Assignee: Josh Cooper
Category: 
Target version: 3.x
Affected Puppet version: 3.0.0
Keywords: windows
Branch: 


Problem originally defined by this exception:


: irb
irb(main):001:0> require "rspec-puppet"
Failed to load feature test for root: uninitialized constant 
Windows::Synchronize
ArgumentError: string contains null byte
from 
C:/ruby193/lib/ruby/gems/1.9.1/gems/puppet-3.0.0/lib/puppet/util/run_mode.rb:67:in
 `join'
from 
C:/ruby193/lib/ruby/gems/1.9.1/gems/puppet-3.0.0/lib/puppet/util/run_mode.rb:67:in
 `conf_dir'
from 
C:/ruby193/lib/ruby/gems/1.9.1/gems/puppet-3.0.0/lib/puppet/settings.rb:495:in 
`user_config_file'
from 
C:/ruby193/lib/ruby/gems/1.9.1/gems/puppet-3.0.0/lib/puppet/settings.rb:1234:in 
`which_configuration_file'
from 
C:/ruby193/lib/ruby/gems/1.9.1/gems/puppet-3.0.0/lib/puppet/settings.rb:475:in 
`parse_config_files'
from 
C:/ruby193/lib/ruby/gems/1.9.1/gems/puppet-3.0.0/lib/puppet/settings.rb:147:in 
`initialize_global_settings'

from 
C:/ruby193/lib/ruby/gems/1.9.1/gems/puppet-3.0.0/lib/puppet.rb:135:in 
`do_initialize_settings_for_run_mode'

from 
C:/ruby193/lib/ruby/gems/1.9.1/gems/puppet-3.0.0/lib/puppet.rb:123:in 
`initialize_settings'
from 
C:/ruby193/lib/ruby/gems/1.9.1/gems/rspec-puppet-0.1.5/lib/rspec-puppet.rb:10:in
 `'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:60:in `require'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:60:in `rescue in 
require'
from 
C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:35:in `require'
from (irb):1
from C:/ruby193/bin/irb:12:in `
'


Research concluded that ruby 1.9.3 does not support File.join of strings that 
are not UTF-8.  There is a ruby fix associated with this problem mentioned here:



Since this fix is not useful for 1.9.3 the following patch is a possible way 
around it.


class File
  class << self
alias_method :original_join, :join
  end

  def self.join(*args)
new_args = args.collect { |questionableEncoding|
  join_encoding_fix(questionableEncoding)
}
self.send(:original_join, new_args)
  end

  def self.join_encoding_fix(value)
if (value.instance_of?(String))
  value = value.encode("UTF-8")
elsif (value.instance_of?(Array))
  value = value.collect { |subValue|
join_encoding_fix(subValue)
  }
end
value
  end
end



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #16945] apt.puppetlabs.com for Debian Lenny is broken ?

[tickets]

Issue #16945 has been updated by Andrew Parker.

Target version changed from 3.0.x to 3.x

As the 3.0.x line is winding down with the impending release of 3.1.0, I am 
removing the target at 3.0.x from tickets in the system and targeting them at 
3.x instead.

Bug #16945: apt.puppetlabs.com for Debian Lenny is broken ?
https://projects.puppetlabs.com/issues/16945#change-80562

Author: Hien Phan
Status: Investigating
Priority: Normal
Assignee: Matthaus Owens
Category: installation
Target version: 3.x
Affected Puppet version: 3.0.0
Keywords: debian lenny
Branch: 


Hello,

I try to install puppet agent on Debian Lenny. I got following error. Seems the 
repo is broken :

node001:~# wget http://apt.puppetlabs.com/puppetlabs-release-lenny.deb
--2012-10-12 02:12:12--  
http://apt.puppetlabs.com/puppetlabs-release-lenny.deb
Resolving apt.puppetlabs.com... 96.126.116.126, 
2600:3c00::f03c:91ff:fe93:711a
Connecting to apt.puppetlabs.com|96.126.116.126|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3396 (3.3K) [application/x-debian-package]
Saving to: `puppetlabs-release-lenny.deb'

100%[==>]
 3,396   --.-K/s   in 0s  
2012-10-12 02:12:18 (426 MB/s) - `puppetlabs-release-lenny.deb' saved 
[3396/3396]
node001:~# dpkg -i puppetlabs-release-lenny.deb 
Selecting previously deselected package puppetlabs-release.
(Reading database ... 21509 files and directories currently installed.)
Unpacking puppetlabs-release (from puppetlabs-release-lenny.deb) ...
Setting up puppetlabs-release (1.0-5) ...
node001:~# cat /etc/apt/sources.list.d/puppetlabs.list 
# Puppetlabs products 
deb http://apt.puppetlabs.com lenny main
deb-src http://apt.puppetlabs.com lenny main
# Puppetlabs devel (uncomment to activate)
# deb http://apt.puppetlabs.com lenny devel
# deb-src http://apt.puppetlabs.com lenny devel
node001:~# apt-get install puppet
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
puppet: Depends: puppet-common (= 2.7.19-1puppetlabs2) but it is not going 
to be installed
E: Broken packages
node001:~# apt-get update
Hit http://debian.securedservers.com lenny Release.gpg
Hit http://apt.puppetlabs.com lenny Release.gpg 
  
Ign http://apt.puppetlabs.com lenny/main Translation-en_US  
  
Hit http://apt.puppetlabs.com lenny Release 
  
Ign http://debian.securedservers.com lenny/main Translation-en_US
Ign http://apt.puppetlabs.com lenny/main Packages/DiffIndex
Ign http://apt.puppetlabs.com lenny/main Sources/DiffIndex  
Hit http://debian.securedservers.com lenny Release  
Hit http://apt.puppetlabs.com lenny/main Packages
Ign http://debian.securedservers.com lenny/main Packages/DiffIndex
Hit http://apt.puppetlabs.com lenny/main Sources
Ign http://debian.securedservers.com lenny/main Sources/DiffIndex
Hit http://debian.securedservers.com lenny/main Packages
Hit http://debian.securedservers.com lenny/main Sources
Reading package lists... Done
node001:~# apt-get install puppet
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
puppet: Depends: puppet-common (= 2.7.19-1puppetlabs2) but it is not going 
to be installed
E: Broken packages


Please help me fix this error. Thanks in advance.



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #16667] Misleading error message "Not authorized to call find" after upgrading from 2.7 to 3.0

[tickets]

Issue #16667 has been updated by Andrew Parker.

Target version changed from 3.0.x to 3.x

As the 3.0.x line is winding down with the impending release of 3.1.0, I am 
removing the target at 3.0.x from tickets in the system and targeting them at 
3.x instead.

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

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


# Overview

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

# Expected behavior

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


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

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



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


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

# Actual Behavior

In 3.0 this is the user's experience:


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



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #16686] File-Serving Configuration parser does not implement allow_ip statements in fileserver.conf

[tickets]

Issue #16686 has been updated by Andrew Parker.

Target version changed from 3.0.x to 3.x

As the 3.0.x line is winding down with the impending release of 3.1.0, I am 
removing the target at 3.0.x from tickets in the system and targeting them at 
3.x instead.

Bug #16686: File-Serving Configuration parser does not implement allow_ip 
statements in fileserver.conf
https://projects.puppetlabs.com/issues/16686#change-80561

Author: Wolfgang Miedl
Status: Accepted
Priority: Normal
Assignee: 
Category: fileserving
Target version: 3.x
Affected Puppet version: 3.0.0
Keywords: 
Branch: 


In the current 3.0.0 release, the file serving configuration parser incorrectly 
handles "allow_ip" statements in fileserver.conf. Both an allow and allow_ip 
statement will result in Puppet::FileServing::Configuration::Parser.allow being 
called, which again calls Puppet::Network::AuthStore.allow.

This will raise an AuthStoreError in case of an allow_ip statement, as 
Puppet::Network::AuthStore::Declaration.parse fails to parse the parameter. The 
fix is to call Puppet::Network::AuthStore.allow_ip instead in case an allow_ip 
statement is read, which will delegate the parsing to the correct method 
(Puppet::Network::AuthStore::Declaration.parse_ip)

The attached diff illustrates the issue and a possible fix.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #14985] calling_module and calling_class don't always return the calling module/class

[tickets]

Issue #14985 has been updated by Andrew Parker.

Target version changed from 3.0.x to 3.x

As the 3.0.x line is winding down with the impending release of 3.1.0, I am 
removing the target at 3.0.x from tickets in the system and targeting them at 
3.x instead.

Bug #14985: calling_module and calling_class don't always return the calling 
module/class
https://projects.puppetlabs.com/issues/14985#change-80559

Author: Patrick Ramsey
Status: In Topic Branch Pending Review
Priority: Normal
Assignee: 
Category: 
Target version: 3.x
Affected Puppet version: 3.0.0
Keywords: hiera calling_class calling_module defined_type
Branch: https://github.com/puppetlabs/puppet/pull/1214


These two special hiera scope values are looked up by doing ".resource.name" on 
the Puppet::Parser::Scope from which hiera() was called, with the assumption 
that this will always return the class name.  However, if hiera() is called 
from within a define, then @real.resource will be an instance of that define, 
rather than of the class, and the value returned will be the name of that 
resource rather than of the class.

This is unintuitive (as it means calling_module/calling_class aren't set to a 
module or classname), and it breaks the ability to namespace against 
calling_class and title (to give specific resources their own configuration) a 
la

:hierarchy: - %{calling_class}/%{title}

I'll submit a patch later.  For now, I'm working around this by setting a 
constant inside my puppet define and matching against that in /etc/hiera.yaml, 
but that's kind of a hack.




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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #11675] user expiry option fills up the logs

[tickets]

Issue #11675 has been updated by Andrew Parker.

Target version changed from 3.0.x to 3.x

As the 3.0.x line is winding down with the impending release of 3.1.0, I am 
removing the target at 3.0.x from tickets in the system and targeting them at 
3.x instead.

Bug #11675: user expiry option fills up the logs
https://projects.puppetlabs.com/issues/11675#change-80558

Author: Bill Tong
Status: Accepted
Priority: Normal
Assignee: Stefan Schulte
Category: provider
Target version: 3.x
Affected Puppet version: 2.7.9
Keywords: 
Branch: 


puppet should not change the expiry for a user unless the requested expiry 
differs from the current expiry.

user { "root": uid => 0, ensure => "present", "expiry" => "2015-01-01", }

will *always* log every time puppet runs.



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #17896] Hiera tool and hiera_array() returns different data

[tickets]

Issue #17896 has been updated by Andrew Parker.

Target version deleted (3.0.x)



Bug #17896: Hiera tool and hiera_array() returns different data
https://projects.puppetlabs.com/issues/17896#change-80557

Author: Vaidas Jablonskis
Status: Closed
Priority: High
Assignee: 
Category: 
Target version: 
Affected Puppet version: 3.0.1
Keywords: hiera, hiera_array, puppet
Branch: 


Hi People,

I came across an issue where hiera command line tool returns a different data 
to what puppet3.0 builtin hiera does.

When I say different data, I mean hiera tool returns an array of items 
collected throughout the hierarchy, while hiera_array() called from within a 
manifest returns an array of items from the very top level of hierarchy.

Here is my setup example:

YAML data files below:

# cat nodes/node1.example.local.yaml:
foo::conf:
- 'node_specific = foo'
- 'node_specific2 = foo2'

# cat common.yaml:
foo::conf:
- 'common = foo'
- 'common2 = foo2'


That's what I get by running hiera tool on the puppet master:

# hiera -c /etc/puppet/hiera.yaml -a foo::conf environment='development' 
fqdn='node1.example.local'
["node_specific = foo", "node_specific2 = foo2", "common = foo", "common2 = 
foo2"]


>From within the manifest, I use as a parameter:
$conf = hiera_array('foo::conf')

and then I have a template which creates a file on a node:
<% conf.each do |item| -%>
<%= item %>
<% end -%>

.. so what this template create is the following content of a file on node1:
node_specific = foo
node_specific2 = foo2

My hiera.yaml looks like this:
# cat /etc/puppet/hiera.yaml 
---
:hierarchy:
- %{environment}/nodes/%{fqdn}
- %{environment}/roles/%{role}
- %{environment}/common
:backends:
- yaml
#- puppet
:yaml:
:datadir: '/etc/puppet/hieradata'
:puppet:
:datasource: 'data'

The node is in development environment.

To me it looks like a bug unless I am doing something fundamentally wrong?

Thanks,
Vaidas


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #16770] "uninitialized constant ActiveRecord" on puppet 3 w/ storedconfigs

[tickets]

Issue #16770 has been updated by Andrew Parker.

Target version deleted (3.0.x)



Bug #16770: "uninitialized constant ActiveRecord" on puppet 3 w/ storedconfigs
https://projects.puppetlabs.com/issues/16770#change-80556

Author: eric sorenson
Status: Closed
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 3.0.0
Keywords: 
Branch: 


Two users on the mailing list reported the same error loading active record on 
Telly: https://groups.google.com/d/topic/puppet-users/3tC0gYg9XA0/discussion

One is on EL6, the other Ubuntu 10.4


Yesterday my puppetmaster and nodes got upgraded to puppet-3.0.0. 

Since then, all puppet runs have been failing with this error: 

Error: Could not retrieve catalog from remote server: Error 400 on 
SERVER: Could not autoload puppet/indirector/node/active_record: 
uninitialized constant ActiveRecord 


My colleague and I have put a few hours into trying to work out what's 
wrong. rubygem-activerecord-2.1.1-2.el6.noarch is installed from the 
puppetlabs RPM repo. We've reinstalled all components but made no progress. 




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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

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

[tickets]

Issue #16651 has been updated by Andrew Parker.

Target version deleted (3.0.x)



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

Author: Jeff McCune
Status: Duplicate
Priority: Normal
Assignee: 
Category: Faces
Target version: 
Affected Puppet version: 3.0.0
Keywords: faces node face subcommand cloud_provisioner
Branch: 


# Overview

In Puppet 3.0.0, installing the official `puppetlabs-cloud_provisioner` module 
from the forge breaks the `puppet node` subcommand.

# Expected behavior

Installing the cloud_provisioner module should not breaking any existing 
functionality of Puppet core.

# Actual Behavior


root@pe-centos6:~# puppet help node
Error: Could not autoload puppet/face/node/classify: no such file to load -- 
puppet/cloudpack
Error: Could not load help for the face node.
Please check the error logs for more information.

Detail: "Could not autoload puppet/face/node/classify: no such file to load -- 
puppet/cloudpack"

Error: Try 'puppet help help help' for usage


# Steps to reproduce

 1. Install Puppet 3.0.0 from official release RPM's on CentOS 6.3: `yum 
install --enablerepo=puppetlabs-devel puppet puppet-server`
 1. Install the cloud provisoner module: `puppet module install 
puppetlabs-cloud_provisioner`

At this point, the node subcommand shows up as having errors in `puppet help`.  
 `puppet help node` is totally broken as well.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #18187] Cached *root* environment isn't cleared when Puppet::Node::Environment.clear is called

[tickets]

Issue #18187 has been updated by Andrew Parker.

Target version deleted (2.7.x)

As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #18187: Cached *root* environment isn't cleared when 
Puppet::Node::Environment.clear is called
https://projects.puppetlabs.com/issues/18187#change-80553

Author: Dominic Cleal
Status: In Topic Branch Pending Review
Priority: Normal
Assignee: Dominic Cleal
Category: autoloader
Target version: 
Affected Puppet version: 2.7.20
Keywords: autoloader environments type regression
Branch: https://github.com/puppetlabs/puppet/pull/1339


2.7.20 included a backport of a performance fix, which included a change to how 
types are autoloaded.

[commit 
8173a6e6c199426381f1f9fb8d0a71e0d0c12f2a](https://github.com/puppetlabs/puppet/commit/8173a6e6c199426381f1f9fb8d0a71e0d0c12f2a)

commit 8173a6e6c199426381f1f9fb8d0a71e0d0c12f2a
Author: Daniel Pittman 
Date:   Mon Jul 16 23:40:31 2012 -0700

Avoid object creation/destruction when possible.

Object creation and destruction, even over a short time-frame, is 
expensive,
so where we can avoid it we should.

[..]
diff --git a/lib/puppet/metatype/manager.rb b/lib/puppet/metatype/manager.rb
index 597a89f..dfcc74d 100644
--- a/lib/puppet/metatype/manager.rb
+++ b/lib/puppet/metatype/manager.rb
@@ -108,17 +108,24 @@ module Manager
[..]
+# Try loading the type.
+if typeloader.load(name, Puppet::Node::Environment.current)
+  Puppet.warning "Loaded puppet/type/#{name} but no class was created" 
unless @types.include? name
 end

This happens to fix #13858, but now makes the autoloader for types depend on 
the current environment.  I run a module spec and load types from a 
`modulepath` (set up in my module's spec_helper for third party modules).  The 
spec_helper looks a bit like this:

require 'puppetlabs_spec_helper/puppetlabs_spec_helper'
Puppet[:modulepath] = File.join(dir, '..', 'modules')

Puppet is initialised, settings are loaded by the pl_spec_helper / testhelper, 
then I specify a new modulepath, then begin loading types and testing them.

The autoloader calls:

real_env = Puppet::Node::Environment.new(env)

With 2.7.19, env would have been nil (since none was passed in) and so 
`Puppet::Node::Environment` returns the "production" environment.  2.7.20 (see 
commit above) gets the "*root*" environment from 
`Puppet::Node::Environment.current` and passes it in.

Both `TestHelper` and `Puppet::Util::Settings` call 
`Puppet::Node::Environment.clear` when things change (i.e. the modulepath I'm 
setting), but this doesn't clear the special `*root*` environment.  This causes 
the old modulepath to remain cached in both the *root* environment itself and 
the autoloader (which has a thread cache based on the environment object), 
therefore types in the new modulepath can't be found.

With 3.1.0 and Josh's fix in #15529, this isn't a problem since the modulepath 
won't get cached until app_defaults_initialized becomes true, which is just 
before the new modulepath is set, so all is OK.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #18296] Puppet only passes location to 'mount', not device and location, so bind mounts do not work correctly after the inital run.

[tickets]

Issue #18296 has been updated by Andrew Parker.

Target version deleted (2.7.x)

As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #18296: Puppet only passes location to 'mount', not device and location, so 
bind mounts do not work correctly after the inital run.
https://projects.puppetlabs.com/issues/18296#change-80554

Author: Will Marler
Status: Unreviewed
Priority: Normal
Assignee: 
Category: mount
Target version: 
Affected Puppet version: 
Keywords: bind, mount, 
Branch: 


Consider the following manifest:

$server = nas.test.com
$path = nas_export
$fstype = nfs #(In our real-world issue it's gluster, but any fstype works to 
reproduce)

mount {'/mnt/test':
  ensure => 'mounted',
  device => "$server:$path",
  fstype => $fstype,
  options => 'defaults',
  atboot => true,
  require => File['/mnt/test'];
}
  }


  mount{ '/var/mnt':
ensure => 'mounted',
device => "/mnt/test",
fstype => 'none',
options => 'rw,bind',
atboot => 'true',
require => [Mount['/mnt/test'],File['/var/mnt']];
  }


When run on a clean system, it correctly creates & executes the mounts and the 
entries in /etc/fstab. This is good. 

However, if one unmounts /mnt/test and /var/mnt, and re-runs puppet, the NFS 
mount /mnt/test is not re-mounted. Only the bind mount /var/mnt to /mnt/test is 
re-mounted. Puppet throws no errors. 

This occurs because puppet calls the mount command in the above scenario as 
"debug: Puppet::Type::Mount::ProviderParsed: Executing '/bin/mount -o defaults 
/mnt/test'". mount interprets "/mnt/test" as the *device* to be mounted and 
performs the bind mount (which works, so no error is thrown), rather than as 
the *location* which should be attached to nas.test.com:nfs_export. This is 
probably "mount" default behavior. 

A solution would be for puppet to call the "mount -o   " removing the ambiguity of "/mnt/test".




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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Feature #17903] The LDAP group provider is hard-coded to manage posixGroup and it's member attribute

[tickets]

Issue #17903 has been updated by Andrew Parker.

Target version deleted (2.7.x)

As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Feature #17903: The LDAP group provider is hard-coded to manage posixGroup and 
it's member attribute
https://projects.puppetlabs.com/issues/17903#change-80552

Author: Neil Hemingway
Status: Unreviewed
Priority: Normal
Assignee: Neil Hemingway
Category: provider
Target version: 
Affected Puppet version: 2.7.20
Keywords: 
Branch: 


On redhat, it's useful to be able to manage also groupOfUniqueNames, with it's 
uniqueMember attribute.

nss_ldap allows the uniqueMember attribute to be nested.  This provides the 
ability to group users into organisational groups and functional groups can 
then be defined in terms of the organisational ones.

For example the following LDIF provides for only having to manage user accounts 
once:

cn=operations, ou=Groups, o=$myorg
uniqueMember: uid=developer1, ou=People, o=$myorg
uniqueMember: uid=developer2, ou=People, o=$myorg

cn=developers, ou=Groups, o=$myorg
uniqueMember: uid=sysadmin1, ou=People, o=$myorg
uniqueMember: uid=sysadmin2, ou=People, o=$myorg

cn=ssh_access, ou=Groups, o=$myorg
uniqueMember: cn=operations, ou=Groups, o=$myorg
uniqueMember: cn=developers, ou=Groups, o=$myorg

would allow all four listed users ssh access to the system in question.  The 
advantage is when developer3 comes along, adding them to the developers group 
automatically grants ssh access.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #17457] Date-like strings are munged during serialization, breaking puppet inspect runs

[tickets]

Issue #17457 has been updated by Andrew Parker.

Target version deleted (2.7.x)

As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #17457: Date-like strings are munged during serialization, breaking puppet 
inspect runs
https://projects.puppetlabs.com/issues/17457#change-80551

Author: Ken Johnson
Status: Tests Insufficient
Priority: Normal
Assignee: David Gwilliam
Category: zaml
Target version: 
Affected Puppet version: 
Keywords: 
Branch: https://github.com/puppetlabs/puppet/pull/1281


So, we had a customer hit an issue with the way Puppet audit changes the date 
in catalogs. This seems to pop up specifically with user resources present 
which have the expiry parameter specified. When a node is affected Puppet 
inspect runs throw an error that looks like this:

Error message from cron:
Could not run: Parameter expiry failed: Expiry dates must be -MM-DD at 
/etc/puppetlabs/puppet/modules/env/manifests/somemanifest.pp:51

Lindsey was able to replicate this by following these steps:

To reproduce, in a PE 2.6 environment:
1) Add the following resource to site.pp:
user {'expirer': 
expiry => '2020-05-01', 
}
2) Run puppet apply -t
3) Run puppet inspect
It looks like the expiry field is getting serialized in the cached catalog in a 
way that makes it unserialize back in to Ruby as not-a-string. This causes 
inspect, which uses the cached catalog, to trip up when validating the expiry:
[3] pry(main)> '2020-05-10' !~ /^\d{4}-\d{2}-\d{2}$/
=> false
[4] pry(main)> 2020-05-10 !~ /^\d{4}-\d{2}-\d{2}$/
=> true
You can verify this is the case by editing the cached catalog and quoting the 
'expiry' value (e.g. from `!ruby/sym expiry: 2020-05-01` to `!ruby/sym expiry: 
"2020-05-01"`.



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #17031] Can't add domain user account as a member of a local group

[tickets]

Issue #17031 has been updated by Andrew Parker.

Target version deleted (2.7.x)

As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #17031: Can't add domain user account as a member of a local group
https://projects.puppetlabs.com/issues/17031#change-80549

Author: Josh Cooper
Status: Accepted
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 2.7.6
Keywords: windows user group domain
Branch: 


This is a common need when managing domain service accounts that need to be a 
member of the local Administrators account. I thought it would be resolved once 
#16581 was fixed, but there's a more fundamental issue with the group provider, 
so I'm filing this as a separate issue.

First, it attempts to add members to the group using an ADSI path of 
`WinNT://WIN-QP47VOHA2P4/BIZARRO\albert,user`, but it needs to be 
`WinNT://WIN-QP47VOHA2P4/BIZARRO/albert,user`


def add_members(*names)
  names.each do |name|
native_group.Add(Puppet::Util::ADSI::User.uri(name))
  end
end


It may be possible to just use the SID form `WinNT://` but I'm not sure if 
that will work in a non-domain environment.

Second, when calculating whether the group's members are insync? it compares 
names:


  members_to_add = desired_members - current_members
  add_members(*members_to_add)


However the ADSI provider returns current members as, e.g. `albert`. But since 
this doesn't match `BIZARRO\albert`, the provider will think the resource is 
out of sync and will attempt to re-add a user that is already a member of the 
group and fail:


err: /Stage[main]//Group[Foobars]/members: change from albertAdministrator to 
BIZARRO\albert Administrator failed: Add
OLE error code:80070562 in Active Directory
  The specified account name is already a member of the group.

HRESULT error code:0x80020009
  Exception occurred.


Really, the group provider needs to compare the current vs desired SIDs to 
determine which users to add, similar to what we do in the file and 
scheduled_task providers.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #17055] Portage package provider seeing incorrect installed version when using latest and category

[tickets]

Issue #17055 has been updated by Andrew Parker.

Target version deleted (2.7.x)

As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #17055: Portage package provider seeing incorrect installed version when 
using latest and category
https://projects.puppetlabs.com/issues/17055#change-80550

Author: Yun Zheng Hu
Status: Investigating
Priority: Normal
Assignee: eric sorenson
Category: provider
Target version: 
Affected Puppet version: 2.7.18
Keywords: mysql eix gentoo latest category
Branch: 


It seems Gentoo's package provider around eix seems to work incorrectly when 
using a "category" and "latest".
(i'm currently using puppet-2.7.18-r1)

Example for mysql, my current portage tree has the following version as the 
latest stable: 5.1.62-r1

This version will install when you do:

puppet apply -e 'package { "mysql": ensure => latest, category => 'dev-db' 
}' --verbose --debug

Running this again will result in:
debug: Puppet::Type::Package::ProviderPortage: Executing '/usr/bin/eix 
--nocolor --pure-packages --stable --installed --format   
[] []  

'
debug: Puppet::Type::Package::ProviderPortage: Executing '/usr/bin/eix 
--nocolor --pure-packages --stable --format   
[] []  

--exact --category-name dev-db/mysql'
debug: /Stage[main]//Package[mysql]/ensure: mysql "5.1" is installed, 
latest is "5.1.62-r1"
debug: Puppet::Type::Package::ProviderPortage: Executing '/usr/bin/emerge 
dev-db/mysql'

As it looks like it seems that it think mysql is on version 5.1 due to the 
virtual package:
eix --exact virtual/mysql
[I] virtual/mysql
Available versions:  [M]4.0 [M]4.1 [M]5.0 5.1{tbz2} [M]~5.2 [M]~5.3 [M]~5.5 
{{embedded minimal static}}
Installed versions:  5.1{tbz2}(18:14:35 10/17/12)(-embedded -minimal 
-static)
Description: Virtual for MySQL client or database


My current workaround is to specify the category name in the package name 
itself, which will not reinstall the package.
puppet apply -e 'package { "dev-db/mysql": ensure => latest }' --verbose 
--debug




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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #16623] yum helper fails when using a custom yum plugin with custom variables

[tickets]

Issue #16623 has been updated by Andrew Parker.

Target version deleted (2.7.x)

As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #16623: yum helper fails when using a custom yum plugin with custom 
variables
https://projects.puppetlabs.com/issues/16623#change-80548

Author: Tim Yim
Status: Needs More Information
Priority: Normal
Assignee: Tim Yim
Category: yumrepo
Target version: 
Affected Puppet version: 2.7.9
Keywords: yumrepo yum
Branch: 


We have a custom yum plugin that provides a custom variable for use in our 
.repo files and the Puppet yum helper does not function correctly with custom 
variables.

First, we ensure our yum plugin is installed on all machines:

package {
'SNC-2-1-1-1:.:.:snc-yum':
name   => 'snc-yum',
ensure => installed
}

Then, we set up our repositories.

sncyumrepo {
'SNC-2-1-3-1:.:.:yumrepo-base':
name => 'base',
alias=> 'base',
descr=> 'CentOS Base Repository',
baseurl  => 'http://repo/centos/$sncversion/os/$basearch/',
enabled  => 1,
gpgcheck => 1,
gpgkey   => 'file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-$releasever',
require  => File['yumparentdir']
}

Notice the baseurl contains our custom variable: $sncversion. This is the 
variable that is provided by the yum plugin.

This will write our the base.repo file WITH that variable in the final output. 
The variable is the replaced by yum just like the built-in yum variable 
$releasever.

Then, we attempt to use the base.repo and it fails!

package {
'SNC-2-1-1-1:.:.:any-package':
name   => 'any-package',
ensure => installed
}

Every call to 'package' that uses the base.repo will fail and also cause the 
yum metadata to be in an inconsistent state. We are forced to run a 'yum clean 
all'.

We believe the Puppet yum helper is not properly using the yum environment and 
is therefore unable to replace the value of $sncversion when trying to install 
a package from the base.repo.

For your convenience, I have attached an RPM of our yum plugin. It is very, 
very basic and is safe to install on el5 and el6. I've included the .src RPM as 
well in case you would like to review the plugin code.



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Feature #16114] Don't reparse puppet.conf when file is merely accessed, not actually modified

[tickets]

Issue #16114 has been updated by Andrew Parker.

Target version deleted (2.7.x)

As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Feature #16114: Don't reparse puppet.conf when file is merely accessed, not 
actually modified
https://projects.puppetlabs.com/issues/16114#change-80547

Author: Nick Chappell
Status: Needs More Information
Priority: Normal
Assignee: Nick Chappell
Category: parser
Target version: 
Affected Puppet version: 2.7.9
Keywords: 
Branch: 


Would it be possible to prevent puppet.conf from being reparsed if the file is 
merely accessed and not actually modified?


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #16106] incorrect command displayed when agent is disabled

[tickets]

Issue #16106 has been updated by Andrew Parker.

Target version deleted (2.7.x)

As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #16106: incorrect command displayed when agent is disabled
https://projects.puppetlabs.com/issues/16106#change-80546

Author: Garrett Honeycutt
Status: Accepted
Priority: Normal
Assignee: 
Category: error reporting
Target version: 
Affected Puppet version: 2.7.12
Keywords: errors
Branch: 



[root@system:~]# puppet  agent -t
notice: Skipping run of Puppet configuration client; administratively disabled; 
use 'puppet Puppet configuration client --enable' to re-enable.

[root@system:~]# puppet Puppet configuration client --enable
Error: Unknown Puppet subcommand 'Puppet'
See 'puppet help' for help on available puppet subcommands


The correct command is

[root@system:~]# puppet agent --enable



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #15992] Report failed if puppet agent get new configuration for itself and restart

[tickets]

Issue #15992 has been updated by Andrew Parker.

Target version deleted (2.7.x)

As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #15992: Report failed if puppet agent get new configuration for itself and 
restart
https://projects.puppetlabs.com/issues/15992#change-80544

Author: Kiril Varnakov
Status: Needs More Information
Priority: Normal
Assignee: Kiril Varnakov
Category: reports
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


If i run puppet agent in first time and it get new configuration for itself and 
restart, i see in dashboard failed report.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #16003] Agent running has transfered to puppetmaster but curl can not capture it,Curl process is hanging.

[tickets]

Issue #16003 has been updated by Andrew Parker.

Target version deleted (2.7.x)

As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #16003: Agent running has transfered to puppetmaster but curl can not 
capture it,Curl process is hanging.
https://projects.puppetlabs.com/issues/16003#change-80545

Author: 俊锋 张
Status: Needs More Information
Priority: Normal
Assignee: 俊锋 张
Category: exec
Target version: 
Affected Puppet version: 2.7.12
Keywords: exec,curl
Branch: 


We use command Curl to trigger puppet run. The command is like this:


curl -k -X PUT -H "Content-Type: text/pson" -d "{}" 
https://192.150.33.247:8139/production/run/no_key


In these days we find when we push a package and a install script to agent and 
trigger to execut that script(exec resource) to install the package.The 
procedure takes nearly an hour.And agent sent its reports to master ,but it 
looks like command "curl" did not receive any thing becasuse we can get nothing 
from it.

Please tell me how to fix it?


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Feature #15629] puppet package provider portupgrade -> install_options support

[tickets]

Issue #15629 has been updated by Andrew Parker.

Target version deleted (2.7.x)

As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Feature #15629: puppet package provider portupgrade -> install_options support
https://projects.puppetlabs.com/issues/15629#change-80542

Author: jayendren maduray
Status: Code Insufficient
Priority: Normal
Assignee: jayendren maduray
Category: package
Target version: 
Affected Puppet version: 2.7.16
Keywords: freebsd portupgrade.rb install_options
Branch: 


class entry:

package { 'dns/unbound':
ensure  => 'installed',
provider=> 'portupgrade',
install_options => '-m "CONFIGURE_ARGS=--with-ssl=/usr/local" -m 
"CONFIGURE_ARGS=--with-ldns-builtin" -m "CONFIGURE_ARGS=--disable-gost" -m 
"CONFIGURE_ARGS=--with-libevent=/usr/local"'
}

puppet log:
info: /Package[dns/unbound]: Provider portupgrade does not support features 
install_options; not managing attribute install_options

patch:
--- portupgrade.rb  2012-07-20 11:15:00.0 +0200
+++ /root/portupgrade.rb2012-07-20 11:10:35.0 +0200
@@ -9,7 +9,7 @@
for the portupgrade port."
## has_features is usually autodetected based on defs below.
-   has_features :installable, :uninstallable, :upgradeable, 
:install_options
+  # has_features :installable, :uninstallable, :upgradeable
commands :portupgrade   => "/usr/local/sbin/portupgrade",
:portinstall   => "/usr/local/sbin/portinstall",
@@ -35,7 +35,7 @@
# regex to match output from pkg_info
regex = %r{^(\S+)-([^-\s]+):(\S+)$}
# Corresponding field names
-fields = [:portname, :ensure, :portorigin, :install_options]
+fields = [:portname, :ensure, :portorigin]
# define Temporary hash used, packages array of hashes
hash = Hash.new
packages = []
@@ -63,7 +63,6 @@
# Set :provider to this object name
hash[:name] = hash[:portorigin]
hash[:provider] = self.name
-hash[:options] = hash[:install_options]
# Add to the full packages listing
packages << new(hash)
@@ -82,7 +81,7 @@
def install
Puppet.debug "portupgrade.install() - Installation call on 
#{@resource[:name]}"
# -M: yes, we're a batch, so don't ask any questions
-cmdline = ["-M BATCH=yes", @resource[:name], 
@resource[:install_options]]
+cmdline = ["-M BATCH=yes", @resource[:name]]
# FIXME: it's possible that portinstall prompts for data so locks up.
begin

puppet log:
debug: Puppet::Type::Package::ProviderPortupgrade: Executing 
'/usr/local/sbin/portinstall -M BATCH=yes dns/unbound -m 
"CONFIGURE_ARGS=--with-ssl=/usr/local" -m "CONFIGURE_ARGS=--with-ldns-builtin" 
-m "CONFIGURE_ARGS=--disable-gost" -m 
"CONFIGURE_ARGS=--with-libevent=/usr/local"'
notice: 
/Stage[main]//Node[freebsd_anycast_dns_server_unbound]/Package[dns/unbound]/ensure:
 created
unbound:
# unbound -h
usage:  unbound [options]
start unbound daemon DNS resolver.
-h  this help
-c file config file to read instead of 
/usr/local/etc/unbound/unbound.conf
file format is described in unbound.conf(5).
-d  do not fork into the background.
-v  verbose (more times to increase verbosity)
Version 1.4.17
linked libs: libevent 1.4.14b-stable (it uses kqueue), ldns 1.6.13, OpenSSL 
0.9.8q 2 Dec 2010
linked modules: validator iterator
configured for amd64-portbld-freebsd9.0 on Fri Jul 20 11:15:56 SAST 2012 
with options: '--with-ssl=/usr' '--disable-gost' '--disable-ecdsa' 
'--with-libevent=/usr/local' '--prefix=/usr/local' '--mandir=/usr/local/man' 
'--infodir=/usr/local/info/' '--build=amd64-portbld-freebsd9.0'
BSD licensed, see LICENSE in source package for details.
Report bugs to unbound-b...@nlnetlabs.nl


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Feature #15873] OpenBSD service provider

[tickets]

Issue #15873 has been updated by Andrew Parker.

Target version deleted (2.7.x)

As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Feature #15873: OpenBSD service provider
https://projects.puppetlabs.com/issues/15873#change-80543

Author: Lucas Yamanishi
Status: Accepted
Priority: Normal
Assignee: 
Category: provider
Target version: 
Affected Puppet version: 
Keywords: openbsd
Branch: 


As of [version 4.9][4.9 release announcement], OpenBSD supports the use of 
service-specific scripts in /etc/rc.d.  This new framework provides a 
consistent interface to _start_, _stop_, _check_ (status) and _reload_ 
functionality.  Puppet should add support for this via a provider for the 
service resource type.

Documentation may be found in the man pages for [rc.d(8)][rc.d(8)] and 
[rc.subr(8)][rc.subr(8)].

[4.9 release announcement]:http://www.openbsd.org/49.html
[rc.d(8)]:http://www.openbsd.org/cgi-bin/man.cgi?query=rc.d
[rc.subr(8)]:http://www.openbsd.org/cgi-bin/man.cgi?query=rc.subr


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #15559] Puppet can't write into directories it creates on Windows unless SYSTEM account is explicitly given write access

[tickets]

Issue #15559 has been updated by Andrew Parker.

Target version deleted (2.7.x)

As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #15559: Puppet can't write into directories it creates on Windows unless 
SYSTEM account is explicitly given write access
https://projects.puppetlabs.com/issues/15559#change-80540

Author: Adam Roben
Status: Accepted
Priority: Normal
Assignee: Josh Cooper
Category: file
Target version: 
Affected Puppet version: 2.7.6
Keywords: windows file permissions dacl ace
Branch: 


Given a manifest like the following:

user { 'SomeUser':
  home => 'C:/Users/SomeUser'
  password => 'SomePassword',
}

file {
  'C:/Users/SomeUser':
ensure  => directory,
owner   => 'SomeUser',
group   => 'SomeUser',
mode=> '0775'
require => User['SomeUser'];
  'C:/Users/SomeUser/SomeFile.txt':
ensure  => present;
}

Puppet will fail to create SomeFile.txt because it doesn't have permission to 
write to C:\Users\SomeUser.

On Linux, where Puppet typically runs as root, this is not a problem. But on 
Windows, the user running Puppet needs to explicitly be given write permissions 
to C:\Users\SomeUser. Perhaps Puppet should do that automatically? This would 
both make Puppet's behavior more intuitive, and make it easier to share 
manifests between Linux and Windows.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #15561] Fix for CVE-2012-3867 is too restrictive

[tickets]

Issue #15561 has been updated by Andrew Parker.

Target version deleted (2.7.x)

As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #15561: Fix for CVE-2012-3867 is too restrictive
https://projects.puppetlabs.com/issues/15561#change-80541

Author: Dustin Mitchell
Status: Accepted
Priority: Urgent
Assignee: 
Category: SSL
Target version: 
Affected Puppet version: 2.7.18
Keywords: certificate
Branch: https://github.com/puppetlabs/puppet/pull/1101


The fix for CVE-2012-3867 involves checking certificate subjects for "weird" 
characters.  From my read of the CVE entry, this is to filter out characters 
that would cause the name to display in a manner visually indistinguishable 
from a valid hostname.

However, the check is too restrictive:

Could not retrieve catalog from remote server: Certname "puppetagain base 
ca/emailaddress=rele...@mozilla.com/ou=release engineering/o=mozilla, inc." 
must not contain unprintable or non-ASCII characters

In particular, / is a very common character in subjects, and should be allowed. 
 Puppet is seeing this subject on my base CA - I'm using certificate chaining.

The fix is one character, so I haven't included a patch, but I'm happy to make 
a pull req if necessary.

Another fix would be to only verify certificate subjects for the leaf 
certificate, and not any of the certs in its signing chain, but that seems less 
secure.

It's also worth noting that the regex is overly broad, since it downcases the 
string, then accepts A-Z among other characters.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #15534] Could not evaluate: undefined method `each' for #

[tickets]

Issue #15534 has been updated by Andrew Parker.

Target version deleted (2.7.x)

As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #15534: Could not evaluate: undefined method `each' for 
#
https://projects.puppetlabs.com/issues/15534#change-80539

Author: Ryan Conway
Status: Accepted
Priority: High
Assignee: 
Category: ruby19
Target version: 
Affected Puppet version: 2.7.18
Keywords: upstart ruby19
Branch: 


I'm seeing what looks like issue #12268 with the latest Puppet 2.7.18, using 
Ruby 1.9.2p290 on Ubuntu 12.04 LTS. (I can't re-open that one hence the 
separate ticket).

Using the following resource: 

service { "ssh":
enable => true,
ensure => running,
subscribe => [File["/etc/default/ssh"], File["/etc/ssh/sshd_config"]],
}

I get the following error:

err: /Stage[main]/Ih-default/Ssh-client[ih]/Service[ssh]: Could not 
evaluate: undefined method `each' for #

And the full stack trace:

debug: /Stage[main]/Ih-default/Ssh-client[ih]/File[/etc/default/ssh]: The 
container Ssh-client[ih] will propagate my refresh event
debug: Puppet::Type::Service::ProviderUpstart: Executing '/sbin/status ssh'
debug: Puppet::Type::Service::ProviderUpstart: Executing '/sbin/initctl 
--version'

/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/provider/service/upstart.rb:203:in
 `enabled_post_0_9_0?'

/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/provider/service/upstart.rb:101:in
 `enabled?'

/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/type/service.rb:55:in
 `retrieve'
/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/type.rb:720:in 
`block in retrieve'
/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/type.rb:715:in 
`each'
/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/type.rb:715:in 
`retrieve'
/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/type.rb:728:in 
`retrieve_resource'

/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/transaction/resource_harness.rb:32:in
 `perform_changes'

/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/transaction/resource_harness.rb:133:in
 `evaluate'

/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/transaction.rb:49:in
 `apply'

/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/transaction.rb:84:in
 `eval_resource'

/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/transaction.rb:104:in
 `block (2 levels) in evaluate'
/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/util.rb:490:in 
`block in thinmark'
/usr/local/lib/ruby/1.9.1/benchmark.rb:310:in `realtime'
/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/util.rb:489:in 
`thinmark'

/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/transaction.rb:104:in
 `block in evaluate'

/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/transaction.rb:386:in
 `traverse'

/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/transaction.rb:99:in
 `evaluate'

/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/resource/catalog.rb:141:in
 `apply'

/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/configurer.rb:122:in
 `block in retrieve_and_apply_catalog'
/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/util.rb:160:in 
`block in benchmark'
/usr/local/lib/ruby/1.9.1/benchmark.rb:310:in `realtime'
/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/util.rb:159:in 
`benchmark'

/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/configurer.rb:121:in
 `retrieve_and_apply_catalog'

/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/configurer.rb:152:in
 `run'
/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/agent.rb:43:in 
`block (4 levels) in run'

/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/agent/locker.rb:21:in
 `lock'
/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/agent.rb:43:in 
`block (3 levels) in run'
/usr/local/lib/ruby/1.9.1/sync.rb:225:in `sync_synchronize'
/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/agent.rb:43:in 
`block (2 levels) in run'
/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/agent.rb:95:in 
`with_client'
/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/agent.rb:41:in 
`block in run'

/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/application.rb:172:in
 `call'

/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/application.rb:172:in
 `controlled_run'
/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/agent.rb:39:in 
`run'

/usr/local/lib/ruby/gems/1.9.1/gems/puppet-2.7.18/lib/puppet/ap

[Puppet - Bug #15292] environment is empty in failed reports

[tickets]

Issue #15292 has been updated by Andrew Parker.

Target version deleted (2.7.x)

As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #15292: environment is empty in failed reports
https://projects.puppetlabs.com/issues/15292#change-80538

Author: Patrick Otto
Status: Needs More Information
Priority: Normal
Assignee: Patrick Otto
Category: reports
Target version: 
Affected Puppet version: 2.7.14
Keywords: 
Branch: 


If a node fails to run it will not set the environment in the report.

# puppet agent --no-usecacheonfailure --onetime


# Node manifest
node 'node' { fail('blah') }


# /var/lib/puppet/state/last_run_report.yaml
--- !ruby/object:Puppet::Transaction::Report
configuration_version: 
environment: 
host: node.dev
kind: apply
logs: 
# ...



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #14790] catch-22 in dependancy ordering for user and ssh_authorized_key

[tickets]

Issue #14790 has been updated by Andrew Parker.

Target version deleted (2.7.x)

As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #14790: catch-22 in dependancy ordering for user and ssh_authorized_key
https://projects.puppetlabs.com/issues/14790#change-80535

Author: Jo Rhett
Status: Accepted
Priority: Normal
Assignee: 
Category: agent
Target version: 
Affected Puppet version: 2.7.14
Keywords: 
Branch: 


In theory, the dependancy of the ssh_authorized_key upon the user makes sense, 
but in practice it fails.

You can't create the ssh_authorized_key until the user exists, check.
You can't remove the ssh_authorized_key unless the user fails... fail.

There's no simple way to order this such that an ssh key is removed when the 
user is removed.

The only way around this problem is the rather ugly:


if $ensure == 'absent' {
ssh_authorized_key{ "system-$username":
ensure  => absent,
name=> "system-$username",
target  => "/etc/ssh/keys/$username",
user=> $username,
type=> $keytype,
key => $key, 
before  => User[$username],
}
}

user { $username:
ensure => $ensure,
comment=> $comment,
home   => $home,
shell  => $shell,
uid=> $uid,
gid=> $groupname,
managehome => true,
system => false,
require=> Group[$groupname]
}   

if $ensure == 'present' {
ssh_authorized_key{ "system-$username":
ensure  => present,
name=> "system-$username",
target  => "/etc/ssh/keys/$username",
user=> $username,   

type=> $keytype,
key => $key, 
} 
} 


That seems a long bit unpuppet-like.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #15106] Missing site.pp can cause error 'Cannot find definition Class'

[tickets]

Issue #15106 has been updated by Andrew Parker.

Target version deleted (2.7.x)

As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #15106: Missing site.pp can cause error 'Cannot find definition Class'
https://projects.puppetlabs.com/issues/15106#change-80536

Author: Ken Barber
Status: Accepted
Priority: Normal
Assignee: 
Category: compiler
Target version: 
Affected Puppet version: 2.7.12
Keywords: 
Branch: 


In certain content scenarios, a missing site.pp can cause the error:

err: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Cannot find definition Class at 
/etc/puppetlabs/puppet/modules/mymodule/manifests/init.pp:3 on node foobar

This can be remedied by touching the site.pp, but since site.pp is no longer 
mandatory this is causing issues for users who are specifically omitting.

This is confirmed at a customer site using PE 2.5.0 running Puppet 2.7.12. This 
is specifically reproducible when the user is using environments, and 
apparently doesn't occur without environments.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #14589] Puppet performs excessive stats when loading types (and other things)

[tickets]

Issue #14589 has been updated by Andrew Parker.

Target version deleted (2.7.x)

As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #14589: Puppet performs excessive stats when loading types (and other 
things)
https://projects.puppetlabs.com/issues/14589#change-80532

Author: Daniel Pittman
Status: Investigating
Priority: Normal
Assignee: 
Category: performance
Target version: 
Affected Puppet version: 2.6.15
Keywords: 
Branch: 


At MediaTemple we traced down excess stat calls for `.../type` directories to 
the autoloader: when evaluating the full set of paths to search it would 
directly stat all possible directories on the path *every time*, rather than 
using the existing file cache mechanisms in place.

The fix, in 2.6.15, for this is here:

https://gist.github.com/2727690#file_use_dir_cache.patch

The second patch is the relevant one - it fixes the performance problem by 
using the existing autoloader `searchpath` implementation on the 2.6.x branch.

It looks like some of this might port forward to at least 2.7.x, and master 
should also be checked.

This is a substantial performance improvement for users who have slow 
file-systems.  (eg: distributed FS, or EC2 nodes)


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #14660] package provider gem does not use the specified source if ensure => latest

[tickets]

Issue #14660 has been updated by Andrew Parker.

Target version deleted (2.7.x)

As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #14660: package provider gem does not use the specified source if ensure => 
latest
https://projects.puppetlabs.com/issues/14660#change-80533

Author: Evgeny Dudin
Status: In Topic Branch Pending Review
Priority: Normal
Assignee: 
Category: package
Target version: 
Affected Puppet version: 2.7.14
Keywords: gem,latest,source
Branch: https://github.com/puppetlabs/puppet/pull/809


I have a local gem repository where I put my gems. In the manifest I specify a 
package with ensure => latest and explicitly set the source

class trocla {
package { "moneta":
ensure  => "latest",
provider=> "gem",
source  => "http://mylocalrepo/gem-repository/";,
}
}

In spite of that, puppet does not use my repo to fetch the list of available 
gems (which is confusing - if I explicitly specify my custom repository, I 
expect this package to be pulled from this particular repository).

This can be seen in the output puppet with --debug option:
`debug: Puppet::Type::Package::ProviderGem: Executing '/usr/bin/gem list 
--remote moneta$'`
  As you can see --source option is missing here



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #14766] 2nd puppet run after restart is ignoring runinterval, negating splay

[tickets]

Issue #14766 has been updated by Andrew Parker.

Target version deleted (2.7.x)

As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #14766: 2nd puppet run after restart is ignoring runinterval, negating splay
https://projects.puppetlabs.com/issues/14766#change-80534

Author: Mariusz Gronczewski
Status: Code Insufficient
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 2.7.14
Keywords: 
Branch: https://github.com/puppetlabs/puppet/pull/1130


after upgrading from 2.7.13 to 2.7.14 I noticed that our  puppets got 
"synchonized" and we have 10-20 clients running in one minute but 1-2 in other, 
which causes big spikes in load, especially if it hits few VMs on same physical 
machine
It seems that second puppet run after splay ignores runinterval:

May 13 05:00:03 blade308 puppet-agent[8820]: Sleeping for 346 seconds 
(splay is enabled) # start
May 13 05:05:49 blade308 puppet-agent[8820]: Retrieving plugin  
 # puppet run 5m after start
May 13 05:10:02 blade308 puppet-agent[8820]: Finished catalog run in 106.23 
seconds
May 13 05:30:17 blade308 puppet-agent[8820]: Retrieving plugin  
 # puppet run 25m after last one, 30m after start
May 13 05:37:28 blade308 puppet-agent[8820]: Finished catalog run in 107.28 
seconds
 
May 14 05:00:04 blade308 puppet-agent[17967]: Sleeping for 1019 seconds 
(splay is enabled)
May 14 05:17:03 blade308 puppet-agent[17967]: Retrieving plugin 
# puppet run 17 min after start
May 14 05:21:03 blade308 puppet-agent[17967]: Finished catalog run in 99.93 
seconds
May 14 05:30:16 blade308 puppet-agent[17967]: Retrieving plugin 
# puoer run 13 min after last one 30m after start
May 14 05:37:21 blade308 puppet-agent[17967]: Finished catalog run in 
103.47 seconds 

It seems like 2nd run is counting time from puppet start, not from last run
For comparision, before update:
Apr 29 04:03:09 blade307 puppet-agent[31595]: Sleeping for 723 seconds 
(splay is enabled)
Apr 29 04:15:12 blade307 puppet-agent[31595]: Retrieving plugin 
   # 12m after start
Apr 29 04:19:54 blade307 puppet-agent[31595]: Finished catalog run in 
127.66 seconds   
Apr 29 04:50:21 blade307 puppet-agent[31595]: Retrieving plugin 
   # 35m after last run, 47 after start.
Apr 29 04:54:27 blade307 puppet-agent[31595]: Finished catalog run in 95.67 
seconds

I noticed that now it counts run interval from start of puppet, not from end of 
last run. While it makes puppet run in interval closer to defined run interval, 
it causes problems when for some case puppet will be ran at same time on many 
nodes. Before every "peak" in load would cause puppet run to take longer so 
next run would be delayed, causing 'peak time' to smooth out after few runs.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #7270] unify global options with face and action options...

[tickets]

Issue #7270 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #7270: unify global options with face and action options...
https://projects.puppetlabs.com/issues/7270#change-80530

Author: Daniel Pittman
Status: In Topic Branch Pending Review
Priority: Low
Assignee: Kelsey Hightower
Category: Faces
Target version: 
Affected Puppet version: development
Keywords: 
Branch: https://github.com/khightower/puppet/commits/feature/master/7270


At the moment we handle global options for faces in a ... different way.  They 
are basically the old fashioned application options, kind of vaguely repurposed 
to do something approximating the right thing.  We should unify the behaviour 
of those, ideally along with options derived from our configuration system, and 
make them all behave consistently.

This would naturally want to involve unification of the DSL for declaring 
options, and in turn for introspection of them: that would make it practical to 
have them in the help output, and so forth.  Which is desirable, especially 
round the area of option validation.

It also means we can unify error handling, so that we don't have some classes 
of validation resulting in good help output, and others resulting in bad help 
output, just because they are handled by different substrates in the product.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #7057] Insertion of default ACLs can be blocked by unrelated ACLs in auth.conf

[tickets]

Issue #7057 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #7057: Insertion of default ACLs can be blocked by unrelated ACLs in 
auth.conf
https://projects.puppetlabs.com/issues/7057#change-80531

Author: Nick Fagerlund
Status: Accepted
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


Quick recap: 

* For REST access, ACLs are tested linearly. Matching stops at the first 
matching ACL. 
* When testing whether an ACL matches, the **path, method, environment,** and 
**auth** are equal peers; if any of them don't match, the ACL isn't relevant to 
the current request. 
* The default ACLs get inserted AFTER all of the ACLs in the `rest_authconfig` 
(auth.conf) file. 
* If a default ACL is duplicated and overridden somewhere in auth.conf, Puppet 
will not insert that default ACL. 

And now for the problem, which is that when deciding whether to skip a default 
ACL, Puppet _does not test whether the two ACLs would match the same requests._ 
Instead, it just compares the path. Thus, the following ACL, intended to allow 
one authenticated host to inspect the pending certificate requests:

path /certificate_request
auth yes
method find, search
allow magpie.lan

...will disallow all incoming certificate requests by overriding the default 
`certificate_request; auth no; method find, save; allow all` ACL, even though 
the sets of requests they match don't intersect at any point. This is bad, and 
seems magical enough that it's tricky to debug. 

Two tentative suggestions are that we can:

* Append all of the default ACLs all the time. Overridden ACLs will then work 
as expected, because lookup proceeds linearly with auth.conf getting the first 
shot; if you override a default, it'll effectively mask the default because no 
requests will survive long enough to reach it. (The current don't-insert 
behavior seems to be based around a mistaken belief that auth.conf works 
similarly to fileserver.conf.) 
* Cease to append default ACLs except for the `path /; auth any` denial rule; 
ship a working auth.conf and expect that things will blow up if you delete it. 
We'll need some way to restore a default ACL when users do something silly.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #7107] Puppet gem install prints several RDoc warnings

[tickets]

Issue #7107 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #7107: Puppet gem install prints several RDoc warnings
https://projects.puppetlabs.com/issues/7107#change-80529

Author: Randall Hansen
Status: Accepted
Priority: Low
Assignee: 
Category: installation
Target version: 
Affected Puppet version: 2.6.7
Keywords: 
Branch: 


Installing the Puppet gem, I got 4 instances of this warning:  "Could not find 
main page README" right after the "Installing RDoc" 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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #7052] Cert generation fails using "--ssldir"

[tickets]

Issue #7052 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #7052: Cert generation fails using "--ssldir"
https://projects.puppetlabs.com/issues/7052#change-80527

Author: Dominic Maraglia
Status: Needs Decision
Priority: High
Assignee: eric sorenson
Category: 
Target version: 
Affected Puppet version: 
Keywords: cert generation ssldir
Branch: 


Cert generation fails when generating a cert and passing options such as 
--ssldir.

Configuration:

  Test Suite: acceptance @ Mon Apr 11 11:25:19 -0700 2011
  
  - Host Configuration Summary -
Platform for centos-55-386-1 centos-5-i386
Platform for centos-55-64-1 centos-5-x86_64
Role for centos-55-386-1 agent
Role for centos-55-64-1 master
Config Key|Val: rubyver "ruby18"
Config Key|Val: version {:puppet=>"2.6.7-60-g7b23e59", :facter=>"1.5.8"}
Config Key|Val: filecount 12
Config Key|Val: puppet_ver "origin/2.6.next"
Config Key|Val: pe_nfs_mount "/mnt/ro/pe"
Config Key|Val: gemver "gem12"Config Key|Val: puppetpath "/etc/puppet"
Config Key|Val: puppetbinpath "/opt/puppet/bin"
Config Key|Val: facter_ver "1.5.8"
Config Key|Val: ssh {:user=>"root", :config=>false, :paranoid=>false, 
:auth_methods=>["publickey"], :port=>22, 
:user_known_hosts_file=>"/home/djm/.ssh/known_hosts", 
:keys=>["/home/djm/.ssh/id_rsa"]}
Config Key|Val: nfs_server "192.168.97.1"
Config Key|Val: puppetbin "/usr/bin/puppet"

  - Test Case Summary -
  Attempted: 89
 Passed: 86
 Failed: 2
Errored: 1
Skipped: 0

  - Specific Test Case Status -
Failed Tests Cases:
  Test Case 
tests/acceptance/ticket_4151_defined_function_should_not_return_true_for_unrealized_virtual_resources.rb
 reported: # is not true.>
  Test Case 
tests/acceptance/ticket_6710_relationship_syntax_should_work_with_title_arrays.rb
 reported: # is not true.>
Errored Tests Cases:
  Test Case tests/acceptance/ticket_3961_puppet_ca_should_produce_certs.rb 
reported: #



Example repro:

[root@centos-55-386-1 tmp]# puppet cert --trace --generate 
working3961.example.org --vardir=/tmp/puppet-ssl-3961 
--ssldir=/tmp/puppet-ssl-3961 --confdir=/tmp/puppet-ssl-3961
notice: Signed certificate request for ca
notice: Rebuilding inventory file
/usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:731:in `initialize'
/usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:731:in `open'
/usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:731:in `writesub'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:162:in `withumask'
/usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:730:in `writesub'
/usr/lib/ruby/site_ruby/1.8/puppet/util/suidmanager.rb:62:in `asuser'
/usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:723:in `writesub'
/usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:709:in `write'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/ssl_file.rb:158:in `write'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/ssl_file.rb:98:in `save'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:267:in `save'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector.rb:68:in `save'
/usr/lib/ruby/site_ruby/1.8/puppet/ssl/certificate_authority.rb:99:in `crl'
/usr/lib/ruby/site_ruby/1.8/puppet/ssl/certificate_authority.rb:136:in 
`generate_ca_certificate'
/usr/lib/ruby/site_ruby/1.8/puppet/ssl/certificate_authority.rb:222:in `setup'
/usr/lib/ruby/site_ruby/1.8/puppet/ssl/certificate_authority.rb:146:in 
`initialize'
/usr/lib/ruby/site_ruby/1.8/puppet/application/cert.rb:81:in `new'
/usr/lib/ruby/site_ruby/1.8/puppet/application/cert.rb:81:in `setup'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:420:in `hook'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:411:in `exit_on_fail'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:62:in `execute'
/usr/bin/puppet:4
Permission denied - /tmp/puppet-ssl-3961/crl.pem
[root@centos-55-386-1 tmp]# ll puppet-ssl-3961/
total 44
drwxrwx--- 5 puppet puppet 4096 Apr 11 11:33 ca
drwxr-xr-x 2 puppet root   4096 Apr 11 11:33 certificate_requests
drwxr-xr-x 2 puppet root   4096 Apr 11 11:33 certs
drwxr-xr-x 2 root   root   4096 Apr 11 11:33 facts
drwxr-xr-x 2 root   root   4096 Apr 11 11:33 lib
drwxr-x--- 2 puppet puppet 4096 Apr 11 11:33 log
drwxr-x--- 2 puppet root   4096 Apr 11 11:33 private
drwxr-x--- 2 puppet root   4096 Apr 11 11:33 private_keys
drwxr-xr-x 2 puppet root   4096 Apr 11 11:33 public_keys
drwxrwxrwt 2 root   root   4096 Apr 11 11:33 run
drwxr-xr-t 2 root   root   4096 Apr 11 11:33 state




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

[Puppet - Bug #7102] Our documentation needs to be updated to reflect the Apache license change from GNU

[tickets]

Issue #7102 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #7102: Our documentation needs to be updated to reflect the Apache license 
change from GNU
https://projects.puppetlabs.com/issues/7102#change-80528

Author: Matt Robinson
Status: Accepted
Priority: High
Assignee: Daniel Pittman
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 



% ack GNU
conf/gentoo/init.d/puppet3:# Distributed under the terms of the GNU General 
Public License v2conf/gentoo/init.d/puppetmaster3:# Distributed under the terms 
of the GNU General Public License v2
lib/puppet/external/event-loop/better-definers.rb
5:# and/or modify it under the terms of the GNU General Public
13:# See the GNU General Public License for more details.
15:# You should have received a copy of the GNU General Public

lib/puppet/external/event-loop/event-loop.rb
5:# and/or modify it under the terms of the GNU General Public
13:# See the GNU General Public License for more details.
15:# You should have received a copy of the GNU General Public

lib/puppet/external/event-loop/signal-system.rb
5:# and/or modify it under the terms of the GNU General Public
13:# See the GNU General Public License for more details.
15:# You should have received a copy of the GNU General Public

man/man8/filebucket.8
81:Copyright (c) 2005 Puppet Labs, LLC Licensed under the GNU Public License

man/man8/pi.8
51:Copyright (c) 2005 Puppet Labs, LLC Licensed under the GNU Public License

man/man8/puppet-agent.8
139:Copyright (c) 2005, 2006 Puppet Labs, LLC Licensed under the GNU Public 
License

man/man8/puppet-apply.8
75:Copyright (c) 2005 Puppet Labs, LLC Licensed under the GNU Public License

man/man8/puppet-cert.8
94:Copyright (c) 2005 Puppet Labs, LLC Licensed under the GNU Public License

man/man8/puppet-describe.8
51:Copyright (c) 2005 Puppet Labs, LLC Licensed under the GNU Public License

man/man8/puppet-doc.8
101:Copyright (c) 2005\-2007 Puppet Labs, LLC Licensed under the GNU Public 
License

man/man8/puppet-filebucket.8
81:Copyright (c) 2005 Puppet Labs, LLC Licensed under the GNU Public License

man/man8/puppet-inspect.8
28:Copyright (c) 2011 Puppet Labs, LLC Licensed under the GNU General Public 
License version 2

man/man8/puppet-kick.8
115:Copyright (c) 2005 Puppet Labs, LLC Licensed under the GNU Public License

man/man8/puppet-master.8
63:Copyright (c) 2005 Puppet Labs, LLC Licensed under the GNU Public License



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #6936] AIX user provider fails if a gid is specified instead of a name.

[tickets]

Issue #6936 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #6936: AIX user provider fails if a gid is specified instead of a name.
https://projects.puppetlabs.com/issues/6936#change-80526

Author: Parker Johnson
Status: Accepted
Priority: Normal
Assignee: 
Category: provider
Target version: 
Affected Puppet version: development
Keywords: AIX user provider puppet gid
Branch: 


Several AIX providers (aixobject/user/group) were merged into the code a couple 
days ago.  I just checked out from source and gave it a try on an AIX6.1 TL4 
host.  Most of it works (thank you! psyched to see puppet and AIX play nice), 
but if you specify a gid instead of a group name, the manifest errors.  See 
below.  I'll be happy to re-test if yall have a hard time finding an AIX host. 
:)



[root@sfcloudap001 puppet]# cat modules/test/manifests/init.pp 
class test {

  group{'test_g':
ensure => present,
gid => 6969,
  }

  user{'test_u':
ensure => present,
uid => 99,
gid => 6969,
home => "/tmp/",
  }
}


[root@autobuild /]# puppet agent --test
warning: iconv doesn't seem to support UTF-8/UTF-16 conversions
info: Caching catalog for autobuild.gid.gap.com
info: Applying configuration version '1301604374'
notice: /Stage[main]/Test/Group[test_g]/ensure: created
err: /Stage[main]/Test/User[test_u]/ensure: change from absent to present 
failed:
Could not set 'present on ensure: undefined method `groupname_by_id' for # at 
/etc/puppet/modules/test/manifests/init.pp:13
notice: Finished catalog run in 2.89 seconds
[root@autobuild /]# 




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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #6810] File 'fail' became a lot more fatal in 2.6.0

[tickets]

Issue #6810 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #6810: File 'fail' became a lot more fatal in 2.6.0
https://projects.puppetlabs.com/issues/6810#change-80525

Author: eric sorenson
Status: Accepted
Priority: Normal
Assignee: 
Category: file
Target version: 
Affected Puppet version: 2.6.0
Keywords: 
Branch: 


In testing 2.6.6, we found that missing source directories in a recurse=>remote 
file copy cause puppetd to exit immediately, whereas earlier versions just 
cause that particular resource to fail but continue with the rest of the 
catalog.  Did failures become intentionally more fatal in 2.6.6?   I can work 
to bisect when this started happening but wondered if it was a known issue. 
Stack trace/output:


/usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:171:in 
`fail'/usr/lib/ruby/site_ruby/1.8/puppet/type/file/source.rb:156:in 
`init_metadata'/usr/lib/ruby/site_ruby/1.8/puppet/util/cacher.rb:106:in `send'
/usr/lib/ruby/site_ruby/1.8/puppet/util/cacher.rb:106:in 
`cached_value'/usr/lib/ruby/1.8/monitor.rb:242:in 
`synchronize'/usr/lib/ruby/site_ruby/1.8/puppet/util/cacher.rb:98:in 
`cached_value'/usr/lib/ruby/site_ruby/1.8/puppet/util/cacher.rb:48:in 
`metadata'/usr/lib/ruby/site_ruby/1.8/puppet/type/file/source.rb:109:in 
`copy_source_values'
/usr/lib/ruby/site_ruby/1.8/puppet/type/file.rb:622:in 
`retrieve'/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:703:in `retrieve_resource'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1874:in `to_trans'
/usr/lib/ruby/site_ruby/1.8/puppet/type/file.rb:691:in `to_trans'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1899:in `to_resource'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:203:in `uniqueness_key'
/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:83:in `add_resource'
/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:72:in `each'
/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:72:in 
`add_resource'/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:561:in 
`to_catalog'
/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:531:in `each'
/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:468:in `to_ral'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:113:in `convert_catalog'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:108:in `retrieve_catalog'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:139:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
/usr/lib/ruby/1.8/sync.rb:230:in `synchronize'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:103:in `with_client'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:37:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `call'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `controlled_run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:35:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:114:in `onetime'
/usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:88:in `run_command'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:410:in `exit_on_fail'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run'
/usr/sbin/puppetd:4
err: Could not run Puppet configuration client: Could not retrieve information 
from source(s) puppet:///async/users/admins/vkoleti/ssh at 
/etc/puppet/modules/homes/manifests/init.pp:28




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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #6809] Ignore "links => follow" when managing symlinks

[tickets]

Issue #6809 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #6809: Ignore "links => follow" when managing symlinks
https://projects.puppetlabs.com/issues/6809#change-80524

Author: Nigel Kersten
Status: Accepted
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


It doesn't make sense to set "links => follow" inside a symlink resource. We're 
not managing content, and you end up with edge cases like this:



file { "/tmp/foo":
  ensure => directory
}

file { "/tmp/bar":
  ensure => "/tmp/foo",
  links  => follow
}




kripke:~ nbk$ puppet -v /tmp/test.pp 
info: Applying configuration version '1300749546'
notice: /Stage[main]//File[/tmp/bar]/ensure: created
notice: /Stage[main]//File[/tmp/foo]/ensure: created

kripke:~ nbk$ puppet -v /tmp/test.pp 
info: Applying configuration version '1300749548'
info: /Stage[main]//File[/tmp/bar]: Recursively backing up to filebucket
notice: /Stage[main]//File[/tmp/bar]: Not removing directory; use 'force' to 
override
info: /Stage[main]//File[/tmp/bar]: Recursively backing up to filebucket
notice: /Stage[main]//File[/tmp/bar]: Not removing directory; use 'force' to 
override
err: /Stage[main]//File[/tmp/bar]/ensure: change from directory to link failed: 
Could not remove existing file



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #6808] Provide informative message when ensure => present, *and* managing content/source, and target is a symlink

[tickets]

Issue #6808 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #6808: Provide informative message when ensure => present, *and* managing 
content/source, and target is a symlink
https://projects.puppetlabs.com/issues/6808#change-80523

Author: Nigel Kersten
Status: Accepted
Priority: Low
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 



/tmp/foo -> /tmp/bar



file { "/tmp/foo":
  ensure  => present,
  content => "foo",
}


When you run this, you get no indication that the content will not be written. 
This is because the existence of the symlink suffices for "ensure => present", 
and the content isn't evaluated.

This is almost certainly another indicator that we should be breaking the 
symlink type out into it's own type, separate from File, but in the meantime we 
should try to log *something* here if feasible.




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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #6798] Infinite recursion in certificate interface's REST terminus

[tickets]

Issue #6798 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #6798: Infinite recursion in certificate interface's REST terminus
https://projects.puppetlabs.com/issues/6798#change-80522

Author: Richard Crowley
Status: In Topic Branch Pending Review
Priority: Normal
Assignee: 
Category: Faces
Target version: 
Affected Puppet version: 
Keywords: 
Branch: https://github.com/rcrowley/puppet-interfaces/tree/ticket/master/6798


The following command will cause infinite recursion:

puppet certificate find --from=rest $(hostname --fqdn)

Link to a branch with a fix is forthcoming.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #6793] mount provider fails when paths have a trailing slash

[tickets]

Issue #6793 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #6793: mount provider fails when paths have a trailing slash
https://projects.puppetlabs.com/issues/6793#change-80521

Author: John Spray
Status: Accepted
Priority: Normal
Assignee: 
Category: mount
Target version: 
Affected Puppet version: 2.6.6
Keywords: 
Branch: 


A resource like
"/mnt/foo" works fine, but "/mnt/foo/" only works on the first mount.  On 
subsequent runs, puppet incorrectly determines the state as unmounted, tries to 
mount it, and fails.

This is because of puppet/provider/mount.rb function "mounted?" which searches 
for resource[:name] in the output of mount.  Mount never prints the trailing 
slash, so puppet things the mount isn't there.

It should either reject as invalid resources with a trailing slash, or make 
sure that they are correctly recognised when mounted.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #6683] Default provider still called even if provider specified

[tickets]

Issue #6683 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #6683: Default provider still called even if provider specified
https://projects.puppetlabs.com/issues/6683#change-80520

Author: Brian Simons
Status: Accepted
Priority: High
Assignee: 
Category: provider
Target version: 
Affected Puppet version: 
Keywords: apache puppetlabs-apache module
Branch: 


I'm using puppetlabs-apache 0.0.3 available at 
http://forge.puppetlabs.com/puppetlabs/apache.

I can create the following config:

   /etc/puppet/manifests/nodes.pp:
  
 node 'ubuntu-testing.verite.com' {
 include apache
  
 @a2mod { 'ssl': ensure => present; }
 realize A2mod['ssl']
  
 }

And on a new ubuntu server install with only ssh and puppet installed, if I try 
to run that manifest with "puppetd --test" I get:

root@ubuntu-testing:~# puppetd --test
info: Retrieving plugin
info: Caching catalog for ubuntu-testing.verite.com
err: Could not run Puppet configuration client: Could not find a default 
provider for a2mod

If I manually install apache2, I do not get this error, and everything works 
just great. For some reason, puppet isn't seeing that apache2 needs to be 
installed before it tries to look for a2enmod and a2dismod.

Help?


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #6553] handling of array values in exec provider is inconsistent.

[tickets]

Issue #6553 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #6553: handling of array values in exec provider is inconsistent.
https://projects.puppetlabs.com/issues/6553#change-80518

Author: Daniel Pittman
Status: Accepted
Priority: Normal
Assignee: 
Category: exec
Target version: 
Affected Puppet version: 2.6.5
Keywords: wtf
Branch: 


In the `exec` provider we handle arrays as arguments inconsistently:

exec { "foo": timeout => [1] }  # works
exec { "foo": tries => [1] } # boom!

We should make a call on which of these two is desired, then implement it.  If 
necessary a deprecation period might be needed to ensure that we don't surprise 
anyone using this (unintuitive) features.

Oh, and:

exec { "foo": timeout => [1,2,3] }  # guess which one we use?



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #6628] Parsed file providers fail to replace missing entries on first run where they are missing

[tickets]

Issue #6628 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #6628: Parsed file providers fail to replace missing entries on first run 
where they are missing
https://projects.puppetlabs.com/issues/6628#change-80519

Author: Paul Berry
Status: Accepted
Priority: Normal
Assignee: 
Category: provider
Target version: 
Affected Puppet version: 2.7.9
Keywords: 
Branch: 


I discovered this bug while trying to write integration tests for the mount 
provider.  Thanks to Nick Lewis for helping me narrow it down to a reproducible 
test case.

Steps to reproduce:

* Start a master running this manifest:

  host { "foo": ip => '1.2.3.4', target => "/tmp/hosts" }

* Start a client using the options `--verbose --no-daemonize --runinterval 60 
--no-onetime` so that the client runs every 60 seconds.

* After the client runs for the first time, open `/tmp/hosts` and delete the 
line

  1.2.3.4   foo

* After the client runs for the second time, reload the file `/tmp/hosts`.  
Expected behavior: the missing line should be back.  Observed behavior: it 
isn't.

* After the client runs for the third time, reload the file `/tmp/hosts`.  The 
missing line is now back.



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #6411] Changing mount device when ensuring unmounted causes bogus mount of new device

[tickets]

Issue #6411 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #6411: Changing mount device when ensuring unmounted causes bogus mount of 
new device
https://projects.puppetlabs.com/issues/6411#change-80516

Author: Paul Berry
Status: Accepted
Priority: Normal
Assignee: 
Category: mount
Target version: 
Affected Puppet version: development
Keywords: 
Branch: 


This behavior was observed on Mac OS X.  Unsure if it exists on other OSes.

First run this manifest:

file { '/Volumes/NIKON_D40X': ensure => directory }
mount { '/Volumes/NIKON_D40X': ensure => unmounted, device => 
"/dev/disk1s1", fstype => msdos, options => ro, require => 
File['/Volumes/NIKON_D40X'] }

Then execute:

mount /Volumes/NIKON_D40X

(Note: this requires you to have a device plugged into /dev/disk1s1--this is 
the SD card reader on mac laptops)

Then run this manifest:

mount { '/Volumes/NIKON_D40X': ensure => unmounted, device => 
"/dev/disk1s2", fstype => msdos, options => ro }

You get this error:


info: Applying configuration version '1298412039'
debug: Puppet::Type::Mount::ProviderParsed: Executing '/sbin/mount'
notice: /Stage[main]//Mount[/Volumes/NIKON_D40X]/device: device changed 
'/dev/disk1s1' to '/dev/disk1s2'
debug: Flushing mount provider target /etc/fstab
debug: Finishing transaction 2164063200
info: FileBucket adding {md5}6e03fd206f67d67d645b74b0baab9a05
info: /Stage[main]//Mount[/Volumes/NIKON_D40X]: Scheduling refresh of 
Mount[/Volumes/NIKON_D40X]
debug: Puppet::Type::Mount::ProviderParsed: Executing '/sbin/mount'
info: Mount[/Volumes/NIKON_D40X](provider=parsed): Remounting
debug: Puppet::Type::Mount::ProviderParsed: Executing '/sbin/umount 
/Volumes/NIKON_D40X'
debug: Puppet::Type::Mount::ProviderParsed: Executing '/sbin/mount'
debug: Puppet::Type::Mount::ProviderParsed: Executing '/sbin/mount'
debug: Flushing mount provider target /etc/fstab
debug: Puppet::Type::Mount::ProviderParsed: Executing '/sbin/mount -o ro 
/Volumes/NIKON_D40X'
err: /Stage[main]//Mount[/Volumes/NIKON_D40X]: Failed to call refresh: 
Execution of '/sbin/mount -o ro /Volumes/NIKON_D40X' returned 1: mount: 
realpath /Volumes/NIKON_D40X: No such file or directory



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #6489] Puppet::Resource::Type#ensure_in_catalog should be able to add defined resource types to catalogs

[tickets]

Issue #6489 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #6489: Puppet::Resource::Type#ensure_in_catalog should be able to add 
defined resource types to catalogs
https://projects.puppetlabs.com/issues/6489#change-80517

Author: Dan Bode
Status: Accepted
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


it would be nice to have a single method for dynamically creating all resource 
types.

it currently only works for nodes/classes


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #6314] ralsh file generates code that 2.6.5rc2 errors on

[tickets]

Issue #6314 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #6314: ralsh file generates code that 2.6.5rc2 errors on
https://projects.puppetlabs.com/issues/6314#change-80515

Author: John Warburton
Status: Accepted
Priority: High
Assignee: 
Category: 
Target version: 
Affected Puppet version: 2.6.0
Keywords: 
Branch: 


Now that issue #3165 is resolved, I can use ralsh on file types. Oh, now the 
code for directories is generating errors :-(

root@engnsvr003# export 
RUBYLIB=/opt/local/pkgs/puppet-2.6.5rc2/lib:/opt/local/lib:/opt/local/lib/ruby/site_ruby/1.8:/opt/local/lib/ruby/site_ruby/1.8/sparc-solaris2.10
   
root@engnsvr003# /opt/local/pkgs/puppet-2.6.5rc2/bin/ralsh file /var | 
egrep -v time
file { '/var':
type => 'directory'
owner => '0',
group => '3',
ensure => 'directory',
mode => '755',
}
root@engnsvr003# /opt/local/pkgs/puppet-2.6.5rc2/bin/ralsh file /var | 
egrep -v time > /tmp/var.pp
root@engnsvr003# /opt/local/pkgs/puppet-2.6.5rc2/bin/puppet apply 
/tmp/var.pp
Parameter type failed: type is read-only at /tmp/var.pp:7

Now, we remove the 'type', and it all works fine

root@engnsvr003# /opt/local/pkgs/puppet-2.6.5rc2/bin/ralsh file /var | 
egrep -v 'type|time' > /tmp/var.pp
root@engnsvr003# /opt/local/pkgs/puppet-2.6.5rc2/bin/puppet apply 
/tmp/var.pp
notice: Finished catalog run in 0.16 seconds

As seen in 
[http://groups.google.com/group/puppet-users/browse_thread/thread/13904f6c8225d5e1](http://groups.google.com/group/puppet-users/browse_thread/thread/13904f6c8225d5e1)



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #6209] Puppet should not change error messages on second run

[tickets]

Issue #6209 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #6209: Puppet should not change error messages on second run
https://projects.puppetlabs.com/issues/6209#change-80512

Author: Nico Schottelius
Status: Accepted
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: usability
Branch: 


Hello!

This is a long outstanding bug I've always forgot to report: Puppet changes the 
error message from

Syntax error at 'libxerces-c-dev'; expected ']' at

to

Could not find class ethz_systems::packages in namespaces ethz_systems at

I was told that this happens, because puppetmaster unloads the class as soon as 
it sees a syntax error.
This may be a valid behaviour internally, but it completly destroys the 
abilitiy to debug the origin of the
error.

Thus everytime I see the

Could not find class

error, I'm forced to restart puppet and watch the logfile to find the origin. 
This is cumbersome, misleading and time-consuming.

Thus I propose to always report the first error, because the second one just 
confuses users.

Cheers,

Nico



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #6168] `puppet master` should not daemonize before checking that it can startup

[tickets]

Issue #6168 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #6168: `puppet master` should not daemonize before checking that it can 
startup
https://projects.puppetlabs.com/issues/6168#change-80511

Author: Jacob Helwig
Status: Accepted
Priority: High
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


If there are problems that would cause the puppet master to fail to start up 
(missing directories, permissions errors, etc, etc), these are not reported 
when running the master via the command line (`puppet master --daemonize`).  
Puppet should check for proper directories, and permissions before daemonizing 
so it can output initialization errors, and return non-zero, rather than giving 
the appearance of success, when it actually has silently failed.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #6268] service{"network": ensure => running } fails on Redhat/Centos w/ dhcp interface

[tickets]

Issue #6268 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #6268: service{"network": ensure => running } fails on Redhat/Centos w/ 
dhcp interface
https://projects.puppetlabs.com/issues/6268#change-80513

Author: Chip Schweiss
Status: Needs More Information
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


Puppet is always reading the status as stopped and attempts to start the 
service on every run.  If the interface is dhcp the start command fails because 
dhclient is already running.  

Puppet needs to properly determine the status.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #6299] fact_names being mangled, 2.6.5rc1, mysql

[tickets]

Issue #6299 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #6299: fact_names being mangled, 2.6.5rc1, mysql 
https://projects.puppetlabs.com/issues/6299#change-80514

Author: Mark Washeim
Status: Needs More Information
Priority: Normal
Assignee: 
Category: parser
Target version: 
Affected Puppet version: 2.6.5
Keywords: 
Branch: 


This looks like it should be timestamp?

| 39 | --- !ruby/sym _timestamp | 2011-02-11 14:58:52 | 2011-02-11 14:58:52 |



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #6112] Puppet cert generate error message when it succeeds

[tickets]

Issue #6112 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #6112: Puppet cert generate error message when it succeeds
https://projects.puppetlabs.com/issues/6112#change-80510

Author: Jeff McCune
Status: Needs More Information
Priority: Normal
Assignee: 
Category: logging
Target version: 
Affected Puppet version: development
Keywords: error cert generate
Branch: 


## Overview ##

Running puppet cert in 2.6.next f135a64 performs the desired certificate 
generation, but displays a nasty error message int he process.

## Steps to reproduce ##

$ puppet cert --confdir ~/.puppet/conf_enc --generate foo.bar.baz 
--certdnsnames foo:foo.bar.baz:puppet
notice: foo.bar.baz has a waiting certificate request
notice: Signed certificate request for foo.bar.baz
notice: Removing file Puppet::SSL::CertificateRequest foo.bar.baz at 
'/Users/jeff/.puppet/var/ssl/ca/requests/foo.bar.baz.pem'
notice: Removing file Puppet::SSL::CertificateRequest foo.bar.baz at 
'/Users/jeff/.puppet/var/ssl/certificate_requests/foo.bar.baz.pem'
err: Could not call generate: Could not find certificate request for 
foo.bar.baz

$ echo $?
0

$ puppet cert --print foo.bar.baz
(Works as expected, certificate was generated and signed)

## Expected Behavior ##

The error shouldn't be displayed.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #6111] Should be able to audit Host resources

[tickets]

Issue #6111 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #6111: Should be able to audit Host resources
https://projects.puppetlabs.com/issues/6111#change-80509

Author: Jeff McCune
Status: Accepted
Priority: Normal
Assignee: 
Category: auditing/compliance
Target version: 
Affected Puppet version: development
Keywords: audit, inspect, 
Branch: 2.6.next


## Overview ##

Using the audit meta-parameter with a host resource does not appear to audit 
the "ip" parameter.  I'm not sure if the this parameter is a property or not, 
but puppet resource is able to sort out the value correctly:

## Impact Data ##

This is relatively low impact, but the ability to audit entries in /etc/hosts 
is important as they have a high impact if they're not in the correct state.  
For example, applications will fail to start entirely.

## Steps to Reproduce ##

Manifest:

host { $fqdn:
  ensure => present,
  ip => $iptouseinetchost,
  alias  => $hostname,
  audit  => ip,
}

## Expected Results ##

Note, I would expect to see something like:

...Host[seed.puppetlabs.vm]/ip audit change: Previously recorded value 
192.168.69.139 has been changed to 192.168.69.138.

I also expect the IP value to show up in Puppet inspection reports and they do 
not.

## Actual Results ##

In a noop run, the previous value is shown in the log messages but does not 
show up in the log messages related to audit change events.

The IP values also do not show up in inspect reports.

## Steps to Reproduce ##

Given the above manifest and the following Puppet Run.

$ envpuppet puppet agent --test --server autoserver --noop
info: Caching catalog for seed.puppetlabs.vm
info: Applying configuration version '1296657013'
notice: /Stage[main]/Resolver_test/Host[seed.puppetlabs.vm]/ip: 
current_value 192.168.69.138, should be 192.168.69.141 (noop) (previously 
recorded value was 192.168.69.139)
notice: Finished catalog run in 0.11 seconds

Notice there is no "audit change:" message like there are for File resources.

You'll need to obtain the catalog once with a noop run, then manually change 
the /etc/hosts file and perform a noop run again to see if the IP property is 
audited as expected.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #6023] puppetmasterd init.d does not create PID file causes failure on status & stop

[tickets]

Issue #6023 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #6023: puppetmasterd init.d does not create PID file causes failure on 
status & stop
https://projects.puppetlabs.com/issues/6023#change-80507

Author: Chip Schweiss
Status: Accepted
Priority: Normal
Assignee: 
Category: Red Hat
Target version: 
Affected Puppet version: 2.6.4
Keywords: 
Branch: 


>From the tar.gz in conf/redhat/server.init line number 60:

daemon $daemonopts $PUPPETMASTER $PUPPETMASTER_OPTS

should be 

daemon $PUPPETMASTER $PUPPETMASTER_OPTS $daemonopts


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #6097] Individual values for parameters can't require features

[tickets]

Issue #6097 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #6097: Individual values for parameters can't require features
https://projects.puppetlabs.com/issues/6097#change-80508

Author: Nick Lewis
Status: Accepted
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


Currently, Puppet supports specifying required features for individual values 
of properties (eg. ensure => latest), but not for parameters. There doesn't 
seem to be any conceptual reason for this limitation, so it would be nice to 
support.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #6005] User type cannot handle project property

[tickets]

Issue #6005 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #6005: User type cannot handle project property
https://projects.puppetlabs.com/issues/6005#change-80505

Author: Stefan Schulte
Status: Accepted
Priority: Normal
Assignee: 
Category: user
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


The user resource has a »project« property that is supposed to set the 
defaultproject for a user in `/etc/user_attr`. This doesnt work.

What you need to reproduce the bug

* Solaris (testet on Solaris 5.10 Intel CPU)
* a project that is present in /etc/project

testproj:4503

* a simple manifest like this

user { "testuser":
  project => "testproj",
  ensure  => present,
}


Now lets run puppet

debug: User[testuser](provider=user_role_add): Executing '/usr/sbin/useradd -p 
testproj testuser'
notice: /Stage[main]//User[testuser]/ensure: created


Unfortunately `useradd -p` and `usermod -p` only add the user in the allowed 
users list in `etc/project`. The project now looks like this

testproj:4503::testuser::

However, no entry is created in `/etc/user_attr` and running `projects -d 
testuser` that will print out the default project for the testusers still says 
`default` (`default` is a project that should be present on every Solaris 
host). So puppet running `useradd -p` (same is true for `usermod -p`)

1. is not what I want/expect
2. is not what puppet checks agains

On any following puppet run, puppet now claims that the user has no default 
project:

debug: User[testuser](provider=user_role_add): Executing '/usr/sbin/usermod -p 
testproj testuser'
notice: /Stage[main]//User[testuser]/project: project changed '' to 'testproj'


Possible solution

To change the defaultproject one can run `usermod -K project=testproj 
testuser`. This will update the entry in `/etc/user_attr` that will now look 
like this:

testusertype=normal;project=testproj

Puppet will now report that the project property is in sync.

Drawback

I dont know a command that will erease the project entry.


usermod -p testuser
# the above erases the user in /etc/project but doesnt remove the user_attr 
entry

usermod -K 'project' testuser
UX: usermod: ERROR: Missing value specification.

usermod -K 'project=' testuser
UX: usermod: ERROR:  is not a valid project name.  Choose another.

usermod -K 'project=""' testuser
UX: usermod: ERROR: "" is not a valid project name.  Choose another.


It is important that we can erase the project entry because if there is none, 
the default will be
a) a project that is called `user.testuser` if there a project with that name
b) a project that is called `group.some_group_testuser_is_in` if there is 
project with that name
c) the project called `default`

If we want this implicit project assignment we have to be able to erase the 
project from the `/etc/user_attr` entry.

Possible solution 2
===

Use a parsedfile provider to update `/etc/user_attr`. That's what I'm doing 
right now.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #6019] Subclasses don't inherit run stage correctly?

[tickets]

Issue #6019 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #6019: Subclasses don't inherit run stage correctly?
https://projects.puppetlabs.com/issues/6019#change-80506

Author: Roald van Loon
Status: Accepted
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


Hi,

Seems like subclasses are not automatically placed in the correct run stage, 
when they inherit the stage from a parent.

Consider the following small test manifest;

stage { second: require => Stage[main] }
notify { "test": }
class testsuper {

}

class testsuper::testsub inherits testsuper {
notify { "this is testsuper::testsub, and my stage is $stage":
require => Notify["test"]
}
}

class { "testsuper": stage => second }

node test {
include testsuper::testsub
}

This results in the following;


debug: /Stage[second]/require: requires Stage[main]
debug: /Stage[main]/Testsuper::Testsub/Notify[this is testsuper::testsub, 
and my stage is second]/require: requires Notify[test]



So apparently, the $stage metaparameter in "testsuper::testsub" is set to 
"second" correctly, but the puppet run still indicates that the notify should 
take place in stage "main".

Looks to me like this is unwanted behavior?

If I change this ...

class { "testsuper": stage => second }

... into this;

class { "testsuper::testsub": stage => second }


... then the "testsub" subclass is executed in the correct stage;


debug: /Stage[second]/require: requires Stage[main]
debug: /Stage[second]/Testsuper::Testsub/Notify[this is testsuper::testsub, 
and my stage is second]/require: requires Notify[test]



But I assume it's not by design that I have to apply the stage to every 
subclass.



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5984] syntax error in import manifest only reported once

[tickets]

Issue #5984 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5984: syntax error in import manifest only reported once
https://projects.puppetlabs.com/issues/5984#change-80504

Author: Johan Huysmans
Status: Accepted
Priority: Normal
Assignee: 
Category: agent
Target version: 
Affected Puppet version: 2.6.1
Keywords: 
Branch: 


In my setup the site.pp contains a set of import statements in import classes 
and variables from other files, while the actual node definition is situation 
in the site.pp file itself.

When a syntax error is made in the site.pp this is reported on every puppet run 
until the problem is fixed.
When a syntax error is made in one of the imported files, this error is 
reported the first time puppet runs. The second time it will won't give an 
error and just says "notice: Finished catalog run..."





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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5981] Puppet shouldn't overwrite symlinks when specifying content and follow is on.

[tickets]

Issue #5981 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5981: Puppet shouldn't overwrite symlinks when specifying content and 
follow is on.
https://projects.puppetlabs.com/issues/5981#change-80503

Author: Nigel Kersten
Status: Accepted
Priority: Normal
Assignee: 
Category: file
Target version: 
Affected Puppet version: 2.7.9
Keywords: 
Branch: 


Illustration of the issue:

kripke:~ nbk$ echo "target" > /tmp/target
kripke:~ nbk$ ln -s /tmp/target /tmp/symlink
kripke:~ nbk$ ls -l /tmp/target /tmp/symlink
lrwxr-xr-x  1 nbk  wheel  11 Jan 23 14:43 /tmp/symlink -> /tmp/target
-rw-r--r--  1 nbk  wheel   7 Jan 23 14:43 /tmp/target




kripke:~ nbk$ puppet --version
2.6.4
kripke:~ nbk$ cat /tmp/test.pp 
file { "/tmp/symlink":
  ensure  => present,
  backup  => false,
  links   => follow,
  content => "content",
}

kripke:~ nbk$ puppet apply -v /tmp/test.pp 
info: Applying configuration version '1295823089'
notice: /Stage[main]//File[/tmp/symlink]/content: content changed 
'{md5}80fb1dd0b20823f1d83e10d25840e2e4' to 
'{md5}9a0364b9e99bb480dd25e1f0284c8555'
kripke:~ nbk$ ls -la /tmp/target /tmp/symlink
-rw-r--r--  1 nbk  wheel  7 Jan 23 14:51 /tmp/symlink
-rw-r--r--  1 nbk  wheel  7 Jan 23 14:47 /tmp/target


So even though we're not managing the symlink, and we've only got ensure set to 
"present", and we have links set to follow, Puppet overwrites the symlink with 
the contents, rather than the target.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5975] puppet kick --ignoreschedules not working

[tickets]

Issue #5975 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5975: puppet kick --ignoreschedules not working
https://projects.puppetlabs.com/issues/5975#change-80501

Author: Yuri Arabadji
Status: Accepted
Priority: Normal
Assignee: 
Category: agent
Target version: 
Affected Puppet version: 2.6.4
Keywords: kick listen schedule ignoreschedules
Branch: 


When --ignoreschedules parameter is specified to puppet kick, it isn't passed 
to client. Probably, --tags doesn't work, too.



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5980] puppet gets crazy on invalid/bad certificate/key

[tickets]

Issue #5980 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5980: puppet gets crazy on invalid/bad certificate/key
https://projects.puppetlabs.com/issues/5980#change-80502

Author: Maxim Ianoglo
Status: Accepted
Priority: High
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


As an example:
if I intentionally introduce an error in host or ca certificate it start to be 
crazy:
in an infinite cycle throws errors:
err: Cached certificate for server40.xxx.xx failed: nested asn1 error
err: Cached certificate for server40.xxx.xx failed: nested asn1 error
err: Cached certificate for server40.xxx.xx failed: nested asn1 error
err: Cached certificate for server40.xxx.xx failed: nested asn1 error

uses 100% CPU, eats memory continuously which leads to OOM.

In my opinion, if a certificate ( key ) is bad at any phase of using it, puppet 
should terminate it's execution with a error.

OS: FreeBSD 7.2 RELEASE-p7
ARCH: amd64
PUPPET: 2.6.4
FACTER: 1.5.8


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5915] We should be consistent about use of underscores and hyphens in config vs application options

[tickets]

Issue #5915 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5915: We should be consistent about use of underscores and hyphens in 
config vs application options
https://projects.puppetlabs.com/issues/5915#change-80500

Author: James Turnbull
Status: Accepted
Priority: Normal
Assignee: 
Category: documentation
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 





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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5898] Node regex beginning with dash results in invalid tag

[tickets]

Issue #5898 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5898: Node regex beginning with dash results in invalid tag
https://projects.puppetlabs.com/issues/5898#change-80499

Author: Matthew Powell
Status: Accepted
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 2.6.4
Keywords: 
Branch: 


A node regex starting with a dash results in a tag that begins with a dash, 
which Puppet doesn't accept as valid:

node /-(abc|def)-/ {

results in the following error when it is matched:

Invalid tag "-abcdef-" on node host-abc-5678.example.com

Removing the initial dash works as expected:

node /(abc|def)-/ {



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5860] arrays do not work in selectors

[tickets]

Issue #5860 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5860: arrays do not work in selectors
https://projects.puppetlabs.com/issues/5860#change-80497

Author: Adam Crews
Status: Accepted
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


Using an array in a selector does not work:

$info = [ "acrews", "Adam", "/bin/bash" ] 
$shell = $info[2] ? { 
/bin/ => $info[2], 
default => "/sbin/nologin", 
} 

I get: Syntax error at '?'; expected '} 

If I do this it works: 

$info = [ "acrews", "Adam", "/bin/bash" ] 
$AA = $info[2] 
$shell => $AA ? { 
   /bin/ => $info[2], 
   default => "/sbin/nologin", 
}

An array element should be able to be used exactly like any normal variable.

I see this on 2.6.4.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5876] Require and Subscribe on the same refreshonly exec doesnt work

[tickets]

Issue #5876 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5876: Require and Subscribe on the same refreshonly exec doesnt work
https://projects.puppetlabs.com/issues/5876#change-80498

Author: R.I. Pienaar
Status: Needs More Information
Priority: Normal
Assignee: Nick Lewis
Category: exec
Target version: 
Affected Puppet version: 0.25.4
Keywords: 
Branch: 


Given this manifest:


exec{"moo":
command => "/usr/bin/cowsay 'fail :('",
refreshonly => true,
logoutput => true,
require  => Exec["false"],
subscribe => [ File["/tmp/1"], File["/tmp/2"], File["/tmp/3"] ]
}

file{"/tmp/1": content => 1}
file{"/tmp/2": content => 2}
file{"/tmp/3": content => 3}
exec{"false": command => "/bin/false"}


The Exec[moo] shouldn't run it requires Exec[false] which will always fail, but 
it gets notified by the file resources via its subscribes and then runs anyway 
regardless of the state of the required resources.

In version 2.6.5 this might be related to #5670 but I am filing a new bug since 
I think its not as this bug is also present in 0.25.x while the one in #5670 is 
2.6.x only


notice: //File[/tmp/1]/content: defined content as 'unknown checksum'
notice: //File[/tmp/3]/content: defined content as 'unknown checksum'
err: //Exec[false]/returns: change from notrun to 0 failed: /bin/false returned 
1 instead of one of [0] at /home/rip/test.pp:12
notice: //File[/tmp/2]/content: defined content as 'unknown checksum'
notice: //Exec[moo]: Dependency exec[/bin/false] has 1 failures
warning: //Exec[moo]: Skipping because of failed dependencies
notice: //Exec[moo]: Triggering 'refresh' from 3 dependencies
notice: //Exec[moo]/returns:  _ 
notice: //Exec[moo]/returns: < fail :( >
notice: //Exec[moo]/returns:  - 
notice: //Exec[moo]/returns: \   ^__^
notice: //Exec[moo]/returns:  \  (oo)\___
notice: //Exec[moo]/returns: (__)\   )\/\
notice: //Exec[moo]/returns: ||w |
notice: //Exec[moo]/returns: || ||



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5839] puppet filebucket -s doesn't work

[tickets]

Issue #5839 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5839: puppet filebucket -s doesn't work
https://projects.puppetlabs.com/issues/5839#change-80496

Author: Jesse Wolfe
Status: Accepted
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 2.6.4
Keywords: 
Branch: 


`puppet filebucket -s servername`
fails with
`ambiguous option: -s`



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5806] puppet cert --clean --all should prompt for confirmation

[tickets]

Issue #5806 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5806: puppet cert --clean --all should prompt for confirmation
https://projects.puppetlabs.com/issues/5806#change-80495

Author: Hunter Haugen
Status: Accepted
Priority: High
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


It's cool that you can run any combination of --sign --list and --clean with 
--all, but really --clean --all is a short way away from everything going fine 
to everything no longer being fine.

It would be helpful if this operation asked for confirmation.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5756] When a resource is being audited for the first time it should produce an event

[tickets]

Issue #5756 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5756: When a resource is being audited for the first time it should 
produce an event
https://projects.puppetlabs.com/issues/5756#change-80494

Author: Matt Robinson
Status: Accepted
Priority: Normal
Assignee: 
Category: auditing/compliance
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


Currently the first audit run for a resource doesn't create an event in the 
report that is produced, but it does log that a new audited value was recorded. 
 Perhaps this is desired behavior.  Perhaps not.  It probably depends on how 
people consuming report events are likely to act on that information, and I 
don't think we have the user stories clear enough for how reports are used to 
make that decision.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5713] Auditing resources resource to get list of all system packages

[tickets]

Issue #5713 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5713: Auditing resources resource to get list of all system packages
https://projects.puppetlabs.com/issues/5713#change-80492

Author: Matt Robinson
Status: Accepted
Priority: Normal
Assignee: 
Category: auditing/compliance
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


Does this work?

resources { package :
  audit => all,
}

If not how could we do something to get a list of all installed system packages 
audited.  I guess this has implications for other types too.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5752] Solaris 10 root crontab gets destroyed

[tickets]

Issue #5752 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5752: Solaris 10 root crontab gets destroyed 
https://projects.puppetlabs.com/issues/5752#change-80493

Author: Kent Holloway
Status: In Topic Branch Pending Review
Priority: High
Assignee: 
Category: cron
Target version: 
Affected Puppet version: 2.6.4
Keywords: 
Branch: https://github.com/puppetlabs/puppet/pull/1100


Scenario:
 Use the cron provider for a user that does not exist corrupts all managed 
crontabs.

Summary:
 While managing cron jobs for the root user and a secondary user called monitor 
the root crontab gets wiped out when the monitor user does not exist on the 
system. Since the crontab -l part happens before the monitor user gets created 
it seems to incorrectly identify that roots crontab does not exist which causes 
it to get created as if it were empty wiping out all current entries and 
leaving only the puppet managed entry with no backup file to recover from. I 
have tested with and without the require option on the monitor cron job and 
moving it into different classes that get run later but it still occurs most 
likely due to the prefetch failing.

This is repeatable every time (remove the monitor user and any puppet managed 
cron job for root user to retest for the failure).
Currently happening on a Solaris 10 zone but most likely also happens on the 
global zone.

Environment:
 Solaris 10 Update 8 (SPARC)
 Puppet 2.6.3
 Facter 1.5.8
 Ruby 1.8.7 (2010-08-16 patchlevel 302) [sparc-solaris2.10]

Debug output:
debug: Prefetching crontab resources for cron
debug: Executing 'crontab -l'
debug: Executing 'crontab -l'
err: Could not prefetch cron provider 'crontab': Could not read crontab for 
monitor: Invalid user: monitor

Code:
import "*"
class coresystems {
user { 'monitor':
uid  => '472',
gid  => '472',
home => '/tmp',
shell=> '/bin/bash',
password => 'NP',
ensure   => 'present',
require  => Group['monitor'],
}

group { 'monitor':
gid=> '472',
ensure => 'present',
}

# Unique time in the range of 0-59 per node name..
$minute = fqdn_rand(59)
$puppet_binary = "/usr/bin/puppet"

if $minute > 29
{
$minute2 = $minute - 30
}
else
{
$minute2 = $minute + 30
}

cron { "manual-puppet":
command => "$puppet_binary agent --onetime --no-daemonize --logdest 
syslog > /dev/null 2>&1",
user => "root",
hour => "*",
minute => [$minute, $minute2],
ensure => present,
}

cron { "myjob":
command => "/opt/bin/test.pl",
user=> "monitor",
hour=> "*",
minute  => [0,5,10,15,20,25,30,35,40,45,50,55],
ensure  => present,
require => User['monitor'],
}
} 


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5663] require() function should fail gracefully when being passed resource references

[tickets]

Issue #5663 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5663: require() function should fail gracefully when being passed resource 
references
https://projects.puppetlabs.com/issues/5663#change-80490

Author: Patrick Mohr
Status: Accepted
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 2.6.4
Keywords: 
Branch: 


When I run the attached manifest using "puppet bug.pp" I get this error:

undefined method `downcase' for # at 
/path_removed/bug.pp:4 on node hostname_removed

I know this syntax is wrong, but I'm assuming that puppet should be handling it 
more gracefully.

--- 
(nigel) - The require function as in #3571 should handle objects other than 
simple class names, but in the meantime we should definitely fail more 
gracefully.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5674] resource auto-search/auto-loading doesn't work in ruby dsl

[tickets]

Issue #5674 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5674: resource auto-search/auto-loading doesn't work in ruby dsl
https://projects.puppetlabs.com/issues/5674#change-80491

Author: Yuri Arabadji
Status: Accepted
Priority: Normal
Assignee: 
Category: language
Target version: 
Affected Puppet version: 2.6.4
Keywords: 
Branch: 


It just doesn't work.

.pp:


node 'default' {
testo::seconddef { 'secdef_rsrc': }
}

**notice: Scope(Testo::Seconddef[secdef_rsrc]): Define: second**

while with .rb:


node 'default' do
create_resource 'testo::seconddef', 'secdef_rsrc'
end

**Cannot find definition Testo::Seconddef on node xxx**



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5620] user password age not updating "lastchg" field in shadow file on solaris

[tickets]

Issue #5620 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5620: user password age not updating "lastchg" field in shadow file on 
solaris
https://projects.puppetlabs.com/issues/5620#change-80489

Author: derek olsen
Status: Tests Insufficient
Priority: Normal
Assignee: 
Category: user
Target version: 
Affected Puppet version: 
Keywords: solaris lastchg password age
Branch: 


  Hello.
  env is puppet 2.6.4, facter 1.5.8, ruby 1.8.7p302, solaris 10 x86

  We are excited to get away from our super exec hacks to manage user password 
expiry.  As part of our migration to 2.6 we are testing the new password age 
management.   While the min and max password age get's adjusted correctly the 
all important "lastchg" field in the solaris shadow file does not get updated 
when the password changes.   I consider this a bug because because if the 
"lastchg" field does not get updated then the min and max ages don't provide 
the functionality they had been intended to provide.

  This example illustrates what I'm seeing.  
 

grep liluser /etc/shadow  (note the date string "14364" that's when the 
password was last changed)
liluser:$2a$04$qJzZqI2839382jdCbXhJ8eJUhng48J/PCUuOG6jk422J/pWZDjASW:14364:7:90

cat pass-age.pp  (i've changed the crypt to force a password update)
  user { 'liluser':
   uid=> '516',
   gid=> '10',
   password_min_age => "7",
   password_max_age => "90",
   password   => '$2a$04$qJzZqI2839382jdCbXhJ8eJUhng48J/PCU283l3h3l22J/pWZDj
ASW',
   comment=> 'pass age test',
   shell  => '/bin/bash',
   ensure => 'present',
   }

puppet apply --debug pass-age.pp 
[stuff removed here]
notice: /Stage[main]//User[liluser]/password: changed password
debug: Finishing transaction 76130560
debug: Storing state
debug: Stored state in 0.04 seconds

grep liluser /etc/shadow  (lastchg field unchanged)
liluser:$2a$04$qJzZqI2839382jdCbXhJ8eJUhng48J/PCUuOG6jk48kJ/pWZDjASW:14364:7:90
 

Thanks.  Derek.



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5608] Puppet shouldn't enumerate LDAP users for local user unmanaged resource purge

[tickets]

Issue #5608 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5608: Puppet shouldn't enumerate LDAP users for local user unmanaged 
resource purge
https://projects.puppetlabs.com/issues/5608#change-80488

Author: Sean Millichamp
Status: Code Insufficient
Priority: Normal
Assignee: Sean Millichamp
Category: user
Target version: 
Affected Puppet version: 2.6.4
Keywords: 
Branch: https://github.com/seanmil/puppet/tree/ticket/2.6.x/5608


When using:

resources { 'user':
  purge => true
}

in a Puppet configuration not setup for LDAP management (intentionally) it is 
using the system getent functions via listbyname() (inherited from 
lib/puppet/provider/nameservice.rb) which nevertheless lists all the LDAP users 
because they show in the getent database via nsswitch.

This causes a number of problems in my situation:

1) The LDAP tree is large enough that Puppet can't complete in a reasonable 
amount of time when it has to list all of the users in LDAP
2) Puppet will see users it can't delete
3) Even if it could delete those users, I only want to use Puppet to manage 
just the local users

Based on my reading of the code, if Puppet is being used to manage LDAP users 
the ldap.rb provider manages that itself and doesn't require use of getpwent in 
nameservice.rb

The workaround I used is by overriding the listbyname() function in a custom 
provider (which inherits from useradd) to look for users in /etc/passwd. It 
seems like it would be safe to just modify the listbyname() function in 
nameservice.rb to look directly in /etc/passwd but I am not certain what else 
that might impact.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5604] disabling of apt-listchanges in puppet provider is a bit aggressive

[tickets]

Issue #5604 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5604: disabling of apt-listchanges in puppet provider is a bit aggressive
https://projects.puppetlabs.com/issues/5604#change-80486

Author: micah -
Status: Accepted
Priority: High
Assignee: 
Category: package
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


it seems like the puppet apt provider mysteriously disables apt-listchanges 
using an environment variable. This is a bit ugly, and hidden.

in /usr/lib/ruby/1.8/puppet/provider/package/apt.rb there is this:

ENV['APT_LISTCHANGES_FRONTEND'] = "none" 


Which is used by apt-listchanges in ./apt-listchanges/ALCConfig.py.

With this environment set, you cannot use apt-listchanges at all. Its true that 
if the listbugs or listchanges front-end is set to an interactive one, and one 
of those is not able to fallback to something else if run from a non 
interactive shell, this commit does the right thing to get things working from 
inside puppet. However, a legitimate way to use apt-listchanges is to set the 
front-end to use "mail" which is a non-interactive way to have it send you 
email about package upgrades... but this change makes even that impossible.

Is there a way we can override the provider's environment setting?

According to git logs, this was changed in b0636354 (Dean Wilson 2010-08-13 
13:50:52 +0100 19) with the commit msg: "Skip apt-listbugs and apt-listchanges 
when installing from puppet", but with no rationale.




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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5605] Prefetch doesnt work when resourcetype uses composite keys

[tickets]

Issue #5605 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5605: Prefetch doesnt work when resourcetype uses composite keys
https://projects.puppetlabs.com/issues/5605#change-80487

Author: Stefan Schulte
Status: Needs More Information
Priority: Normal
Assignee: 
Category: transactions
Target version: 
Affected Puppet version: 2.6.0
Keywords: transaction, prefetch, provider
Branch: https://github.com/stschulte/puppet/tree/ticket/2.6.x/5605


One can create types with multiple keyattributes by using isnamevar multiple 
times. (Example: Port in /etc/services with the keyattributes name and 
protocol).

Unfortunately prefetching of these types is broken in transaction.rb

def prefetch
  prefetchers = {}
  @catalog.vertices.each do |resource|
if provider = resource.provider and 
provider.class.respond_to?(:prefetch)
  prefetchers[provider.class] ||= {}
  prefetchers[provider.class][resource.name] = resource
end
  end
  [...]
end

Because `resource.name` is not uniq anymore we will eventually overwrite 
existing resources in the prefetch-hash and thus not all resources are passed 
to the prefetch method of the underlying provider. So if the user defined the 
following manifest:

port { 'telnet:tcp': name => 'telnet', protocol => 'tcp', number => '23'}
port { 'telnet:udp': name => 'telnet', protocol => 'udp', number => '23'}

The providers defined `def self.prefetch(resources)` will only get 
`resources['telnet'] = `

I have the following suggestions:

* use `resource.uniqueness_key` instead of `resource.name`. `uniqueness_key` is 
an array of all the key_attributes. This can only work if you can reliably use 
arrays as hashkeys. I don't know if thats true for all ruby versions. This 
solution will probably break every existing provider who uses prefetch
* same as firstone except use uniqueness_key[0].intern if we only have one 
keyattribute. This solution will hopefully not break existing providers
* use `prefetchers[provider.class][resource.name] << resource` so we will not 
overwrite but build an array if name is not uniq.
* build a nested hash, so in my port example we whould get 
`prefetchers[provider.class][resource[:name]][resource[:protocol]]`


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5405] puppet-master logcheck rule needs adjustment

[tickets]

Issue #5405 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5405: puppet-master logcheck rule needs adjustment
https://projects.puppetlabs.com/issues/5405#change-80484

Author: micah -
Status: In Topic Branch Pending Review
Priority: Normal
Assignee: 
Category: ext
Target version: 
Affected Puppet version: 2.6.0
Keywords: logcheck, puppet-master, environment
Branch: 


The logcheck update for 2.6 that was done in #4706 didn't catch the fact that 
there was a change in the puppet-master log for catalog compilations, namely 
the environment was added, please change the ext/logcheck/puppet as follows:


-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ puppet-master\[[0-9]+\]: Compiled catalog 
for [._[:alnum:]-]+ in [.0-9]+ seconds$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ puppet-master\[[0-9]+\]: Compiled catalog 
for [._[:alnum:]-]+ in environment [._[:alnum:]-]+ in [.[:digit:]]+ seconds$




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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5382] Legacy executables should issue deprecation warnings

[tickets]

Issue #5382 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5382: Legacy executables should issue deprecation warnings
https://projects.puppetlabs.com/issues/5382#change-80483

Author: Nick Fagerlund
Status: Accepted
Priority: Normal
Assignee: 
Category: executables
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


Since the single executable introduced in 2.6.0 is now the official way to 
invoke all of Puppet's functions, we should deprecate all the standalone 
executables (puppetmasterd, puppetd, puppet \[without a command\], puppetca, 
ralsh, puppetrun, puppetqd, filebucket, puppetdoc, and pi) and print warnings 
when they're used. I'm told it'd be impolite to start warning during 2.6, so 
let's start in 2.7.0.

In terms of documentation, I'm going to start describing these standalone 
executables as "legacy" and slated for deprecation; once 2.7 drops, I'll start 
describing them as deprecated and slated for removal. 


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5467] Block comments should work with `puppet apply`

[tickets]

Issue #5467 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5467: Block comments should work with `puppet apply`
https://projects.puppetlabs.com/issues/5467#change-80485

Author: Hunter Haugen
Status: Accepted
Priority: Low
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


As stated in 
http://projects.puppetlabs.com/projects/1/wiki/Puppet_Manifest_Documentation 
block comments in the syntax of 
/* foo */ should not be evaluated. This doesn't work in 2.6.4


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5369] Autorequire loop resolution inadequate

[tickets]

Issue #5369 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5369: Autorequire loop resolution inadequate
https://projects.puppetlabs.com/issues/5369#change-80482

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


In the following there is an implied dependency (autorequire) between the file 
and its parent directory.


file { "/tmp/a": ensure => directory }
file { "/tmp/a/b": content => 'foo' }


The dependency can be overridden by a direct, explicit contra-dependency:


file { "/tmp/a": ensure => directory }
file { "/tmp/a/b": content => 'foo' }
File['/tmp/a'] <- File['/tmp/a/b']


But fails with a cycle if the explicit contra-dependency is indirect:


file { "/tmp/a": ensure => directory }
file { "/tmp/a/b": content => 'foo' }
file { "/tmp/c": content => 'bar' }
File['/tmp/a'] <- File['/tmp/c'] <- File['/tmp/a/b']




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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5362] Remote file bucket won't work under certain situations unless "path => false"

[tickets]

Issue #5362 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5362: Remote file bucket won't work under certain situations unless "path 
=> false"
https://projects.puppetlabs.com/issues/5362#change-80480

Author: Luke Bigum
Status: Code Insufficient
Priority: Normal
Assignee: 
Category: fileserving
Target version: 
Affected Puppet version: 2.6.2
Keywords: filebucket
Branch: 


Following on from the thread 'client won't use remote file bucket', the 
following configuration does not file bucket to the puppet master:


filebucket { "main": server => "puppet" }
File { backup => "main" }
node 'default' {
  include test
}

class test {
  file { "/etc/sudoers":
source => "puppet:///modules/test/sudoers",
owner => "root",
group => "root",
mode => "0440",
ensure => present,
backup => "main",
  }
} 


The fix is to have "path => false" added to the filebucket declaration. Is it 
possible the path variable has some default value that's stopping such a 
generic filebucket definition from working? If you need more information I'm 
happy to play with the config to test various situations for you.

CentOS release 5.5 (Final)

*** LOCAL GEMS ***

facter (1.5.8)
fastthread (1.0.7)
mysql (2.8.1)
passenger (2.2.9)
puppet (2.6.2)
rack (1.1.0)
rake (0.8.7)

ruby 1.8.7 (2010-04-19 patchlevel 253) [x86_64-linux], MBARI 0x6770, Ruby 
Enterprise Edition 2010.02



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5368] Using a parameterized class that doesn't exist results in a confusing error.

[tickets]

Issue #5368 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5368: Using a parameterized class that doesn't exist results in a 
confusing error.
https://projects.puppetlabs.com/issues/5368#change-80481

Author: Jordan Sissel
Status: Accepted
Priority: Normal
Assignee: 
Category: error reporting
Target version: 
Affected Puppet version: 2.6.4
Keywords: parameterized class classes confusing error message
parameterized_classes
Branch: 


Error message: Puppet::Parser::AST::Resource failed with error ArgumentError: 
Invalid resource type class at ...

I expected that 'include foo' and 'class { "foo": ...; }' should result in the 
same error message if class 'foo' does not exist.

For example:


% puppet apply -e 'include notbar'
Could not find class notbar at line 1 on node snack.home

% puppet apply -e 'class { "notbar": ; }'
Puppet::Parser::AST::Resource failed with error ArgumentError: Invalid resource 
type class at line 1 on node snack.home


Confirmed this problem is in both 2.6.2 and 2.6.3


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5290] No tests for RDoc puppet generator code

[tickets]

Issue #5290 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5290: No tests for RDoc puppet generator code
https://projects.puppetlabs.com/issues/5290#change-80479

Author: Matt Robinson
Status: Accepted
Priority: Normal
Assignee: 
Category: testing
Target version: 
Affected Puppet version: 2.6.0
Keywords: rdoc tests
Branch: 


lib/puppet/util/rdoc/generators/puppet_generator.rb has no tests.  Brice thinks 
there may not be a useful way to test it because of the interactions with RDoc, 
but it should be looked into at the very least the next time a patch affects 
this portion of the code (for example #4911 recently fixed something in this 
code for which no regression test was added).


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5257] Files written to non-existent directories get confusing error messages

[tickets]

Issue #5257 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5257: Files written to non-existent directories get confusing error 
messages
https://projects.puppetlabs.com/issues/5257#change-80478

Author: Jordan Sissel
Status: Accepted
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: usability
Branch: 


This is a common report in #puppet on freenode:


14:45 < astrostl> getting a "change from absent to file failed" on that one, 
with a "no 
  such file or directory bar.puppettmp_2893"


The cause is an attempt to write a file to a directory that does not exist, for 
example:


ops(~) !127! % puppet apply -e 'file { "/tmp/path/does/not/exist/myfile": 
ensure => file, content => "Hello"; }'
err: /Stage[main]//File[/tmp/path/does/not/exist/myfile]/ensure: change from 
absent to file failed: Could not set 'file on ensure: No such file or directory 
- /tmp/path/does/not/exist/myfile.puppettmp_7620 at line 1


This error message gets confusing right about the time it says ".puppettmp_..." 
- It would be much better if this error message said more explicitly something 
like: "Could not set file on ensure: Directory does not exist: 
/tmp/path/does/not/exist" - or something similar.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5241] puppetd ignores local ca.pem when connecting to master for the first time

[tickets]

Issue #5241 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5241: puppetd ignores local ca.pem when connecting to master for the first 
time
https://projects.puppetlabs.com/issues/5241#change-80476

Author: Tal Y.
Status: Accepted
Priority: High
Assignee: 
Category: SSL
Target version: 
Affected Puppet version: 2.6.2
Keywords: 
Branch: 


Hi,

I have a clean machine, with only puppet.conf configured (using --genconfig) 
and /etc/puppet/ssl/certs/ca.pem. I now run for the first time puppetd and 
connect to a server that has a *different* CA.

I believe the expected behavior should be that puppetd will abort the 
connection because it connects to an unauthorized server. Instead, puppetd 
continues to communicate with the unauthorized master and generates a new 
certificate request.

Unless I'm mistaken, this scenario could lead to a security breach: if an 
attacker gains control over the DNS, it can redirect new machines to its own 
malicious master. The master will make the node install a rootkit for example. 
Afterwards the attacker will redirect the DNS back to the original master. The 
node will then retrieve from the original (unsuspecting) master sensitive 
information, information that now the attacker can access.

I'm running puppet version 2.6.2.

Thanks,
Tal


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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #5256] Ruby DSL changes require puppet master restart

[tickets]

Issue #5256 has been updated by Andrew Parker.


As the 2.7.x line is winding down, I am removing the target at 2.7.x from 
tickets in the system. The 2.7 line should only receive fixes for major 
problems (crashes, for instance) or security problems.

Bug #5256: Ruby DSL changes require puppet master restart
https://projects.puppetlabs.com/issues/5256#change-80477

Author: Nan Liu
Status: Accepted
Priority: High
Assignee: 
Category: 
Target version: 
Affected Puppet version: 2.6.2
Keywords: ruby, dsl
Branch: 


Unlike puppet manifests, changes to Ruby DSL require complete restart of puppet 
master to take effect. If you edit init.rb file after puppet master process the 
.rb file the agent will receive a class can not be found error:

 # vim /etc/puppet/modules/ntp/manifests/init.rb
 # puppet agent -t
 err: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Could not find class ntp at /etc/puppet/manifests/site.pp:2 on node 
puppet.training

A restart resolves the problem:
 # service puppetmaster restart
 Stopping puppetmaster: [  OK  ]
 Starting puppetmaster: [  OK  ]
 # puppet agent -t
 ...
 notice: puppet.training
 notice: /Stage[main]/Ntp/Notify[hello]/message: defined 'message' as 
'puppet.training'
 notice: Finished catalog run in 0.76 seconds



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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.