http://permalink.gmane.org/gmane.comp.sysutils.puppet.bugs hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.sysutils.puppet.bugs/49442 <pre> The 'Downloading Puppet' wiki page has been updated by Matthaus Owens. Downloading Puppet: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet View differences: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet/253/diff </pre> tickets< at >puppetlabs.com 2013-05-17T22:59:38 http://permalink.gmane.org/gmane.comp.sysutils.puppet.bugs/49441 <pre> Issue #20787 has been updated by Ruth Linehan. It takes 36 seconds, so not quite as long, but still not good. ---------------------------------------- Bug #20787: 'puppet resource group' takes incredibly long on Windows https://projects.puppetlabs.com/issues/20787#change-91191 * Author: Ruth Linehan * Status: Accepted * Priority: High * Assignee: * Category: * Target version: * Affected Puppet version: 3.2.0-rc2 * Keywords: windows, windows 2008 r2 * Branch: ---------------------------------------- on Windows 2008 R2, running Puppet 3.2.0 (Puppet Enterprise 3.0.0-debian-preview4-52), `puppet resource group` takes ~100 seconds. Josh Cooper noted that this seems to be because we are using ADSI to enumerate user's groups and groups' members, and we should use Win32 APIs instead. Changing Puppet::Util::ADSI::User#groups (line 125) and Puppet::Util::ADSI::Groups#members (line 25) to return empty arrays cut the time in half. </pre> tickets< at >puppetlabs.com 2013-05-17T19:31:15 http://permalink.gmane.org/gmane.comp.sysutils.puppet.bugs/49440 <pre> Issue #17710 has been updated by Hailee Kenney. Status changed from In Topic Branch Pending Review to Merged - Pending Release ---------------------------------------- Refactor #17710: issues with IP facts https://projects.puppetlabs.com/issues/17710#change-91190 * Author: Alex Harvey * Status: Merged - Pending Release * Priority: Normal * Assignee: * Category: util_ip * Target version: 2.0.0 * Keywords: * Branch: https://github.com/puppetlabs/facter/pull/423 * Affected Facter version: 1.6.14 ---------------------------------------- </pre> tickets< at >puppetlabs.com 2013-05-17T19:28:43 http://permalink.gmane.org/gmane.comp.sysutils.puppet.bugs/49439 <pre> Issue #20787 has been updated by Josh Cooper. Status changed from Unreviewed to Accepted Does `puppet resource user` take equally long? ---------------------------------------- Bug #20787: 'puppet resource group' takes incredibly long on Windows https://projects.puppetlabs.com/issues/20787#change-91189 * Author: Ruth Linehan * Status: Accepted * Priority: High * Assignee: * Category: * Target version: * Affected Puppet version: 3.2.0-rc2 * Keywords: windows, windows 2008 r2 * Branch: ---------------------------------------- on Windows 2008 R2, running Puppet 3.2.0 (Puppet Enterprise 3.0.0-debian-preview4-52), `puppet resource group` takes ~100 seconds. Josh Cooper noted that this seems to be because we are using ADSI to enumerate user's groups and groups' members, and we should use Win32 APIs instead. Changing Puppet::Util::ADSI::User#groups (line 125) and Puppet::Util::ADSI::Groups#members (line 25) to return empty arrays cut the time in half. </pre> tickets< at >puppetlabs.com 2013-05-17T19:26:31 http://permalink.gmane.org/gmane.comp.sysutils.puppet.bugs/49438 <pre> Issue #20784 has been updated by Charlie Sharpsteen. Jarvis Canning wrote: If availability of packages is the primary roadblock, PuppetLabs maintains a repository for RHEL5 at: &lt;http://yum.puppetlabs.com/el/5/products/&gt; Compared to EPEL, the latest releases for each of our series are available there. Returning to your issue, it is starting to look like the server might be compiling the catalog successfully and delivering it to the agent, but the agent is failing to de-parse the JSON. After running the agent, could you check for a recently modified file in: /var/lib/puppet/client_data/catalog If one exists, try applying it directly with: puppet apply --apply /var/lib/puppet/client_data/catalog/&lt;agent fqdn&gt;.json\ And see if the same error message pops up. ---------------------------------------- Bug #20784: err: Could not retrieve catalog from remote server: Could not intern from pson: Could not parse for environment production: stack level too deep https://projects.puppetlabs.com/issues/20</pre> tickets< at >puppetlabs.com 2013-05-17T19:02:54 http://permalink.gmane.org/gmane.comp.sysutils.puppet.bugs/49437 <pre> Issue #20779 has been updated by Charlie Sharpsteen. Status changed from Unreviewed to Rejected Assignee set to Charlie Sharpsteen The `settings` class contains information derived from settings and command line arguments that were passed to the process hosting the compiler. The documentation describes [the situation in detail](http://docs.puppetlabs.com/puppet/2.7/reference/lang_variables.html#master-set-variables), but the important summary is: With `puppet apply`, you get the value of `--tags` because both compilation and catalog application are happening inside the same process and there is no split between "master settings" and "agent settings". ---------------------------------------- Bug #20779: --tags available with puppet apply but not with puppet agent https://projects.puppetlabs.com/issues/20779#change-91183 * Author: Benjamin Pillet * Status: Rejected * Priority: Normal * Assignee: Charlie Sharpsteen * Category: * Target version: * Affected Puppet version: 2.7.17 * Keywords: * Branch: </pre> tickets< at >puppetlabs.com 2013-05-17T18:06:35 http://permalink.gmane.org/gmane.comp.sysutils.puppet.bugs/49436 <pre> Issue #20742 has been updated by Andrew Parker. Status changed from In Topic Branch Pending Review to Merged - Pending Release Merged into stable as &lt;https://github.com/puppetlabs/puppet/commit/acd02bb814b890498316c0a39dc68cf89f3f90e5&gt; ---------------------------------------- Bug #20742: unauthenticated clients unable to communicate with puppet master (running in passenger) https://projects.puppetlabs.com/issues/20742#change-91182 * Author: Mike Szymanski * Status: Merged - Pending Release * Priority: Normal * Assignee: Andrew Parker * Category: * Target version: 3.2.1 * Affected Puppet version: 3.2.0-rc2 * Keywords: * Branch: https://github.com/puppetlabs/puppet/pull/1653 ---------------------------------------- I am having an issue adding new clients to puppet. The master is not accepting connections from unauthenticated clients, even though my auth.conf that worked with v3.1.1 has not changed. If I test ssl via curl -k, the puppet master returns "can't convert nil into String" to the client. The</pre> tickets< at >puppetlabs.com 2013-05-17T17:41:41 http://permalink.gmane.org/gmane.comp.sysutils.puppet.bugs/49435 <pre> Issue #20787 has been reported by Ruth Linehan. ---------------------------------------- Bug #20787: 'puppet resource group' takes incredibly long on Windows https://projects.puppetlabs.com/issues/20787 * Author: Ruth Linehan * Status: Unreviewed * Priority: High * Assignee: * Category: * Target version: * Affected Puppet version: 3.2.0-rc2 * Keywords: windows, windows 2008 r2 * Branch: ---------------------------------------- on Windows 2008 R2, running Puppet 3.2.0 (Puppet Enterprise 3.0.0-debian-preview4-52), `puppet resource group` takes ~100 seconds. Josh Cooper noted that this seems to be because we are using ADSI to enumerate user's groups and groups' members, and we should use Win32 APIs instead. Changing Puppet::Util::ADSI::User#groups (line 125) and Puppet::Util::ADSI::Groups#members (line 25) to return empty arrays cut the time in half. </pre> tickets< at >puppetlabs.com 2013-05-17T17:13:01 http://permalink.gmane.org/gmane.comp.sysutils.puppet.bugs/49434 <pre> Issue #20784 has been updated by Jarvis Canning. File puppetmaster.log added Hi Charlie, Thank you for your prompt response. 2.6.18 is what is provided by the EPEL repo for RHEL5. It's the easiest to use for my purposes. When the repo updates to 2.7 I'll update my server and clients. The amount of data that puppetmasterd puts out it pretty huge so I've attached a log file instead of trying to cut and paste. ---------------------------------------- Bug #20784: err: Could not retrieve catalog from remote server: Could not intern from pson: Could not parse for environment production: stack level too deep https://projects.puppetlabs.com/issues/20784#change-91181 * Author: Jarvis Canning * Status: Needs More Information * Priority: Normal * Assignee: Jarvis Canning * Category: agent * Target version: * Affected Puppet version: 2.6.18 * Keywords: * Branch: ---------------------------------------- I have a network of 30 RHEL 5 boxes with puppet-2.6.18-3.el5 installed. One of the 40 boxes refuses to work</pre> tickets< at >puppetlabs.com 2013-05-17T16:59:12 http://permalink.gmane.org/gmane.comp.sysutils.puppet.bugs/49433 <pre> Issue #20784 has been updated by Charlie Sharpsteen. Status changed from Unreviewed to Needs More Information Assignee set to Jarvis Canning Hi Jarvis, The 2.6.x line of Puppet releases is getting a little long in the tooth and there have been a lot of fixes and changes that have occurred in the 2.7.x and 3.x lines. You should consider migrating to the 2.7.x series as it is very likely that 2.6.x will be completely wound down in the near future. In this case, the actual error is occurring on the Puppet server. Could you provide `--debug` and `--trace` information from the puppet master process? ---------------------------------------- Bug #20784: err: Could not retrieve catalog from remote server: Could not intern from pson: Could not parse for environment production: stack level too deep https://projects.puppetlabs.com/issues/20784#change-91179 * Author: Jarvis Canning * Status: Needs More Information * Priority: Normal * Assignee: Jarvis Canning * Category: agent * Target version: * Affected Puppe</pre> tickets< at >puppetlabs.com 2013-05-17T16:38:33 http://permalink.gmane.org/gmane.comp.sysutils.puppet.bugs/49432 <pre> Issue #20531 has been updated by Josh Cooper. Keywords set to windows ---------------------------------------- Bug #20531: puppet module tool on windows will (sometimes) create a PaxHeader directory https://projects.puppetlabs.com/issues/20531#change-91177 * Author: Andrew Parker * Status: Accepted * Priority: Normal * Assignee: Josh Cooper * Category: * Target version: * Affected Puppet version: * Keywords: windows * Branch: ---------------------------------------- In Puppet 3.2 the module tool started using minitar when the tar executable is not present. It turns out that minitar does not understand the [PAX](http://en.wikipedia.org/wiki/Pax_(Unix)) format. An example of a module that was created with this is [liamjbennet/win_facts v0.0.1](https://forge.puppetlabs.com/liamjbennett/win_facts/0.0.1). When that module is installed the problem appears as follows. &lt;pre&gt; C:\Program Files (x86)\Puppet Labs\Puppet\bin&gt;puppet module install liamjbennett -win_facts Notice: Preparing to install into C:/Prog</pre> tickets< at >puppetlabs.com 2013-05-17T16:18:02 http://permalink.gmane.org/gmane.comp.sysutils.puppet.bugs/49431 <pre> Issue #20223 has been updated by Josh Cooper. Keywords changed from puppet rdoc to puppet rdoc windows ---------------------------------------- Bug #20223: puppet doc fails under windows https://projects.puppetlabs.com/issues/20223#change-91175 * Author: Frederic Schaer * Status: Accepted * Priority: Normal * Assignee: * Category: documentation * Target version: * Affected Puppet version: 3.1.1 * Keywords: puppet rdoc windows * Branch: ---------------------------------------- Hi, puppet 3.1.1 seems unable to generate documentation on windows, either under cygwin or in a plain DOS cmd. It fails with the attached error (I don't know how to paste code in here). It seems it is trying to create the files/C: dir, and all other directories using the "C:" part of the path. I'm not sure this is a puppet or a ruby issue, but since ruby is shipped with puppet under windows... I tried to see if I could work around that with string substitution (replace the '/' with '\', and the ':' with '_', but since I'm a r</pre> tickets< at >puppetlabs.com 2013-05-17T16:16:15 http://permalink.gmane.org/gmane.comp.sysutils.puppet.bugs/49430 <pre> Issue #20528 has been updated by Josh Cooper. Keywords set to windows ---------------------------------------- Bug #20528: puppet in windows install mangles one liners (using Start Command Prompt with Puppet) https://projects.puppetlabs.com/issues/20528#change-91174 * Author: Andrew Parker * Status: In Topic Branch Pending Review * Priority: Normal * Assignee: Josh Cooper * Category: * Target version: * Affected Puppet version: * Keywords: windows * Branch: https://github.com/puppetlabs/puppet-docs/pull/161 ---------------------------------------- The command: &lt;pre&gt; C:\Program Files (x86)\Puppet Labs\Puppet\bin&gt;puppet apply -e 'notify { foo: message =&gt; "hello world!" }' &lt;/pre&gt; Produces: &lt;pre&gt; Error: Could not parse for environment production: Syntax error at '='; expected '}' at line 1 on node win-p4cvm028u5j.localdomain Error: Could not parse for environment production: Syntax error at '='; expected '}' at line 1 on node win-p4cvm028u5j.localdomain &lt;/pre&gt; If you take the same snippet and place it i</pre> tickets< at >puppetlabs.com 2013-05-17T16:15:50 http://permalink.gmane.org/gmane.comp.sysutils.puppet.bugs/49429 <pre> Issue #20784 has been updated by Charlie Sharpsteen. Description updated ---------------------------------------- Bug #20784: err: Could not retrieve catalog from remote server: Could not intern from pson: Could not parse for environment production: stack level too deep https://projects.puppetlabs.com/issues/20784#change-91173 * Author: Jarvis Canning * Status: Unreviewed * Priority: Normal * Assignee: * Category: agent * Target version: * Affected Puppet version: 2.6.18 * Keywords: * Branch: ---------------------------------------- I have a network of 30 RHEL 5 boxes with puppet-2.6.18-3.el5 installed. One of the 40 boxes refuses to work citing the above error. I have : 1) Reinstalled puppet 2) Reinstalled all puppet pre-reqs. 3) Ensured that both puppet-server and puppet are running the same version. 4) Uninstalled puppet and removed all puppet related files (ssl keys) from client and server and reinstalled. &lt;pre&gt; root&lt; at &gt;caotlvbld2 ~]# puppetd --verbose --debug --no-daemonize --trace debug: Puppet</pre> tickets< at >puppetlabs.com 2013-05-17T16:15:25 http://permalink.gmane.org/gmane.comp.sysutils.puppet.bugs/49428 <pre> Issue #20531 has been updated by Josh Cooper. Status changed from Unreviewed to Accepted ---------------------------------------- Bug #20531: puppet module tool on windows will (sometimes) create a PaxHeader directory https://projects.puppetlabs.com/issues/20531#change-91172 * Author: Andrew Parker * Status: Accepted * Priority: Normal * Assignee: Josh Cooper * Category: * Target version: * Affected Puppet version: * Keywords: * Branch: ---------------------------------------- In Puppet 3.2 the module tool started using minitar when the tar executable is not present. It turns out that minitar does not understand the [PAX](http://en.wikipedia.org/wiki/Pax_(Unix)) format. An example of a module that was created with this is [liamjbennet/win_facts v0.0.1](https://forge.puppetlabs.com/liamjbennett/win_facts/0.0.1). When that module is installed the problem appears as follows. &lt;pre&gt; C:\Program Files (x86)\Puppet Labs\Puppet\bin&gt;puppet module install liamjbennett -win_facts Notice: Preparing to install </pre> tickets< at >puppetlabs.com 2013-05-17T16:15:22 http://permalink.gmane.org/gmane.comp.sysutils.puppet.bugs/49427 <pre> Issue #20785 has been reported by Chris Denneen. ---------------------------------------- Feature #20785: hiera hash priority https://projects.puppetlabs.com/issues/20785 * Author: Chris Denneen * Status: Unreviewed * Priority: Normal * Assignee: * Category: * Target version: * Affected Puppet version: * Keywords: * Branch: ---------------------------------------- hiera() does priority lookup and hiera_hash() combines into one large hash is there anyway that it can combine the priority function so lets say i have --bar.yaml user: foo: uid: 8001 --common.yaml user: foo: uid: 1001 name: "Foo user" shell: '/bin/bash' so desired result would be it adds user foo to all hosts with uid 1001 but on host bar it adds as uid 8001 but still gets shell /bin/bash and name "Foo user" </pre> tickets< at >puppetlabs.com 2013-05-17T15:49:42 http://permalink.gmane.org/gmane.comp.sysutils.puppet.bugs/49426 <pre> Issue #20784 has been reported by Jarvis Canning. ---------------------------------------- Bug #20784: err: Could not retrieve catalog from remote server: Could not intern from pson: Could not parse for environment production: stack level too deep https://projects.puppetlabs.com/issues/20784 * Author: Jarvis Canning * Status: Unreviewed * Priority: Normal * Assignee: * Category: agent * Target version: * Affected Puppet version: 2.6.18 * Keywords: * Branch: ---------------------------------------- I have a network of 30 RHEL 5 boxes with puppet-2.6.18-3.el5 installed. One of the 40 boxes refuses to work citing the above error. I have : 1) Reinstalled puppet 2) Reinstalled all puppet pre-reqs. 3) Ensured that both puppet-server and puppet are running the same version. 4) Uninstalled puppet and removed all puppet related files (ssl keys) from client and server and reinstalled. root&lt; at &gt;caotlvbld2 ~]# puppetd --verbose --debug --no-daemonize --trace debug: Puppet::Type::User::ProviderDirectoryservice: fil</pre> tickets< at >puppetlabs.com 2013-05-17T15:41:02 http://permalink.gmane.org/gmane.comp.sysutils.puppet.bugs/49425 <pre> Issue #18427 has been updated by Pedro Côrte-Real. I've hit this issue with nothing but the default rubygems repository. Here's a minimal puppet script that causes the issue: package {'nokogiri': provider =&gt; 'gem', ensure =&gt; 'latest', } The output from this is the same every time: $ sudo puppet apply puppet-gem-bug.pp Notice: /Stage[main]//Package[nokogiri]/ensure: ensure changed '["1.5.9"]' to '1.5.9 ruby java x86-mingw32 x86-mswin32-60' Notice: Finished catalog run in 9.97 seconds I'm running the latest puppet from apt.puppetlabs.com and the latest rubygems from ruby 1.9 in ubuntu precise. $ puppet --version 3.1.1 $ gem -v 1.8.11 I believe the extra stuff after the version number are the platforms that the gem supports. This is common in gems that have native extensions. The workaround should probably be to do a split by "," to get the various versions and then do a split by " " and take the first to get the actual version number. --------------</pre> tickets< at >puppetlabs.com 2013-05-17T14:58:39 http://permalink.gmane.org/gmane.comp.sysutils.puppet.bugs/49424 <pre> Issue #1398 has been updated by Trevor Vaughan. +1 to Pedro's suggestion. A composite namevar with pkgname and provider is the way to go. ---------------------------------------- Feature #1398: Common package name in two different providers https://projects.puppetlabs.com/issues/1398#change-91160 * Author: Lawrence Ludwig * Status: Accepted * Priority: Normal * Assignee: * Category: package * Target version: * Affected Puppet version: 0.24.4 * Keywords: package alias * Branch: ---------------------------------------- I have a common package name, that's in two different package managers (one with yum the other with gem) package { "remove-mysql": name =&gt; "mysql", provider =&gt; "yum", ensure =&gt; absent, } --------------------------------------------------------- package { "gem-mysql": name =&gt; "mysql", ensure =&gt; "2.7", provider =&gt; gem, } ----------------------------</pre> tickets< at >puppetlabs.com 2013-05-17T12:04:12 http://permalink.gmane.org/gmane.comp.sysutils.puppet.bugs/49423 <pre> Issue #20779 has been reported by Benjamin Pillet. ---------------------------------------- Bug #20779: --tags available with puppet apply but not with puppet agent https://projects.puppetlabs.com/issues/20779 * Author: Benjamin Pillet * Status: Unreviewed * Priority: Normal * Assignee: * Category: * Target version: * Affected Puppet version: 2.7.17 * Keywords: * Branch: ---------------------------------------- I have code in a catalog that logs the tags and the logdir settings: err("tags: ${settings::tags} logdir ${settings::logdir}") When I run the catalog with "puppet apply --tags=foo", it logs "tags: foo logdir: /var/log/puppet" But, when I run the catalog remotely with "puppet agent --tags=foo -tv", it logs "tags: logdir: /var/log/puppet" Shouldn't the settings::tags be available too? </pre> tickets< at >puppetlabs.com 2013-05-17T01:15:24 http://permalink.gmane.org/gmane.comp.sysutils.puppet.bugs/49422 <pre> Issue #20742 has been updated by Andrew Parker. Target version set to 3.2.1 ---------------------------------------- Bug #20742: unauthenticated clients unable to communicate with puppet master (running in passenger) https://projects.puppetlabs.com/issues/20742#change-91152 * Author: Mike Szymanski * Status: In Topic Branch Pending Review * Priority: Normal * Assignee: Andrew Parker * Category: * Target version: 3.2.1 * Affected Puppet version: 3.2.0-rc2 * Keywords: * Branch: https://github.com/puppetlabs/puppet/pull/1653 ---------------------------------------- I am having an issue adding new clients to puppet. The master is not accepting connections from unauthenticated clients, even though my auth.conf that worked with v3.1.1 has not changed. If I test ssl via curl -k, the puppet master returns "can't convert nil into String" to the client. The http log on the master shows a 400 return code. Also note, I'm using passenger &amp; httpd with my puppet master. If I do the certificate generation &amp; signi</pre> tickets< at >puppetlabs.com 2013-05-16T22:16:13 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.sysutils.puppet.bugs