[Puppet Users] Puppet caught TERM; calling stop - error

[Will S. G.]

I'm running puppet on CentOS 6.3 x86_64: 

   - facter.i386   1:1.6.12-2.el6@puppet
   - puppet.noarch 2.7.19-1.el6  @puppet
   - ruby-shadow.x86_641.4.1-13.el6  @puppet

Puppetmaster: 

   - facter.x86_64 1:1.6.12-2.el6@puppet
   - hiera.noarch  1.0.0-2.el6   @puppet
   - puppet.noarch 2.7.19-1.el6  @puppet
   - puppet-dashboard.noarch 1.2.11-1.el6  @puppet
   - puppet-server.noarch  2.7.19-1.el6  @puppet
   - ruby-mysql.x86_64 2.8.2-1.el6   @puppet
   - ruby-shadow.x86_641.4.1-13.el6  @puppet

I keep getting seeing the following error on my puppet agent: 

Wed Oct 03 23:25:43 -0700 2012 Puppet (notice): Starting Puppet client 
version 2.7.19
Wed Oct 03 23:26:11 -0700 2012 Puppet (notice): Caught TERM; calling stop
Wed Oct 03 23:26:16 -0700 2012 Puppet (notice): Reopening log files
Wed Oct 03 23:26:55 -0700 2012 Puppet (err): Could not retrieve catalog 
from remote server: Error 400 on SERVER: could not obtain a database 
connection within 5 seconds.  The max pool size is currently 5; consider 
increasing it.

I can't seem to figure out what's wrong. What's even more weird is that 
only some of the agents are displaying this error. 

Any suggestions? 

-- 
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/-/zYRXI3Fkt2wJ.
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: Need help with dashboad configuration..

[Rajeev Iyer]

The doc says:

If you haven't installed Dashboard from a package, you must create a user 
and group for Dashboard and chown all its files to be owned by that user 
and group.

So, how should the entry look like:

Is there something specific?

Regards,
Rajeev



On Thursday, October 4, 2012 11:02:29 AM UTC+5:30, Rajeev Iyer wrote:

Thanks LL.
>
>
> On Wednesday, October 3, 2012 10:23:07 PM UTC+5:30, Lunixer wrote:
>>
>> It does take some reading.
>>
>> The main doc page[1] has information plus several resources[2] here and 
>> there.
>> Follow the instructions here[3] to install the puppetlabs repo so you can 
>> use yum.
>> When you do "yum install puppet-dashboard", it creates the unix account. 
>> Do "grep puppet /etc/passwd" and you'll see the account there.
>>
>> [1] http://docs.puppetlabs.com/dashboard/manual/1.2/bootstrapping.html
>> [2] http://www.how2centos.com/installing-puppet-dashboard-on-centos-5-5/
>> [3] 
>> http://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html
>>
>> LL
>> 
>>
>> http://docs.puppetlabs.com/dashboard/manual/1.2/bootstrapping.html
>>
>> On Wednesday, October 3, 2012 4:10:20 AM UTC-7, Rajeev Iyer wrote:
>>>
>>> Hi,
>>>
>>>   I am new to this.
>>>
>>> Can someone lead me to a step by step configuration for dashboard. The 
>>> ones on the web is too confusing.
>>> Like, it says we need to have an entry for puppet-dashboard in 
>>> /etc/passwd. So how does that look like?
>>>
>>> Rajeev
>>>
>>>

-- 
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/-/lUhqdsSG6w8J.
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: Need help with dashboad configuration..

[Rajeev Iyer]

Thanks LL.


On Wednesday, October 3, 2012 10:23:07 PM UTC+5:30, Lunixer wrote:
>
> It does take some reading.
>
> The main doc page[1] has information plus several resources[2] here and 
> there.
> Follow the instructions here[3] to install the puppetlabs repo so you can 
> use yum.
> When you do "yum install puppet-dashboard", it creates the unix account. 
> Do "grep puppet /etc/passwd" and you'll see the account there.
>
> [1] http://docs.puppetlabs.com/dashboard/manual/1.2/bootstrapping.html
> [2] http://www.how2centos.com/installing-puppet-dashboard-on-centos-5-5/
> [3] http://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html
>
> LL
> 
>
> http://docs.puppetlabs.com/dashboard/manual/1.2/bootstrapping.html
>
> On Wednesday, October 3, 2012 4:10:20 AM UTC-7, Rajeev Iyer wrote:
>>
>> Hi,
>>
>>   I am new to this.
>>
>> Can someone lead me to a step by step configuration for dashboard. The 
>> ones on the web is too confusing.
>> Like, it says we need to have an entry for puppet-dashboard in 
>> /etc/passwd. So how does that look like?
>>
>> Rajeev
>>
>>

-- 
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/-/lL3KyiGkMtUJ.
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/Passenger :: Could not retrieve catalog from remote server:Error 403 on server

[Jo Rhett]

On Oct 1, 2012, at 5:00 PM, Lunixer wrote:
> I'll try strace instead of tcpdump, being that this is not a TCP 
> communication problem over the wire but rather a file or directory access 
> problem.


Um, no. Puppet client talks to the server over the network, even on the same 
host. You really should listen to advice we provide. 

-- 
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.



-- 
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] Puppet 3 docs are live

[Nick Fagerlund]

Puppet 3 docs are now posted at 
http://docs.puppetlabs.com/puppet/3/reference/ . We apologize for the 
delay! This update adds release notes and a Puppet 3 language reference 
with all of the relevant updated. Next on deck is improved Hiera 
documentation. 

-- 
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/-/GetE5HzFiLcJ.
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] Removing intermediate variables in calculation

[Amos Shapira]

Thanks John. At least I know there is no way to improve my code.
I prefer to try to keep logic in the .pp files and out of the templates, 
just to make it easier to find.

On Thursday, October 4, 2012 1:02:35 AM UTC+10, jcbollinger wrote:
>
>
>
> On Tuesday, October 2, 2012 10:10:13 AM UTC-5, Guzmán Brasó wrote:
>>
>> I'm in no way a puppet guru but rewritting it didnt work? from a 
>> logic point of view this should work:
>>
>>
>> class 
>>   $baseurl,
>>   $webapp_context_path = ''
>> ) {
>>   if ($webapp_context_path == '') {   
>> # Try to get value from baseurl
>> $webapp_context_path = regsubst($baseurl, '^https?://[^/]+(/.*)', 
>> '\1')
>> if ($webapp_context_path == '') {
>>   #Set default
>>   $webapp_context_path = '/'
>> }
>>  }  
>>  notify{"rewritted webapp_context_path='${webapp_context_path}' from 
>> url='${baseurl}'": }
>> }
>>
>>
>
> No, that won't work, because Puppet variables, including class and 
> definition parameters, can be assigned a value at most once.  There are 
> good reasons for that, but they're not really relevant to the present 
> question.
>  
> Anyway, for that very reason, constructs involving internal variables such 
> as $int_webapp_context_path are fairly standard practice in Puppet.  
> Among the alternatives could be to redesign your class parameterization 
> or to drop the adaptive behavior.  Or you could write a custom function 
> implementing the logic for context path selection, or you could put it into 
> your template instead of your class.
>
> (Note, by the way, that because you assign a default value of '/' to 
> $webapp_context_path in your parameter list, in the class body that 
> parameter will be observed to have an empty value only if such a value is 
> explicitly set when the class is declared.)
>
>
> John
>
> 

-- 
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/-/Bmju_PjXasEJ.
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 3.0.0 and Augeas on Ubuntu Lucid 10.04

[Eric Sorenson]

Hi Paul, I created a ticket to track this issue, thanks for posting the 
trace output and manifest.

http://projects.puppetlabs.com/issues/16772

-=Eric

On Wednesday, October 3, 2012 6:27:41 AM UTC-7, Paul Tötterman wrote:
>
> > Ubuntu released a backport of 0.3.0 into lucid-backports which will 
> > resolve the issue for you here: 
> >  http://packages.ubuntu.com/lucid-backports/libaugeas-ruby
>
> Unfortunately upgrading the package did not solve the problem. Also the 
> error message doesn't match the bug report.
>
> --trace gives:
>
> Error: /Stage[main]/Grub::Server/Augeas[grub-serial]: Could not evaluate: 
> uninitialized constant Augeas::NO_LOAD
> /usr/lib/ruby/vendor_ruby/puppet/provider/augeas/augeas.rb:152:in 
> `open_augeas'
> /usr/lib/ruby/vendor_ruby/puppet/provider/augeas/augeas.rb:342:in 
> `need_to_run?'
> /usr/lib/ruby/vendor_ruby/puppet/type/augeas.rb:205:in `retrieve'
> /usr/lib/ruby/vendor_ruby/puppet/type.rb:685:in `retrieve'
> /usr/lib/ruby/vendor_ruby/puppet/type.rb:680:in `each'
> /usr/lib/ruby/vendor_ruby/puppet/type.rb:680:in `retrieve'
> /usr/lib/ruby/vendor_ruby/puppet/type.rb:693:in `retrieve_resource'
> /usr/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:32:in 
> `perform_changes'
> /usr/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:133:in 
> `evaluate'
> /usr/lib/ruby/vendor_ruby/puppet/transaction.rb:49:in `apply'
> /usr/lib/ruby/vendor_ruby/puppet/transaction.rb:84:in `eval_resource'
> /usr/lib/ruby/vendor_ruby/puppet/transaction.rb:104:in `evaluate'
> /usr/lib/ruby/vendor_ruby/puppet/util.rb:348:in `thinmark'
> /usr/lib/ruby/1.8/benchmark.rb:308:in `realtime'
> /usr/lib/ruby/vendor_ruby/puppet/util.rb:347:in `thinmark'
> /usr/lib/ruby/vendor_ruby/puppet/transaction.rb:104:in `evaluate'
> /usr/lib/ruby/vendor_ruby/puppet/transaction.rb:383:in `traverse'
> /usr/lib/ruby/vendor_ruby/puppet/transaction.rb:99:in `evaluate'
> /usr/lib/ruby/vendor_ruby/puppet/resource/catalog.rb:144:in `apply'
> /usr/lib/ruby/vendor_ruby/puppet/configurer.rb:122:in `apply_catalog'
> /usr/lib/ruby/vendor_ruby/puppet/util.rb:179:in `benchmark'
> /usr/lib/ruby/1.8/benchmark.rb:308:in `realtime'
> /usr/lib/ruby/vendor_ruby/puppet/util.rb:178:in `benchmark'
> /usr/lib/ruby/vendor_ruby/puppet/configurer.rb:121:in `apply_catalog'
> /usr/lib/ruby/vendor_ruby/puppet/configurer.rb:179:in `run'
> /usr/lib/ruby/vendor_ruby/puppet/agent.rb:45
> /usr/lib/ruby/vendor_ruby/puppet/agent/locker.rb:20:in `lock'
> /usr/lib/ruby/vendor_ruby/puppet/agent.rb:45
> /usr/lib/ruby/1.8/sync.rb:230:in `synchronize'
> /usr/lib/ruby/vendor_ruby/puppet/agent.rb:45
> /usr/lib/ruby/vendor_ruby/puppet/agent.rb:119:in `with_client'
> /usr/lib/ruby/vendor_ruby/puppet/agent.rb:42
> /usr/lib/ruby/vendor_ruby/puppet/agent.rb:84:in `run_in_fork'
> /usr/lib/ruby/vendor_ruby/puppet/agent.rb:41
> /usr/lib/ruby/vendor_ruby/puppet/application.rb:175:in `call'
> /usr/lib/ruby/vendor_ruby/puppet/application.rb:175:in `controlled_run'
> /usr/lib/ruby/vendor_ruby/puppet/agent.rb:39:in `run'
> /usr/lib/ruby/vendor_ruby/puppet/application/agent.rb:338:in `onetime'
> /usr/lib/ruby/vendor_ruby/puppet/application/agent.rb:311:in `run_command'
> /usr/lib/ruby/vendor_ruby/puppet/application.rb:346:in `run'
> /usr/lib/ruby/vendor_ruby/puppet/application.rb:438:in `plugin_hook'
> /usr/lib/ruby/vendor_ruby/puppet/application.rb:346:in `run'
> /usr/lib/ruby/vendor_ruby/puppet/util.rb:500:in `exit_on_fail'
> /usr/lib/ruby/vendor_ruby/puppet/application.rb:346:in `run'
> /usr/lib/ruby/vendor_ruby/puppet/util/command_line.rb:76:in `execute'
> /usr/bin/puppet:10
>
> And the augeas definition from the manifest is:
>
> $grub_console = 'console serial'
>
> augeas { 'grub-serial':
> context => '/files/etc/default/grub',
> changes => ["set GRUB_TERMINAL \"'$grub_console'\"",
> 'set GRUB_SERIAL_COMMAND "\'serial --speed=115200 
> --unit=0 --word=8 --parity=no --stop=1\'"',
> 'set GRUB_CMDLINE_LINUX_DEFAULT ""',
> 'set GRUB_CMDLINE_LINUX "\'console=tty1 
> console=ttyS0,115200n8\'"'],
> }
>
> Cheers,
> Paul
>

-- 
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/-/wcOTxmRY01IJ.
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] Removing intermediate variables in calculation

[Amos Shapira]

Thanks Guzman, as John pointed out that won't work (I think this is because 
Puppet's language is declarative, even if it resembles procedural language 
in many ways).

