[Puppet Users] Re: Puppetdb installed with puppetlabs/puppetdb migration 65 failing

2019-06-26 Thread Charlie Sharpsteen 
Postgres versions released last Thursday June 20th 
 contain a regression in the 
behavior of the ALTER TABLE statement that is causing this issue by 
preventing PuppetDB from initializing its database schema. A concise 
summary of the issue can be found in this message to the Postgres mailing 
list:

https://www.postgresql.org/message-id/20190621004554.GB1626%40paquier.xyz

A patch has been merged to work around the issue and is currently pending 
release:

https://tickets.puppetlabs.com/browse/PDB-4422

Until PuppetDB or Postgres release a new version, the best workaround is to 
use an older version of Postgres such as 9.6.13.

-Charlie

On Wednesday, June 26, 2019 at 7:39:48 AM UTC-7, Farko wrote:
>
> Hi all!
>
> Added the puppetdb module, runs through and gets stuck on boot with the 
> following error:
>
> 2019-06-26 14:20:21,638 INFO  [p.p.s.migrate] Applying database migration 
> version 65
>
> 2019-06-26 14:20:21,673 ERROR [p.p.s.migrate] Caught SQLException during 
> migration
>
> ...
>
> 2019-06-26 14:20:21,675 ERROR [p.p.s.migrate] Unravelled exception
> org.postgresql.util.PSQLException: ERROR: relation 
> "resource_events_status_for_corrective_change_idx" already exists
> at 
> org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2284)
> at 
> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2003)
> at 
> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:360)
> at 
> org.postgresql.jdbc.PgStatement.executeBatch(PgStatement.java:1019)
>
> Tried dropping the puppetdb database, and restarting puppetdb, same error 
> occurs.
>
> puppetdb version: 5.2.8
>
> Thank you!
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/86932f55-f2ee-494c-a6fa-eb7a287ec364%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Trouble after Agent upgrade -- Error: Could not autoload puppet/provider/package/gem: superclass must be a Class (Module given)

2019-06-21 Thread Charlie Sharpsteen 
A quick update on this one:

With Patrick's help, we were able to re-produce the issue in AWS. The root 
cause appears to be that the Puppet::Provider class includes the 
Puppet::Util module, which also happens to have a Puppet::Util::Package 
sub-module. So, depending on the load order of puppet/util/package and 
puppet/provider/package files, providers using the new PackageTargatable 
class could trip this error as there is a window where 
Puppet::Provider::Package may actually be the Puppet::Util::Package module.

TL/DR: Including a module in Ruby brings in more than just methods.

A JIRA bug is open and a PR is up with changes to the package providers to 
ensure the right files are required before class inheritance happens:

https://tickets.puppetlabs.com/browse/PUP-9794

Thanks a bunch to everyone who reported this issue and especially to 
Patrick Whitney for working with us to troubleshoot it.

-Charlie

