date:20130110

Hello,

I am trying to find out how to manage versions for installed software.

It seems that the 'package' plugin does not take a version argument, 
rendering it quite less useful than it could be. Yes, I can manage a 
version with Puppet, but maybe in certain environments I would like to be 
able to manage the version of the installed software from mc.

So what I would like to do is:

mco package install myapp 1.1.2 -C myapp -F environment=development 

Obviously this is not possible now because package does not take versions 
as an argument.

I have tried the 'packages' plug-in that claims to manage several packages 
and takes versions but, it plainly does not work (they say they tested it 
with EL6, I use EL5).

I control the version of packages with puppet/hiera currently. This is a 
good solution, but I am looking to let puppet do all the work up to the 
last bit, where the application version can be changed the same way as you 
would o yum install package-*version*. I am not looking for how to do this 
with yum or puppet, but with mcollective.


So, what do you guys and girls do to manage package versions for your 
environments with mcollective?

Many thanks in advance.

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/favSOmJKYp0J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] mcollective package plugin rpm versions

2013-01-10 Thread R.I.Pienaar

- Original Message -
 From: Guillem Liarte guillem.lia...@googlemail.com
 To: puppet-users@googlegroups.com
 Sent: Thursday, January 10, 2013 11:44:13 AM
 Subject: [Puppet Users] mcollective package plugin rpm versions

 Hello,

 I am trying to find out how to manage versions for installed software.

 It seems that the 'package' plugin does not take a version argument,
 rendering it quite less useful than it could be. Yes, I can manage a
 version with Puppet, but maybe in certain environments I would like to be
 able to manage the version of the installed software from mc.

 So what I would like to do is:

 mco package install myapp 1.1.2 -C myapp -F environment=development

 Obviously this is not possible now because package does not take versions
 as an argument.

 I have tried the 'packages' plug-in that claims to manage several packages
 and takes versions but, it plainly does not work (they say they tested it
 with EL6, I use EL5).

 I control the version of packages with puppet/hiera currently. This is a
 good solution, but I am looking to let puppet do all the work up to the
 last bit, where the application version can be changed the same way as you
 would o yum install package-*version*. I am not looking for how to do this
 with yum or puppet, but with mcollective.

 So, what do you guys and girls do to manage package versions for your
 environments with mcollective?

it would be easy to add the ability to manage the ensure property of the 
package from the mcollective command line.  We've not had that feature
request though before now

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

Re: [Puppet Users] mcollective package plugin rpm versions

Mr Pienaar,

I would love to help adding it then. 

Where do I start? 

Guillem Liarte

On Thursday, 10 January 2013 11:59:28 UTC, R.I. Pienaar wrote:



 - Original Message - 
  From: Guillem Liarte guillem...@googlemail.com javascript: 
  To: puppet...@googlegroups.com javascript: 
  Sent: Thursday, January 10, 2013 11:44:13 AM 
  Subject: [Puppet Users] mcollective package plugin rpm versions 
  
  Hello, 
  
  I am trying to find out how to manage versions for installed software. 
  
  It seems that the 'package' plugin does not take a version argument, 
  rendering it quite less useful than it could be. Yes, I can manage a 
  version with Puppet, but maybe in certain environments I would like to 
 be 
  able to manage the version of the installed software from mc. 
  
  So what I would like to do is: 
  
  mco package install myapp 1.1.2 -C myapp -F environment=development 
  
  Obviously this is not possible now because package does not take 
 versions 
  as an argument. 
  
  I have tried the 'packages' plug-in that claims to manage several 
 packages 
  and takes versions but, it plainly does not work (they say they tested 
 it 
  with EL6, I use EL5). 
  
  I control the version of packages with puppet/hiera currently. This is a 
  good solution, but I am looking to let puppet do all the work up to the 
  last bit, where the application version can be changed the same way as 
 you 
  would o yum install package-*version*. I am not looking for how to do 
 this 
  with yum or puppet, but with mcollective. 
  
  
  So, what do you guys and girls do to manage package versions for your 
  environments with mcollective? 

 it would be easy to add the ability to manage the ensure property of the 
 package from the mcollective command line.  We've not had that feature 
 request though before now 


-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/j04nhS8P4KEJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] mcollective package plugin rpm versions

2013-01-10 Thread R.I.Pienaar

- Original Message -
 From: Guillem Liarte guillem.lia...@googlemail.com
 To: puppet-users@googlegroups.com
 Sent: Thursday, January 10, 2013 12:57:02 PM
 Subject: Re: [Puppet Users] mcollective package plugin rpm versions

 Mr Pienaar,

 I would love to help adding it then.

 Where do I start?

Basically the line in the agent:

  pkg = ::Puppet::Type.type(:package).new(:name = package).provider

loads up the puppet type without providing any version hints, so what
you see there is equivalent to:

  package{x: } 

and then we specifically call install/update/uninstall as needed.

I suspect that if you just change that line to something like:

  pkg = ::Puppet::Type.type(:package).new(:name = package, :ensure = 
1.2.3).provider

ie. add an ensure property with your desired version, it would do
the right thing, you could perhaps do a manual test to confirm
that?

If it does work we just need to pass the version from the client to this code
and I can point you in the right direction with that.

Probably best to take this to the mcollective-users list on google
groups though

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

[Puppet Users] Re: Puppet dashboard not enabling inventory

2013-01-10 Thread Luke

Has anyone else successfully got the puppet dashboard working with 
dashboard version *1.2.17 with puppet 3?*

On Wednesday, January 9, 2013 10:11:11 AM UTC-4, Luke wrote:

 Hello,

 My puppet dashboard is not enabling the inventory tab / node info even 
 though I have:

 *enable_inventory_service set to true*
 *
 *
 *Pointing to correct port for puppetdb and server in settings.yml.*
 *
 *
 Everything is wide open in auth.conf and puppetdb is working fine. 

 I mean regardless of what settings are set shouldn't I at least be able to 
 see the inventory tab if *enable_inventory_service is set to true?*
 *
 *
 *Using dashboard 1.2.17.*
 *
 *
 *Thanks for all the help!*
 *
 *
 *Luke*
 *
 *
 *
 *



-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/RF_qPkwdTE0J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] mcollective package plugin rpm versions

Mr. Pienaar,


I have tested the following:

Changes in the MC server, package.rb:

  pkg = ::Puppet::Type.type(:package).new(:name = package, :ensure 
= 20060214-1.7).provider
  #pkg = ::Puppet::Type.type(:package).new(:name = 
package).provider


MC client output

[root@ttraflonrh364 application]# mco package status ksh -W 
hostname=ttraflocorh170

 * [  ] 1 / 1

ttraflocorh170.global.trafigura.com  version = ksh-20100621-5.el5

 package agent summary 
 Nodes: 1 / 1
 Versions: 1 * 20100621-5.el5
 Elapsed Time: 0.53 s

[root@ttraflonrh364 application]# mco package uninstall ksh -W 
hostname=ttraflocorh170

 * [  ] 1 / 1

ttraflocorh170.global.trafigura.com  version = absent

 package agent summary 
 Nodes: 1 / 1
 Versions: 1 * absent
 Elapsed Time: 6.23 s

[root@ttraflonrh364 application]# mco package status ksh -W 
hostname=ttraflocorh170

 * [  ] 1 / 1

ttraflocorh170.global.trafigura.com  version = absent

 package agent summary 
 Nodes: 1 / 1
 Versions: 1 * absent
 Elapsed Time: 0.12 s

[root@ttraflonrh364 application]# mco package install ksh -W 
hostname=ttraflocorh170

 * [  ] 1 / 1

ttraflocorh170.global.trafigura.com  version = ksh-20060214-1.7

 package agent summary 
 Nodes: 1 / 1
 Versions: 1 * 20060214-1.7
 Elapsed Time: 11.25 s

The version seems to change effectively. So yes, it does seem to work as 
you said.

Do you want em to open a new post in mcollective group?