On Wednesday, October 3, 2012 1:10:13 AM UTC+10, Guzmán Brasó wrote:
>
> I'm in no way a puppet guru but rewritting it didnt work? from a logic 
> point of view this should work:
>
>
> class 
>   $baseurl,
>   $webapp_context_path = ''
> ) {
>   if ($webapp_context_path == '') {   
> # Try to get value from baseurl
> $webapp_context_path = regsubst($baseurl, '^https?://[^/]+(/.*)', '\1')
> if ($webapp_context_path == '') {
>   #Set default
>   $webapp_context_path = '/'
> }
>  }  
>  notify{"rewritted webapp_context_path='${webapp_context_path}' from 
> url='${baseurl}'": }
> }
>
> But as I said I'm fairly new with puppet, did not tried above code.
>
> On Mon, Oct 1, 2012 at 10:28 PM, Amos Shapira 
> 
> > wrote:
>
>> Hello,
>>
>> I have a small Puppet 2.7 module to configure Sonatype Nexus 
>> Professional. The module takes, among other things, a baseurl in the form 
>> of "http://example.com/path"; and I'd like it to extract the "/path" from 
>> that variable into a separate variable IF an optional "path" variable 
>> haven't been supplied.
>>
>> Here is an extract:
>> class nexus::config(
>> ...
>>   $baseurl,
>>   $webapp_context_path = ''
>> ) {
>>   if ($webapp_context_path == '')
>>   {
>> $webapp_context_path = regsubst($baseurl, '^https?://[^/]+(/.*)', 
>> '\1')
>>
>
>$webapp_context_path = regsubst($baseurl, '^https?://[^/]+(/.*)', '\1')
>
> if ($extracted_url_path)
>> {
>>   $int_webapp_context_path = $extracted_url_path
>> }
>> else
>> {
>>   # in case we were given a $baseurl without the tailing "/"
>>   $int_webapp_context_path = '/'
>> }
>> notify{"extracted int_webapp_context_path 
>> \"${int_webapp_context_path}\" from url \"${baseurl}\"": }
>>   }
>>
>>   # use $int_webapp_context_path in the .erb template file
>>
>> My question - this use of $int_webapp_context_path and 
>> $extracted_url_path looks a bit shabby. But I didn't find a way to use 
>> conditional assignments to remove these intermediate variables and either:
>> 1. Assign the value I want to $webapp_context_path if it's not set yet.
>> 2. Or at least get rid of the $extracted_url_path
>>
>> Is there a nicer way to achieve the above?
>>
>> 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/-/rNRGRX2LrzkJ.
>> 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.
>>
>
>
>
> -- 
> GuruHub - Guzmán Brasó
> http://www.guruhub.com.uy - +59898674020
> Rivera 3565 - CP11400 - Montevideo, Uruguay
>
> 

-- 
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/-/sM14FzeDd3AJ.
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] anchor pattern and class containment status

[Dan Bode]

On Wed, Oct 3, 2012 at 2:57 PM, Tim Mooney  wrote:

>
> All-
>
> We're currently using puppet 2.7.14 on master and all clients.
>
> I thought I understood why 'anchor' is part of stdlib, but after
> re-reading both
>
> http://projects.puppetlabs.**com/projects/puppet/wiki/**
> Anchor_Pattern
>
> and
>
> 
> http://projects.puppetlabs.**com/issues/8040
>
> yesterday in preparation for trying to explain it to one of our team
> that's coming up to speed on puppet, now I'm not so certain I really
> understand.
>

yep, its probably the most confusing part of Puppet :(


>
> Specifically, is it necessary to use the anchor pattern if your module
> only defines resources and doesn't require or include any other classes?
>

you only have to use the anchor pattern when you need to depend on a class
that has classes defined in it. The example below does not need the anchor
pattern.


> For example, if I have
>
> class benthic {
>
>   group { 'squarepants':
> ensure => present,
> gid=> '9',
>   }
>
>   user { 'spongebob':
> ensure => present,
> uid=> '9',
> gid=> 'squarepants',
> home   => '/home/pineapple',
>   }
>
>   package { 'starfish':
> ensure => present,
>   }
>
>   file { '/etc/starfish.conf':
> ensure  => file,
> owner   => 'root',
> group   => 'squarepants',
> mode=> '0640',
> source  => 'puppet:///benthic/starfish.**conf',
> require => [
>   Package['starfish'],
>   User['spongebob'],
> ],
>   }
>
>   service { 'i_m_ready',
> ensure  => running,
> enable  => true,
> require => Package['starfish'],
>   }
> }
>
> Given that class, do I need to use anchors to ensure that the
> group/user/package/file/**service resource graph is correctly attached to
> (contained within) Class['benthic'], so that if some other module does
>
>   someresource { 'whatever':
> ...
> require => Class['benthic'],
>   }
>
> it just works, or, should I augment my class to also have
>
> anchor { 'benthic::begin': }
> anchor { 'benthic::end': }
>
> Anchor['benthic::begin'] -> Group['squarepants']
> Service['i_m_ready'] -> Anchor['benthic::end']
>
> ?
>
> My resources within the class are using explicit "require" when necessary
> and relying on puppet's automatic "require" logic in other places so they
> are correctly ordered, but it's not clear from the pattern document
> in the wiki or the ticket whether the issue is solely with nested
> classes, or whether it's important to also use the pattern for standard
> resources.
>
> Also, the ticket was with respect to 2.6.  I know this hasn't changed for
> 2.7, but is there anything in 3.0 that addresses the issue?
>
> Tim
> --
> Tim Mooney tim.moo...@ndsu.edu
> Enterprise Computing & Infrastructure  701-231-1076(Voice)
> Room 242-J6, IACC Building 701-231-8541 (Fax)
> North Dakota State University, Fargo, ND 58105-5164
>
> --
> 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 .
> 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 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: activerecord and puppet-3.0.0

[Eric Sorenson]

Thanks for reporting this, we're looking into it.  I've made a ticket for 
your issue: https://projects.puppetlabs.com/issues/16770

If you can do so, could you please run the puppet master with the '--trace' 
option ( either on the command line or with a `ARGV << '--trace'` line in 
config.ru if you are starting from passenger, and update the ticket with 
the output? Thanks!!

eric0

On Wednesday, October 3, 2012 2:26:42 AM UTC-7, Jonathan Gazeley wrote:
>
> Yesterday my puppetmaster and nodes got upgraded to puppet-3.0.0. 
>
> Since then, all puppet runs have been failing with this error: 
>
> Error: Could not retrieve catalog from remote server: Error 400 on 
> SERVER: Could not autoload puppet/indirector/node/active_record: 
> uninitialized constant ActiveRecord 
>
>
> My colleague and I have put a few hours into trying to work out what's 
> wrong. rubygem-activerecord-2.1.1-2.el6.noarch is installed from the 
> puppetlabs RPM repo. We've reinstalled all components but made no 
> progress. 
>
> I found this thread which seems to describe the same behaviour, but 
> there are no replies: 
>
> https://groups.google.com/forum/?fromgroups=#!topic/puppet-dev/D85TsZ70LKQ 
>
> Anyone got any ideas? 
>
> Thanks, 
> Jonathan 
>

-- 
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/-/KPQEZyWqezMJ.
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 3.0 with passenger

[Eric Sorenson]

Hi JM, this sounds like a real problem that was probably introduced with 
our code to start warning on certificates close to their expiration dates.

(#7962) 

https://github.com/puppetlabs/puppet/commit/12d81c7ef97167f1831143ff0037ae9a3970960d

I created a ticket for this 
issue: https://projects.puppetlabs.com/issues/16769

Can you please update the ticket with more information about your 
environment?

- what version of passenger?
- what version of apache?

Thanks!

On Tuesday, October 2, 2012 7:07:32 AM UTC-7, A_SAAS wrote:
>
> Hi everyone,
>
> I am trying to setup puppet 3.0 with passenger since this morning, it is a 
> really painful for me.
>
> I am using the directive:
> SSLOptions  +StdEnvVars +ExportCertData
>
>
> No problem, but when putting '+ExportCertData', I am unable to autosign or 
> revoke remotely any certificate I have the following error:
> info: Creating a new SSL key for linux-install.fqdn
> err: Could not request certificate: Error 400 on SERVER: header too long
> Exiting; failed to retrieve certificate and waitforcert is disabled
>
> When using only:
> SSLOptions  +StdEnvVars
>
> Everything works perfectly.
>
>
> So here is the apache configuration file:
> --
> # you probably want to tune these settings
> PassengerMaxPoolSize 12
> PassengerPoolIdleTime 1500
> # PassengerMaxRequests 1000
> PassengerStatThrottleRate 120
> RackAutoDetect Off
> RailsAutoDetect Off
> PassengerHighPerformance on
>
> Listen 8140
>
> 
> ServerName puppetmaster.fqdn
> ServerAlias puppetmaster
>
> ErrorLog /var/log/apache2/puppetmaster_error.log
> LogLevel warn
> SetEnvIf Remote_Addr "::1" dontlog
> CustomLog /var/log/apache2/puppetmaster_access.log combined 
> env=!dontlog
>
> SSLEngine on
> SSLProtocol -ALL +SSLv3 +TLSv1
> SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
>
> SSLCertificateFile 
>  /data/local/puppet/ssl/certs/puppetmaster.fqdn.pem
> SSLCertificateKeyFile   
> /data/local/puppet/ssl/private_keys/puppetmaster.fqdn.pem
> SSLCertificateChainFile /data/local/puppet/ssl/ca/ca_crt.pem
> SSLCACertificateFile/data/local/puppet/ssl/ca/ca_crt.pem
> # If Apache complains about invalid signatures on the CRL, you can 
> try disabling
> # CRL checking by commenting the next line, but this is not 
> recommended.
> SSLCARevocationFile /data/local/puppet/ssl/ca/ca_crl.pem
> SSLVerifyClient optional
> SSLVerifyDepth  1
> # The `ExportCertData` option is needed for agent certificate 
> expiration warnings
> SSLOptions  +StdEnvVars +ExportCertData
>
> # This header needs to be set if using a loadbalancer or proxy
> # RequestHeader unset X-Forwarded-For
>
> RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e
> RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
> RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e
>
> RackAutoDetect  On
>
> DocumentRoot /var/www/puppetmaster/public/
> RackBaseURI /
> 
> Options None
> AllowOverride None
> Order allow,deny
> allow from all
> 
> 
> --
>
>
> So any clue?
>
>
> Regards,
> JM
>
>

-- 
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/-/ap55DPU-uRsJ.
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] anchor pattern and class containment status

[Tim Mooney]

All-

We're currently using puppet 2.7.14 on master and all clients.

I thought I understood why 'anchor' is part of stdlib, but after
re-reading both

http://projects.puppetlabs.com/projects/puppet/wiki/Anchor_Pattern

and

http://projects.puppetlabs.com/issues/8040

yesterday in preparation for trying to explain it to one of our team
that's coming up to speed on puppet, now I'm not so certain I really
understand.

Specifically, is it necessary to use the anchor pattern if your module
only defines resources and doesn't require or include any other classes?

For example, if I have

class benthic {

  group { 'squarepants':
ensure => present,
gid=> '9',
  }

  user { 'spongebob':
ensure => present,
uid=> '9',
gid=> 'squarepants',
home   => '/home/pineapple',
  }

  package { 'starfish':
ensure => present,
  }

  file { '/etc/starfish.conf':
ensure  => file,
owner   => 'root',
group   => 'squarepants',
mode=> '0640',
source  => 'puppet:///benthic/starfish.conf',
require => [
  Package['starfish'],
  User['spongebob'],
],
  }

  service { 'i_m_ready',
ensure  => running,
enable  => true,
require => Package['starfish'],
  }
}

Given that class, do I need to use anchors to ensure that the
group/user/package/file/service resource graph is correctly attached to
(contained within) Class['benthic'], so that if some other module does

  someresource { 'whatever':
...
require => Class['benthic'],
  }

it just works, or, should I augment my class to also have

anchor { 'benthic::begin': }
anchor { 'benthic::end': }

Anchor['benthic::begin'] -> Group['squarepants']
Service['i_m_ready'] -> Anchor['benthic::end']

?

My resources within the class are using explicit "require" when necessary
and relying on puppet's automatic "require" logic in other places so 
they are correctly ordered, but it's not clear from the pattern document

in the wiki or the ticket whether the issue is solely with nested
classes, or whether it's important to also use the pattern for standard
resources.

Also, the ticket was with respect to 2.6.  I know this hasn't changed for
2.7, but is there anything in 3.0 that addresses the issue?

Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing & Infrastructure  701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164

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

[llowder]

On Wednesday, October 3, 2012 4:40:59 AM UTC-5, Mister Guru wrote:
>
>
> On 3 Oct 2012, at 03:35, Ryan Coleman wrote: 
>
> > Hello, 
> > 
> > If you weren't at PuppetConf or didn't catch my talk, here's a quick 
> > recap. I'm product owner for the Puppet Forge team which formed in 
> > July with 2 awesome engineers and an equally awesome designer. We're a 
> > team dedicated to the Forge and while ramping up, we've shipped three 
> > small improvements to the Forge that we hope you enjoy. 
>
> Good Morning Ryan! Nice to hear news about the puppet forge! Product owner 
> huh?? Hey guys, now we know who to bug when it come to the Forge! 
>
> > 
> > * Two lists were added to the homepage, highlighting recently active 
> > modules and contributors 
> > * An authors Gravatar is now displayed on each module page. 
> > * Today, the Forge will now retrieve information about GitHub issues 
> > and pull requests for a module for display on a module page. This has 
> > been automatically enabled for any module that lists GitHub as its 
> > 'Project Issue Tracker URL'. 
>
> I noticed this last night, it was great. I was stuck with a module I 
> downloaded - I looked it up on the forge, and I noticed a link to the git 
> page - I then realised the problem was ummm. me, using the module in 
> the not right way. Most useful, saved me bashing my keyboard against the 
> computer 
>
> > The team is just getting started. In the mean-time, we've been making 
> > improvements to our back-end services, user-testing new feature ideas 
> > and getting ready for the next wave of functionality. Our next 
> > features will focus on these two areas. A) Making it easy for you to 
> > contribute your module & B) Improve the information you have to make a 
> > decision about which module to use. 
> > 
> > As we develop and test ideas to address these goals, we want your 
> feedback! 
> > 
>
> Ah yes - Point B - How about ranking by downloads? I'm sure you can pull 
> the stats from Forge servers. I'm assuming people log into the forge to do 
> some background before running public code, for compliance, and in my case 
> to suppress paranoia :) 
>
> How about making the forge a bit more social - For example how about being 
> able to review a module, or write a comment about it on the forge? That 
> way, it's a bit easier for the author to get some feedback, and also for 
> others to get an idea how 'good' the module is. 
>
> That would come in useful when some modules depend on others, if I'm 
> trying to install module A, and A insists on B, C, and D - I'd rather read 
> up on others, who went live straight away without testing and are 
> complaining about their broken systems  Oh, I mean, I'd like to read 
> the reviews from other users praising the awesomeness of the forge. 
>
> Imagine that - In 6 months we could have modules writers competing against 
> each other - now that would be cool - Author rankings, (obviously Puppet 
> Labs Employees and modules excluded!) - and peer competition could only 
> lead to better code 
>

+1 on all these ideas, though I don't think that the "number of downloads" 
metric is really useful, a high number could just mean that it is easrlier 
in the list and still a crappy module..

But I do really like the idea of being able have some sort of community 
review on the modules, be that comments or even a simple up/down voting 
type system. 

>
> > Feel free to file bugs, features --anything really-- to our Redmine 
> > project: https://projects.puppetlabs.com/projects/module-site/issues 
> > Aside from that and this user list, you may always email me directly 
> > -- ry...@puppetlabs.com  -- or find me on #puppet as 
> ryancoleman. I'm 
> > always connected via ZNC so if you don't get an immediate response in 
> > IRC, know that I'll see your message and reply if I can. 
> > 
> > 
> > Finally, if you haven't tried out the Forge in a while, please give it 
> > another go. http://forge.puppetlabs.com -- Each day new content is 
> > added or updated and there's some truly awesome stuff amongst the 500+ 
> > Forge modules. There's also a blog-post series showcasing a new one 
> > each week. links.puppetlabs.com/motw 
> > 
> > Thanks for your time and for being an awesome community! 
> > 
> > --Ryan 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "Puppet Users" group. 
> > 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/-/Sa2VOCrA2nQJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 

Re: [Puppet Users] Introducing our new Community Manager - Dawn Foster

[Mister Guru]

On 2 October 2012 22:35, James Turnbull  wrote:

> Hi all
>
> I am thrilled to announce our new Community Manager: Dawn Foster. Dawn
> joins us from Intel where she managed several open source communities
> (I'm going to let her introduce herself in more detail in a later email).
>
> Dawn will initially be lurking and getting to know you all. She's going
> to have a focus on helping us communicate better, making the
> relationship between the community and Puppet Labs work better,
> extending our developer community, helping getting traction on tickets
> and features the community wants, sharing lots of cool metrics and
> generally working to make Puppet and the community more awesome.
>
> Please make Dawn welcome!
>
> Regards
>
> James
>
>
Welcome Dawn! Go Team 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.

Re: [Puppet Users] How to prevent puppet clients from updating to version 3?

[Mister Guru]

I agree, I learnt my lesson, but thankfully, it was in my testing
environment - I've been writing shitty basic puppet code, and I'd just
built a new puppet master, which was behaving very odd! That's when I
noticed it was V3 - Good job I don;t run updates in my master - It also hit
me that I don't actually manage the puppet client versions - I think I'm
going to have to add that to my default node definition.

On 3 October 2012 17:38, Jeffrey Watts  wrote:

> This update will serve to educate them that using ensure => latest for
> critical packages like this in a production environment is not a good idea.
>  :)
>
> Jeffrey.
>
>
> On Wed, Oct 3, 2012 at 9:36 AM, Mister Guru wrote:
>
>> I'm sending this email to start this thread, feel free to comment as
>> appropriate. I'm going to assume that it's going to take a while for most
>> people to actually realise that the puppet update may be giving them some
>> issues, so, comments and suggestion please!
>>
>>
>  --
> 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.
>

-- 
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] Re: activerecord and puppet-3.0.0

[Joe Hillenbrand]

btw, I'm running Ubuntu 10.04.1

-- 
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: Introducing our new Community Manager - Dawn Foster

[jcbollinger]

On Wednesday, October 3, 2012 12:58:02 PM UTC-5, Dawn Foster wrote:
>
>
> On Tue, Oct 2, 2012 at 2:35 PM, James Turnbull 
> 
> > wrote:
>
>> Hi all
>>
>> I am thrilled to announce our new Community Manager: Dawn Foster. Dawn
>> joins us from Intel where she managed several open source communities
>> (I'm going to let her introduce herself in more detail in a later email).
>>
>
> Thanks!
>
> I'm really excited to be joining Puppet Labs as the new Community Manager.
> My first day at Puppet Labs was at PuppetConf, which was both awesome
> and a bit surreal at the same time. I'm now in day 5, and I think I'm 
> already behind.
>


Welcome!  What a day to make your debut on the group, just as the biggest 
controversy in months seems to be breaking!

 

>
> Here is a little background to help you understand why I'm crazy enough to 
> want
> to be an open source community manager. I've been working with open source
> communities mostly full-time for the past 12 years, and I've been using 
> open
> source software since the early 90's. I've been a UNIX sys admin, a 
> programmer,
> a program manager, a market researcher and more.
>
> I've managed quite a few open source communities over the past few years, 
> including
> Tizen and MeeGo while working in Intel's Open Source Technology Center, 
> Openfire
> at Jive Software, etc. I also have a BS in Computer Science and an MBA, 
> which just
> proves that I'm one of those weird people who likes to take classes and 
> hang out at
> Universities.
>
> On a personal note, I ...
> * drink too much green tea
> * am a data / metrics geek
> * actually enjoy running and lifting weights
> * wrote 2 books: one on community and a vegan cookbook
> * read a lot of science fiction / fantasy (see my website for a list)
>  
>


It sounds like you'll fit in just fine with the rest of us geeks.  Don't 
worry, we're mostly harmless.

 

>
>> Dawn will initially be lurking and getting to know you all. She's going
>> to have a focus on helping us communicate better, making the
>> relationship between the community and Puppet Labs work better,
>> extending our developer community, helping getting traction on tickets
>> and features the community wants, sharing lots of cool metrics and
>> generally working to make Puppet and the community more awesome.
>>
>
> To avoid doing anything too stupid in my first month, I will spend most of
> my time lurking, learning and working on published community metrics.
>
> As I mentioned during PuppetConf, feel free to let me me know
> * what you love about the Puppet Community (I'll try not to screw it up)
> * what you don't like (I'll try to fix it)
> * when someone isn't responding (I can glare at the right person until
> we reply to pull requests, bugs or other neglected bits)
>
> You can find me here on the mailing lists or via:
> * email: da...@puppetlabs.com 
> * Twitter and other sites: @geekygirldawn
> * IRC: DawnFoster
> * Website: http://fastwonderblog.com
>
> Oh, and I can also be a little long-winded (fair warning).
>


Duly noted, and that's more warning than I ever gave


Cheers,

John

-- 
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/-/YZYFFA0ZEvgJ.
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] RHEL 5: Stuck on Puppet 2.7

[Stefan Heijmans]

How about switching to the gem version of passenger;
gem install passenger

-- 
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/-/A8FERt3aTbIJ.
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 2.7 v 3.0 in the PuppetLabs yum repo

[R.I.Pienaar]

- Original Message -
> From: "R.I.Pienaar" 
> To: puppet-users@googlegroups.com
> Sent: Wednesday, October 3, 2012 8:25:52 PM
> Subject: Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
> 
> 
> 
> - Original Message -
> > From: "jcbollinger" 
> > To: puppet-users@googlegroups.com
> > Sent: Wednesday, October 3, 2012 8:20:38 PM
> > Subject: Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum
> > repo
> > 
> > 
> > 
> > On Wednesday, October 3, 2012 9:24:01 AM UTC-5, R.I. Pienaar wrote:
> > 
> > 
> > 
> > - Original Message -
> > > From: "Rilindo Foster" < ril...@mac.com >
> > > To: puppet...@googlegroups.com
> > > Sent: Wednesday, October 3, 2012 3:02:58 PM
> > > Subject: Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs
> > > yum
> > > repo
> > > 
> > > I usually explicitly set the $puppetversion in my manifest for my
> > > environment. Furthermore, I have my own mirror copied from puppet
> > > labs repo and install it from that location instead. That way, I
> > > have control of what I push out and only update when I know that
> > > the
> > > new version is sound.
> > > 
> > > So I am not sure what the hubbub is all about. If you are not
> > > controlling what you push out, don't be surprised when something
> > > breaks.
> > 
> > +100, people seem to be expecting the rest of the world to maintain
> > a controlled environment simply because they don't?
> > 
> > Do you really trust a random third party as the source of your
> > packages?
> > 
> > What if there is an outage at one of these 3rd party package
> > providers
> > and you cannot build new machines? How do you explain that on the
> > day
> > that you suddenly need to scale your infrastructure due to a
> > critical
> > request or failure?
> > 
> > You have to build local repo mirrors and you have to be able to
> > recover
> > from a disaster or simply provision new infrastructure based on
> > your
> > own processes and systems you influence, if you do not you have
> > bigger
> > problems than what version of Puppet is on some 3rd party repo.
> > 
> > 
> > Of course it is ultimately my responsibility which versions of
> > which
> > packages get installed on my systems, from which repositories. Of
> > course it is in my best interest to ensure package availability if
> > that's important to me. Indeed, I do maintain local mirrors of the
> > repositories I depend on. All of that is beside the point.
> > 
> > Personally, I expect package repository managers to make a best
> > effort at maintaining a managed environment because I perceive that
> > as an implicit promise that repository management makes to clients
> > by virtue of providing a public repository in the first place.
> > Whether that perception is reasonable is also not the point, but
> > the
> > fact that it seems to be shared by a a substantial number of users
> > should certainly trigger an alarm at PL HQ.
> > 
> > 
> > John
> > 
> > 
> > 
> > --
> > 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/-/NnjAVc7q3QUJ .
> > 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.
> > 
> > 
> > 
> > On Wednesday, October 3, 2012 9:24:01 AM UTC-5, R.I. Pienaar wrote:
> > >
> > >
> > >
> > > - Original Message -
> > > > From: "Rilindo Foster" >
> > > > To: puppet...@googlegroups.com 
> > > > Sent: Wednesday, October 3, 2012 3:02:58 PM
> > > > Subject: Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs
> > > > yum repo
> > > > 
> > > > I usually explicitly set the $puppetversion in my manifest for
> > > > my
> > > > environment. Furthermore, I have my own mirror copied from
> > > > puppet
> > > > labs repo and install it from that location instead. That way,
> > > > I
> > > > have control of what I push out and only update when I know
> > > > that
> > > > the
> > > > new version is sound.
> > > > 
> > > > So I am not sure what the hubbub is all about. If you are not
> > > > controlling what you push out, don't be surprised when
> > > > something
> > > > breaks.
> > >
> > > +100, people seem to be expecting the rest of the world to
> > > maintain
> > > a controlled environment simply because they don't?
> > >
> > > Do you really trust a random third party as the source of your
> > > packages?
> > >
> > > What if there is an outage at one of these 3rd party package
> > > providers
> > > and you cannot build new machines? How do you explain that on the
> > > day
> > > that you suddenly need to scale your infrastructure due to a
> > > critical
> > > request or failure?
> > >
> > > You have to build local repo mirrors and you have to be able to
> > > recover
> > > from a disaster or simply provision 

Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo

[R.I.Pienaar]

- Original Message -
> From: "jcbollinger" 
> To: puppet-users@googlegroups.com
> Sent: Wednesday, October 3, 2012 8:20:38 PM
> Subject: Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
> 
> 
> 
> On Wednesday, October 3, 2012 9:24:01 AM UTC-5, R.I. Pienaar wrote:
> 
> 
> 
> - Original Message -
> > From: "Rilindo Foster" < ril...@mac.com >
> > To: puppet...@googlegroups.com
> > Sent: Wednesday, October 3, 2012 3:02:58 PM
> > Subject: Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum
> > repo
> > 
> > I usually explicitly set the $puppetversion in my manifest for my
> > environment. Furthermore, I have my own mirror copied from puppet
> > labs repo and install it from that location instead. That way, I
> > have control of what I push out and only update when I know that
> > the
> > new version is sound.
> > 
> > So I am not sure what the hubbub is all about. If you are not
> > controlling what you push out, don't be surprised when something
> > breaks.
> 
> +100, people seem to be expecting the rest of the world to maintain
> a controlled environment simply because they don't?
> 
> Do you really trust a random third party as the source of your
> packages?
> 
> What if there is an outage at one of these 3rd party package
> providers
> and you cannot build new machines? How do you explain that on the day
> that you suddenly need to scale your infrastructure due to a critical
> request or failure?
> 
> You have to build local repo mirrors and you have to be able to
> recover
> from a disaster or simply provision new infrastructure based on your
> own processes and systems you influence, if you do not you have
> bigger
> problems than what version of Puppet is on some 3rd party repo.
> 
> 
> Of course it is ultimately my responsibility which versions of which
> packages get installed on my systems, from which repositories. Of
> course it is in my best interest to ensure package availability if
> that's important to me. Indeed, I do maintain local mirrors of the
> repositories I depend on. All of that is beside the point.
> 
> Personally, I expect package repository managers to make a best
> effort at maintaining a managed environment because I perceive that
> as an implicit promise that repository management makes to clients
> by virtue of providing a public repository in the first place.
> Whether that perception is reasonable is also not the point, but the
> fact that it seems to be shared by a a substantial number of users
> should certainly trigger an alarm at PL HQ.
> 
> 
> John
> 
> 
> 
> --
> 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/-/NnjAVc7q3QUJ .
> 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.
> 
> 
> 
> On Wednesday, October 3, 2012 9:24:01 AM UTC-5, R.I. Pienaar wrote:
> >
> >
> >
> > - Original Message -
> > > From: "Rilindo Foster" >
> > > To: puppet...@googlegroups.com 
> > > Sent: Wednesday, October 3, 2012 3:02:58 PM
> > > Subject: Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs
> > > yum repo
> > > 
> > > I usually explicitly set the $puppetversion in my manifest for my
> > > environment. Furthermore, I have my own mirror copied from puppet
> > > labs repo and install it from that location instead. That way, I
> > > have control of what I push out and only update when I know that
> > > the
> > > new version is sound.
> > > 
> > > So I am not sure what the hubbub is all about. If you are not
> > > controlling what you push out, don't be surprised when something
> > > breaks.
> >
> > +100, people seem to be expecting the rest of the world to maintain
> > a controlled environment simply because they don't?
> >
> > Do you really trust a random third party as the source of your
> > packages?
> >
> > What if there is an outage at one of these 3rd party package
> > providers
> > and you cannot build new machines? How do you explain that on the
> > day
> > that you suddenly need to scale your infrastructure due to a
> > critical
> > request or failure?
> >
> > You have to build local repo mirrors and you have to be able to
> > recover
> > from a disaster or simply provision new infrastructure based on
> > your
> > own processes and systems you influence, if you do not you have
> > bigger
> > problems than what version of Puppet is on some 3rd party repo.
> >
> >
> Of course it is ultimately my responsibility which versions of which
> packages get installed on my systems, from which repositories.  Of
> course
> it is in my best interest to ensure package availability if that's
> important to me.  Indeed, I do maintain local mirrors of the
> repositories I
> depend on.  All of that is beside the point

Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo

[jcbollinger]

On Wednesday, October 3, 2012 9:24:01 AM UTC-5, R.I. Pienaar wrote:
>
>
>
> - Original Message - 
> > From: "Rilindo Foster" > 
> > To: puppet...@googlegroups.com  
> > Sent: Wednesday, October 3, 2012 3:02:58 PM 
> > Subject: Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo 
> > 
> > I usually explicitly set the $puppetversion in my manifest for my 
> > environment. Furthermore, I have my own mirror copied from puppet 
> > labs repo and install it from that location instead. That way, I 
> > have control of what I push out and only update when I know that the 
> > new version is sound. 
> > 
> > So I am not sure what the hubbub is all about. If you are not 
> > controlling what you push out, don't be surprised when something 
> > breaks. 
>
> +100, people seem to be expecting the rest of the world to maintain 
> a controlled environment simply because they don't? 
>
> Do you really trust a random third party as the source of your packages? 
>
> What if there is an outage at one of these 3rd party package providers 
> and you cannot build new machines? How do you explain that on the day 
> that you suddenly need to scale your infrastructure due to a critical 
> request or failure? 
>
> You have to build local repo mirrors and you have to be able to recover 
> from a disaster or simply provision new infrastructure based on your 
> own processes and systems you influence, if you do not you have bigger 
> problems than what version of Puppet is on some 3rd party repo. 
>
>
Of course it is ultimately my responsibility which versions of which 
packages get installed on my systems, from which repositories.  Of course 
it is in my best interest to ensure package availability if that's 
important to me.  Indeed, I do maintain local mirrors of the repositories I 
depend on.  All of that is beside the point.

Personally, I expect package repository managers to make a best effort at 
maintaining a managed environment *because I perceive that as an implicit 
promise that repository management makes to clients* by virtue of providing 
a public repository in the first place.  Whether that perception is 
reasonable is also not the point, but the fact that it seems to be shared 
by a a substantial number of users should certainly trigger an alarm at PL 
HQ.


John

-- 
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/-/NnjAVc7q3QUJ.
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 Autosign

[Rilindo Foster]

As Steven said, it is normal for a puppet-master not to allow a re-imaged 
machine until the certificate is re-generated. I will point out that depending 
on the your environment, it may be a security risk to any client to 
authenticate against the puppet-master. 

For my environment, I explicitly disable autosign and manually sign most 
machines (I may re-enable it once I move Puppet into a cluster that allow me to 
explicitly allow/disallow access at a layer 4 level). it takes some work, but I 
am not building hundreds of machines a day (yet). Even then, you can mass sign 
the machines with:

puppet cert sign --all

That said, you can pre sign the certs with:

puppet cert --generate client.fqdn

and then integrate as part of your build process. That way, if you need to 
rebuild the machines, you can just use the same cert without having to re-sign 
the client again.

- Rilindo

On Oct 3, 2012, at 11:18 AM, RedJinnee  wrote:

> Hi, 
> I have upgraded my puppet master to 2.7 with autosign enabled, it works 
> great, the only issue I have it that when I re-image any client machine (blow 
> away /var/lib/puppet ) folder and try to run puppet again, it fails to 
> authenticate. 
> The solution will be to (revoke + clean) the certificate of the client from 
> the puppetmaster then remove /var/lib/puppet from client and re-run puppetd 
> on client. 
> 
> Is this a normal behaviour from puppet 2.7 ? or should the client look up if 
> the master has an old certificate and just use it, rather than asking for new 
> one.
> 
> an insight will be helpful.
> 
> /etc/puppet$ cat autosign.conf 
> *.localdomain.local
> 
> 
> -- 
> 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/-/81blhmqfeSsJ.
> 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.

-- 
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: activerecord and puppet-3.0.0

[llowder]

Comments inline.

On Wednesday, October 3, 2012 1:55:35 PM UTC-5, Joehillen wrote:
>
> Same issue here. I'd love to get some info on this.
>
> On Wednesday, October 3, 2012 2:26:42 AM UTC-7, Jonathan Gazeley wrote:
>>
>> Yesterday my puppetmaster and nodes got upgraded to puppet-3.0.0. 
>>
>> Since then, all puppet runs have been failing with this error: 
>>
>> Error: Could not retrieve catalog from remote server: Error 400 on 
>> SERVER: Could not autoload puppet/indirector/node/active_record: 
>> uninitialized constant ActiveRecord 
>>
>>
>> My colleague and I have put a few hours into trying to work out what's 
>> wrong. rubygem-activerecord-2.1.1-2.el6.noarch is installed from the 
>> puppetlabs RPM repo. We've reinstalled all components but made no 
>> progress. 
>>
>> I found this thread which seems to describe the same behaviour, but 
>> there are no replies: 
>>
>> https://groups.google.com/forum/?fromgroups=#!topic/puppet-dev/D85TsZ70LKQ 
>>
>> Anyone got any ideas? 
>>
>>
I can't find the sources now, but I vaguely remember seeing something 
related to this and they had to downgrade their activerecord install. But 
unfortunately, I do not remember the specifics.

 

> Thanks, 
>> Jonathan 
>>
>

-- 
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/-/w-6uBm_Up4wJ.
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] How to prevent puppet clients from updating to version 3?

[Mister Guru]

I think a bit of learning, and burned fingers happened today - I'm
searching my manifests for ensure => latest and getting rid of it!

On 3 October 2012 19:14, Dan White  wrote:

> My $0.02:
>
> I appended the following to  /etc/yum.conf  (RHEL 5 server)
>
> exclude=puppet puppet-server ruby*
>
> - Original Message -
> I'm sending this email to start this thread, feel free to comment as
> appropriate. I'm going to assume that it's going to take a while for most
> people to actually realise that the puppet update may be giving them some
> issues, so, comments and suggestion please!
>
>
> --
> “Sometimes I think the surest sign that intelligent life exists elsewhere
> in the universe is that none of it has tried to contact us.”
> Bill Waterson (Calvin & Hobbes)
>
> --
> 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.
>
>

-- 
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: activerecord and puppet-3.0.0

[Joehillen]

Same issue here. I'd love to get some info on this.

On Wednesday, October 3, 2012 2:26:42 AM UTC-7, Jonathan Gazeley wrote:
>
> Yesterday my puppetmaster and nodes got upgraded to puppet-3.0.0. 
>
> Since then, all puppet runs have been failing with this error: 
>
> Error: Could not retrieve catalog from remote server: Error 400 on 
> SERVER: Could not autoload puppet/indirector/node/active_record: 
> uninitialized constant ActiveRecord 
>
>
> My colleague and I have put a few hours into trying to work out what's 
> wrong. rubygem-activerecord-2.1.1-2.el6.noarch is installed from the 
> puppetlabs RPM repo. We've reinstalled all components but made no 
> progress. 
>
> I found this thread which seems to describe the same behaviour, but 
> there are no replies: 
>
> https://groups.google.com/forum/?fromgroups=#!topic/puppet-dev/D85TsZ70LKQ 
>
> Anyone got any ideas? 
>
> Thanks, 
> Jonathan 
>

-- 
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/-/kN4FhBYFBegJ.
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 2.7 v 3.0 in the PuppetLabs yum repo

[Aaron Russo]

full disclosure: I don't use the puppetlabs repos. Below are just some
observations and concerns I wanted to voice.

On Tue, Oct 2, 2012 at 5:36 PM, Michael Stahnke wrote:

> On Tue, Oct 2, 2012 at 1:30 PM, Jeff McCune  wrote:
> > On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg 
> wrote:
> >> I am using CentOS 6 with the PuppetLabs yum repo from
> >> http://yum.puppetlabs.com
> >>
> >> I noticed that today version 3 is available on the repo, so of course,
> an
> >> upgrade to Puppet is available.
> >
> > Yes, this major version update went live on Monday.  There are a
> > number of breaking-changes between 2.7 and 3.0 which are described at:
> > http://links.puppetlabs.com/telly_breaking_changes
> >
> >> Ideally, it would have been better if v3 had a different distribution
> name,
> >> so that systems with v2.7.x are not upgraded (especially if there will
> be
> >> future releases if v2.7).
>
> We sent out several notices about this prior to doing it. The Puppet
> Labs repositories are designed to be the place you get the latest
> software from Puppet Labs.  This was a conscious choice.
>

Where was this announced? On the list?  Not everyone who follows the
official install instructions (
http://docs.puppetlabs.com/guides/installation.html) is cool enough to join
the mailing list :-P

The real problem, IMHO, is there is no clear policy regarding the
PuppetLabs repo (or at least none I could find easily).  "These repos
contain the latest available packages for Puppet, ..." is somewhat
ambiguous (or maybe its just me) -- does that mean the latest of the
current release or the latest version overall? We now know it's the latter.

To that affect, I think it would benefit the community if there was a
clearly defined policy with respect to the repos, much like EPEL does (
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies).  The closest
thing I found was (
http://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html),
which I don't think is adequate to describe the intention of the repos.

Second-to-lastly, my biggest concern with this problem in its current
state, is the potential fallout of users (and the people they influence)
who now find puppet to be "too volatile" or "too unstable", and decide to
look for alternatives.  I won't argue against that these users should have
had better practices to prevent this, because it doesn't change the fact
that these people are still put off.

Personally, I would have liked to see a separate repo for each version of
puppet (so that users of 2.6.x, 2.7.x and 3.0.x could continue to receive
the latest and greatest for their version).  But I also don't have to
manage the thing, so I respect that it didn't turn out this way.  However,
I think the method of communicating to the community can be improved to
compensate.

And finally, thanks for all the work guys.  Puppet is a fantastic product,
and has a fantastic community behind it.

Cheers,
Aaron Russo


>
> >
> > Could you please file an issue (with impact data) about the
> > distribution name issue.  I believe we considered doing what you
> > describe, but decided against it.  I don't know the reasons off the
> > top of my head though, an issue will give us a clear place to track
> > the request, the impact it has on you and your organization, and the
> > decision we come to (or have already come to).
> >
> >> I am concerned about things breaking. So is there a document detailing
> >> incompatibilities? Will there be future 2.7 releases?
> There will be.  I'd imagine you'll see activity slow on it though.
>
> >
> > There will be future releases of 2.7.  We will continue to fix bugs in
> > the 2.7 series, but we are intending to avoid adding any new features
> > or make any large changes to the behavior of Puppet 2.7.
> >
> > Hope this helps,
> > -Jeff
> >
> > --
> > 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.
> >
>
> --
> 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.
>
>

-- 
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] Puppet warning error messages after upgrading to version 3

[Brent Clark]

Good day

I seem to have a problem whereby, I get the following message when I do 
a puppet run.


Warning: Unable to fetch my node definition, but the agent run will 
continue:
Warning: Could not intern from pson: source '"#in PSON!


I did google and I came across this for the second error message.

http://projects.puppetlabs.com/issues/3160#note-7

I did make the mistake of first upgrading the client to version 3 on one 
of my test hosts. But then after seeing the above message, I upgraded 
the puppet master.

But the above error message is still present.

If someone could shed some light, it would gratefully be appreciated.

Kind regards
Brent Clark

--
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] How to prevent puppet clients from updating to version 3?

[Dan White]

My $0.02:

I appended the following to  /etc/yum.conf  (RHEL 5 server)

exclude=puppet puppet-server ruby*

- Original Message -
I'm sending this email to start this thread, feel free to comment as 
appropriate. I'm going to assume that it's going to take a while for most 
people to actually realise that the puppet update may be giving them some 
issues, so, comments and suggestion please! 


-- 
“Sometimes I think the surest sign that intelligent life exists elsewhere in 
the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)

-- 
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] How to prevent puppet clients from updating to version 3?

[Aaron Grewell]

If you really want control over this you should build your own local repo
mirror. That way you can be absolutely certain of what your systems will
have access to. RHEL and friends come with all the tools to do this so it's
not a major undertaking.
On Oct 3, 2012 7:37 AM, "Mister Guru"  wrote:

> I'm sending this email to start this thread, feel free to comment as
> appropriate. I'm going to assume that it's going to take a while for most
> people to actually realise that the puppet update may be giving them some
> issues, so, comments and suggestion please!
>
> --
> 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.
>

-- 
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: Introducing our new Community Manager - Dawn Foster

[Dawn Foster]

On Tue, Oct 2, 2012 at 2:35 PM, James Turnbull  wrote:

> Hi all
>
> I am thrilled to announce our new Community Manager: Dawn Foster. Dawn
> joins us from Intel where she managed several open source communities
> (I'm going to let her introduce herself in more detail in a later email).
>

Thanks!

I'm really excited to be joining Puppet Labs as the new Community Manager.
My first day at Puppet Labs was at PuppetConf, which was both awesome
and a bit surreal at the same time. I'm now in day 5, and I think I'm
already behind.

Here is a little background to help you understand why I'm crazy enough to
want
to be an open source community manager. I've been working with open source
communities mostly full-time for the past 12 years, and I've been using open
source software since the early 90's. I've been a UNIX sys admin, a
programmer,
a program manager, a market researcher and more.

I've managed quite a few open source communities over the past few years,
including
Tizen and MeeGo while working in Intel's Open Source Technology Center,
Openfire
at Jive Software, etc. I also have a BS in Computer Science and an MBA,
which just
proves that I'm one of those weird people who likes to take classes and
hang out at
Universities.

On a personal note, I ...
* drink too much green tea
* am a data / metrics geek
* actually enjoy running and lifting weights
* wrote 2 books: one on community and a vegan cookbook
* read a lot of science fiction / fantasy (see my website for a list)


>
> Dawn will initially be lurking and getting to know you all. She's going
> to have a focus on helping us communicate better, making the
> relationship between the community and Puppet Labs work better,
> extending our developer community, helping getting traction on tickets
> and features the community wants, sharing lots of cool metrics and
> generally working to make Puppet and the community more awesome.
>

To avoid doing anything too stupid in my first month, I will spend most of
my time lurking, learning and working on published community metrics.

As I mentioned during PuppetConf, feel free to let me me know
* what you love about the Puppet Community (I'll try not to screw it up)
* what you don't like (I'll try to fix it)
* when someone isn't responding (I can glare at the right person until
we reply to pull requests, bugs or other neglected bits)

You can find me here on the mailing lists or via:
* email: d...@puppetlabs.com
* Twitter and other sites: @geekygirldawn
* IRC: DawnFoster
* Website: http://fastwonderblog.com

Oh, and I can also be a little long-winded (fair warning).

Dawn

-- 
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, uWSGI and nginx

[Juan José Presa Rodal]

Ok, I was missing the following line in the nginx location statement:

uwsgi_modifier1 7;


Now seems that works correctly (and very fast). When thoroughly adjusted I 
will publish the complete configuration. Thanks again.

El miércoles, 3 de octubre de 2012 16:40:28 UTC+2, Juan José Presa Rodal 
escribió:
>
> Hi, I'm trying to configure distributed Puppet with uWSGI server 
> application without success.
>
> I'm configuring NGINX in a similar way that with Unicorn or Passenger and 
> also inspiring in this blog entry: 
> http://www.prontab.com/2011/01/this-page-should-outline-how-to-set-up.html
>
> ¿Anybody has experience with this full-featured application container? 
> 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/-/aNxqQGyXQfUJ.
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: Need help with dashboad configuration..

[Lunixer]

It does take some reading.

The main doc page[1] has information plus several resources[2] here and 
there.
Follow the instructions here[3] to install the puppetlabs repo so you can 
use yum.
When you do "yum install puppet-dashboard", it creates the unix account. Do 
"grep puppet /etc/passwd" and you'll see the account there.

[1] http://docs.puppetlabs.com/dashboard/manual/1.2/bootstrapping.html
[2] http://www.how2centos.com/installing-puppet-dashboard-on-centos-5-5/
[3] http://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html

LL


http://docs.puppetlabs.com/dashboard/manual/1.2/bootstrapping.html

On Wednesday, October 3, 2012 4:10:20 AM UTC-7, Rajeev Iyer wrote:
>
> Hi,
>
>   I am new to this.
>
> Can someone lead me to a step by step configuration for dashboard. The 
> ones on the web is too confusing.
> Like, it says we need to have an entry for puppet-dashboard in 
> /etc/passwd. So how does that look like?
>
> Rajeev
>
>

-- 
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/-/HXm6GtfqG4cJ.
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 2.7 v 3.0 in the PuppetLabs yum repo

[Jeffrey Watts]

+1

On Wed, Oct 3, 2012 at 9:02 AM, Rilindo Foster  wrote:

> I usually explicitly set the $puppetversion in my manifest for my
> environment. Furthermore, I have my own mirror copied from puppet labs repo
> and install it from that location instead. That way, I have control of what
> I push out and only update when I know that the new version is sound.
>
> So I am not sure what the hubbub is all about. If you are not controlling
> what you push out, don't be surprised when something breaks.
>

-- 
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] Re: Puppet 2.7 v 3.0 in the PuppetLabs yum repo

[Jeff McCune]

On Wed, Oct 3, 2012 at 8:32 AM, Robert Rothenberg  wrote:
> BTW, I have reported this at https://projects.puppetlabs.com/issues/16729

Thank you for filing this ticket.  We're having a hard time
understanding how many people were actually negatively affected by
this change.  If you were affected by the backwards incompatible
release to the main package repositories, could you please update
ticket 16729 with any impact data you have and also vote up the
ticket?

The Puppet core team is currently using up-votes as a rough guide to
how many users are affected by particular issues.

Finally watching the ticket will help ensure you get up to date
information as it becomes available.

Thanks,
-Jeff McCune

-- 
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] How to prevent puppet clients from updating to version 3?

[Jeffrey Watts]

This update will serve to educate them that using ensure => latest for
critical packages like this in a production environment is not a good idea.
 :)

Jeffrey.

On Wed, Oct 3, 2012 at 9:36 AM, Mister Guru  wrote:

> I'm sending this email to start this thread, feel free to comment as
> appropriate. I'm going to assume that it's going to take a while for most
> people to actually realise that the puppet update may be giving them some
> issues, so, comments and suggestion please!
>
>

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

[Steven Nemetz]

This is normal.
New system will always generate a new cert.

You only need to delete /var/lib/puppet/ssl on the client and remove the cert 
on the master "puppet cert clean "
There has been some discussions on ways to automate this. Should be able to 
find them in the archives.

Steven

Date: Wed, 3 Oct 2012 09:18:49 -0700
From: redjin...@gmail.com
To: puppet-users@googlegroups.com
Subject: [Puppet Users] Puppet Autosign

Hi, I have upgraded my puppet master to 2.7 with autosign enabled, it works 
great, the only issue I have it that when I re-image any client machine (blow 
away /var/lib/puppet ) folder and try to run puppet again, it fails to 
authenticate. The solution will be to (revoke + clean) the certificate of the 
client from the puppetmaster then remove /var/lib/puppet from client and re-run 
puppetd on client. 
Is this a normal behaviour from puppet 2.7 ? or should the client look up if 
the master has an old certificate and just use it, rather than asking for new 
one.
an insight will be helpful.
/etc/puppet$ cat autosign.conf *.localdomain.local




-- 

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/-/81blhmqfeSsJ.
 
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.
  

-- 
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] Puppet Autosign

[RedJinnee]

Hi, 
I have upgraded my puppet master to 2.7 with autosign enabled, it works 
great, the only issue I have it that when I re-image any client machine 
(blow away /var/lib/puppet ) folder and try to run puppet again, it fails 
to authenticate. 
The solution will be to (revoke + clean) the certificate of the client from 
the puppetmaster then remove /var/lib/puppet from client and re-run puppetd 
on client. 

Is this a normal behaviour from puppet 2.7 ? or should the client look up 
if the master has an old certificate and just use it, rather than asking 
for new one.

an insight will be helpful.

/etc/puppet$ cat autosign.conf 
*.localdomain.local

-- 
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/-/81blhmqfeSsJ.
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] Re: Puppet 2.7 v 3.0 in the PuppetLabs yum repo

[James Turnbull]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robert Rothenberg wrote:
> BTW, I have reported this at https://projects.puppetlabs.com/issues/16729
> 

So taking my Puppet Labs hat off and speaking purely as a sysadmin ... I
guess I have some commentary on what I would consider best practice.

1. I never ensure => latest to a repo where I don't control the repo
content.
2. I always mirror the packages that are mission-critical to a local
repo where I can control the versions.
3. Where possible I manage versions by pinning not by relaying on the
multiple naming hacks distros use.

Regards

James

- -- 
Author of:
* Pro Puppet (http://tinyurl.com/ppuppet)
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQbF5/AAoJECFa/lDkFHAyTEQIAIZyCeLwt90Nh5wu/ynYLJkR
stMQM+SAXNwAsqWMXW1RHAOxa/GAtopJmMJKePduGT0m8adVbZp7qGcOlx3emNI2
FSWoW9dBCU5ncWj0aU/TxFUzbhfKzf89zzUu908SYMMqYCfNdgM2m5gAxGXCrjhT
wnu9K9Ls8Kv0LsawYylVuThaZmLVGhBH+DuSVmiGHir63h0sGDDazbxyHUMTlTMC
nBerxcEF6+2uxPuZgxQaSvon2ZpM7dkSjBOhZzI5S2WjOamnlxnjd7Hc/npe2xsI
wfKS40sq40pKifo35eDhwGp6svBPx/tyZUCC+Ukfxkyrrmn58eFQNTaPnsuB0SE=
=pnk6
-END PGP SIGNATURE-

-- 
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] New Puppet/Linux opening

[Jim Dakin]

At Rapid7 in Boston we are searching for another Linux System Admin with a 
knowledge of Puppet. We are growing and have rather large infrastructure 
buildouts ready to go. Any interest?  Contact me via www.rapid7.com

Jim

-- 
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 2.7 v 3.0 in the PuppetLabs yum repo

[Robert Rothenberg]

BTW, I have reported this at https://projects.puppetlabs.com/issues/16729

-- 
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/-/0mmf1DmfyDIJ.
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 2.7 v 3.0 in the PuppetLabs yum repo

[Robert Rothenberg]

On Wednesday, October 3, 2012 3:51:28 PM UTC+1, Chad Huneycutt wrote:
>
> I agree that folks should manage their repos, but I wanted to throw in 
> a couple of thoughts: 
>
> * The package name hacks (eg puppet3) are usually done by 
> distributions to allow multiple versions of software to co-exist. 
>

No. The puppet2 and puppet3 packages can be marked as mutually exclusive.
 

>
> * Take a look at the yum versionlock plugin.  My life has been much 
> simpler since I deployed it.  For a while I was "exclude"ing puppet 
> and friends in yum.conf, but that was a real pain.  The versionlock 
> plugin "pins" a package at the version  you want, and then you can 
> update when ready. 
>

The problem I have is in deploying new VMs with Cobbler.  The versionlock 
plugin does not work for deploying new machines, and unfortunately, 
Cobbler's package exclusion doesn't work either.


 

> - Chad 
>
> On Wed, Oct 3, 2012 at 9:16 AM, jcbollinger 
> > 
> wrote: 
> > 
> > 
> > On Tuesday, October 2, 2012 7:36:22 PM UTC-5, Michael Stanhke wrote: 
> >> 
> >> On Tue, Oct 2, 2012 at 1:30 PM, Jeff McCune  
> wrote: 
> >> > On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg  
> >> > wrote: 
> >> >> I am using CentOS 6 with the PuppetLabs yum repo from 
> >> >> http://yum.puppetlabs.com 
> >> >> 
> >> >> I noticed that today version 3 is available on the repo, so of 
> course, 
> >> >> an 
> >> >> upgrade to Puppet is available. 
> >> > 
> >> > Yes, this major version update went live on Monday.  There are a 
> >> > number of breaking-changes between 2.7 and 3.0 which are described 
> at: 
> >> > http://links.puppetlabs.com/telly_breaking_changes 
> >> > 
> >> >> Ideally, it would have been better if v3 had a different 
> distribution 
> >> >> name, 
> >> >> so that systems with v2.7.x are not upgraded (especially if there 
> will 
> >> >> be 
> >> >> future releases if v2.7). 
> >> 
> >> We sent out several notices about this prior to doing it. The Puppet 
> >> Labs repositories are designed to be the place you get the latest 
> >> software from Puppet Labs.  This was a conscious choice. 
> >> 
> >> > 
> >> > Could you please file an issue (with impact data) about the 
> >> > distribution name issue.  I believe we considered doing what you 
> >> > describe, but decided against it.  I don't know the reasons off the 
> >> > top of my head though, an issue will give us a clear place to track 
> >> > the request, the impact it has on you and your organization, and the 
> >> > decision we come to (or have already come to). 
> >> > 
> >> >> I am concerned about things breaking. So is there a document 
> detailing 
> >> >> incompatibilities? Will there be future 2.7 releases? 
> >> There will be.  I'd imagine you'll see activity slow on it though. 
> >> 
> >> > 
> >> > There will be future releases of 2.7.  We will continue to fix bugs 
> in 
> >> > the 2.7 series, but we are intending to avoid adding any new features 
> >> > or make any large changes to the behavior of Puppet 2.7. 
> > 
> > 
> > I am not directly affected by this issue, but I agree with those 
> complaining 
> > that it was unwise, or at least inhospitable for PL to release Puppet 3 
> into 
> > its repositories in this way, especially considering that PL intends to 
> > continue with maintenance releases in the 2.7 series.  It is tantamount 
> to a 
> > recommendation for all users to upgrade to the new line immediately, and 
> > considering the number of breaking changes, I cannot believe that that 
> was 
> > intended. 
> > 
> > The customary way to handle dual lines of packages is to give one line a 
> > different name, for example "puppet3-*" instead of plain "puppet-*". 
> > Failing that, it is essential that the package name for the 2.7 series 
> be 
> > changed, else the PL repository will be near-useless to people who want 
> to 
> > stay at 2.7 for the time being.  If that's the plan then the first 
> > "puppet2-*" packages should have been released at the same time that the 
> > mainline packages were updated to v 3.0. 
> > 
> > Alternatively, PL could set up a separate repository for the Puppet 2 
> > maintenance releases. 
> > 
> > Distinguishing the lines only by their version numbers simply isn't 
> useful, 
> > and dropping v3 packages with their breaking changes into the same 
> > repository with v2 will cause breakage for users.  PL, I urge you to 
> > reconsider.  Soon. 
> > 
> > 
> > John 
> > 
> > -- 
> > 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/-/AG4SVCmBV1cJ. 
> > 
> > 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. 
>
>
>
> -- 
> Chad M. Huneycutt 
>

-- 
You received this 

RE: [Puppet Users] hiera and fallback to params?

[Steven Nemetz]

Take a look at Example42's Next Gen modules on github. They all do what you're 
asking about and a bit more

There is a routine defined within the puppi module, that the rest of the 
modules use to lookup variable values. Defaults are assigned in params.pp which 
the main class inherits and they are defined as parameters. So, the variable 
can be set via a default, parameter, or hiera. This makes it very flexible.

Steven

> Date: Wed, 3 Oct 2012 17:02:45 +0200
> From: jso...@srce.hr
> To: puppet-users@googlegroups.com
> Subject: [Puppet Users] hiera and fallback to params?
> 
> Hi.
> 
> I would like to setup my manifests, so that variable data is gathered
> from hiera, if it's available there, and if not, then to fallback on
> some predefined value...
> 
> Something like this:
> 
> $my_var = hiera('myvar') || 'base_value'
> 
> So if there is no myvar in hiera data, that manifest falls back to
> base_value. Is that possible somehow?
> 
> 
> 
> -- 
> 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.
> 
  

-- 
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] Testing exported resources

[Pete]

Hello,

Is there any way to test if a resources has been exported (without 
realising it)?  The reason being - I don't want to realise a nagios_service 
that's associated with a nagios_hostgroup until at least one nagios_host 
belonging to that hostgroup exists (otherwise nagios will refuse to start).

Any ideas?

Pete

-- 

--
This email was sent by a company owned by Pearson plc, registered office at 
80 Strand, London WC2R 0RL.  Registered in England and Wales with company 
number 53723.

-- 
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/-/7g4gHwSXefQJ.
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] hiera and fallback to params?

[Jonathan Proulx]

On Wed, Oct 3, 2012 at 11:02 AM, Jakov Sosic  wrote:
> Hi.
>
> I would like to setup my manifests, so that variable data is gathered
> from hiera, if it's available there, and if not, then to fallback on
> some predefined value...

The "right" thing is to put that default somewhere in hiera.  What we do is:

cat /etc/puppet/hiera.yaml
---
:hierarchy:
 - %{fqdn}
 - %{role}
 - %{group}
 - common
:backends:
 - yaml
 - puppet
:yaml:
 :datadir: /etc/puppet/environments/%{environment}/data
:puppet:
 :datasource: data

so there is both a common.yaml file in your data directory for local
fall back, and an ultimate fallback to puppet variables defined in
::data, so we can manage defaults with in the module for
example our local ntp module has them in modules/ntp/data.pp

-Jon

> Something like this:
>
> $my_var = hiera('myvar') || 'base_value'
>
> So if there is no myvar in hiera data, that manifest falls back to
> base_value. Is that possible somehow?
>
>
>
> --
> 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.
>

-- 
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: hiera and fallback to params?

[llowder]

On Wednesday, October 3, 2012 10:03:17 AM UTC-5, Jakov Sosic wrote:
>
> Hi. 
>
> I would like to setup my manifests, so that variable data is gathered 
> from hiera, if it's available there, and if not, then to fallback on 
> some predefined value... 
>
> Something like this: 
>
> $my_var = hiera('myvar') || 'base_value' 
>
> So if there is no myvar in hiera data, that manifest falls back to 
> base_value. Is that possible somehow? 
>
>
$my_var = hiera('somevar', 'some_default') will do exactly that.
 

-- 
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/-/5vVlXJWbRIUJ.
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] hiera and fallback to params?

[Jakov Sosic]

Hi.

I would like to setup my manifests, so that variable data is gathered
from hiera, if it's available there, and if not, then to fallback on
some predefined value...

Something like this:

$my_var = hiera('myvar') || 'base_value'

So if there is no myvar in hiera data, that manifest falls back to
base_value. Is that possible somehow?



-- 
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] Removing intermediate variables in calculation

[jcbollinger]

On Tuesday, October 2, 2012 10:10:13 AM UTC-5, Guzmán Brasó wrote:
>
> I'm in no way a puppet guru but rewritting it didnt work? from a logic 
> point of view this should work:
>
>
> class 
>   $baseurl,
>   $webapp_context_path = ''
> ) {
>   if ($webapp_context_path == '') {   
> # Try to get value from baseurl
> $webapp_context_path = regsubst($baseurl, '^https?://[^/]+(/.*)', '\1')
> if ($webapp_context_path == '') {
>   #Set default
>   $webapp_context_path = '/'
> }
>  }  
>  notify{"rewritted webapp_context_path='${webapp_context_path}' from 
> url='${baseurl}'": }
> }
>
>

No, that won't work, because Puppet variables, including class and 
definition parameters, can be assigned a value at most once.  There are 
good reasons for that, but they're not really relevant to the present 
question.
 
Anyway, for that very reason, constructs involving internal variables such 
as $int_webapp_context_path are fairly standard practice in Puppet.  Among 
the alternatives could be to redesign your class parameterization or to 
drop the adaptive behavior.  Or you could write a custom function 
implementing the logic for context path selection, or you could put it into 
your template instead of your class.

(Note, by the way, that because you assign a default value of '/' to 
$webapp_context_path in your parameter list, in the class body that 
parameter will be observed to have an empty value only if such a value is 
explicitly set when the class is declared.)


John

-- 
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/-/sF_qog4IzWQJ.
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 2.7 v 3.0 in the PuppetLabs yum repo

[Throwe, Jesse]

It might be worth an enhancement request to have Package: ensure => version
call yum versionlock or zypper add-lock if they are present
On Oct 3, 2012 10:55 AM, "Mister Guru"  wrote:

>
>
> On 3 October 2012 15:51, Chad Huneycutt  wrote:
>
>> I agree that folks should manage their repos, but I wanted to throw in
>> a couple of thoughts:
>>
>> * The package name hacks (eg puppet3) are usually done by
>> distributions to allow multiple versions of software to co-exist.
>>
>
> I think that we have the requirements for the package name hack, as in 2
> separate package versions
>
>
>>
>> * Take a look at the yum versionlock plugin.  My life has been much
>> simpler since I deployed it.  For a while I was "exclude"ing puppet
>> and friends in yum.conf, but that was a real pain.  The versionlock
>> plugin "pins" a package at the version  you want, and then you can
>> update when ready.
>>
>
> I will take a look at this plugin when I have a moment, thanks for the tip
>
>
>>
>> - Chad
>>
>> On Wed, Oct 3, 2012 at 9:16 AM, jcbollinger 
>> wrote:
>> >
>> >
>> > On Tuesday, October 2, 2012 7:36:22 PM UTC-5, Michael Stanhke wrote:
>> >>
>> >> On Tue, Oct 2, 2012 at 1:30 PM, Jeff McCune 
>> wrote:
>> >> > On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg 
>> >> > wrote:
>> >> >> I am using CentOS 6 with the PuppetLabs yum repo from
>> >> >> http://yum.puppetlabs.com
>> >> >>
>> >> >> I noticed that today version 3 is available on the repo, so of
>> course,
>> >> >> an
>> >> >> upgrade to Puppet is available.
>> >> >
>> >> > Yes, this major version update went live on Monday.  There are a
>> >> > number of breaking-changes between 2.7 and 3.0 which are described
>> at:
>> >> > http://links.puppetlabs.com/telly_breaking_changes
>> >> >
>> >> >> Ideally, it would have been better if v3 had a different
>> distribution
>> >> >> name,
>> >> >> so that systems with v2.7.x are not upgraded (especially if there
>> will
>> >> >> be
>> >> >> future releases if v2.7).
>> >>
>> >> We sent out several notices about this prior to doing it. The Puppet
>> >> Labs repositories are designed to be the place you get the latest
>> >> software from Puppet Labs.  This was a conscious choice.
>> >>
>> >> >
>> >> > Could you please file an issue (with impact data) about the
>> >> > distribution name issue.  I believe we considered doing what you
>> >> > describe, but decided against it.  I don't know the reasons off the
>> >> > top of my head though, an issue will give us a clear place to track
>> >> > the request, the impact it has on you and your organization, and the
>> >> > decision we come to (or have already come to).
>> >> >
>> >> >> I am concerned about things breaking. So is there a document
>> detailing
>> >> >> incompatibilities? Will there be future 2.7 releases?
>> >> There will be.  I'd imagine you'll see activity slow on it though.
>> >>
>> >> >
>> >> > There will be future releases of 2.7.  We will continue to fix bugs
>> in
>> >> > the 2.7 series, but we are intending to avoid adding any new features
>> >> > or make any large changes to the behavior of Puppet 2.7.
>> >
>> >
>> > I am not directly affected by this issue, but I agree with those
>> complaining
>> > that it was unwise, or at least inhospitable for PL to release Puppet 3
>> into
>> > its repositories in this way, especially considering that PL intends to
>> > continue with maintenance releases in the 2.7 series.  It is tantamount
>> to a
>> > recommendation for all users to upgrade to the new line immediately, and
>> > considering the number of breaking changes, I cannot believe that that
>> was
>> > intended.
>> >
>> > The customary way to handle dual lines of packages is to give one line a
>> > different name, for example "puppet3-*" instead of plain "puppet-*".
>> > Failing that, it is essential that the package name for the 2.7 series
>> be
>> > changed, else the PL repository will be near-useless to people who want
>> to
>> > stay at 2.7 for the time being.  If that's the plan then the first
>> > "puppet2-*" packages should have been released at the same time that the
>> > mainline packages were updated to v 3.0.
>> >
>> > Alternatively, PL could set up a separate repository for the Puppet 2
>> > maintenance releases.
>> >
>> > Distinguishing the lines only by their version numbers simply isn't
>> useful,
>> > and dropping v3 packages with their breaking changes into the same
>> > repository with v2 will cause breakage for users.  PL, I urge you to
>> > reconsider.  Soon.
>> >
>> >
>> > John
>> >
>> > --
>> > 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/-/AG4SVCmBV1cJ.
>> >
>> > 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

Re: [Puppet Users] How to prevent puppet clients from updating to version 3?

[Chad Huneycutt]

For yum-based updates, take a look at the yum versionlock plugin.
Works great here, although you have to specify the entire package name
that you want (I don't think just specifying puppet-2.7 will work).

debian-based distros support pinning, but haven't gotten that going yet.

- Chad

On Wed, Oct 3, 2012 at 10:36 AM, Mister Guru  wrote:
> I'm sending this email to start this thread, feel free to comment as
> appropriate. I'm going to assume that it's going to take a while for most
> people to actually realise that the puppet update may be giving them some
> issues, so, comments and suggestion please!
>
> --
> 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.



-- 
Chad M. Huneycutt

-- 
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 2.7 v 3.0 in the PuppetLabs yum repo

[Mister Guru]

On 3 October 2012 15:51, Chad Huneycutt  wrote:

> I agree that folks should manage their repos, but I wanted to throw in
> a couple of thoughts:
>
> * The package name hacks (eg puppet3) are usually done by
> distributions to allow multiple versions of software to co-exist.
>

I think that we have the requirements for the package name hack, as in 2
separate package versions


>
> * Take a look at the yum versionlock plugin.  My life has been much
> simpler since I deployed it.  For a while I was "exclude"ing puppet
> and friends in yum.conf, but that was a real pain.  The versionlock
> plugin "pins" a package at the version  you want, and then you can
> update when ready.
>

I will take a look at this plugin when I have a moment, thanks for the tip


>
> - Chad
>
> On Wed, Oct 3, 2012 at 9:16 AM, jcbollinger 
> wrote:
> >
> >
> > On Tuesday, October 2, 2012 7:36:22 PM UTC-5, Michael Stanhke wrote:
> >>
> >> On Tue, Oct 2, 2012 at 1:30 PM, Jeff McCune 
> wrote:
> >> > On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg 
> >> > wrote:
> >> >> I am using CentOS 6 with the PuppetLabs yum repo from
> >> >> http://yum.puppetlabs.com
> >> >>
> >> >> I noticed that today version 3 is available on the repo, so of
> course,
> >> >> an
> >> >> upgrade to Puppet is available.
> >> >
> >> > Yes, this major version update went live on Monday.  There are a
> >> > number of breaking-changes between 2.7 and 3.0 which are described at:
> >> > http://links.puppetlabs.com/telly_breaking_changes
> >> >
> >> >> Ideally, it would have been better if v3 had a different distribution
> >> >> name,
> >> >> so that systems with v2.7.x are not upgraded (especially if there
> will
> >> >> be
> >> >> future releases if v2.7).
> >>
> >> We sent out several notices about this prior to doing it. The Puppet
> >> Labs repositories are designed to be the place you get the latest
> >> software from Puppet Labs.  This was a conscious choice.
> >>
> >> >
> >> > Could you please file an issue (with impact data) about the
> >> > distribution name issue.  I believe we considered doing what you
> >> > describe, but decided against it.  I don't know the reasons off the
> >> > top of my head though, an issue will give us a clear place to track
> >> > the request, the impact it has on you and your organization, and the
> >> > decision we come to (or have already come to).
> >> >
> >> >> I am concerned about things breaking. So is there a document
> detailing
> >> >> incompatibilities? Will there be future 2.7 releases?
> >> There will be.  I'd imagine you'll see activity slow on it though.
> >>
> >> >
> >> > There will be future releases of 2.7.  We will continue to fix bugs in
> >> > the 2.7 series, but we are intending to avoid adding any new features
> >> > or make any large changes to the behavior of Puppet 2.7.
> >
> >
> > I am not directly affected by this issue, but I agree with those
> complaining
> > that it was unwise, or at least inhospitable for PL to release Puppet 3
> into
> > its repositories in this way, especially considering that PL intends to
> > continue with maintenance releases in the 2.7 series.  It is tantamount
> to a
> > recommendation for all users to upgrade to the new line immediately, and
> > considering the number of breaking changes, I cannot believe that that
> was
> > intended.
> >
> > The customary way to handle dual lines of packages is to give one line a
> > different name, for example "puppet3-*" instead of plain "puppet-*".
> > Failing that, it is essential that the package name for the 2.7 series be
> > changed, else the PL repository will be near-useless to people who want
> to
> > stay at 2.7 for the time being.  If that's the plan then the first
> > "puppet2-*" packages should have been released at the same time that the
> > mainline packages were updated to v 3.0.
> >
> > Alternatively, PL could set up a separate repository for the Puppet 2
> > maintenance releases.
> >
> > Distinguishing the lines only by their version numbers simply isn't
> useful,
> > and dropping v3 packages with their breaking changes into the same
> > repository with v2 will cause breakage for users.  PL, I urge you to
> > reconsider.  Soon.
> >
> >
> > John
> >
> > --
> > 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/-/AG4SVCmBV1cJ.
> >
> > 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.
>
>
>
> --
> Chad M. Huneycutt
>
> --
> 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

Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo

[Chad Huneycutt]

I agree that folks should manage their repos, but I wanted to throw in
a couple of thoughts:

* The package name hacks (eg puppet3) are usually done by
distributions to allow multiple versions of software to co-exist.

* Take a look at the yum versionlock plugin.  My life has been much
simpler since I deployed it.  For a while I was "exclude"ing puppet
and friends in yum.conf, but that was a real pain.  The versionlock
plugin "pins" a package at the version  you want, and then you can
update when ready.

- Chad

On Wed, Oct 3, 2012 at 9:16 AM, jcbollinger  wrote:
>
>
> On Tuesday, October 2, 2012 7:36:22 PM UTC-5, Michael Stanhke wrote:
>>
>> On Tue, Oct 2, 2012 at 1:30 PM, Jeff McCune  wrote:
>> > On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg 
>> > wrote:
>> >> I am using CentOS 6 with the PuppetLabs yum repo from
>> >> http://yum.puppetlabs.com
>> >>
>> >> I noticed that today version 3 is available on the repo, so of course,
>> >> an
>> >> upgrade to Puppet is available.
>> >
>> > Yes, this major version update went live on Monday.  There are a
>> > number of breaking-changes between 2.7 and 3.0 which are described at:
>> > http://links.puppetlabs.com/telly_breaking_changes
>> >
>> >> Ideally, it would have been better if v3 had a different distribution
>> >> name,
>> >> so that systems with v2.7.x are not upgraded (especially if there will
>> >> be
>> >> future releases if v2.7).
>>
>> We sent out several notices about this prior to doing it. The Puppet
>> Labs repositories are designed to be the place you get the latest
>> software from Puppet Labs.  This was a conscious choice.
>>
>> >
>> > Could you please file an issue (with impact data) about the
>> > distribution name issue.  I believe we considered doing what you
>> > describe, but decided against it.  I don't know the reasons off the
>> > top of my head though, an issue will give us a clear place to track
>> > the request, the impact it has on you and your organization, and the
>> > decision we come to (or have already come to).
>> >
>> >> I am concerned about things breaking. So is there a document detailing
>> >> incompatibilities? Will there be future 2.7 releases?
>> There will be.  I'd imagine you'll see activity slow on it though.
>>
>> >
>> > There will be future releases of 2.7.  We will continue to fix bugs in
>> > the 2.7 series, but we are intending to avoid adding any new features
>> > or make any large changes to the behavior of Puppet 2.7.
>
>
> I am not directly affected by this issue, but I agree with those complaining
> that it was unwise, or at least inhospitable for PL to release Puppet 3 into
> its repositories in this way, especially considering that PL intends to
> continue with maintenance releases in the 2.7 series.  It is tantamount to a
> recommendation for all users to upgrade to the new line immediately, and
> considering the number of breaking changes, I cannot believe that that was
> intended.
>
> The customary way to handle dual lines of packages is to give one line a
> different name, for example "puppet3-*" instead of plain "puppet-*".
> Failing that, it is essential that the package name for the 2.7 series be
> changed, else the PL repository will be near-useless to people who want to
> stay at 2.7 for the time being.  If that's the plan then the first
> "puppet2-*" packages should have been released at the same time that the
> mainline packages were updated to v 3.0.
>
> Alternatively, PL could set up a separate repository for the Puppet 2
> maintenance releases.
>
> Distinguishing the lines only by their version numbers simply isn't useful,
> and dropping v3 packages with their breaking changes into the same
> repository with v2 will cause breakage for users.  PL, I urge you to
> reconsider.  Soon.
>
>
> John
>
> --
> 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/-/AG4SVCmBV1cJ.
>
> 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.



-- 
Chad M. Huneycutt

-- 
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: How to prevent puppet clients from updating to version 3?

[llowder]

On Wednesday, October 3, 2012 9:37:01 AM UTC-5, Mister Guru wrote:
>
> I'm sending this email to start this thread, feel free to comment as 
> appropriate. I'm going to assume that it's going to take a while for most 
> people to actually realise that the puppet update may be giving them some 
> issues, so, comments and suggestion please! 
>

Don't use ensure => latest.

Either just use installed, or a specific version, and then you can upgrade 
when you are ready to.

-- 
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/-/lPyCxjld3_MJ.
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: Operating system conflict?

[jcbollinger]

On Tuesday, October 2, 2012 9:35:13 AM UTC-5, Mike wrote:
>
> Hi,
>
> I've have some problems with my puppet configuration, I'm managing several 
> Ubuntu and OpenBSD hosts.
>
> I sometimes get on OpenBSD hosts (5.0 is OpenBSD release):
> info: Retrieving plugin
> err: Could not retrieve catalog from remote server: Error 400 on SERVER: 
> Could not find template 'ubuntu-common/5.0/etc-openntpd-ntpd.conf.erb' at 
> /usr/share/puppet/modules/ubuntu-common/manifests/base.pp:7 on node xxx
> warning: Not using cache on failed catalog
> err: Could not retrieve catalog; skipping run
>
> But this is in an Ubuntu template file, OpenBSD should never include this 
> file, according to the case $operatingsystem in site.pp.
>
> I tracked the exact scenario which make it fail:
>
> 1. Restart puppet master - run agent only with OpenBSD hosts - it never 
> fails, everything works as expected
> 2. Restart puppet master - run agent only with Ubuntu hosts - it never 
> fails, everything works as expected
> 3. Restart puppet master - run agent with Ubuntu and OpenBSD hosts - 
> Ubuntu works as expected, OpenBSD fails with the above error message (after 
> the first Ubuntu agent was connected)
> 4. after scenario 3. on puppet config file changes, OpenBSD works again 
> until an Ubuntu agent connects to the master
>
> Do you have an idea of what could be wrong, or an known issue of puppet?
>


I am not aware of any known Puppet issue that results in behavior 
comparable to this.

 

>
> Could it be a puppet version issue, the master and Ubuntu hosts are using 
> 2.7.19, OpenBSD hosts are using 2.7.1? (I haven't tried to downgrade ubuntu 
> or upgrade OpenBSD's version, newer OpenBSD 5.1 comes with puppet 2.7.5)
>


That should not be an issue.  If the master and all the clients are on 
2.7.x, and none of the clients use newer Puppet than the master, then you 
should be fine.  You should be ok even with 2.6.x clients.

 

>
> According to scenario 4. could it be a caching issue on the master?
>


It rather looks like one, but the key question is why would such an issue 
arise?  Puppet should never use cached details of one node's catalog to 
build a different node's catalog.  Although I can't rule out a Puppet bug, 
it more likely arises from a problem in your manifests or client 
configuration.


> I tried some puppet.conf options:
>
> ignorecache=true
> usecacheonfailure=false
>
> but it didn't change anything.
>


Those options affect only the agent as far as I know, not the master.
 

>
> The master and ubuntu hosts are running on Ubuntu 12.04
> # puppet --version
> 2.7.19
> # ruby --version
> ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
>
> The OpenBSD hosts are OpenBSD 5.0
> # puppet --version
> 2.7.1
> # ruby18  --version
> ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-openbsd]
>
> Here is my very simplified version of puppet files, I didn't try exactly 
> this subset of configuration, I will try to narrow down the problem to the 
> simplest configuration.
>


Often the process of narrowing it down will itself reveal the problem.  I 
don't see why the manifest set you presented would exhibit a problem such 
as the one you described, and since you didn't confirm that it does, I'm 
not going to do further analysis.

My only guess at this point is that something is screwy with your SSL 
configuration.  Puppet identifies nodes by the certname on the client 
certificates they present, so if you've done something like sharing the 
same client cert among all your clients then the master will not recognize 
them as different nodes.  Node facts (including $hostname) do not enter 
that picture.


John

-- 
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/-/fMZeUmBcZJgJ.
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] Puppet, uWSGI and nginx

[Juan José Presa Rodal]

Hi, I'm trying to configure distributed Puppet with uWSGI server 
application without success.

I'm configuring NGINX in a similar way that with Unicorn or Passenger and 
also inspiring in this blog entry: 
http://www.prontab.com/2011/01/this-page-should-outline-how-to-set-up.html

¿Anybody has experience with this full-featured application container? 
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/-/IGMz_jwXtQIJ.
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] Re: Set variable value

[Darvin Denmian]

Thanks for your reply. I'll try it right now.

Regards.

On Wed, Oct 3, 2012 at 11:18 AM, jcbollinger  wrote:
>
>
> On Tuesday, October 2, 2012 1:03:23 PM UTC-5, Darvin Denmian wrote:
>>
>> Hi,
>>
>> Is it possible to set the value of a variable from the content of
>> a text file?
>>
>
> If the target file is on the master, then you can load its entire contents
> into a variable via the file() function that David suggested:
>
> $myvar = file('/path/to/file')
>
> If needed, you can then use other Puppet functions to parse out the value
> you want.
>
> Alternatively, you can always write a custom function to parse any file
> format you want.  If the target file is one that you intend to create and
> maintain for this purpose, however, then I would recommend using Hiera
> instead.  It's a little more involved to set up (unless you're on Puppet 3,
> where it's built in), but it's the de facto standard for accessing external
> data even on Puppet 2.
>
> On the other hand, if your file resides on the node being configured, then
> what you're looking for is a custom fact.  They are pretty easy to write and
> distribute: http://docs.puppetlabs.com/guides/custom_facts.html.
>
>
> John
>
> --
> 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/-/I6MysO4VpEsJ.
>
> 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.

-- 
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] How to prevent puppet clients from updating to version 3?

[Mister Guru]

I'm sending this email to start this thread, feel free to comment as
appropriate. I'm going to assume that it's going to take a while for most
people to actually realise that the puppet update may be giving them some
issues, so, comments and suggestion please!

-- 
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 2.7 v 3.0 in the PuppetLabs yum repo

[Mister Guru]

On 3 October 2012 15:02, Rilindo Foster  wrote:

> I usually explicitly set the $puppetversion in my manifest for my
> environment. Furthermore, I have my own mirror copied from puppet labs repo
> and install it from that location instead. That way, I have control of what
> I push out and only update when I know that the new version is sound.
>
> So I am not sure what the hubbub is all about. If you are not controlling
> what you push out, don't be surprised when something breaks.
>

I'm partially pissed of with PL as well, and I'm really not liking the
responses that say, "well you should manage the package versions you have
installed"

To me, the point is here, that this is more of a case of BAD repo
managment. It's NOT the same package, AND it doesn't have full 100%
backward compatibility - So it's a DIFFERENT package - give it a new name.
Also, those gloating that manage their packages using version numbers, and
are not affected by this - YOU ARE NOT HELPING. The problem is HOW the
package was pushed out, not the fact that it was pushed out.

Also, puppet v2 is also going to be available still - If it was me, I would
have created a meta package called puppet, and 'linked' that puppet 2, and
called puppet3, puppet 3. I'd also create a package called puppet2. And
about 6 weeks after release, upgrade meta package puppet to puppet 3.   --
I'm just saying :)



>
>  - RIlindo
>
>
> On Oct 3, 2012, at 8:16 AM, jcbollinger  wrote:
>
>
> I am not directly affected by this issue, but I agree with those
> complaining that it was unwise, or at least inhospitable for PL to release
> Puppet 3 into its repositories in this way, especially considering that PL
> intends to continue with maintenance releases in the 2.7 series.  It is
> tantamount to a recommendation for all users to upgrade to the new line
> immediately, and considering the number of breaking changes, I cannot
> believe that that was intended.
>
> The customary way to handle dual lines of packages is to give one line a
> different name, for example "puppet3-*" instead of plain "puppet-*".
> Failing that, it is essential that the package name for the 2.7 series be
> changed, else the PL repository will be near-useless to people who want to
> stay at 2.7 for the time being.  If that's the plan then the first
> "puppet2-*" packages should have been released at the same time that the
> mainline packages were updated to v 3.0.
>
> Alternatively, PL could set up a separate repository for the Puppet 2
> maintenance releases.
>
> Distinguishing the lines only by their version numbers simply isn't
> useful, and dropping v3 packages with their breaking changes into the same
> repository with v2 *will* cause breakage for users.  PL, I urge you to
> reconsider.  Soon.
>
>
> John
>
> Agreed + 101 (looks at RIP)

-- 
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: service question

[jcbollinger]

On Tuesday, October 2, 2012 11:47:43 AM UTC-5, ureal frank wrote:
>
>  Hi, 
>
> I have a service /etc/init.d/a that spawns multiple daemons b and c.
>
> This manifest does not make much sense to me but… any tip?
>
> service { 'a': 
> ensure => running, 
> pattern => ["/usr/local/bin/b", "/usr/local/bin/c"],
> }
>
>

As far as I know, the 'pattern' parameter understands only a single 
pattern.  What you have written probably won't do what you want.

 

> or should I test them individually?
>
> service { 'a': 
> ensure => running, 
> pattern => "/usr/local/bin/b",
> }
> service { 'a': 
> ensure => running, 
> pattern => "/usr/local/bin/c",
> }
>
>
No, you cannot declare Service['a'] (or any other resource) twice.

Your best bet would be to make the service control script /etc/init.d/a 
respond to the "status" command in an appropriate way (ideally as specified 
by the LSB; see 
http://refspecs.freestandards.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html),
 
and leave off the 'pattern' parameter in the service declaration.  If you 
are running a Puppet version older than 2.7.0 then you will also need to 
add "hasstatus => true" to the service parameters.


John

-- 
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/-/NpAfZV6TrIkJ.
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 2.7 v 3.0 in the PuppetLabs yum repo

[R.I.Pienaar]

- Original Message -
> From: "Rilindo Foster" 
> To: puppet-users@googlegroups.com
> Sent: Wednesday, October 3, 2012 3:02:58 PM
> Subject: Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
> 
> I usually explicitly set the $puppetversion in my manifest for my
> environment. Furthermore, I have my own mirror copied from puppet
> labs repo and install it from that location instead. That way, I
> have control of what I push out and only update when I know that the
> new version is sound.
> 
> So I am not sure what the hubbub is all about. If you are not
> controlling what you push out, don't be surprised when something
> breaks.

+100, people seem to be expecting the rest of the world to maintain
a controlled environment simply because they don't?

Do you really trust a random third party as the source of your packages?

What if there is an outage at one of these 3rd party package providers
and you cannot build new machines? How do you explain that on the day
that you suddenly need to scale your infrastructure due to a critical
request or failure?

You have to build local repo mirrors and you have to be able to recover
from a disaster or simply provision new infrastructure based on your 
own processes and systems you influence, if you do not you have bigger
problems than what version of Puppet is on some 3rd party repo.

-- 
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: Set variable value

[jcbollinger]

On Tuesday, October 2, 2012 1:03:23 PM UTC-5, Darvin Denmian wrote:
>
> Hi, 
>
> Is it possible to set the value of a variable from the content of 
> a text file? 
>
>
If the target file is on the master, then you can load its entire contents 
into a variable via the file() function that David suggested:

$myvar = file('/path/to/file')

If needed, you can then use other Puppet functions to parse out the value 
you want.

Alternatively, you can always write a custom function to parse any file 
format you want.  If the target file is one that you intend to create and 
maintain for this purpose, however, then I would recommend using Hiera 
instead.  It's a little more involved to set up (unless you're on Puppet 3, 
where it's built in), but it's the de facto standard for accessing external 
data even on Puppet 2.

On the other hand, if your file resides on the node being configured, then 
what you're looking for is a custom fact.  They are pretty easy to write 
and distribute: http://docs.puppetlabs.com/guides/custom_facts.html.


John

-- 
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/-/I6MysO4VpEsJ.
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: PROBLEM : Cannot require an Exec

[jcbollinger]

On Tuesday, October 2, 2012 3:36:10 PM UTC-5, am-aaron wrote:
>
> hello:
>
> i currently am using Puppet to run some commands in a sequence. there are 
> two sequences of exec resources. we found that we cannot use require => 
> Exec and it does not work at all as expected. here is some sample code.
>
> exec { "exec-AAA":
>   command => "/bin/true",
>   returns => 0,
>   notify  => Exec["exec-BBB"],
> }
> exec { "exec-BBB":
>   refreshonly => true,
>   command => "/bin/false",
>   returns => 0,
>   notify  => Exec["exec-CCC"],
> }
> exec { "exec-CCC":
>   refreshonly => true,
>   command => "/bin/touch /tmp/CCC",
>   returns => 0,
> }
>
> exec { "exec-DDD":
>   require => Exec["exec-CCC"],
>   command => "/bin/true",
>   returns => 0,
>   notify  => Exec["exec-EEE"],
> }
> exec { "exec-EEE":
>   refreshonly => true,
>   command => "/bin/false",
>   notify  => Exec["exec-FFF"],
> }
> exec { "exec-FFF":
>   refreshonly => true,
>   command => "/bin/touch /tmp/FFF",
>   returns => 0,
> }
>
> *ms1:/root/aaron> puppet apply t1.pp*
>
> notice: /Stage[main]//Exec[exec-AAA]/returns: executed successfully
> err: /Stage[main]//Exec[exec-BBB]: Failed to call refresh: /bin/false 
> returned 1 instead of one of [0] at /root/aaron/t1.pp:11
> notice: /Stage[main]//Exec[exec-DDD]/returns: executed successfully
> err: /Stage[main]//Exec[exec-EEE]: Failed to call refresh: /bin/false 
> returned 1 instead of one of [0] at /root/aaron/t1.pp:28
> notice: Finished catalog run in 0.36 seconds
>
> in the example above, how did Exec["exec-DDD"] run when Exec["exec-CCC"] 
> did not run and Exec["exec-DDD"] require Exec["exec-CCC"]?
>
> *ms1:/root/aaron> puppet apply --debug t1.pp*
>
> info: Applying configuration version '1349209769'
> debug: /Stage[main]//Exec[exec-DDD]/require: requires Exec[exec-CCC]
> debug: /Stage[main]//Exec[exec-DDD]/notify: subscribes to Exec[exec-EEE]
> debug: /Stage[main]//Exec[exec-BBB]/notify: subscribes to Exec[exec-CCC]
> debug: /Stage[main]//Exec[exec-AAA]/notify: subscribes to Exec[exec-BBB]
> debug: /Stage[main]//Exec[exec-EEE]/notify: subscribes to Exec[exec-FFF]
> debug: /Schedule[never]: Skipping device resources because running on a 
> host
> debug: /Schedule[daily]: Skipping device resources because running on a 
> host
> debug: /Schedule[monthly]: Skipping device resources because running on a 
> host
> debug: /Schedule[puppet]: Skipping device resources because running on a 
> host
> debug: /Schedule[hourly]: Skipping device resources because running on a 
> host
> debug: /Schedule[weekly]: Skipping device resources because running on a 
> host
> debug: Exec[exec-AAA](provider=posix): Executing '/bin/true'
> debug: Executing '/bin/true'
> notice: /Stage[main]//Exec[exec-AAA]/returns: executed successfully
> debug: /Stage[main]//Exec[exec-AAA]: The container Class[Main] will 
> propagate my refresh event
> info: /Stage[main]//Exec[exec-AAA]: Scheduling refresh of Exec[exec-BBB]
> debug: Exec[exec-BBB](provider=posix): Executing '/bin/false'
> debug: Executing '/bin/false'
> err: /Stage[main]//Exec[exec-BBB]: Failed to call refresh: /bin/false 
> returned 1 instead of one of [0] at /root/aaron/t1.pp:11
> debug: Exec[exec-DDD](provider=posix): Executing '/bin/true'
> debug: Executing '/bin/true'
> notice: /Stage[main]//Exec[exec-DDD]/returns: executed successfully
> debug: /Stage[main]//Exec[exec-DDD]: The container Class[Main] will 
> propagate my refresh event
> info: /Stage[main]//Exec[exec-DDD]: Scheduling refresh of Exec[exec-EEE]
> debug: Exec[exec-EEE](provider=posix): Executing '/bin/false'
> debug: Executing '/bin/false'
> err: /Stage[main]//Exec[exec-EEE]: Failed to call refresh: /bin/false 
> returned 1 instead of one of [0] at /root/aaron/t1.pp:28
> debug: Class[Main]: The container Stage[main] will propagate my refresh 
> event
> debug: Finishing transaction 70054935787440
> debug: Storing state
> debug: Stored state in 0.06 seconds
> notice: Finished catalog run in 0.37 seconds
> debug: /File[/var/lib/puppet/rrd]/seluser: Found seluser default 
> 'system_u' for /var/lib/puppet/rrd
> debug: /File[/var/lib/puppet/rrd]/selrole: Found selrole default 
> 'object_r' for /var/lib/puppet/rrd
> debug: /File[/var/lib/puppet/rrd]/seltype: Found seltype default 
> 'puppet_var_lib_t' for /var/lib/puppet/rrd
> debug: /File[/var/lib/puppet/rrd]/selrange: Found selrange default 's0' 
> for /var/lib/puppet/rrd
> debug: Finishing transaction 70054934905120
> debug: Recieved report to process from ms1
> debug: Processing report from ms1 with processor Puppet::Reports::Store
>
> as you can see in the debug run, even though Exec["exec-DDD"] require 
> Exec["exec-CCC"], and the latter does not run, the former runs. what is 
> going on here?
>
>

The 'require' metaparameter is no different for Exec resources than for any 
other resource type: foo { 'myfoo': require => Bar['mybar'] } means that 
when the agent applies the catalog, it must successfully *apply* resourc

Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo

[Rilindo Foster]

I usually explicitly set the $puppetversion in my manifest for my environment. 
Furthermore, I have my own mirror copied from puppet labs repo and install it 
from that location instead. That way, I have control of what I push out and 
only update when I know that the new version is sound.

So I am not sure what the hubbub is all about. If you are not controlling what 
you push out, don't be surprised when something breaks.

 - RIlindo

On Oct 3, 2012, at 8:16 AM, jcbollinger  wrote:

> 
> I am not directly affected by this issue, but I agree with those complaining 
> that it was unwise, or at least inhospitable for PL to release Puppet 3 into 
> its repositories in this way, especially considering that PL intends to 
> continue with maintenance releases in the 2.7 series.  It is tantamount to a 
> recommendation for all users to upgrade to the new line immediately, and 
> considering the number of breaking changes, I cannot believe that that was 
> intended.
> 
> The customary way to handle dual lines of packages is to give one line a 
> different name, for example "puppet3-*" instead of plain "puppet-*".  Failing 
> that, it is essential that the package name for the 2.7 series be changed, 
> else the PL repository will be near-useless to people who want to stay at 2.7 
> for the time being.  If that's the plan then the first "puppet2-*" packages 
> should have been released at the same time that the mainline packages were 
> updated to v 3.0.
> 
> Alternatively, PL could set up a separate repository for the Puppet 2 
> maintenance releases.
> 
> Distinguishing the lines only by their version numbers simply isn't useful, 
> and dropping v3 packages with their breaking changes into the same repository 
> with v2 will cause breakage for users.  PL, I urge you to reconsider.  Soon.
> 
> 
> John
> 
> 
> -- 
> 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/-/AG4SVCmBV1cJ.
> 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.

-- 
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 3 killed my environment variables

[David Carr]

Within a provider, I think you can use this syntax:

has_command(:port, "/opt/local/bin/port") do
  environment :HOME => "/opt/local"
end


http://www.mail-archive.com/puppet-dev@googlegroups.com/msg17373.html


On Wednesday, October 3, 2012 9:11:03 AM UTC-4, jwkoelewijn wrote:

> Hi Stephen,
>
> You are right about the exec command being able to receive an environment 
> hash. This, however, does not solve our problem, because this is not 
> possible when creating a new Puppet Type and Provider. In the provider 
> commands are created using the "commands  => 'system_command' " class 
> level method. Whenever a command is to be executed by the provider, this 
> command is executed _without_ the USER, HOME and LOGNAME variables. There 
> does not seem to be a method to pass environment variables from within a 
> provider...
>
> Best regards,
>
> Jan-Willem Koelewijn
>
> On Wednesday, October 3, 2012 3:00:54 PM UTC+2, Stephen Gran wrote:
>>
>> Hi, 
>>
>> On Wed, 2012-10-03 at 05:45 -0700, Daniele Sluijters wrote: 
>> > Hello, 
>> > 
>> > 
>> > In Puppet 3 Puppet does its absolute best to make sure $HOME, $USER 
>> > and $LOGNAME environment variables are unset and nowhere to be found. 
>> > I realise this change was necessary because it caused some weird 
>> > start-up issues with Puppet but this also killed our RabbitMQ module. 
>> > 
>> > 
>> > RabbitMQ is written in Erlang and that thing _requires_ a $HOME to be 
>> > set as it will try to write an erlang-cookie to it and horribly fail 
>> > and go up in flames if it can't. Since Puppet 3 every Exec we have in 
>> > the RabbitMQ module now fails because of this. We've tried changing 
>> > the command to '$HOME=/var/lib/misc/puppet rabbitmqctl ' 
>> > but yet again the Exec type just nukes the environment too. This being 
>> > the 'offending' pull request which got 
>> > merged: 
>> https://github.com/puppetlabs/puppet/commit/14670c5850462472f5efcfc6ea11d2b4cab708a7
>>  
>> > 
>> > 
>> > So, short of patching Puppet to not do this or generate static 
>> > wrappers for every rabbitmqctl command which then in turn get called 
>> > by an Exec, how do we solve this? I really don't feel like generating 
>> > wrappers for every Exec that needs one of those environment variables 
>> > set. I'd actually expect that Exec would allow me to explicitly pass 
>> > in environment variables that I really need set in that case but the 
>> > docs don't seem to know anything about that. 
>>
>> Can you not just set resource defaults like: 
>>
>> Exec { 
>> environment => "HOME=/home/wibble" 
>> } 
>>
>> ? 
>>
>> Cheers, 
>> -- 
>> Stephen Gran 
>> Senior Systems Integrator - The Guardian 
>>
>> Please consider the environment before printing this email. 
>> -- 
>> Visit guardian.co.uk - newspaper of the year 
>>
>> www.guardian.co.ukwww.observer.co.uk www.guardiannews.com 
>>
>> On your mobile, visit m.guardian.co.uk or download the Guardian 
>> iPhone app www.guardian.co.uk/iphone and iPad edition 
>> www.guardian.co.uk/iPad 
>>   
>> Save up to 37% by subscribing to the Guardian and Observer - choose the 
>> papers you want and get full digital access. 
>> Visit guardian.co.uk/subscribe 
>>
>> - 
>> This e-mail and all attachments are confidential and may also 
>> be privileged. If you are not the named recipient, please notify 
>> the sender and delete the e-mail and all attachments immediately. 
>> Do not disclose the contents to another person. You may not use 
>> the information for any purpose, or store, or copy, it in any way. 
>>   
>> Guardian News & Media Limited is not liable for any computer 
>> viruses or other material transmitted with or as part of this 
>> e-mail. You should employ virus checking software. 
>>
>> Guardian News & Media Limited 
>>
>> A member of Guardian Media Group plc 
>> Registered Office 
>> PO Box 68164 
>> Kings Place 
>> 90 York Way 
>> London 
>> N1P 2AP 
>>
>> Registered in England Number 908396 
>>
>>

-- 
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/-/90rD99fFEWwJ.
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] Puppet doc no longer producing documentation

[Hugh Cole-Baker]

After upgrading to Puppet 3.0.0 it seems that puppet doc is no longer 
producing documentation from my modules / manifests.
I have a setup with two environments in 
/etc/puppet/environments/[production, testing], and I'm running the 
following command to generate the docs:

puppet doc --all --mode rdoc --environment production --outputdir doc

After running this it creates the 'doc' directory but there are no files in 
it.
The same command was working OK on 2.7.19.

Has anything changed in the required format of doc comments in the 
manifests?

-- 
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/-/_wWW_iC720cJ.
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 3.0.0 and Augeas on Ubuntu Lucid 10.04

[Paul Tötterman]

> Ubuntu released a backport of 0.3.0 into lucid-backports which will 
> resolve the issue for you here: 
>  http://packages.ubuntu.com/lucid-backports/libaugeas-ruby

Unfortunately upgrading the package did not solve the problem. Also the 
error message doesn't match the bug report.

--trace gives:

Error: /Stage[main]/Grub::Server/Augeas[grub-serial]: Could not evaluate: 
uninitialized constant Augeas::NO_LOAD
/usr/lib/ruby/vendor_ruby/puppet/provider/augeas/augeas.rb:152:in 
`open_augeas'
/usr/lib/ruby/vendor_ruby/puppet/provider/augeas/augeas.rb:342:in 
`need_to_run?'
/usr/lib/ruby/vendor_ruby/puppet/type/augeas.rb:205:in `retrieve'
/usr/lib/ruby/vendor_ruby/puppet/type.rb:685:in `retrieve'
/usr/lib/ruby/vendor_ruby/puppet/type.rb:680:in `each'
/usr/lib/ruby/vendor_ruby/puppet/type.rb:680:in `retrieve'
/usr/lib/ruby/vendor_ruby/puppet/type.rb:693:in `retrieve_resource'
/usr/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:32:in 
`perform_changes'
/usr/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:133:in 
`evaluate'
/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:49:in `apply'
/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:84:in `eval_resource'
/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:104:in `evaluate'
/usr/lib/ruby/vendor_ruby/puppet/util.rb:348:in `thinmark'
/usr/lib/ruby/1.8/benchmark.rb:308:in `realtime'
/usr/lib/ruby/vendor_ruby/puppet/util.rb:347:in `thinmark'
/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:104:in `evaluate'
/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:383:in `traverse'
/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:99:in `evaluate'
/usr/lib/ruby/vendor_ruby/puppet/resource/catalog.rb:144:in `apply'
/usr/lib/ruby/vendor_ruby/puppet/configurer.rb:122:in `apply_catalog'
/usr/lib/ruby/vendor_ruby/puppet/util.rb:179:in `benchmark'
/usr/lib/ruby/1.8/benchmark.rb:308:in `realtime'
/usr/lib/ruby/vendor_ruby/puppet/util.rb:178:in `benchmark'
/usr/lib/ruby/vendor_ruby/puppet/configurer.rb:121:in `apply_catalog'
/usr/lib/ruby/vendor_ruby/puppet/configurer.rb:179:in `run'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:45
/usr/lib/ruby/vendor_ruby/puppet/agent/locker.rb:20:in `lock'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:45
/usr/lib/ruby/1.8/sync.rb:230:in `synchronize'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:45
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:119:in `with_client'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:42
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:84:in `run_in_fork'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:41
/usr/lib/ruby/vendor_ruby/puppet/application.rb:175:in `call'
/usr/lib/ruby/vendor_ruby/puppet/application.rb:175:in `controlled_run'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:39:in `run'
/usr/lib/ruby/vendor_ruby/puppet/application/agent.rb:338:in `onetime'
/usr/lib/ruby/vendor_ruby/puppet/application/agent.rb:311:in `run_command'
/usr/lib/ruby/vendor_ruby/puppet/application.rb:346:in `run'
/usr/lib/ruby/vendor_ruby/puppet/application.rb:438:in `plugin_hook'
/usr/lib/ruby/vendor_ruby/puppet/application.rb:346:in `run'
/usr/lib/ruby/vendor_ruby/puppet/util.rb:500:in `exit_on_fail'
/usr/lib/ruby/vendor_ruby/puppet/application.rb:346:in `run'
/usr/lib/ruby/vendor_ruby/puppet/util/command_line.rb:76:in `execute'
/usr/bin/puppet:10

And the augeas definition from the manifest is:

$grub_console = 'console serial'

augeas { 'grub-serial':
context => '/files/etc/default/grub',
changes => ["set GRUB_TERMINAL \"'$grub_console'\"",
'set GRUB_SERIAL_COMMAND "\'serial --speed=115200 
--unit=0 --word=8 --parity=no --stop=1\'"',
'set GRUB_CMDLINE_LINUX_DEFAULT ""',
'set GRUB_CMDLINE_LINUX "\'console=tty1 
console=ttyS0,115200n8\'"'],
}

Cheers,
Paul

-- 
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/-/yCsb2Vj6z-oJ.
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] RHEL 5: Stuck on Puppet 2.7

[Dan White]

Running a Puppetmaster on a Red Hat Enterprise Linux 5 server using the 
Stealthy Monkeys RPM's for Passenger.

First the setup:

yum wants to update from :

puppet.noarch  2.7.19-1.el5 installed
puppet-server.noarch   2.7.19-1.el5 installed
ruby.x86_641.8.5-24.el5 installed
ruby-devel.i3861.8.5-24.el5 installed
ruby-devel.x86_64  1.8.5-24.el5 installed
ruby-irb.x86_641.8.5-24.el5 installed
ruby-libs.i386 1.8.5-24.el5 installed
ruby-libs.x86_64   1.8.5-24.el5 installed
ruby-rdoc.x86_64   1.8.5-24.el5 installed

to :

puppet.noarch  3.0.0-1.el5  puppetlabs-products 
puppet-server.noarch   3.0.0-1.el5  puppetlabs-products 
ruby.x86_641.8.7.370-1.el5  puppetlabs-deps 
ruby-devel.x86_64  1.8.7.370-1.el5  puppetlabs-deps 
ruby-irb.x86_641.8.7.370-1.el5  puppetlabs-deps 
ruby-libs.x86_64   1.8.7.370-1.el5  puppetlabs-deps 
ruby-rdoc.x86_64   1.8.7.370-1.el5  puppetlabs-deps 

So, the attempted update ends like this:

1:rubygem-passenger-native-libs-3.0.12-1.el5.centos_1.8.5.x86_64 from installed 
has depsolving problems
  --> Missing Dependency: ruby = 1.8.5 is needed by package 
1:rubygem-passenger-native-libs-3.0.12-1.el5.centos_1.8.5.x86_64 (installed)
Error: Missing Dependency: ruby = 1.8.5 is needed by package 
1:rubygem-passenger-native-libs-3.0.12-1.el5.centos_1.8.5.x86_64 (installed)

OK, a bit of Google-ing says that Passenger 3.0.14 was released in July
http://blog.phusion.nl/2012/07/22/phusion-passenger-3-0-14-released/#.UGsb6-c547w

But the latest RPM on http://passenger.stealthymonkeys.com/rhel/5Server/x86_64/
is rubygem-passenger-native-libs-3.0.12-1.el5.centos_1.8.5.x86_64.rpm -- which 
is what I currently have.

Suggestions ?  I sent an email to Erik Ogan, owner of Stealth Monkeys, but have 
not received a response.


“Sometimes I think the surest sign that intelligent life exists elsewhere in 
the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)

-- 
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 3 killed my environment variables

[jwkoelewijn]

Hi Stephen,

You are right about the exec command being able to receive an environment 
hash. This, however, does not solve our problem, because this is not 
possible when creating a new Puppet Type and Provider. In the provider 
commands are created using the "commands  => 'system_command' " class 
level method. Whenever a command is to be executed by the provider, this 
command is executed _without_ the USER, HOME and LOGNAME variables. There 
does not seem to be a method to pass environment variables from within a 
provider...

Best regards,

Jan-Willem Koelewijn

On Wednesday, October 3, 2012 3:00:54 PM UTC+2, Stephen Gran wrote:
>
> Hi, 
>
> On Wed, 2012-10-03 at 05:45 -0700, Daniele Sluijters wrote: 
> > Hello, 
> > 
> > 
> > In Puppet 3 Puppet does its absolute best to make sure $HOME, $USER 
> > and $LOGNAME environment variables are unset and nowhere to be found. 
> > I realise this change was necessary because it caused some weird 
> > start-up issues with Puppet but this also killed our RabbitMQ module. 
> > 
> > 
> > RabbitMQ is written in Erlang and that thing _requires_ a $HOME to be 
> > set as it will try to write an erlang-cookie to it and horribly fail 
> > and go up in flames if it can't. Since Puppet 3 every Exec we have in 
> > the RabbitMQ module now fails because of this. We've tried changing 
> > the command to '$HOME=/var/lib/misc/puppet rabbitmqctl ' 
> > but yet again the Exec type just nukes the environment too. This being 
> > the 'offending' pull request which got 
> > merged: 
> https://github.com/puppetlabs/puppet/commit/14670c5850462472f5efcfc6ea11d2b4cab708a7
>  
> > 
> > 
> > So, short of patching Puppet to not do this or generate static 
> > wrappers for every rabbitmqctl command which then in turn get called 
> > by an Exec, how do we solve this? I really don't feel like generating 
> > wrappers for every Exec that needs one of those environment variables 
> > set. I'd actually expect that Exec would allow me to explicitly pass 
> > in environment variables that I really need set in that case but the 
> > docs don't seem to know anything about that. 
>
> Can you not just set resource defaults like: 
>
> Exec { 
> environment => "HOME=/home/wibble" 
> } 
>
> ? 
>
> Cheers, 
> -- 
> Stephen Gran 
> Senior Systems Integrator - The Guardian 
>
> Please consider the environment before printing this email. 
> -- 
> Visit guardian.co.uk - newspaper of the year 
>
> www.guardian.co.ukwww.observer.co.uk www.guardiannews.com 
>
> On your mobile, visit m.guardian.co.uk or download the Guardian 
> iPhone app www.guardian.co.uk/iphone and iPad edition 
> www.guardian.co.uk/iPad 
>   
> Save up to 37% by subscribing to the Guardian and Observer - choose the 
> papers you want and get full digital access. 
> Visit guardian.co.uk/subscribe 
>
> - 
> This e-mail and all attachments are confidential and may also 
> be privileged. If you are not the named recipient, please notify 
> the sender and delete the e-mail and all attachments immediately. 
> Do not disclose the contents to another person. You may not use 
> the information for any purpose, or store, or copy, it in any way. 
>   
> Guardian News & Media Limited is not liable for any computer 
> viruses or other material transmitted with or as part of this 
> e-mail. You should employ virus checking software. 
>
> Guardian News & Media Limited 
>
> A member of Guardian Media Group plc 
> Registered Office 
> PO Box 68164 
> Kings Place 
> 90 York Way 
> London 
> N1P 2AP 
>
> Registered in England Number 908396 
>
>

-- 
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/-/_Ud91jE-FMAJ.
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 2.7 v 3.0 in the PuppetLabs yum repo

[jcbollinger]

On Tuesday, October 2, 2012 7:36:22 PM UTC-5, Michael Stanhke wrote:
>
> On Tue, Oct 2, 2012 at 1:30 PM, Jeff McCune 
> > 
> wrote: 
> > On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg 
> > > 
> wrote: 
> >> I am using CentOS 6 with the PuppetLabs yum repo from 
> >> http://yum.puppetlabs.com 
> >> 
> >> I noticed that today version 3 is available on the repo, so of course, 
> an 
> >> upgrade to Puppet is available. 
> > 
> > Yes, this major version update went live on Monday.  There are a 
> > number of breaking-changes between 2.7 and 3.0 which are described at: 
> > http://links.puppetlabs.com/telly_breaking_changes 
> > 
> >> Ideally, it would have been better if v3 had a different distribution 
> name, 
> >> so that systems with v2.7.x are not upgraded (especially if there will 
> be 
> >> future releases if v2.7). 
>
> We sent out several notices about this prior to doing it. The Puppet 
> Labs repositories are designed to be the place you get the latest 
> software from Puppet Labs.  This was a conscious choice. 
>
> > 
> > Could you please file an issue (with impact data) about the 
> > distribution name issue.  I believe we considered doing what you 
> > describe, but decided against it.  I don't know the reasons off the 
> > top of my head though, an issue will give us a clear place to track 
> > the request, the impact it has on you and your organization, and the 
> > decision we come to (or have already come to). 
> > 
> >> I am concerned about things breaking. So is there a document detailing 
> >> incompatibilities? Will there be future 2.7 releases? 
> There will be.  I'd imagine you'll see activity slow on it though. 
>
> > 
> > There will be future releases of 2.7.  We will continue to fix bugs in 
> > the 2.7 series, but we are intending to avoid adding any new features 
> > or make any large changes to the behavior of Puppet 2.7. 
>

I am not directly affected by this issue, but I agree with those 
complaining that it was unwise, or at least inhospitable for PL to release 
Puppet 3 into its repositories in this way, especially considering that PL 
intends to continue with maintenance releases in the 2.7 series.  It is 
tantamount to a recommendation for all users to upgrade to the new line 
immediately, and considering the number of breaking changes, I cannot 
believe that that was intended.

The customary way to handle dual lines of packages is to give one line a 
different name, for example "puppet3-*" instead of plain "puppet-*".  
Failing that, it is essential that the package name for the 2.7 series be 
changed, else the PL repository will be near-useless to people who want to 
stay at 2.7 for the time being.  If that's the plan then the first 
"puppet2-*" packages should have been released at the same time that the 
mainline packages were updated to v 3.0.

Alternatively, PL could set up a separate repository for the Puppet 2 
maintenance releases.

Distinguishing the lines only by their version numbers simply isn't useful, 
and dropping v3 packages with their breaking changes into the same 
repository with v2 *will* cause breakage for users.  PL, I urge you to 
reconsider.  Soon.


John

-- 
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/-/AG4SVCmBV1cJ.
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 3 killed my environment variables

[Daniele Sluijters]

Hi,

Sorry, I got confused between two things. It's not the actual Exec type. 
it's when a provider executes a command that the environment cannot be set.

-- 
Daniele Sluijters

On Wednesday, 3 October 2012 15:00:54 UTC+2, Stephen Gran wrote:
>
> Hi, 
>
> On Wed, 2012-10-03 at 05:45 -0700, Daniele Sluijters wrote: 
> > Hello, 
> > 
> > 
> > In Puppet 3 Puppet does its absolute best to make sure $HOME, $USER 
> > and $LOGNAME environment variables are unset and nowhere to be found. 
> > I realise this change was necessary because it caused some weird 
> > start-up issues with Puppet but this also killed our RabbitMQ module. 
> > 
> > 
> > RabbitMQ is written in Erlang and that thing _requires_ a $HOME to be 
> > set as it will try to write an erlang-cookie to it and horribly fail 
> > and go up in flames if it can't. Since Puppet 3 every Exec we have in 
> > the RabbitMQ module now fails because of this. We've tried changing 
> > the command to '$HOME=/var/lib/misc/puppet rabbitmqctl ' 
> > but yet again the Exec type just nukes the environment too. This being 
> > the 'offending' pull request which got 
> > merged: 
> https://github.com/puppetlabs/puppet/commit/14670c5850462472f5efcfc6ea11d2b4cab708a7
>  
> > 
> > 
> > So, short of patching Puppet to not do this or generate static 
> > wrappers for every rabbitmqctl command which then in turn get called 
> > by an Exec, how do we solve this? I really don't feel like generating 
> > wrappers for every Exec that needs one of those environment variables 
> > set. I'd actually expect that Exec would allow me to explicitly pass 
> > in environment variables that I really need set in that case but the 
> > docs don't seem to know anything about that. 
>
> Can you not just set resource defaults like: 
>
> Exec { 
> environment => "HOME=/home/wibble" 
> } 
>
> ? 
>
> Cheers, 
> -- 
> Stephen Gran 
> Senior Systems Integrator - The Guardian 
>
> Please consider the environment before printing this email. 
> -- 
> Visit guardian.co.uk - newspaper of the year 
>
> www.guardian.co.ukwww.observer.co.uk www.guardiannews.com 
>
> On your mobile, visit m.guardian.co.uk or download the Guardian 
> iPhone app www.guardian.co.uk/iphone and iPad edition 
> www.guardian.co.uk/iPad 
>   
> Save up to 37% by subscribing to the Guardian and Observer - choose the 
> papers you want and get full digital access. 
> Visit guardian.co.uk/subscribe 
>
> - 
> This e-mail and all attachments are confidential and may also 
> be privileged. If you are not the named recipient, please notify 
> the sender and delete the e-mail and all attachments immediately. 
> Do not disclose the contents to another person. You may not use 
> the information for any purpose, or store, or copy, it in any way. 
>   
> Guardian News & Media Limited is not liable for any computer 
> viruses or other material transmitted with or as part of this 
> e-mail. You should employ virus checking software. 
>
> Guardian News & Media Limited 
>
> A member of Guardian Media Group plc 
> Registered Office 
> PO Box 68164 
> Kings Place 
> 90 York Way 
> London 
> N1P 2AP 
>
> Registered in England Number 908396 
>
>

-- 
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/-/ghtP6bqOcegJ.
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 3 killed my environment variables

[Stephen Gran]

Hi,

On Wed, 2012-10-03 at 05:45 -0700, Daniele Sluijters wrote:
> Hello,
> 
> 
> In Puppet 3 Puppet does its absolute best to make sure $HOME, $USER
> and $LOGNAME environment variables are unset and nowhere to be found.
> I realise this change was necessary because it caused some weird
> start-up issues with Puppet but this also killed our RabbitMQ module.
> 
> 
> RabbitMQ is written in Erlang and that thing _requires_ a $HOME to be
> set as it will try to write an erlang-cookie to it and horribly fail
> and go up in flames if it can't. Since Puppet 3 every Exec we have in
> the RabbitMQ module now fails because of this. We've tried changing
> the command to '$HOME=/var/lib/misc/puppet rabbitmqctl '
> but yet again the Exec type just nukes the environment too. This being
> the 'offending' pull request which got
> merged: 
> https://github.com/puppetlabs/puppet/commit/14670c5850462472f5efcfc6ea11d2b4cab708a7
> 
> 
> So, short of patching Puppet to not do this or generate static
> wrappers for every rabbitmqctl command which then in turn get called
> by an Exec, how do we solve this? I really don't feel like generating
> wrappers for every Exec that needs one of those environment variables
> set. I'd actually expect that Exec would allow me to explicitly pass
> in environment variables that I really need set in that case but the
> docs don't seem to know anything about that.

Can you not just set resource defaults like:

Exec {
environment => "HOME=/home/wibble"
}

?

Cheers,
-- 
Stephen Gran
Senior Systems Integrator - The Guardian

Please consider the environment before printing this email.
--
Visit guardian.co.uk - newspaper of the year

www.guardian.co.ukwww.observer.co.uk www.guardiannews.com 

On your mobile, visit m.guardian.co.uk or download the Guardian
iPhone app www.guardian.co.uk/iphone and iPad edition www.guardian.co.uk/iPad 
 
Save up to 37% by subscribing to the Guardian and Observer - choose the papers 
you want and get full digital access. 
Visit guardian.co.uk/subscribe 

-
This e-mail and all attachments are confidential and may also
be privileged. If you are not the named recipient, please notify
the sender and delete the e-mail and all attachments immediately.
Do not disclose the contents to another person. You may not use
the information for any purpose, or store, or copy, it in any way.
 
Guardian News & Media Limited is not liable for any computer
viruses or other material transmitted with or as part of this
e-mail. You should employ virus checking software.

Guardian News & Media Limited

A member of Guardian Media Group plc
Registered Office
PO Box 68164
Kings Place
90 York Way
London
N1P 2AP

Registered in England Number 908396

-- 
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] Puppet 3 killed my environment variables

[Daniele Sluijters]

Hello,

In Puppet 3 Puppet does its absolute best to make sure $HOME, $USER and 
$LOGNAME environment variables are unset and nowhere to be found. I realise 
this change was necessary because it caused some weird start-up issues with 
Puppet but this also killed our RabbitMQ module.

RabbitMQ is written in Erlang and that thing _requires_ a $HOME to be set 
as it will try to write an erlang-cookie to it and horribly fail and go up 
in flames if it can't. Since Puppet 3 every Exec we have in the RabbitMQ 
module now fails because of this. We've tried changing the command to 
'$HOME=/var/lib/misc/puppet rabbitmqctl ' but yet again the 
Exec type just nukes the environment too. This being the 'offending' pull 
request which got 
merged: 
https://github.com/puppetlabs/puppet/commit/14670c5850462472f5efcfc6ea11d2b4cab708a7

So, short of patching Puppet to not do this or generate static wrappers for 
every rabbitmqctl command which then in turn get called by an Exec, how do 
we solve this? I really don't feel like generating wrappers for every Exec 
that needs one of those environment variables set. I'd actually expect that 
Exec would allow me to explicitly pass in environment variables that I 
really need set in that case but the docs don't seem to know anything about 
that.

Kind regards,

-- 
Daniele Sluijters

-- 
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/-/iOy3L_m66GUJ.
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] Fileserver error with Puppet 3.0

[Wolfgang Miedl]

On Wednesday, October 3, 2012 1:53:13 PM UTC+2, Arnaud Gomes-do-Vale wrote:
>
> Thank you for your help. Looks like something is still broken. 
>
> I replaced all "allow" directoves in fileserver.conf with allow_ip; I 
> still had the same errors: 
>

I ran into the same issue yesterday, which is caused by an incorrect 
handling of the allow_ip keyword in the parser for fileserver.conf, and 
have filed the following bug report:

http://projects.puppetlabs.com/issues/16686

-- 
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/-/xjI9T4M0uRAJ.
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] How to create a directory if that path does not yet exist?

[Marc Haber]

On Mon, Oct 01, 2012 at 04:11:06PM -0400, Thomas Linkin wrote:
> There is no way in the resource declaration for 'file' to stop it from
> ensuring your symlink is made into a directory. That is because this
> is the state you're asking to have ensured when you compile that
> resource into a catalog. What you may want to do is find a way to have
> the resource either ensure a symlink for those hosts or not be in your
> catalog. I recommend the finding a way to have it ensure a symlink.

Thanks for the explanation. I'm going to use an exec. Ugly, but it
will be easier to understand than the other options you mentioned.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 31958062

-- 
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] Fileserver error with Puppet 3.0

[Arnaud Gomes-do-Vale]

Matthaus Owens  writes:

> In Puppet 3.x, allow directives are limited to hostnames, if you wish
> to allow an ip address, the allow_ip directive should be used. This
> was in response to CVE-2012-3408
> (http://puppetlabs.com/security/cve/cve-2012-3408/).

Thank you for your help. Looks like something is still broken.

I replaced all "allow" directoves in fileserver.conf with allow_ip; I
still had the same errors:

### Broken!
[files]
 path /etc/puppet/files
 allow_ip 129.102.0.0/16
 allow_ip 2001:660:3004::/49

[private]
 path /etc/puppet/files-private/%H
 allow_ip 129.102.0.0/16
 allow_ip 2001:660:3004::/49
# EOF

I then replaced them with "allow *", which fixed the problem but
introduces a change of behavior:

### Working
[files]
 path /etc/puppet/files
 allow *

[private]
 path /etc/puppet/files-private/%H
 allow *
# EOF

This is definitely a regression.

-- 
A

-- 
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] Need help with dashboad configuration..

[Rajeev Iyer]

Hi,

  I am new to this.

Can someone lead me to a step by step configuration for dashboard. The ones 
on the web is too confusing.
Like, it says we need to have an entry for puppet-dashboard in /etc/passwd. 
So how does that look like?

Rajeev

-- 
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/-/JnzTANLHgtcJ.
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] puppet 2.7.9 init.pp error

[SDM]

Hello all,

I have the current configuration with puppet 2.7.9:

in modules/app/manifests

init.pp

import "*"

facesquare.pp

class app::facesquare {
...
}

twitstagram.pp

class app::twitstagram {
 
}

in node file 

include app::facesquare
include app::twitstagram

When i run puppet i get : 
*Erreur**Could not retrieve catalog from remote server: Error 400 on 
SERVER: Could not find class app::facesquare*
If i remove the init.pp file it works correctly.

In fact i have to upgrade a master with puppet 2.6.4 to 2.7.9. But old 
puppet scripts generate errors cause of the init.pp file (i suppose). 

Is the init.pp file still usefull with puppet 2.7.9 ?

Thx for your help.

Seb.

-- 
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/-/VhubDVUjuAQJ.
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 2.7 v 3.0 in the PuppetLabs yum repo

[Mister Guru]

On 2 Oct 2012, at 21:17, Robert Rothenberg wrote:

> I am using CentOS 6 with the PuppetLabs yum repo from 
> http://yum.puppetlabs.com
> 
> I noticed that today version 3 is available on the repo, so of course, an 
> upgrade to Puppet is available.
> 
> Ideally, it would have been better if v3 had a different distribution name, 
> so that systems with v2.7.x are not upgraded (especially if there will be 
> future releases if v2.7).
> 
> I am concerned about things breaking. So is there a document detailing 
> incompatibilities? Will there be future 2.7 releases?
> 
> 
I noticed this this morning as well, that some of my new cloud boxe installed 
puppet client 3, I'm also currently wondering if this is going to affect my new 
builds ... 

> 
> 
> -- 
> 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/-/o33U4atSmJwJ.
> 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.

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

[Mister Guru]

On 3 Oct 2012, at 03:35, Ryan Coleman wrote:

> Hello,
> 
> If you weren't at PuppetConf or didn't catch my talk, here's a quick
> recap. I'm product owner for the Puppet Forge team which formed in
> July with 2 awesome engineers and an equally awesome designer. We're a
> team dedicated to the Forge and while ramping up, we've shipped three
> small improvements to the Forge that we hope you enjoy.

Good Morning Ryan! Nice to hear news about the puppet forge! Product owner 
huh?? Hey guys, now we know who to bug when it come to the Forge!

> 
> * Two lists were added to the homepage, highlighting recently active
> modules and contributors
> * An authors Gravatar is now displayed on each module page.
> * Today, the Forge will now retrieve information about GitHub issues
> and pull requests for a module for display on a module page. This has
> been automatically enabled for any module that lists GitHub as its
> 'Project Issue Tracker URL'.

I noticed this last night, it was great. I was stuck with a module I downloaded 
- I looked it up on the forge, and I noticed a link to the git page - I then 
realised the problem was ummm. me, using the module in the not right way. 
Most useful, saved me bashing my keyboard against the computer

> The team is just getting started. In the mean-time, we've been making
> improvements to our back-end services, user-testing new feature ideas
> and getting ready for the next wave of functionality. Our next
> features will focus on these two areas. A) Making it easy for you to
> contribute your module & B) Improve the information you have to make a
> decision about which module to use.
> 
> As we develop and test ideas to address these goals, we want your feedback!
> 

Ah yes - Point B - How about ranking by downloads? I'm sure you can pull the 
stats from Forge servers. I'm assuming people log into the forge to do some 
background before running public code, for compliance, and in my case to 
suppress paranoia :)

How about making the forge a bit more social - For example how about being able 
to review a module, or write a comment about it on the forge? That way, it's a 
bit easier for the author to get some feedback, and also for others to get an 
idea how 'good' the module is.

That would come in useful when some modules depend on others, if I'm trying to 
install module A, and A insists on B, C, and D - I'd rather read up on others, 
who went live straight away without testing and are complaining about their 
broken systems  Oh, I mean, I'd like to read the reviews from other users 
praising the awesomeness of the forge.

Imagine that - In 6 months we could have modules writers competing against each 
other - now that would be cool - Author rankings, (obviously Puppet Labs 
Employees and modules excluded!) - and peer competition could only lead to 
better code

> Feel free to file bugs, features --anything really-- to our Redmine
> project: https://projects.puppetlabs.com/projects/module-site/issues
> Aside from that and this user list, you may always email me directly
> -- r...@puppetlabs.com -- or find me on #puppet as ryancoleman. I'm
> always connected via ZNC so if you don't get an immediate response in
> IRC, know that I'll see your message and reply if I can.
> 
> 
> Finally, if you haven't tried out the Forge in a while, please give it
> another go. http://forge.puppetlabs.com -- Each day new content is
> added or updated and there's some truly awesome stuff amongst the 500+
> Forge modules. There's also a blog-post series showcasing a new one
> each week. links.puppetlabs.com/motw
> 
> Thanks for your time and for being an awesome community!
> 
> --Ryan
> 
> -- 
> 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.
> 

-- 
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] activerecord and puppet-3.0.0

[Jonathan Gazeley]

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

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

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



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


I found this thread which seems to describe the same behaviour, but 
there are no replies:


https://groups.google.com/forum/?fromgroups=#!topic/puppet-dev/D85TsZ70LKQ

Anyone got any ideas?

Thanks,
Jonathan

--
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 2.7 v 3.0 in the PuppetLabs yum repo

[Robert Rothenberg]

On Wednesday, October 3, 2012 1:36:22 AM UTC+1, Michael Stanhke wrote:
>
> On Tue, Oct 2, 2012 at 1:30 PM, Jeff McCune 
> > 
> wrote: 
> > On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg 
> > > 
> wrote: 
> >> I am using CentOS 6 with the PuppetLabs yum repo from 
> >> http://yum.puppetlabs.com 
> >> 
> >> I noticed that today version 3 is available on the repo, so of course, 
> an 
> >> upgrade to Puppet is available. 
> > 
> > Yes, this major version update went live on Monday.  There are a 
> > number of breaking-changes between 2.7 and 3.0 which are described at: 
> > http://links.puppetlabs.com/telly_breaking_changes 
> > 
> >> Ideally, it would have been better if v3 had a different distribution 
> name, 
> >> so that systems with v2.7.x are not upgraded (especially if there will 
> be 
> >> future releases if v2.7). 
>
> We sent out several notices about this prior to doing it. The Puppet 
>

Not everyone subscribes to notices or reads the mailing lists regularly.
 

> Labs repositories are designed to be the place you get the latest 
> software from Puppet Labs.  This was a conscious choice. 
>

Yes. And users would expect to receive things like security updates and bug 
fixes fairly quickly.

But a major upgrade than can break existing infrastructure should not have 
the same distribution name. It means that users who aren't ready to upgrade 
cannot use yum--- they will have to manually install updates to 2.7 because 
there will always be a newer v3 (unless you decide to create a separate 
distribution name for puppet 2.7, so that users can track that instead).
 
I maintain a network that uses a non-standard Puppet installation (where 
manifests are distributed using git hooks instead of using a Puppet 
master). So my concerns about a major upgrade are that much greater.

I should add that I work for a small company that chose Puppet because we 
don't want to use large amounts of our time with system administration. So 
releasing a major upgrade in this manner negates that reason.

> 
> > Could you please file an issue (with impact data) about the 
> > distribution name issue.  I believe we considered doing what you 
>

Under what project should the issue be filed?
 

> > describe, but decided against it.  I don't know the reasons off the 
> > top of my head though, an issue will give us a clear place to track 
> > the request, the impact it has on you and your organization, and the 
> > decision we come to (or have already come to). 
> > 
> >> I am concerned about things breaking. So is there a document detailing 
> >> incompatibilities? Will there be future 2.7 releases? 
>
 

> There will be.  I'd imagine you'll see activity slow on it though. 
>
>

 

> > 
> > There will be future releases of 2.7.  We will continue to fix bugs in 
> > the 2.7 series, but we are intending to avoid adding any new features 
> > or make any large changes to the behavior of Puppet 2.7. 
> > 
> > Hope this helps, 
> > -Jeff 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "Puppet Users" group. 
> > 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/-/XKCXN15MfqMJ.
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 Forge Happenings

[aussielunix]

G`Day !

On Wednesday, 3 October 2012 12:35:34 UTC+10, Ryan Coleman wrote:
>
> Hello, 
>
> If you weren't at PuppetConf or didn't catch my talk, here's a quick 
> recap. I'm product owner for the Puppet Forge team which formed in 
> July with 2 awesome engineers and an equally awesome designer. We're a 
> team dedicated to the Forge and while ramping up, we've shipped three 
> small improvements to the Forge that we hope you enjoy. 
>
> It is good to see the Forge getting some love. 
*snip* 

> As we develop and test ideas to address these goals, we want your 
> feedback! 
>
> Feel free to file bugs, features --anything really-- to our Redmine 
> project: https://projects.puppetlabs.com/projects/module-site/issues 
> Aside from that and this user list, you may always email me directly 
> -- ry...@puppetlabs.com  -- or find me on #puppet as 
> ryancoleman. I'm 
> always connected via ZNC so if you don't get an immediate response in  

IRC, know that I'll see your message and reply if I can. 
>
> I have put down some of my thoughts around modules, the forge and PMT. 
https://gist.github.com/3825350
I am often lurking in #puppet during my day (UTC+10) if anyone wants to 
ping me about my notes

Thanks for your time and for being an awesome community! 
>
> --Ryan 
>

Cheers
Mick Pollard
@aussielunix 

-- 
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/-/iedIHySZ6qEJ.
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 3.0.0 and Augeas on Ubuntu Lucid 10.04

[Dominic Cleal]

On 02/10/12 14:49, Paul Tötterman wrote:
> Hi,
> 
> My manifests used to work with 2.7.19 but after upgrading to 3.0.0 I
> keep getting:
> 
> Error: /Stage[main]/.../Augeas[...]: Could not evaluate: uninitialized
> constant Augeas::NO_LOAD

This will be a dependency on ruby-augeas 0.3.0 or higher.  I'm pretty
sure we've had this in a different form though since 2.7.12, but perhaps
if you didn't have any Augeas resources that changed (as opposed to just
checked and passed) then you might not have seen it, or I've
misunderstood the problem.

https://projects.puppetlabs.com/issues/13107 was raised when we
accidentally added this dependency in 2.7.12.

Ubuntu released a backport of 0.3.0 into lucid-backports which will
resolve the issue for you here:
  http://packages.ubuntu.com/lucid-backports/libaugeas-ruby

https://projects.puppetlabs.com/issues/16203 was also raised to make
sure the package depends or recommends on 0.3.0 as a minimum version,
but this hasn't been completed yet.

-- 
Dominic Cleal
Red Hat Consulting
m: +44 (0)7817 878113

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