On Friday, June 21, 2019 at 11:10:30 AM UTC-7, Jeff Cheng wrote:
>
> We're seeing similar issues with the official v6.5.0 docker image when 
> running in circleci:
> circleci@default-d4c9fa03-e104-4e3d-bb5e-3510a1a9eed8:~/project$ docker 
> run --rm puppet/puppet-agent-ubuntu:6.5.0 resource --types
> Error: Could not autoload puppet/provider/package/gem: superclass must be 
> a Class (Module given)
> Error: Could not autoload puppet/type/package: Could not autoload puppet/
> provider/package/gem: superclass must be a Class (Module given)
> Error: Could not parse application options: Could not autoload puppet/type
> /package: Could not autoload puppet/provider/package/gem: superclass must 
> be a Class (Module given)
>
> Running with v6.4.2 works fine on the same box:
> circleci@default-d4c9fa03-e104-4e3d-bb5e-3510a1a9eed8:~/project$ docker 
> run --rm puppet/puppet-agent-ubuntu:6.4.2 resource --types
> augeas
> cron
> exec
> file
> filebucket
> group
> host
> mount
> notify
> package
> resources
> schedule
> scheduled_task
> selboolean
> selmodule
> service
> ssh_authorized_key
> sshkey
> stage
> tidy
> user
> whit
> yumrepo
> zfs
> zone
> zpool
>
>
> On Thursday, June 20, 2019 at 4:53:34 PM UTC-4, Patrick Whitney wrote:
>>
>> Hello Everyone,
>>
>> I hope you can help.
>>
>> Our puppet agent was updated to version 6.5.0 on our servers last night.  
>> Things are working fine, except for two servers are throwing the error 
>> below (SNIP #1).A little digging found I could reproduce the error by 
>> running 'facter -p' or 'puppet facts'  (SNIP #2).  Trying to identify 
>> exactly what is going on, I got as far as running the offending ruby script 
>> (package_provider.rb) and it also returns the error, but, at least with a 
>> stack trace (SNIP #3).  
>>
>> Does anyone have any idea what we've encountered?  
>>
>> Any help would be greatly appreciated. 
>>
>> Thanks!
>> -Pat
>>
>>
>>
>> SNIP #1
>>
>> # puppet agent -t
>> Info: Using configured environment 'production'
>> Info: Retrieving pluginfacts
>> Info: Retrieving plugin
>> Info: Retrieving locales
>> Info: Loading facts
>> Error: Could not autoload puppet/provider/package/gem: superclass must 
>> be a Class (Module given)
>> Error: Facter: error while resolving custom facts in /opt/puppetlabs/
>> puppet/cache/lib/facter/package_provider.rb: Could not autoload puppet/
>> provider/package/gem: superclass must be a Class (Module given)
>> Info: Caching catalog for eu-assist.aws-eu.int.luminoso.com
>> Info: Applying configuration version '1561063233'
>> Notice: Applied catalog in 15.24 seconds
>>
>>
>> SNIP #2
>> # puppet facts > /dev/null
>> Error: Could not autoload puppet/provider/package/gem: superclass must 
>> be a Class (Module given)
>> Error: Facter: error while resolving custom facts in /opt/puppetlabs/
>> puppet/cache/lib/facter/package_provider.rb: Could not autoload puppet/
>> provider/package/gem: superclass must be a Class (Module given)
>> # facter -p > /dev/null
>> 2019-06-20 20:42:36.539351 ERROR puppetlabs.facter - error while 
>> resolving custom facts in /opt/puppetlabs/puppet/cache/lib/facter/
>> package_provider.rb: Could not autoload puppet/provider/package/gem: 
>> superclass must be a Class (Module given)
>>
>> SNIP #3
>> # /opt/puppetlabs/puppet/bin/ruby 
>> /opt/puppetlabs/puppet/cache/lib/facter/package_provider.rb
>> Traceback (most recent call last):
>>  15: from /opt/puppetlabs/puppet/cache/lib/facter/package_provider.rb:11:
>> in `'
>>  14: from 
>> /opt/puppetlabs/puppet/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
>>  
>> `require'
>>  13: from 
>> /opt/puppetlabs/puppet/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
>>  
>> `require'
>>  12: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/package
>> .rb:9:in `'
>>  11: from 
>> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/package.rb:10:in `
>> '
>>  10: from 
>> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/metatype/manager.rb:127:in
>>  
>> `newtype'
>>  9: from

[Puppet Users] Re: Trouble after Agent upgrade -- Error: Could not autoload puppet/provider/package/gem: superclass must be a Class (Module given)

2019-06-20 Thread Charlie Sharpsteen 
Could you post the content of package_provider.rb? Since that is in 
cache/lib/facter, it is a custom fact and the specifics of its 
implementation could shed some light on what is happening.

-Charlie


On Thursday, June 20, 2019 at 1:53:34 PM UTC-7, Patrick Whitney wrote:
>
> Hello Everyone,
>
> I hope you can help.
>
> Our puppet agent was updated to version 6.5.0 on our servers last night.  
> Things are working fine, except for two servers are throwing the error 
> below (SNIP #1).A little digging found I could reproduce the error by 
> running 'facter -p' or 'puppet facts'  (SNIP #2).  Trying to identify 
> exactly what is going on, I got as far as running the offending ruby script 
> (package_provider.rb) and it also returns the error, but, at least with a 
> stack trace (SNIP #3).  
>
> Does anyone have any idea what we've encountered?  
>
> Any help would be greatly appreciated. 
>
> Thanks!
> -Pat
>
>
>
> SNIP #1
>
> # puppet agent -t
> Info: Using configured environment 'production'
> Info: Retrieving pluginfacts
> Info: Retrieving plugin
> Info: Retrieving locales
> Info: Loading facts
> Error: Could not autoload puppet/provider/package/gem: superclass must be 
> a Class (Module given)
> Error: Facter: error while resolving custom facts in /opt/puppetlabs/
> puppet/cache/lib/facter/package_provider.rb: Could not autoload puppet/
> provider/package/gem: superclass must be a Class (Module given)
> Info: Caching catalog for eu-assist.aws-eu.int.luminoso.com
> Info: Applying configuration version '1561063233'
> Notice: Applied catalog in 15.24 seconds
>
>
> SNIP #2
> # puppet facts > /dev/null
> Error: Could not autoload puppet/provider/package/gem: superclass must be 
> a Class (Module given)
> Error: Facter: error while resolving custom facts in /opt/puppetlabs/
> puppet/cache/lib/facter/package_provider.rb: Could not autoload puppet/
> provider/package/gem: superclass must be a Class (Module given)
> # facter -p > /dev/null
> 2019-06-20 20:42:36.539351 ERROR puppetlabs.facter - error while 
> resolving custom facts in /opt/puppetlabs/puppet/cache/lib/facter/
> package_provider.rb: Could not autoload puppet/provider/package/gem: 
> superclass must be a Class (Module given)
>
> SNIP #3
> # /opt/puppetlabs/puppet/bin/ruby 
> /opt/puppetlabs/puppet/cache/lib/facter/package_provider.rb
> Traceback (most recent call last):
>  15: from /opt/puppetlabs/puppet/cache/lib/facter/package_provider.rb:11:
> in `'
>  14: from 
> /opt/puppetlabs/puppet/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
>  
> `require'
>  13: from 
> /opt/puppetlabs/puppet/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
>  
> `require'
>  12: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/package.
> rb:9:in `'
>  11: from 
> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/package.rb:10:in `
> '
>  10: from 
> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/metatype/manager.rb:127:in 
> `newtype'
>  9: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/autoload.
> rb:215:in `loadall'
>  8: from 
> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/autoload.rb:79:in `
> loadall'
>  7: from 
> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/autoload.rb:79:in 
> `each'
>  6: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/autoload.
> rb:81:in `block in loadall'
>  5: from 
> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/autoload.rb:66:in `
> load_file'
>  4: from 
> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/autoload.rb:66:in 
> `load'
>  3: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/
> package/gem.rb:1:in `'
>  2: from 
> /opt/puppetlabs/puppet/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
>  
> `require'
>  1: from 
> /opt/puppetlabs/puppet/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
>  
> `require'
> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/
> package_targetable.rb:23:in `': Could not autoload 
> puppet/provider/package/gem: superclass must be a Class (Module given) 
> (Puppet::Error)
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/ee5c8fe3-61ed-47f5-b6da-cf1d771790b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Install puppet 4.0 on centos 7?

2015-10-14 Thread Charlie Sharpsteen 
On Wednesday, October 14, 2015 at 6:18:33 PM UTC-5, anton kropp wrote:
>
> I feel like I'm missing something super obvious here but I'm trying to 
> install puppet 4.0 on centos 7 and the only packages i can see are 3.8.3. 
>  When I check the repo https://yum.puppetlabs.com/el/7/products/x86_64/ 
> there is no 4.0 puppet-server package?  Can someone help steer me in the 
> right direction?
>

Starting with Puppet 4, releases are grouped into repositories known as 
"package collections". This allows us to create a new collection repository 
when breaking changes happen. For CentOS 7 x86_64, you'll want to pull 
packages from the "PC1" repository:

 https://yum.puppetlabs.com/el/7/PC1/x86_64/

This can repo can be configured by installing the following package from 
the root of yum.puppetlabs.com:

  https://yum.puppetlabs.com/puppetlabs-release-pc1-el-7.noarch.rpm

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/fd695f7d-ac93-408e-ad6b-40fa82ee6bf6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Puppet Agent broken on OS X (Yosemite w/ Ruby 2.2.0)?

2015-03-24 Thread Charlie Sharpsteen 
On Tuesday, March 24, 2015 at 11:42:57 AM UTC-7, Joaquin Menchaca wrote:


 $ ruby --version
 ruby 2.2.0p0 (2014-12-25 revision 49005) [x86_64-darwin14]

 $ puppet --version
 /Users/vagrant/.rvm/gems/ruby-2.2.0/gems/puppet-3.7.4/lib/puppet/defaults.rb:465:
  
 warning: duplicated key at line 466 ignored: :queue_type
 /Users/vagrant/.rvm/gems/ruby-2.2.0/gems/puppet-3.7.4/lib/puppet/vendor/safe_yaml/lib/safe_yaml/syck_node_monkeypatch.rb:42:in
  
 `top (required)': uninitialized constant Syck (NameError)
 from 
 /Users/vagrant/.rvm/rubies/ruby-2.2.0/lib/ruby/site_ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in
  
 `require'
 from 
 /Users/vagrant/.rvm/rubies/ruby-2.2.0/lib/ruby/site_ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in
  
 `require'
 from 
 /Users/vagrant/.rvm/gems/ruby-2.2.0/gems/puppet-3.7.4/lib/puppet/vendor/safe_yaml/lib/safe_yaml.rb:197:in
  
 `module:YAML'
 from 
 /Users/vagrant/.rvm/gems/ruby-2.2.0/gems/puppet-3.7.4/lib/puppet/vendor/safe_yaml/lib/safe_yaml.rb:132:in
  
 `top (required)'
 from 
 /Users/vagrant/.rvm/rubies/ruby-2.2.0/lib/ruby/site_ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in
  
 `require'
 from 
 /Users/vagrant/.rvm/rubies/ruby-2.2.0/lib/ruby/site_ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in
  
 `require'
 from 
 /Users/vagrant/.rvm/gems/ruby-2.2.0/gems/puppet-3.7.4/lib/puppet/vendor/require_vendored.rb:4:in
  
 `top (required)'
 from 
 /Users/vagrant/.rvm/rubies/ruby-2.2.0/lib/ruby/site_ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in
  
 `require'
 from 
 /Users/vagrant/.rvm/rubies/ruby-2.2.0/lib/ruby/site_ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in
  
 `require'
 from 
 /Users/vagrant/.rvm/gems/ruby-2.2.0/gems/puppet-3.7.4/lib/puppet/vendor.rb:40:in
  
 `require_libs'
 from 
 /Users/vagrant/.rvm/gems/ruby-2.2.0/gems/puppet-3.7.4/lib/puppet/vendor.rb:53:in
  
 `load_vendored'
 from 
 /Users/vagrant/.rvm/gems/ruby-2.2.0/gems/puppet-3.7.4/lib/puppet.rb:172:in 
 `module:Puppet'
 from 
 /Users/vagrant/.rvm/gems/ruby-2.2.0/gems/puppet-3.7.4/lib/puppet.rb:29:in 
 `top (required)'
 from 
 /Users/vagrant/.rvm/rubies/ruby-2.2.0/lib/ruby/site_ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in
  
 `require'
 from 
 /Users/vagrant/.rvm/rubies/ruby-2.2.0/lib/ruby/site_ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in
  
 `require'
 from 
 /Users/vagrant/.rvm/gems/ruby-2.2.0/gems/puppet-3.7.4/lib/puppet/util/command_line.rb:12:in
  
 `top (required)'
 from 
 /Users/vagrant/.rvm/rubies/ruby-2.2.0/lib/ruby/site_ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in
  
 `require'
 from 
 /Users/vagrant/.rvm/rubies/ruby-2.2.0/lib/ruby/site_ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in
  
 `require'
 from 
 /Users/vagrant/.rvm/gems/ruby-2.2.0/gems/puppet-3.7.4/bin/puppet:7:in `top 
 (required)'
 from /Users/vagrant/.rvm/gems/ruby-2.2.0/bin/puppet:23:in `load'
 from /Users/vagrant/.rvm/gems/ruby-2.2.0/bin/puppet:23:in `main'
 from 
 /Users/vagrant/.rvm/gems/ruby-2.2.0/bin/ruby_executable_hooks:15:in `eval'
 from 
 /Users/vagrant/.rvm/gems/ruby-2.2.0/bin/ruby_executable_hooks:15:in `main'


Currently, the 3.7.x branch of Puppet is only tested against Ruby 1.8.7 
through 2.1.0. The upcoming 4.0 release drops Ruby 1.8.7, adds 2.2.0 and 
contains a fix for this issue.

There is a ticket open about getting the fix for this issue backported to 
3.7:

https://tickets.puppetlabs.com/browse/PUP-3796


-Charlie


-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/a09903fe-eb88-428f-9e40-f2b4f8137c7f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Puppet fails to run if ruby1.8 is not installed.

2014-04-04 Thread Charlie Sharpsteen 
On Friday, April 4, 2014 12:40:44 PM UTC-7, Tom Poulton wrote:

 I was running into this problem as well so I ran:

 *sudo cp -r /usr/lib/ruby/site_ruby/1.8/* 
 /usr/local/share/ruby/site_ruby/2.0/*

 /usr/local/share/ruby/site_ruby/2.0/ is part of the $LOAD_PATH so I 
 figured why not stick the files in there and see what happens, now I can 
 run *puppet --version* plus *facter ipaddress* etc. That's all I've run 
 so far so there might be some weirdness down the line, but it's a start!?

 It would be better if it was a symlink or something so you wouldn't have 
 to run this again after a yum update, but hopefully puppetlabs will ralease 
 a new RPM soon that works, I'm guessing they will now that AWS are running 
 ruby 2.0.0 as default!?


The Puppet Labs EL 6 repos are designed to be compatible with RHEL 6.x and 
CentOS 6.x which will remain on Ruby 1.8.7 for the rest of their lifetimes. 
By upgrading the default Ruby to 2.0, Amazon Linux has broken compatibility 
with EL 6. Puppet Labs probably won't be able to compensate for this in the 
EL 6 repos due to the need to stay compatible with systems running 1.8.7.

Renaming the site_ruby directory may bring varying degrees of success, but 
the puppet package has at least two dependencies, ruby-augeas and 
ruby-shadow, that contain extensions that have been compiled against the 
Ruby 1.8.7 libraries. The only way to achieve compatibility in these cases 
is to re-build the packages against Ruby 2.0.0.

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1b2c7286-b8c9-4234-afc9-8903ec188b68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: vagrant and reusing certs after destroy box

2014-02-28 Thread Charlie Sharpsteen 
On Thursday, February 27, 2014 12:17:51 PM UTC-8, Johan De Wit wrote:

 Hi, 

 The situation ; 

 Whenever I bring up a vagrant box, I do a puppet run against my puppet 
 master to configure some common things I need. 
 And I want to avoid the remove/new request and sign cycle after a 
 vagrant destroy. 

 This can be done using following vagrant config : 

  vm_config.vm.provision :puppet_server do |puppet_server| 
puppet_server.client_cert_path= 
 box_certs/rspecfc20/cert_rspecfc20.koewacht.net.pem 
puppet_server.client_private_key_path = 
 box_certs/rspecfc20/priv_rspecfc20.koewacht.net.pem 
puppet_server.puppet_node = rspecfc20.koewacht.net 
puppet_server.puppet_server   = puppet.koewacht.net 
  end 

 but it does not work, 
 I get a Error: Could not request certificate: stack level too deep 

 so, i stumbled against https://projects.puppetlabs.com/issues/21869 

 This bug seemed to be solved in 3.4.x, but I'm running 3.4.3 

 But I think, when I want to reuse my certs on my clean vagrant box, 

   CA public key of the server should also be provided with both the 
 generated cert/private key of the node. 

 Even if i stumbled against this bug, which did give the solution of my 
 problem, I think puppetmasters CA public key should always be provided. 

 I added in my fork of the vagrant code this extra config option, and now 
 I my puppet run against my master, reusing my certs works : 

puppet_server.server_ca_public_key= box_certs/ca.pem 

 But is this the way to do this, or a bug ? 

 Grts 

 Johan


Hi Johan,

It looks like the fix for #21869 was supposed to go out in 3.4.0 but got 
stuck on our master branch --- this means the fix won't show up until 
3.5.0.

Your strategy of copying the CA pubkey and agent keypair to each node 
should work.

-Charlie

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/4185b79c-0dfc-4d42-932d-0a9b7c67e275%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Hiera isn't merging hashes

2014-02-26 Thread Charlie Sharpsteen 
On Wednesday, February 26, 2014 2:19:23 PM UTC-8, paul@complex.com 
wrote:

 I have been doing some experimenting with Puppet + Hiera with some of my 
 hashes, but when it is going through my hierarchy it is returning whatever 
 hash it hits first and skipping the others.

 For my node 'sandbox1'

 sandbox.pp:

 node /^sandbox\d+/ {
   class { 'php':}
   notify { 'PHP hash':
 message = hiera('php::augeas',{})
   }
   $php_settings = hiera('php::augeas',{})
   create_resources('php::augeas',$php_settings)
 }



The `hiera` lookup function only returns the first key it finds --- which 
is the behavior you are observing. For hash merge lookup, you will need to 
use the `hiera_hash` function in your manifest instead of `hiera`.

For full details, see the docs on Hiera lookup functions:

http://docs.puppetlabs.com/hiera/1/puppet.html#hiera-lookup-functions

Hope this helps!

-Charlie

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/646bc467-b109-4828-baa8-74af6bed6426%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Puppet 3.4.0 name as an array in package

2013-12-20 Thread Charlie Sharpsteen 


On Friday, December 20, 2013 10:30:14 AM UTC-8, Fabrice Bacchella wrote:

Puppet 3.4 is out and broke an very usefull undocument feature. 

 Previsiously, one can write : 

 package {'bla': 
 ensure = present, 
 name = ['pkg1', 'pkg2'] 
 } 

 and it will install pkg1 and pkg2. 

 It now says : 
  Parameter name failed on Package['blab']: Name must be a String not Array 
 at /etc/puppet/modules/... 


 I know this was undocument, considered as a bad practice. But I used it 
 intensively because it provides a quick solution to 3 problems : 
 - a small performance gain, it reduce the number of call to your package 
 manage (at least in redhat) because it executes 'yum ... pkg1 pkg2' once 
 - easier to read dependency, 'bla' was a symbolic name for a dependency 
 set, and I could easily wrote : 
  require = Package['bla'] 
  what ever the real packages list it was. 
 - a easer solution to multiple dependencies for the same package, as I 
 could write : 
 in openssh module : 
 package {'openssh': 
 name = ['openssl', ...] 
 } 

 package {'https': 
 name = ['openssl', ...] 
 } 
 without any complication to solve it. Yum would just be called twice for 
 the same package. 

 quick clean, very readable. I loved this feature^Wbug. 

 I don't really hope to get this back, but can some on help on clean and 
 quick alternative solution for the same feature set ? 

Hi Fabrice,

This came up during the development of 3.4.0 and sparked quite a bit of 
discussion that can be found in this Redmine ticket:

https://projects.puppetlabs.com/issues/22557

Eventually, it was decided not to restore the ability to pass an array of 
packages to the name parameter because:

   - It was an “accidental” feature that was never intended to work. 
   - It only works when the entire array of packages is in the same state. 
   If one package is out of sync with the rest, unexpected results will occur. 
   - We could not find any forge modules that exploited this behavior. 

The recommended workaround is to pass an array of resource titles:

package {['pkg1', 'pkg2']:
  ensure = present, 
}

This won’t achieve the exact same effect, i.e. there will be multiple calls 
to yum, but it is pretty close for most use cases.

Hope this helps!
-- 
Charlie Sharpsteen
Open Source Support Engineer
Puppet Labs

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/c7ec165b-e900-4559-bc9c-fb4bdcd36b67%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Projects.puppetlabs.com undergoing maintenance at 9PM PST

2013-12-16 Thread Charlie Sharpsteen 
On Sunday, December 15, 2013 8:46:42 PM UTC-8, Matt Kirby wrote:

 Hello,

 We will be performing maintenance on Puppet Labs redmine at 
 projects.puppetlabs.com starting at 9PM PST. During this time redmine 
 will be unavailable. Estimated downtime for maintenance is one hour after 
 which all redmine projects will be read-only in favor of 
 tickets.puppetlabs.com , our new bug tracker, which allows public user 
 sign up and access starting at 9:30PM PST, with the exception of the Ask 
 and CLA projects. They will follow soon. I will send a follow up 
 notification when this maintenance has been completed.


Redmine maintenance has been completed successfully and the site is now in 
read-only mode. One-click issue migration has been enabled for open tickets 
in the following Redmine projects:

  - Puppet
  - Puppet Enterprise (Public)
  - Facter
  - Hiera
  - MCollective
  - PuppetDB

Let us know if you have any questions about the migration or if the ticket 
exporter on the old Redmine site does not appear to be working properly!

-- 
Charlie Sharpsteen
Open Source Support Engineer
Puppet Labs

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/913033f7-c30a-4b8d-af7a-9b93ff9b3b9c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Puppet Labs issue tracker migration 16 Dec 2013

2013-12-16 Thread Charlie Sharpsteen 
On Monday, December 16, 2013 1:46:45 AM UTC-8, R.I. Pienaar wrote:


 I am probably just missing the obvious - in redmine it was possible to 
 subscribe to an entire project and get all activity.  How do I do the same 
 with Jira?


 In JIRA, you can subscribe to any saved issue query and have the updates 
mailed out on a set schedule. More information can be found here:

  
https://confluence.atlassian.com/display/JIRA061/Receiving+Search+Results+via+Email

Updates for all platform projects are also being sent by JIRA to the 
puppet-bugs mailing list.

-- 
Charlie Sharpsteen
Open Source Support Engineer
Puppet Labs

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/571b9e48-a538-49d2-881d-eb028ce545d4%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Puppet Labs issue tracker migration 16 Dec 2013

2013-12-16 Thread Charlie Sharpsteen 
On Monday, December 16, 2013 11:37:26 AM UTC-8, Jason Antman wrote:

 I've gone through and migrated most of the issues I was watching (and 
 still care about) that weren't already. 

 I ran into 4 issues that show up with a message of: 

 This issue is currently not available for export. If you are 
 experiencing the issue described below, please file a new ticket in 
 JIRA. Once a new ticket has been created, please add a link to it that 
 points back to this Redmine ticket. 

 Should I do so, or is there a better way of handling this? 

 The issues in question are 4240, 13602, 17439 and 22902. 

 Thanks, 
 j antman 


Hi Jason,

Thanks for bringing these to our attention! Redmine to JIRA issue export 
has been enabled for:

  -  Puppet Community Package Repository
  -  Puppet Labs Modules

I have migrated 13602, 17439 and 22902. Ticket 4240 is in a project that 
has not seen significant activity for quite a while and so automatic issue 
migration will not be set up. For cases like this, we can discuss the 
status of the ticket on IRC in #puppet-dev.

Let us know if you have any more questions!

-- 
Charlie Sharpsteen
Open Source Support Engineer
Puppet Labs

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/59426220-8cb6-46b7-84d2-c6d2ad61f622%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] get a *structured* version of the puppet agent output

2013-12-15 Thread Charlie Sharpsteen 


On Friday, December 13, 2013 2:43:41 PM UTC-8, David Portabella wrote:


 is there a way to get the list of resources created when using a puppet 
 apply (instead of puppet agent)?

 the point is that we need this when refactoring puppet modules, in order 
 to test the modules in a vagrant machine and check that there are not 
 regression issues.
 so, i run our current puppet modules in a vagrant machine, get the list of 
 all puppet resources created,
 then i refactor the puppet modules, i run again the refactored puppet 
 modules in a new vagrant machine,
 and i compare all the files and other resources.

 If you are looking to keep track of resources while refactoring, then 
there are a few approaches you can take:

   1. Add another VM to your Vagrant environment that runs a Puppet Master 
   and do the refactoring there. This gives you access to tools such as 
   PuppetDB and the Dashboard while also simulating how your refactor will 
   affect an agent/master setup. 
   2. Set up your VM such that puppet apply submits the catalog and reports 
   to PuppetDB: 
   https://docs.puppetlabs.com/puppetdb/1.5/connect_puppet_apply.html 
   3. Configure configure YAML caching for puppet apply in 
   /etc/puppet/routes.yaml: 


---
apply:
  catalog:
cache: yaml

This will cause puppet apply to save a copy of the last compiled catalog to 
/var/lib/puppet/state/client_yaml/catalog/certname.yaml. The information 
in this file can be combined with the report in 
/var/lib/puppet/state/last_run_report.yaml to create a list of applied 
resources along with their properties and resulting changes.

The first two approaches will cut down on the amount of custom code you 
need to write as the task of parsing and storing the reports and catalogs 
is handled by PuppetDB or the dashboard. Approach 3 works as well and 
offers a lot of control, but you will need to write a bit of code that 
extracts data from the catalog and report files before you can focus on the 
analysis.
-- 
Charlie Sharpsteen
Open Source Support Engineer
Puppet Labs

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/6892e0dd-61a1-4728-b78f-2407e1124962%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: err: Could not send report: Error 400 on SERVER: (unknown): found character that cannot start any token while scanning for the next token

2013-12-14 Thread Charlie Sharpsteen 
On Saturday, December 14, 2013 6:59:22 AM UTC-8, John Naggets wrote:

 Hi,

 On some of my puppet agents at each puppet agent run I get the following 
 error message:

 err: Could not send report: Error 400 on SERVER: (unknown): found 
 character that cannot start any token while scanning for the next token at 
 line 1519 column 14

 I believe the agent has some issues here sending the report to the puppet 
 dashboard but I can't find what is the issue. Does anyone have an idea? 
 Also which file exactly is this error message referring to (line 1519 
 column 14)?

 Thanks
 John


Hi John,

This error is thrown by the Ruby YAML parser when it encounters a malformed 
YAML document (such as a report) that cannot be loaded. It looks like the 
report is being sent fine, but the YAML parser in the receiving dashboard 
is throwing an error. A copy of the report the agent was attempting to send 
can usually be found in /var/lib/puppet/state/last_run_report.yaml --- this 
is the file that the line and column numbers relate to.

Hope this is helpful!

-- 
Charlie Sharpsteen
Open Source Support Engineer
Puppet Labs

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/98d78d4b-1f03-40bb-8fcc-6c8c9acc7a9d%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] get a *structured* version of the puppet agent output

2013-12-13 Thread Charlie Sharpsteen 


On Friday, December 13, 2013 5:30:19 AM UTC-8, David Portabella wrote:

Given this puppet manifest (test.pp):
 $dir = '/tmp'
 file {'myfile':
   path = $dir/myfile.txt,
   content = 'hello'
 }

 puppet produces this report:
 [...]
 File[myfile]: !ruby/object:Puppet::Resource::Status
   resource: File[myfile]
   file: /Users/david/test.pp
   line: 4
   evaluation_time: 0.001354
   change_count: 1
   out_of_sync_count: 1
   tags: 
 - file
 - myfile
 - class
   time: 2013-12-13 11:44:59.092716 +01:00
   events: 
 - !ruby/object:Puppet::Transaction::Event
   audited: false
   property: ensure
   previous_value: !ruby/sym absent
   desired_value: !ruby/sym file
   historical_value: 
   message: defined content as 
 '{md5}5d41402abc4b2a76b9719d911017c592'
   name: !ruby/sym file_created
   status: success
   time: 2013-12-13 11:44:59.093067 +01:00
   out_of_sync: true
   changed: true
   resource_type: File
   title: myfile
   skipped: false
   failed: false
   containment_path: 
 - Stage[main]
 - 
 - File[myfile]
 [...]

 so, the report tells that it has created File[myfile],
 but it does not contain the path of the file /tmp/myfile.txt.

 that's a pity, because it means that I cannot get a list of all the files 
 updated by puppet.

 is there a way to get the final path of all File resources created by 
 puppet?
 (not $dir/myfile.txt, but /tmp/myfile.txt)

 The report is focused on describing the changes that occurred during that 
run. To that end, only the title is included as that information is 
sufficient to uniquely identify the reporting resource when combined with 
resource_type. Information concerning properties that were not changed 
during the run is omitted as this data can be obtained from the catalog 
that the agent was processing.

In this specific situation, you can modify your file resource such that the 
path is used as the title:

$dir = '/tmp'
file { $dir/myfile.txt:
  content = 'hello'
}

However, the general problem of matching changes to resources can be solved 
by loading the report and then loading the catalog and joining the two 
datasets using the resource_type and title. However, this particular task 
is one of the problems PuppetDB was designed to solve. PuppetDB stores both 
the catalogs and reports and provides an API that can be used to query the 
data.

For example, the changes related to myfile can be retrieved by querying the 
events 
endpoint https://docs.puppetlabs.com/puppetdb/1.5/api/query/v3/events.htmlof 
the PuppetDB API:

curl -G 'http://localhost:8080/v3/events' --data-urlencode query=\'[and, 
[=, resource-type, File],
  [=, containing-class, Testfile],
  [=, certname, pe-310-agent.puppetdebug.vlan]]'

Which gives results similar to the following:

[ {

  status : success,
  timestamp : 2013-12-13T17:11:39.144Z,
  certname : pe-310-agent.puppetdebug.vlan,
  containing-class : Testfile,
  containment-path : [ Stage[main], Testfile, File[myfile] ],
  report : 6bed5163b50b5857921b5ec27d9147b428c684f8,
  run-start-time : 2013-12-13T17:11:29.382Z,
  resource-title : myfile,
  configuration-version : 1386954691,
  run-end-time : 2013-12-13T17:11:36.527Z,
  property : ensure,
  message : defined content as '{md5}5d41402abc4b2a76b9719d911017c592',
  new-value : file,
  old-value : absent,
  line : 44,
  file : /etc/puppetlabs/puppet/modules/testfile/manifests/init.pp,
  report-receive-time : 2013-12-13T17:11:41.334Z,
  resource-type : File} ]

The resource contained in the catalog delivered to that node, which 
contains properties such as the path, can be retrieved by passing the 
resource Type and title to the resources 
endpointhttps://docs.puppetlabs.com/puppetdb/1.5/api/query/v3/resources.html
:

curl -G 'http://localhost:8080/v3/resources/File/myfile' --data-urlencode 
'query=[=, certname, pe-310-agent.puppetdebug.vlan]'

This returns all the parameters of interest:

[ {
  parameters : {
path : /tmp/myfile.txt,
mode : 0755,
content : hello,
backup : main,
alias : [ /tmp/myfile.txt ]
  },
  line : 45,
  file : /etc/puppetlabs/puppet/modules/testfile/manifests/init.pp,
  exported : false,
  tags : [ default, node, myfile, testfile, class, file ],
  title : myfile,
  type : File,
  resource : 93f90701c8f54a485246a9e3725040f1992fd90b,
  certname : pe-310-agent.puppetdebug.vlan} ]

The power of PuppetDB in this situation is that your reporting script can 
now focus on analyzing the data instead of finding and then filtering it.

Hope this helps!
-- 
Charlie Sharpsteen
Open Source Support Engineer
Puppet Labs

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion

Re: [Puppet Users] Puppet Labs issue tracker migration 16 Dec 2013

2013-12-11 Thread Charlie Sharpsteen 
On Tuesday, December 10, 2013 2:37:14 PM UTC-8, John Warburton wrote:

 * Everybody needs to create a new account on JIRA, since we can’t migrate 
 passwords from redmine to jira.


 Is the JIRA link available? From the front page, Bug 
 Trackerhttp://projects.puppetlabs.compoints at RedMine . Or do I need to 
 hold my horses?

 Thanks

 John


Hi John,

Updated documentation will be rolled out alongside public access to JIRA on 
the 16th. Account creation will be opened on that day as well.

Let us know if you have any other questions about the migration!

--
Charlie Sharpsteen
Open Source Support Engineer
Puppet Labs

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/4fd99caa-b8ae-4fb8-9dce-9ddf5e489ecf%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.