On Thursday, 10 January 2013 13:01:33 UTC, R.I. Pienaar wrote:



 - Original Message - 
  From: Guillem Liarte guillem...@googlemail.com javascript: 
  To: puppet...@googlegroups.com javascript: 
  Sent: Thursday, January 10, 2013 12:57:02 PM 
  Subject: Re: [Puppet Users] mcollective package plugin rpm versions 
  
  Mr Pienaar, 
  
  I would love to help adding it then. 
  
  Where do I start? 

 Basically the line in the agent: 
   
   pkg = ::Puppet::Type.type(:package).new(:name = package).provider 

 loads up the puppet type without providing any version hints, so what 
 you see there is equivalent to: 

   package{x: } 

 and then we specifically call install/update/uninstall as needed. 

 I suspect that if you just change that line to something like: 

   pkg = ::Puppet::Type.type(:package).new(:name = package, :ensure = 
 1.2.3).provider 

 ie. add an ensure property with your desired version, it would do 
 the right thing, you could perhaps do a manual test to confirm 
 that? 

 If it does work we just need to pass the version from the client to this 
 code 
 and I can point you in the right direction with that. 

 Probably best to take this to the mcollective-users list on google 
 groups though 


-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/aC_Jn5Ly68YJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] mcollective package plugin rpm versions

2013-01-10 Thread R.I.Pienaar



- Original Message -
 From: Guillem Liarte guillem.lia...@googlemail.com
 To: puppet-users@googlegroups.com
 Sent: Thursday, January 10, 2013 2:59:40 PM
 Subject: Re: [Puppet Users] mcollective package plugin rpm versions
 
 Mr. Pienaar,
 
 
 I have tested the following:
 
 Changes in the MC server, package.rb:
 
   pkg = ::Puppet::Type.type(:package).new(:name = package, :ensure
 = 20060214-1.7).provider
   #pkg = ::Puppet::Type.type(:package).new(:name =
 package).provider
 
 
 MC client output
 
 [root@ttraflonrh364 application]# mco package status ksh -W
 hostname=ttraflocorh170
 
  * [  ] 1 / 1
 
 ttraflocorh170.global.trafigura.com  version = ksh-20100621-5.el5
 
  package agent summary 
  Nodes: 1 / 1
  Versions: 1 * 20100621-5.el5
  Elapsed Time: 0.53 s
 
 [root@ttraflonrh364 application]# mco package uninstall ksh -W
 hostname=ttraflocorh170
 
  * [  ] 1 / 1
 
 ttraflocorh170.global.trafigura.com  version = absent
 
  package agent summary 
  Nodes: 1 / 1
  Versions: 1 * absent
  Elapsed Time: 6.23 s
 
 [root@ttraflonrh364 application]# mco package status ksh -W
 hostname=ttraflocorh170
 
  * [  ] 1 / 1
 
 ttraflocorh170.global.trafigura.com  version = absent
 
  package agent summary 
  Nodes: 1 / 1
  Versions: 1 * absent
  Elapsed Time: 0.12 s
 
 [root@ttraflonrh364 application]# mco package install ksh -W
 hostname=ttraflocorh170
 
  * [  ] 1 / 1
 
 ttraflocorh170.global.trafigura.com  version = ksh-20060214-1.7
 
  package agent summary 
  Nodes: 1 / 1
  Versions: 1 * 20060214-1.7
  Elapsed Time: 11.25 s
 
 The version seems to change effectively. So yes, it does seem to work as
 you said.

That's encouraging, means we could no doubt make a plan then!

 Do you want em to open a new post in mcollective group?

That would be great

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

Re: [Puppet Users] mcollective package plugin rpm versions



On Thursday, 10 January 2013 13:01:33 UTC, R.I. Pienaar wrote:



 - Original Message - 
  From: Guillem Liarte guillem...@googlemail.com javascript: 
  To: puppet...@googlegroups.com javascript: 
  Sent: Thursday, January 10, 2013 12:57:02 PM 
  Subject: Re: [Puppet Users] mcollective package plugin rpm versions 
  
  Mr Pienaar, 
  
  I would love to help adding it then. 
  
  Where do I start? 

 Basically the line in the agent: 
   
   pkg = ::Puppet::Type.type(:package).new(:name = package).provider 

 loads up the puppet type without providing any version hints, so what 
 you see there is equivalent to: 

   package{x: } 

 and then we specifically call install/update/uninstall as needed. 

 I suspect that if you just change that line to something like: 

   pkg = ::Puppet::Type.type(:package).new(:name = package, :ensure = 
 1.2.3).provider 

 ie. add an ensure property with your desired version, it would do 
 the right thing, you could perhaps do a manual test to confirm 
 that? 

 If it does work we just need to pass the version from the client to this 
 code 
 and I can point you in the right direction with that. 

 Probably best to take this to the mcollective-users list on google 
 groups though 



Mr. Pienaar,


I have tested the following:

Changes in the MC server, package.rb:

  pkg = ::Puppet::Type.type(:package).
new(:name = package, :ensure = 20060214-1.7).provider
  #pkg = ::Puppet::Type.type(:package).new(:name = 
package).provider


MC client output

# mco package status ksh -W hostname=host1

 * [  ] 1 / 1

host1.domain.com version = ksh-20100621-5.el5

 package agent summary 
 Nodes: 1 / 1
 Versions: 1 * 20100621-5.el5
 Elapsed Time: 0.53 s

]# mco package uninstall ksh -W hostname=host1

 * [  ] 1 / 1

host1.domain.com  version = absent

 package agent summary 
 Nodes: 1 / 1
 Versions: 1 * absent
 Elapsed Time: 6.23 s

# mco package status ksh -W hostname=host1

 * [  ] 1 / 1

host1.domain.com  version = absent

 package agent summary 
 Nodes: 1 / 1
 Versions: 1 * absent
 Elapsed Time: 0.12 s

]# mco package install ksh -W hostname=host1

 * [  ] 1 / 1

host1.domain.com  version = ksh-20060214-1.7

 package agent summary 
 Nodes: 1 / 1
 Versions: 1 * 20060214-1.7
 Elapsed Time: 11.25 s

The version seems to change effectively. So yes, it does seem to work as 
you said.

Do you want em to open a new post in mcollective group?
 

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/9Yv257eM7psJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Thoughts on roles/profiles class paradigm

2013-01-10 Thread Craig Dunn


On 09/01/2013 20:03, Roman Shaposhnik wrote:

* A role contains business logic

Could you give an example here? What else are roles, but a flat collection
of profiles?



Essentially yes, thats all they are and while I generally opt to make 
them classes you could do this from within an ENC instead.  The 
implementation is not as important as the concept, so if you want to 
replace the roles function with groups of profiles in an ENC you'll 
still get the same benefits.


One reason I keep roles in code is it allows me to be a bit more 
flexible.  For example I can use inheritance to minimize duplication  
roles::appserver::foo roles::appserver::baretc inheriting from 
roles::appserver where I might have stuff like tomcat.


Craig

--
Craig Dunn
Professional Services
Puppet Labs Inc.
http://www.puppetlabs.com

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

[Puppet Users] Re: Announce: Puppet 3.1.0-rc1 available

2013-01-10 Thread Chuck

This bug is impacting Puppet 3.1.0-rc1.  I posted one possible solution.

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

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/AEYqCi9XwUoJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Announce: PuppetDB 1.1.0-rc4 now available

2013-01-10 Thread Eric Kissinger


The 
puppetdb-1.1.0-0.1rc4.el6.noarch.rpmhttp://yum.puppetlabs.com/el/6/devel/x86_64/puppetdb-1.1.0-0.1rc4.el6.noarch.rpmpackage
 seems to have an error when unpacking the puppetdb.jar.

This is the output:


Downloading Packages:
puppetdb-1.1.0-0.1rc4.el6.noarch.rpm
  
|  14 MB 00:00
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Updating   : 
puppetdb-1.1.0-0.1rc4.el6.noarch
  
1/2
Error unpacking rpm package puppetdb-1.1.0-0.1rc4.el6.noarch
warning: /etc/puppetdb/conf.d/config.ini created as 
/etc/puppetdb/conf.d/config.ini.rpmnew
error: unpacking of archive failed on file 
/usr/share/puppetdb/puppetdb.jar;50eed3a6: cpio: read

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/cK5qyYqYVZYJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] stdlib take almost 14 minutes to sync on CentOS Vagrant VM

2013-01-10 Thread Kirk Steffensen

SOLVED: I didn't have the VMs in the host's /etc/hosts.  Once I put all of 
them into the host (i.e, the Puppet Master), then everything sped up to 
full speed on the clients.  (I had been thinking it was a problem on the 
client side, so all of my troubleshooting had been isolated to the clients. 
 I finally thought to try the server side this morning.)

Question: Should I submit this as a bug?  I'm not sure if this is a Puppet 
bug or an OS bug?  The Puppet Master was eventually serving up the files, 
but only after 10 seconds (while it was trying to resolve the name?)  Since 
the Puppet Master was able to reply without being able to resolve the name, 
why was it bothering to resolve the name instead of just replying directly 
to the request?

Thanks,
Kirk

On Wednesday, January 9, 2013 5:45:16 PM UTC-5, Kirk Steffensen wrote:

 Josh, 

 use_srv_records is not set in puppet.conf.  'puppet config print 
 use_srv_records shows it set to the default of false.

 I ran tcpdump from inside the Vagrant VM during pluginsync.  On eth1, 
 where the VM is connecting to the puppet master running on the host, the 
 only calls are puppet calls on 8140 with replies coming back on 34757.  
 Running 'tcpdump port 53' shows no DNS traffic at all during the 
 pluginsync.  (FWIW, I'm not running DNS for these vagrant boxes.  
 Everything is in /etc/hosts, so it doesn't surprise me that there are zero 
 DNS calls.)

 Thanks,
 Kirk

 On Wednesday, January 9, 2013 5:13:04 PM UTC-5, Josh Cooper wrote:

 Hi Kirk, 

 Do you happen to have SRV lookups enabled via the `use_srv_records` 
 setting? You may want to run tcpdump and look for extraneous DNS 
 lookups. 

 Josh 

 On Wed, Jan 9, 2013 at 2:00 PM, Kirk Steffensen 
 ki...@steffensenfamily.com wrote: 
  Here is the strace output from one of the 10-second periods while 
 waiting 
  for the File notice to appear.  https://gist.github.com/4497263 
  
  The strace output came in two bursts during this 10-seconds. 
  
  The thing that leaps out at me is that of the 4061 lines of output, 
 3754 of 
  them are rt_sigprocmask calls.  I'm wondering if it's a Ruby bug?  For 
 these 
  VMs, I'm using 1.8.7, installed from source: 
  http://ftp.ruby-lang.org/pub/ruby/ruby-1.8.7-p358.tar.gz 
  
  I created another gist with the rt_sigprocmask calls to make it easier 
 to 
  tell if there is anything else going on.  
 https://gist.github.com/4497335 
  From my quick review, nothing leaps out. 
  
  Hope this helps point the troubleshooting in the right direction. 
  
  Thanks, 
  Kirk 
  
  
  On Wednesday, January 9, 2013 12:59:40 PM UTC-5, Ken Barber wrote: 
  
   Ken, thanks.  Unfortunately, (from a troubleshooting standpoint), it 
   only 
   took one or two seconds to sync stdlib on the local box. 
   
   rm -rf /var/lib/puppet/lib/* 
   puppet agent --test 
   
   I saw the same stream of File notices, but they streamed by in real 
   time, 
   instead of taking 10 seconds per notice. 
  
  Yeah, thats gotta be some comms problem between your PM and clients 
  then ... just not sure what. 
  
   John may still have something.  There may still be some name 
 resolution 
   issue on the client, but it's just not obvious from the testing that 
 I 
   did. 
  
  Perhaps perhaps ... I'd strace the puppet process to see whats 
  happening in the gaps. 10-15 seconds would lead me to suspect DNS as 
  well. Perhaps we haven't exhausted this avenue ... try adding all your 
  hosts into /etc/hosts on each box perhaps? Disabling DNS temporarily 
  (from say nsswitch.conf) then will remove that avenue of potential 
  :-). 
  
   I haven't dug into the file provider code.  What mechanism is it 
 using 
   to 
   move the files from the server to the client?  Could it be a delay 
 in an 
   scp 
   handshake or the like? 
  
  HTTPS actually ... with client and server certificates. 
  
  ken. 
  
  -- 
  You received this message because you are subscribed to the Google 
 Groups 
  Puppet Users group. 
  To view this discussion on the web visit 
  https://groups.google.com/d/msg/puppet-users/-/OKNPyOQqZcQJ. 
  
  To post to this group, send email to puppet...@googlegroups.com. 
  To unsubscribe from this group, send email to 
  puppet-users...@googlegroups.com. 
  For more options, visit this group at 
  http://groups.google.com/group/puppet-users?hl=en. 



 -- 
 Josh Cooper 
 Developer, Puppet Labs 



-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/SjgPXE3VnbYJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Difficulty debugging crashing PuppetDB

2013-01-10 Thread Chris Price

Cody,

Can you provide some details on your OS and JVM flavors / versions?  Also, 
you mentioned there was nothing in the logs--does this include the 
syslog?  And are there any other *files* in the /var/log/puppetdb directory?


On Wednesday, January 9, 2013 5:30:03 PM UTC-8, Cody Robertson wrote:

 I have no core dumps however I need to make sure I have it set to allow 
 them. It literally just goes kaput - very strange. I've yet to have time to 
 strace it yet today however I did it briefly and it was merely doing a 
 bunch of waits.

 On Wednesday, January 9, 2013 6:43:05 PM UTC-5, Ken Barber wrote:

 Do you get a core dump? Does it seriously just silently 'stop' with no 
 SEGV or anything - even in the forground? 

 On Wed, Jan 9, 2013 at 11:07 PM, Cody Robertson codyha...@gmail.com 
 wrote: 
  There is nothing in the logs as previously noted. It simply crashed 
 quietly. 
  
  This is the same for when I'm running it in the foreground with --debug 
 or 
  when it's a daemon. It simply quietly crashes. 
  
  -- 
  013-01-09 18:00:15,841 DEBUG [command-proc-89] 
  [bonecp.PreparedStatementHandle] SELECT timestamp FROM 
 certname_catalogs 
  WHERE certname='typhoon.xxx.com' ORDER BY timestamp DESC LIMIT 1 
  2013-01-09 18:00:16,185 DEBUG [command-proc-89] 
  [bonecp.PreparedStatementHandle] SELECT 1 FROM catalogs WHERE 
  hash='b9915aef874b1a291e32f1b7cbe0efa9848fb923' LIMIT 1 
  2013-01-09 18:00:16,185 DEBUG [command-proc-89] 
 [bonecp.StatementHandle] 
  UPDATE catalogs SET api_version=1, catalog_version='1357754062' WHERE 
  hash='b9915aef874b1a291e32f1b7cbe0efa9848fb923' 
  2013-01-09 18:00:16,185 DEBUG [command-proc-89] 
 [bonecp.StatementHandle] 
  DELETE FROM certname_catalogs WHERE certname='typhoon.xxx.com' 
  2013-01-09 18:00:16,186 DEBUG [command-proc-89] 
  [bonecp.PreparedStatementHandle] INSERT INTO certname_catalogs 
  (certname,catalog,timestamp) VALUES 
  ('typhoon.xxx.com','b9915aef874b1a291e32f1b7cbe0efa9848fb923',2013-01-09 

  18:00:15.815) 
  2013-01-09 18:00:16,186 INFO  [command-proc-89] [puppetdb.command] 
  [7779017b-5be2-415d-afd6-264d6d4d789e] [replace catalog] 
 typhoon.xxx.com 
  sh-4.1# 
  -- 
  
  I'll attempt to attach a strace to it however it's so remarkably 
 verbose 
  it's always a treat to sift through it. Is there an easy way to 
 increase the 
  verbosity of puppetDB perhaps? 
  
  -Cody 
  
  On Wednesday, January 9, 2013 6:11:19 AM UTC-5, Matthew Burgess wrote: 
  
  On Wed, Jan 9, 2013 at 1:37 AM, Cody Robertson codyha...@gmail.com 
  wrote: 
   Hello! How is everyone this splendid evening? 
   
   I've recently migrated to the latest Puppet and PuppetDB (using the 
   build in 
   database) however I'm noticing PuppetDB keeps crashing without any 
   errors 
   that I can find in the logs. I've ran it in the foreground using the 
   puppetdb-foreground command however it simply exits after awhile. 
 The 
   only 
   thing I can consistently do is see it crash - I can't get any useful 
   debug 
   information beyond that. 
   
   Can anyone shed some light on how I should go about this? Thank you! 
  
  What does /var/log/messages say.  Just a stab in the dark, but if your 
  server is short of memory, then the kernel's oom killer may be 
  targetting the puppetdb process; that would certainly be evident in 
  your /var/log/messages output. 
  
  If that's not the culprit, then attaching 'strace' to the puppetdb 
  process might be informative (strace -p pid). 
  
  Regards, 
  
  Matt. 
  
  -- 
  You received this message because you are subscribed to the Google 
 Groups 
  Puppet Users group. 
  To view this discussion on the web visit 
  https://groups.google.com/d/msg/puppet-users/-/vADEbpPDw7IJ. 
  
  To post to this group, send email to puppet...@googlegroups.com. 
  To unsubscribe from this group, send email to 
  puppet-users...@googlegroups.com. 
  For more options, visit this group at 
  http://groups.google.com/group/puppet-users?hl=en. 



-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/4eL0sJzc1IoJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] stdlib take almost 14 minutes to sync on CentOS Vagrant VM

2013-01-10 Thread Ken Barber

Huh, good find. I'm guessing you're still running webrick? Based on a
quick google it looks like it by does reverse DNS by default. Most web
servers have this disabled by default but I think webrick does not
(Apache at least disabled dns lookups I'm sure by default).

I think if Puppet passes DoNotReverseLookup = true when creating the
Webrick object (HTTPServer) this will avoid the reverse DNS lookup.
Its quite a small thing, but might help a few people avoid this kind
of hassle going forward:

https://gist.github.com/4503915

The only problem I think, is that this probably only works for the
Webrick available in Ruby 1.9.x ... :-(. Ruby 1.8.7 might need some
other hackery to disable it ...

I can't speak for the core Puppet team (Josh?), but I think it might
be bug-worthy. Most people utilise Apache or Nginx in production so
they don't see the problem, but still for small dev style purposes
like yours its an annoying distraction.

ken.

On Thu, Jan 10, 2013 at 3:58 PM, Kirk Steffensen
k...@steffensenfamily.com wrote:
 SOLVED: I didn't have the VMs in the host's /etc/hosts.  Once I put all of
 them into the host (i.e, the Puppet Master), then everything sped up to full
 speed on the clients.  (I had been thinking it was a problem on the client
 side, so all of my troubleshooting had been isolated to the clients.  I
 finally thought to try the server side this morning.)

 Question: Should I submit this as a bug?  I'm not sure if this is a Puppet
 bug or an OS bug?  The Puppet Master was eventually serving up the files,
 but only after 10 seconds (while it was trying to resolve the name?)  Since
 the Puppet Master was able to reply without being able to resolve the name,
 why was it bothering to resolve the name instead of just replying directly
 to the request?

 Thanks,
 Kirk


 On Wednesday, January 9, 2013 5:45:16 PM UTC-5, Kirk Steffensen wrote:

 Josh,

 use_srv_records is not set in puppet.conf.  'puppet config print
 use_srv_records shows it set to the default of false.

 I ran tcpdump from inside the Vagrant VM during pluginsync.  On eth1,
 where the VM is connecting to the puppet master running on the host, the
 only calls are puppet calls on 8140 with replies coming back on 34757.
 Running 'tcpdump port 53' shows no DNS traffic at all during the pluginsync.
 (FWIW, I'm not running DNS for these vagrant boxes.  Everything is in
 /etc/hosts, so it doesn't surprise me that there are zero DNS calls.)

 Thanks,
 Kirk

 On Wednesday, January 9, 2013 5:13:04 PM UTC-5, Josh Cooper wrote:

 Hi Kirk,

 Do you happen to have SRV lookups enabled via the `use_srv_records`
 setting? You may want to run tcpdump and look for extraneous DNS
 lookups.

 Josh

 On Wed, Jan 9, 2013 at 2:00 PM, Kirk Steffensen
 ki...@steffensenfamily.com wrote:
  Here is the strace output from one of the 10-second periods while
  waiting
  for the File notice to appear.  https://gist.github.com/4497263
 
  The strace output came in two bursts during this 10-seconds.
 
  The thing that leaps out at me is that of the 4061 lines of output,
  3754 of
  them are rt_sigprocmask calls.  I'm wondering if it's a Ruby bug?  For
  these
  VMs, I'm using 1.8.7, installed from source:
  http://ftp.ruby-lang.org/pub/ruby/ruby-1.8.7-p358.tar.gz
 
  I created another gist with the rt_sigprocmask calls to make it easier
  to
  tell if there is anything else going on.
  https://gist.github.com/4497335
  From my quick review, nothing leaps out.
 
  Hope this helps point the troubleshooting in the right direction.
 
  Thanks,
  Kirk
 
 
  On Wednesday, January 9, 2013 12:59:40 PM UTC-5, Ken Barber wrote:
 
   Ken, thanks.  Unfortunately, (from a troubleshooting standpoint), it
   only
   took one or two seconds to sync stdlib on the local box.
  
   rm -rf /var/lib/puppet/lib/*
   puppet agent --test
  
   I saw the same stream of File notices, but they streamed by in real
   time,
   instead of taking 10 seconds per notice.
 
  Yeah, thats gotta be some comms problem between your PM and clients
  then ... just not sure what.
 
   John may still have something.  There may still be some name
   resolution
   issue on the client, but it's just not obvious from the testing that
   I
   did.
 
  Perhaps perhaps ... I'd strace the puppet process to see whats
  happening in the gaps. 10-15 seconds would lead me to suspect DNS as
  well. Perhaps we haven't exhausted this avenue ... try adding all your
  hosts into /etc/hosts on each box perhaps? Disabling DNS temporarily
  (from say nsswitch.conf) then will remove that avenue of potential
  :-).
 
   I haven't dug into the file provider code.  What mechanism is it
   using
   to
   move the files from the server to the client?  Could it be a delay
   in an
   scp
   handshake or the like?
 
  HTTPS actually ... with client and server certificates.
 
  ken.
 
  --
  You received this message because you are subscribed to the Google
  Groups
  Puppet Users group.
  To view this discussion on the web visit

Re: [Puppet Users] stdlib take almost 14 minutes to sync on CentOS Vagrant VM

2013-01-10 Thread Josh Cooper

Hi Kirk

On Thu, Jan 10, 2013 at 7:58 AM, Kirk Steffensen
k...@steffensenfamily.com wrote:
 SOLVED: I didn't have the VMs in the host's /etc/hosts.  Once I put all of
 them into the host (i.e, the Puppet Master), then everything sped up to full
 speed on the clients.  (I had been thinking it was a problem on the client
 side, so all of my troubleshooting had been isolated to the clients.  I
 finally thought to try the server side this morning.)

 Question: Should I submit this as a bug?  I'm not sure if this is a Puppet
 bug or an OS bug?  The Puppet Master was eventually serving up the files,
 but only after 10 seconds (while it was trying to resolve the name?)  Since
 the Puppet Master was able to reply without being able to resolve the name,
 why was it bothering to resolve the name instead of just replying directly
 to the request?


The puppetmaster, specifically
Puppet::Network::HTTP::Handler#resolve_node, will perform a reverse
lookup in some situations. When using webrick, the puppetmaster will
perform a reverse lookup if the request does not contain a
client_cert. When using puppetmaster inside a rack application, it
will perform a reverse lookup if the request does not contain a header
parameter that matches Puppet's `ssl_client_header` setting.

If all of your agents have already been issued certificates, then I
would not expect any unauthenticated requests, so I wouldn't expect
any further lookups...

Also, when looking into the SRV support in puppet, I found that ruby's
internal DNS resolver does not cache SRV lookups, at least in 1.8.7.
It may not cache reverse lookups either, which could make this issue
worse for you.

Josh

 Thanks,
 Kirk


 On Wednesday, January 9, 2013 5:45:16 PM UTC-5, Kirk Steffensen wrote:

 Josh,

 use_srv_records is not set in puppet.conf.  'puppet config print
 use_srv_records shows it set to the default of false.

 I ran tcpdump from inside the Vagrant VM during pluginsync.  On eth1,
 where the VM is connecting to the puppet master running on the host, the
 only calls are puppet calls on 8140 with replies coming back on 34757.
 Running 'tcpdump port 53' shows no DNS traffic at all during the pluginsync.
 (FWIW, I'm not running DNS for these vagrant boxes.  Everything is in
 /etc/hosts, so it doesn't surprise me that there are zero DNS calls.)

 Thanks,
 Kirk

 On Wednesday, January 9, 2013 5:13:04 PM UTC-5, Josh Cooper wrote:

 Hi Kirk,

 Do you happen to have SRV lookups enabled via the `use_srv_records`
 setting? You may want to run tcpdump and look for extraneous DNS
 lookups.

 Josh

 On Wed, Jan 9, 2013 at 2:00 PM, Kirk Steffensen
 ki...@steffensenfamily.com wrote:
  Here is the strace output from one of the 10-second periods while
  waiting
  for the File notice to appear.  https://gist.github.com/4497263
 
  The strace output came in two bursts during this 10-seconds.
 
  The thing that leaps out at me is that of the 4061 lines of output,
  3754 of
  them are rt_sigprocmask calls.  I'm wondering if it's a Ruby bug?  For
  these
  VMs, I'm using 1.8.7, installed from source:
  http://ftp.ruby-lang.org/pub/ruby/ruby-1.8.7-p358.tar.gz
 
  I created another gist with the rt_sigprocmask calls to make it easier
  to
  tell if there is anything else going on.
  https://gist.github.com/4497335
  From my quick review, nothing leaps out.
 
  Hope this helps point the troubleshooting in the right direction.
 
  Thanks,
  Kirk
 
 
  On Wednesday, January 9, 2013 12:59:40 PM UTC-5, Ken Barber wrote:
 
   Ken, thanks.  Unfortunately, (from a troubleshooting standpoint), it
   only
   took one or two seconds to sync stdlib on the local box.
  
   rm -rf /var/lib/puppet/lib/*
   puppet agent --test
  
   I saw the same stream of File notices, but they streamed by in real
   time,
   instead of taking 10 seconds per notice.
 
  Yeah, thats gotta be some comms problem between your PM and clients
  then ... just not sure what.
 
   John may still have something.  There may still be some name
   resolution
   issue on the client, but it's just not obvious from the testing that
   I
   did.
 
  Perhaps perhaps ... I'd strace the puppet process to see whats
  happening in the gaps. 10-15 seconds would lead me to suspect DNS as
  well. Perhaps we haven't exhausted this avenue ... try adding all your
  hosts into /etc/hosts on each box perhaps? Disabling DNS temporarily
  (from say nsswitch.conf) then will remove that avenue of potential
  :-).
 
   I haven't dug into the file provider code.  What mechanism is it
   using
   to
   move the files from the server to the client?  Could it be a delay
   in an
   scp
   handshake or the like?
 
  HTTPS actually ... with client and server certificates.
 
  ken.
 
  --
  You received this message because you are subscribed to the Google
  Groups
  Puppet Users group.
  To view this discussion on the web visit
  https://groups.google.com/d/msg/puppet-users/-/OKNPyOQqZcQJ.
 
  To post to this group, send email to

Re: [Puppet Users] Re: Announce: PuppetDB 1.1.0-rc4 now available

2013-01-10 Thread Moses Mendoza

On Thu, Jan 10, 2013 at 7:27 AM, Eric Kissinger
eric.kissin...@gmail.com wrote:


 The puppetdb-1.1.0-0.1rc4.el6.noarch.rpm package seems to have an error when 
 unpacking the puppetdb.jar.

 This is the output:


 Downloading Packages:
 puppetdb-1.1.0-0.1rc4.el6.noarch.rpm  
 |  14 MB 00:00
 Running rpm_check_debug
 Running Transaction Test
 Transaction Test Succeeded
 Running Transaction
   Updating   : puppetdb-1.1.0-0.1rc4.el6.noarch   
1/2
 Error unpacking rpm package puppetdb-1.1.0-0.1rc4.el6.noarch
 warning: /etc/puppetdb/conf.d/config.ini created as 
 /etc/puppetdb/conf.d/config.ini.rpmnew
 error: unpacking of archive failed on file 
 /usr/share/puppetdb/puppetdb.jar;50eed3a6: cpio: read

Hi Eric,

I'm having a hard time replicating your issue. On my centos 6 vm, I
can do a clean install and also upgrade from puppetdb 1.0.5 without
issue.  Also of note, your log shows a file size of 14 MB, but
puppetdb is more like 16 MB, which perhaps could indicate some
corruption somewhere. E.g., from my install output:

Downloading Packages:
Setting up and reading Presto delta metadata
Processing delta metadata
Package(s) data still to download: 16 M
puppetdb-1.1.0-0.1rc4.el6.noarch.rpm
   |  16 MB 00:30
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing : puppetdb-1.1.0-0.1rc4.el6.noarch
  1/1
Certificate was added to keystore
  Verifying  : puppetdb-1.1.0-0.1rc4.el6.noarch
  1/1

Installed:
  puppetdb.noarch 0:1.1.0-0.1rc4.el6

Complete!

Perhaps something went awry during your repo metadata gathering? Maybe
try `yum clean metadata`? and installing again? In case its a
packaging issue, what version of puppetdb are you upgrading from, and
what OS are you installing onto?

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

Re: [Puppet Users] Puppet module for managing Cobbler

2013-01-10 Thread Ryan Coleman

I think Jakov meant to post this module:
http://forge.puppetlabs.com/jsosic/cobbler and not apache.

Thanks for sharing!

On Sat, Dec 29, 2012 at 11:54 AM, Jakov Sosic jso...@srce.hr wrote:

Module on forge:

http://forge.puppetlabs.com/**puppetlabs/apachehttp://forge.puppetlabs.com/puppetlabs/apache

Code and issue tracker:

https://bitbucket.org/jsosic/**puppet-cobblerhttps://bitbucket.org/jsosic/puppet-cobbler

Comments are welcome, hope somebody finds it useful. I'm very happy with
it so far :D

The reason I'm posting it is that couple of people asked me about
publishing this module while I was in a process of developing it, so If
those people are still reading the list, here you go!

I've also got 4 custom types, one of them uses hashes, so it's a good
showcase for anyone interested in writing their own complex custom
providers.

enjoy

--
Jakov Sosic
www.srce.unizg.hr

--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe@**
googlegroups.com puppet-users%2bunsubscr...@googlegroups.com.
For more options, visit this group at http://groups.google.com/**
group/puppet-users?hl=enhttp://groups.google.com/group/puppet-users?hl=en
.

--
Ryan Coleman | Modules Forge | @ryanycoleman | ryancoleman in #puppet

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

[Puppet Users] Access variables defined in defined type

2013-01-10 Thread Vladimir Rutsky

Hello!

How can I access variable defined inside defined type?

For example I have following define:

define python_virtualenv( $directory ) {
  # Setup virtualenv in directory here

  $easy_install = ${directory}/bin/easy_install
}

And use it in this way:

python_virtualenv { 'env for Django':
  directory = '/opt/django/env'
}

python_virtualenv { 'env for Worker':
  directory = '/opt/worker/env'
}

# Now I want to use easy_install from created virtual environments:
class { 'django':
  easy_install = ???$Python_virtualenv['env for Django']::binary_dir???
}

class { 'django-cache':
  easy_install = ???$Python_virtualenv['env for Django']::binary_dir???
}

class { 'worker':
  easy_install = ???$Python_virtualenv['env for Worker']::binary_dir???
}

How to access $easy_install from created resources?


Thanks in advance,

Vladimir Rutsky


-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/Ql6_ZaIIQAcJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] JBOSS installation and Configuration through puppet

2013-01-10 Thread Andrey Kouznetsov

I have the same error.
I am using puppet-jboss module from example42 and trying to install it on
clean ubuntu 12.04 server.
User jboss does not exists before (so and after) I run puppet agent.
Here is part of output:

Debug: Executing '/usr/sbin/groupadd jboss'
Notice: /Stage[main]/Jboss::User/Group[jboss]/ensure: created
Debug: /Stage[main]/Jboss::User/Group[jboss]: The container Class[Jboss::User]
will propagate my refresh event
Debug: Executing '/usr/sbin/useradd -p ! -c jboss user -d /opt/jboss -s
/bin/bash jboss'
Error: Could not create user jboss: Execution of '/usr/sbin/useradd -p ! -c
jboss user -d /opt/jboss -s /bin/bash jboss' returned 9: useradd: group jboss
exists - if you want to add this user to that group, use -g.

Error: /Stage[main]/Jboss::User/User[jboss]/ensure: change from absent to
present failed: Could not create user jboss: Execution of '/usr/sbin/useradd -p
! -c jboss user -d /opt/jboss -s /bin/bash jboss' returned 9: useradd: group
jboss exists - if you want to add this user to that group, use -g.

Debug: Class[Jboss::User]: The container Stage[main] will propagate my refresh
event

On Monday, August 27, 2012 4:58:40 AM UTC+4, skylove wrote:

the user jobss is exists in you system!

2012/8/25 Ajeet Raina ajeet...@gmail.com javascript:

Hi All,

I have puppet server and client ready. I found JBOSS module and manifests
under
https://github.com/example42/puppet-jboss/https://github.com/example42/puppet-jboss/blob/master/manifests/init.pp
and
imported it through git.
I am encountering these isse while I run :

http://pastebin.com/S67JqmSK

--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/iaYlyzVcuLUJ.
To post to this group, send email to puppet...@googlegroups.comjavascript:
.
To unsubscribe from this group, send email to
puppet-users...@googlegroups.com javascript:.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/n6KiYY427rUJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Access variables defined in defined type

2013-01-10 Thread Vladimir Rutsky

Sorry, there is a typo in example:

define python_virtualenv( $directory ) {
  # Setup virtualenv in directory here
  ...

  $easy_install = ${directory}/bin/easy_install
}

And use it in this way:

python_virtualenv { 'env for Django':
  directory = '/opt/django/env'
}

python_virtualenv { 'env for Worker':
  directory = '/opt/worker/env'
}

# Now I want to use easy_install from created virtual environments:
class { 'django':
  easy_install = ???$Python_virtualenv['env for Django']::easy_install???
}

class { 'django-cache':
  easy_install = ???$Python_virtualenv['env for Django']::easy_install???
}

class { 'worker':
  easy_install = ???$Python_virtualenv['env for Worker']::easy_install???
}

Question remains the same: how to access $easy_install variable defined 
inside type define resource?  


Vladimir Rutsky

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/ocFhp6JW43cJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Access variables defined in defined type

2013-01-10 Thread llowder



On Thursday, January 10, 2013 2:53:34 PM UTC-6, Vladimir Rutsky wrote:

 Sorry, there is a typo in example:

 define python_virtualenv( $directory ) {
   # Setup virtualenv in directory here
   ...

   $easy_install = ${directory}/bin/easy_install
 }

 And use it in this way:

 python_virtualenv { 'env for Django':
   directory = '/opt/django/env'
 }

 python_virtualenv { 'env for Worker':
   directory = '/opt/worker/env'
 }

 # Now I want to use easy_install from created virtual environments:
 class { 'django':
   easy_install = ???$Python_virtualenv['env for Django']::easy_install???
 }

 class { 'django-cache':
   easy_install = ???$Python_virtualenv['env for Django']::easy_install???
 }

 class { 'worker':
   easy_install = ???$Python_virtualenv['env for Worker']::easy_install???
 }

 Question remains the same: how to access $easy_install variable defined 
 inside type define resource?  


You can't.  Defines, or as the are more formally called, defined types, act 
more like the built in resource types rather than classes. The variables 
and parameters from a define can only be accessed from the define itself, 
and from templates invoked within the define.

 


 Vladimir Rutsky



-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/ZIhCgvZ_C6oJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Puppet dashboard not enabling inventory

2013-01-10 Thread Stefan Heijmans

I mean regardless of what settings are set shouldn't I at least be able 
to see the inventory tab if enable_inventory_service is set to true?
Yes if you mean the one on top of the screen
If you click on a node when it's not configured correctly it shows;
Inventory
Could not retrieve facts from inventory service: getaddrinfo: Name or 
service not known

Pointing to correct port for puppetdb and server in settings.yml
my inventory_server  inventory_port parameters points to puppetmaster 
server puppetmaster port 8140

Has anyone else successfully got the puppet dashboard working with 
dashboard version 1.2.17 with puppet 3?
Yes on rhel63 with
puppet 3.0.2
puppet dashboard 1.2.18
puppetdb 1.0.5

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/QPUP0oc6Gy0J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Help needed in setting up a simple ENC

Hello,

I am trying to set up a simple ENC, but definitely missing pieces because 
of which the client data is not propagated to the master. Any help is 
appreciated. Here is what I do after following some of puppetlab docs 
(which is not very verbose TBH) :

In the puppet-master the yaml containing client data is sitting in,

/var/lib/enc/node_name.yaml

contains,

~]# /usr/local/bin/enclassfier node_name
---
environment:
classes:
  - defaultcls
  - dyd::agents

/usr/local/bin/enclassifier is a simple bash script that catenate the 
content of node_name.yaml.

puppet.conf on the puppet-master contains these two extra lines :

node_terminus = exec
external_nodes = /usr/local/bin/enclassifier

site.pp is made empty with no node definition for node 'node_name'.

Now running puppet agent on node_name ends up with the following error :

puppet agent --server=puppet --onetime --verbose --no-daemonize



Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Could not find default node or by name with 'node_name' on node node_name


What is missing in this configuration ? 

Thanks for any suggestion or any pointer to a good example set.







-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/neMgoYbIwa8J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Announce: PuppetDB 1.1.0-rc5 Available

2013-01-10 Thread Moses Mendoza

PuppetDB 1.1.0-rc5 is now available for download. 1.1.0-rc5
specifically addresses a regression in Debian packaging of PuppetDB.
RPM packages are unchanged since 1.1.0-rc4.

# Downloads
==
Available in native package format in the pre-release repositories at:
http://yum.puppetlabs.com and http://apt.puppetlabs.com

For information on how to enable the Puppet Labs pre-release repos, see:
http://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html#enabling-the-prerelease-repos

Puppet module:
http://forge.puppetlabs.com/puppetlabs/puppetdb

Source (same license as Puppet): http://github.com/puppetlabs/puppetdb/

# Documentation (including how to install): http://docs.puppetlabs.com/puppetdb

# Issues can be filed at:
http://projects.puppetlabs.com/projects/puppetdb/issues

# See our development board on Trello:
http://links.puppetlabs.com/puppetdb-trello

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

[Puppet Users] changing the root password on PUPPET master and init.pp

2013-01-10 Thread DJames

I understand that you must change the password on the host itself first, 
then change the password in /etc/puppet/modules/users/manifests/init.pp

what makes the password encrypted? Do i just put the non-encrypted new root 
password in the following sections? then puppet encrypts it?


lass users {
   case $operatingsystem {
  'RedHat', 'CentOS': {
 user {
root:
   comment  = '[ROOT]',
   uid  = 0,
   gid  = root,
   home = /root,

password = $ ? {
  4 = '',
  5 = '',
  6 = '',




-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/mEeGNkFMgusJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Help needed in setting up a simple ENC

Just to add :

I am using puppet-3.0.2x

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/jaQ7a_m_DmsJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Help needed in setting up a simple ENC

What happens when you run `/usr/local/bin/enclassifier node_name`as the
puppet user?


On Thu, Jan 10, 2013 at 1:41 PM, iamauser tapas.sara...@gmail.com wrote:

 Hello,

 I am trying to set up a simple ENC, but definitely missing pieces because
 of which the client data is not propagated to the master. Any help is
 appreciated. Here is what I do after following some of puppetlab docs
 (which is not very verbose TBH) :

 In the puppet-master the yaml containing client data is sitting in,

 /var/lib/enc/node_name.yaml

 contains,

 ~]# /usr/local/bin/enclassfier node_name
 ---
 environment:
 classes:
   - defaultcls
   - dyd::agents

 /usr/local/bin/enclassifier is a simple bash script that catenate the
 content of node_name.yaml.

 puppet.conf on the puppet-master contains these two extra lines :

 node_terminus = exec
 external_nodes = /usr/local/bin/enclassifier

 site.pp is made empty with no node definition for node 'node_name'.

 Now running puppet agent on node_name ends up with the following error :

 puppet agent --server=puppet --onetime --verbose --no-daemonize
 
 
 
 Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
 Could not find default node or by name with 'node_name' on node node_name


 What is missing in this configuration ?

 Thanks for any suggestion or any pointer to a good example set.







  --
 You received this message because you are subscribed to the Google Groups
 Puppet Users group.
 To view this discussion on the web visit
 https://groups.google.com/d/msg/puppet-users/-/neMgoYbIwa8J.
 To post to this group, send email to puppet-users@googlegroups.com.
 To unsubscribe from this group, send email to
 puppet-users+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/puppet-users?hl=en.




-- 
Gary Larizza
Professional Services Engineer

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

Re: [Puppet Users] Help needed in setting up a simple ENC

On Thursday, January 10, 2013 4:07:45 PM UTC-6, Gary Larizza wrote:

 What happens when you run `/usr/local/bin/enclassifier node_name`as the 
 puppet user? 


 
This is what it prints out if I run it on puppet-server.

~]# /usr/local/bin/enclassfier node_name
---
environment:
classes:
  - defaultcls
  - dyd::agents

To cross check whether puppetmaster is reading the external_nodes 
correctly, I tried the following command :

~]# puppet master --configprint external_nodes node_name
/usr/local/bin/enclassifier

Thanks

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/a0P6X7DjuOQJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Help needed in setting up a simple ENC

On Thu, Jan 10, 2013 at 2:56 PM, iamauser tapas.sara...@gmail.com wrote:

Hi,

Here is the output. Sorry I didn't get it the first time :)

]# su -s /bin/sh puppet -c /usr/local/bin/enclassifier node_name
---
environment: production
classes:
defaultcls:
dyd::agents:

Cool. Okay, so you said initially that site.pp exists, but it's blank -
there's no default node at all. Have you tried creating a blank default
node declaration (or one with a simple notify statement) to debug what's
going on? I'd do that next just to rule out a missing default node causing
issues (I know there was a bug awhile back where Puppet threw a fit
whenever it didn't find a default node declaration, but I can't remember
how it was resolved).

Thanks

On Thursday, January 10, 2013 4:36:14 PM UTC-6, Gary Larizza wrote:

On Thu, Jan 10, 2013 at 2:13 PM, iamauser tapas@gmail.com wrote:

On Thursday, January 10, 2013 4:07:45 PM UTC-6, Gary Larizza wrote:

What happens when you run `/usr/local/bin/enclassifier node_name`as
the puppet user?

This is what it prints out if I run it on puppet-server.

~]# /usr/local/bin/enclassfier node_name
---
environment:
classes:
- defaultcls
- dyd::agents

What user were you using to run that command? I see the hash, so I
assume it's root. Try running this as the 'puppet' user - does it spit out
the same thing? Remember that Puppet runs the script as the user which is
running the puppet master service (which is usually 'puppet'). I just want
to clarify this before we go on :)

To cross check whether puppetmaster is reading the external_nodes
correctly, I tried the following command :

~]# puppet master --configprint external_nodes node_name
/usr/local/bin/enclassifier

Thanks

--
You received this message because you are subscribed to the Google
Groups Puppet Users group.
To view this discussion on the web visit https://groups.google.com/d/**
msg/puppet-users/-/**a0P6X7DjuOQJhttps://groups.google.com/d/msg/puppet-users/-/a0P6X7DjuOQJ
.

To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@**
googlegroups.com.

For more options, visit this group at http://groups.google.com/**
group/puppet-users?hl=enhttp://groups.google.com/group/puppet-users?hl=en
.

--
Gary Larizza
Professional Services Engineer

--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/mkZL7rwW1AgJ.

To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

--
Gary Larizza
Professional Services Engineer

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

Re: [Puppet Users] Help needed in setting up a simple ENC

Running puppet agent with a blank node default didn't throw any error and 
prints out the notification. I get this message when puppet agent runs on 
'node_name'.

Notice: I AM DEFAULTing...
Notice: /Stage[main]//Node[default]/Notify[I AM DEFAULTing...]/message: 
defined 'message' as 'I AM DEFAULTing...'

I tried to give another notify message in one of the classes (dyd::agents), 
but it didn't print that out. So it is definitely not considering the 
policies defined in that class.

Just to note, without the ENC, include dyd::agents in site.pp works and 
propagate the policies and prints the notification.


-Thanks



On Thursday, January 10, 2013 5:02:08 PM UTC-6, Gary Larizza wrote:




 On Thu, Jan 10, 2013 at 2:56 PM, iamauser tapas@gmail.comjavascript:
  wrote:

 Hi,

 Here is the output. Sorry I didn't get it the first time :)

 ]# su -s /bin/sh puppet -c /usr/local/bin/enclassifier node_name
 ---
 environment: production
 classes:
defaultcls:
dyd::agents:


 Cool.  Okay, so you said initially that site.pp exists, but it's blank - 
 there's no default node at all.  Have you tried creating a blank default 
 node declaration (or one with a simple notify statement) to debug what's 
 going on?  I'd do that next just to rule out a missing default node causing 
 issues (I know there was a bug awhile back where Puppet threw a fit 
 whenever it didn't find a default node declaration, but I can't remember 
 how it was resolved).



-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/dcC_pakJNe0J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Help needed in setting up a simple ENC

On Thu, Jan 10, 2013 at 3:18 PM, iamauser tapas.sara...@gmail.com wrote:

 Running puppet agent with a blank node default didn't throw any error and
 prints out the notification. I get this message when puppet agent runs on
 'node_name'.

 Notice: I AM DEFAULTing...
 Notice: /Stage[main]//Node[default]/Notify[I AM DEFAULTing...]/message:
 defined 'message' as 'I AM DEFAULTing...'

 I tried to give another notify message in one of the classes
 (dyd::agents), but it didn't print that out. So it is definitely not
 considering the policies defined in that class.

 Just to note, without the ENC, include dyd::agents in site.pp works and
 propagate the policies and prints the notification.



Ahh,

I think I see something.  Looking at this:

---
environment: production
classes:
   defaultcls:
   dyd::agents:

It looks like the classes are being listed as hashes without values, and
not as an array of class names.  How are you generating this YAML?  It
should be displaying like:

---
environment:
classes:
  - defaultcls
  - dyd::agents

(note the dashes)  When you ORIGINALLY gave us the output, it was being
output correctly, but when you pasted the output when you run the ENC as
the puppet user, it seems to be incorrect.  ENCs can pass parameters for
class declarations like so:

---
environment: production
classes:
   defaultcls:
 parameter: value
   dyd::agents:
 parameter: value

...but the fact that you're not passing parameters may be messing with
Puppet (I'm going off the top of my head without validating this, so please
someone else speak up if what I'm saying is not entirely true).



-Thanks



 On Thursday, January 10, 2013 5:02:08 PM UTC-6, Gary Larizza wrote:




 On Thu, Jan 10, 2013 at 2:56 PM, iamauser tapas@gmail.com wrote:

 Hi,

 Here is the output. Sorry I didn't get it the first time :)

 ]# su -s /bin/sh puppet -c /usr/local/bin/enclassifier node_name
 ---
 environment: production
 classes:
defaultcls:
dyd::agents:


 Cool.  Okay, so you said initially that site.pp exists, but it's blank -
 there's no default node at all.  Have you tried creating a blank default
 node declaration (or one with a simple notify statement) to debug what's
 going on?  I'd do that next just to rule out a missing default node causing
 issues (I know there was a bug awhile back where Puppet threw a fit
 whenever it didn't find a default node declaration, but I can't remember
 how it was resolved).

  --
 You received this message because you are subscribed to the Google Groups
 Puppet Users group.
 To view this discussion on the web visit
 https://groups.google.com/d/msg/puppet-users/-/dcC_pakJNe0J.

 To post to this group, send email to puppet-users@googlegroups.com.
 To unsubscribe from this group, send email to
 puppet-users+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/puppet-users?hl=en.




-- 
Gary Larizza
Professional Services Engineer

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

Re: [Puppet Users] Help needed in setting up a simple ENC

I guess I figured it out after looking at the PuppetlabConf video on 
youtube :)
Need to restart the puppetmaster. There was a laugh about during in the 
talk !huh! 

It doesn't solve my problem though. It now ends up with another error. 
First warning and then error :

]$ sudo puppet agent --server=puppet --no-daemonize --verbose --onetime
Warning: Unable to fetch my node definition, but the agent run will 
continue:
Warning: Error 400 on SERVER: Failed to find node_name via exec: Execution 
of '/usr/loca/bin/enclassifier node_name' returned 1: 



Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Failed when searching for node node_name: Failed to find node_name via 
exec: Execution of '/usr/loca/bin/enclassifier node_name' returned 1: 

Here 'node_name' is the full fqdn of the node. Should the 
/usr/local/bin/enclassifier and the node_name.yaml be defined in the 
node_name as well ?


-Thanks






-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/h5ehR71VNiMJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Help needed in setting up a simple ENC

On Thu, Jan 10, 2013 at 3:38 PM, iamauser tapas.sara...@gmail.com wrote:

 I guess I figured it out after looking at the PuppetlabConf video on
 youtube :)
 Need to restart the puppetmaster. There was a laugh about during in the
 talk !huh!

 It doesn't solve my problem though. It now ends up with another error.
 First warning and then error :

 ]$ sudo puppet agent --server=puppet --no-daemonize --verbose --onetime
 Warning: Unable to fetch my node definition, but the agent run will
 continue:
 Warning: Error 400 on SERVER: Failed to find node_name via exec: Execution
 of '/usr/loca/bin/enclassifier node_name' returned 1:
 
 
 
 Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
 Failed when searching for node node_name: Failed to find node_name via
 exec: Execution of '/usr/loca/bin/enclassifier node_name' returned 1:


^^ Note the typo for /usr/LOCAL  :)



 Here 'node_name' is the full fqdn of the node. Should the
 /usr/local/bin/enclassifier and the node_name.yaml be defined in the
 node_name as well ?


 -Thanks




  --
 You received this message because you are subscribed to the Google Groups
 Puppet Users group.
 To view this discussion on the web visit
 https://groups.google.com/d/msg/puppet-users/-/h5ehR71VNiMJ.

 To post to this group, send email to puppet-users@googlegroups.com.
 To unsubscribe from this group, send email to
 puppet-users+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/puppet-users?hl=en.




-- 
Gary Larizza
Professional Services Engineer

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

Re: [Puppet Users] Help needed in setting up a simple ENC

On Thu, Jan 10, 2013 at 3:36 PM, Gary Larizza g...@puppetlabs.com wrote:




 On Thu, Jan 10, 2013 at 3:18 PM, iamauser tapas.sara...@gmail.com wrote:

 Running puppet agent with a blank node default didn't throw any error and
 prints out the notification. I get this message when puppet agent runs on
 'node_name'.

 Notice: I AM DEFAULTing...
 Notice: /Stage[main]//Node[default]/Notify[I AM DEFAULTing...]/message:
 defined 'message' as 'I AM DEFAULTing...'

 I tried to give another notify message in one of the classes
 (dyd::agents), but it didn't print that out. So it is definitely not
 considering the policies defined in that class.

 Just to note, without the ENC, include dyd::agents in site.pp works and
 propagate the policies and prints the notification.



 Ahh,

 I think I see something.  Looking at this:

 ---
 environment: production
 classes:
defaultcls:
dyd::agents:

 It looks like the classes are being listed as hashes without values, and
 not as an array of class names.  How are you generating this YAML?  It
 should be displaying like:

 ---
 environment:
 classes:
   - defaultcls
   - dyd::agents

 (note the dashes)  When you ORIGINALLY gave us the output, it was being
 output correctly, but when you pasted the output when you run the ENC as
 the puppet user, it seems to be incorrect.  ENCs can pass parameters for
 class declarations like so:


Also, I'm wrong on this ^^; I just tested it out and it DOES work.  You can
pass class values as a hash.  So disregard this comment


 ---
 environment: production
 classes:
defaultcls:
  parameter: value
dyd::agents:
  parameter: value

 ...but the fact that you're not passing parameters may be messing with
 Puppet (I'm going off the top of my head without validating this, so please
 someone else speak up if what I'm saying is not entirely true).



 -Thanks



 On Thursday, January 10, 2013 5:02:08 PM UTC-6, Gary Larizza wrote:




 On Thu, Jan 10, 2013 at 2:56 PM, iamauser tapas@gmail.com wrote:

 Hi,

 Here is the output. Sorry I didn't get it the first time :)

 ]# su -s /bin/sh puppet -c /usr/local/bin/enclassifier node_name
 ---
 environment: production
 classes:
defaultcls:
dyd::agents:


 Cool.  Okay, so you said initially that site.pp exists, but it's blank -
 there's no default node at all.  Have you tried creating a blank default
 node declaration (or one with a simple notify statement) to debug what's
 going on?  I'd do that next just to rule out a missing default node causing
 issues (I know there was a bug awhile back where Puppet threw a fit
 whenever it didn't find a default node declaration, but I can't remember
 how it was resolved).

  --
 You received this message because you are subscribed to the Google Groups
 Puppet Users group.
 To view this discussion on the web visit
 https://groups.google.com/d/msg/puppet-users/-/dcC_pakJNe0J.

 To post to this group, send email to puppet-users@googlegroups.com.
 To unsubscribe from this group, send email to
 puppet-users+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/puppet-users?hl=en.




 --
 Gary Larizza
 Professional Services Engineer




-- 
Gary Larizza
Professional Services Engineer

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

Re: [Puppet Users] Help needed in setting up a simple ENC

Yep... Typo indeed... It all works now... 

Thanks for your patience It now prints out the notification in the 
class dyd::agents... 


Cheers



On Thursday, January 10, 2013 5:42:57 PM UTC-6, Gary Larizza wrote:




 On Thu, Jan 10, 2013 at 3:36 PM, Gary Larizza 
 ga...@puppetlabs.comjavascript:
  wrote:




 On Thu, Jan 10, 2013 at 3:18 PM, iamauser tapas@gmail.comjavascript:
  wrote:

 Running puppet agent with a blank node default didn't throw any error 
 and prints out the notification. I get this message when puppet agent runs 
 on 'node_name'.

 Notice: I AM DEFAULTing...
 Notice: /Stage[main]//Node[default]/Notify[I AM DEFAULTing...]/message: 
 defined 'message' as 'I AM DEFAULTing...'

 I tried to give another notify message in one of the classes 
 (dyd::agents), but it didn't print that out. So it is definitely not 
 considering the policies defined in that class.

 Just to note, without the ENC, include dyd::agents in site.pp works and 
 propagate the policies and prints the notification.



 Ahh,

 I think I see something.  Looking at this:

 ---
 environment: production
 classes:
defaultcls:
dyd::agents:

 It looks like the classes are being listed as hashes without values, and 
 not as an array of class names.  How are you generating this YAML?  It 
 should be displaying like:
  
 ---
 environment:
 classes:
   - defaultcls
   - dyd::agents

 (note the dashes)  When you ORIGINALLY gave us the output, it was being 
 output correctly, but when you pasted the output when you run the ENC as 
 the puppet user, it seems to be incorrect.  ENCs can pass parameters for 
 class declarations like so:


 Also, I'm wrong on this ^^; I just tested it out and it DOES work.  You 
 can pass class values as a hash.  So disregard this comment
  

 ---
 environment: production
 classes:
defaultcls:
  parameter: value
dyd::agents:
  parameter: value

 ...but the fact that you're not passing parameters may be messing with 
 Puppet (I'm going off the top of my head without validating this, so please 
 someone else speak up if what I'm saying is not entirely true).
  


 -Thanks



 On Thursday, January 10, 2013 5:02:08 PM UTC-6, Gary Larizza wrote:




 On Thu, Jan 10, 2013 at 2:56 PM, iamauser tapas@gmail.com wrote:

 Hi,

 Here is the output. Sorry I didn't get it the first time :)

 ]# su -s /bin/sh puppet -c /usr/local/bin/enclassifier node_name
 ---
 environment: production
 classes:
defaultcls:
dyd::agents:


 Cool.  Okay, so you said initially that site.pp exists, but it's blank 
 - there's no default node at all.  Have you tried creating a blank default 
 node declaration (or one with a simple notify statement) to debug what's 
 going on?  I'd do that next just to rule out a missing default node 
 causing 
 issues (I know there was a bug awhile back where Puppet threw a fit 
 whenever it didn't find a default node declaration, but I can't remember 
 how it was resolved).

  -- 
 You received this message because you are subscribed to the Google 
 Groups Puppet Users group.
 To view this discussion on the web visit 
 https://groups.google.com/d/msg/puppet-users/-/dcC_pakJNe0J.

 To post to this group, send email to puppet...@googlegroups.comjavascript:
 .
 To unsubscribe from this group, send email to 
 puppet-users...@googlegroups.com javascript:.
 For more options, visit this group at 
 http://groups.google.com/group/puppet-users?hl=en.




 -- 
 Gary Larizza
 Professional Services Engineer 




 -- 
 Gary Larizza
 Professional Services Engineer 


-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/2bI1gLc5m5MJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] ghost overwriting puppet.conf (help!)