Re: [Puppet Users] PuppetMaster LB on top of OCFS2

[Wil Cooley]

On Jul 18, 2013 10:00 AM, "Jakov Sosic"  wrote:

> I'm trying to design a solution that will encompass load balancing
> puppet master.
>
> I have two nodes, and idea is to connect them with DRBD, put some
> cluster aware filesystem (OCFS2 or GFS2), and just link /etc/puppet and
> /var/lib/puppet on both nodes to cluster FS.
>
> Accessing to the masters would be load balanced by round-robin DNS.
>
> Would this work? Is there any problem that both masters are using the
> same directories? Any possibility of data corruption or potential
> race-conditions?

This would be risky if not disastrous. I am wary of anything that might
depend on file locking on shared file systems, unless it is well-supported
by the vendor.

You should be able to share /etc/puppet as this should be read-only for the
master process (you might have a function that generates or writes files
here, but that would be unusual). But you could more simply maintain this
with SCM checkouts, unless you have the agent generating files here and
precise consistency required.

For /var, however, you might divide into data subsets, some that you could
safely share and some definitely not:

  - Reports processed with "store" are named with timestamps and node
names, so that might be ok. And a single report, stored in a single file,
is unlikely to be a big deal if lost.

  - Reports processed with "rrdgraph" seem like a big risk.

  - The CA store seems highly vulnerable to race conditions, unless you
have such a low rate of node provisioning you can guarantee serial access
-- but you probably would not need an HA setup in that case.

 - The filebucket I would expect to be risky -- seems like a high
probability of attempted concurrent writes of the same file.

 - Other stuff is specific to the node agent and node master that you would
not want to share in any case.

You might consider an active/passive setup with a front-end load balancer,
where one of the above data subsets is effectively read-only for the
passive server. You could distribute the load by taking advantage of the
ability to configure the various master roles (fileserver, catalog,
inventory, filebucket, CA, etc.) with different hostnames and ports. It
would still be a risk of corruption in a split-brain situation, but that's
often (always?) a danger with shared-storage filesystems.

Wil

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: puppet cert error

[G M]

Thanks. This fixed it for me. :) :D

On Wednesday, July 10, 2013 11:13:28 PM UTC+10, binaryred wrote:
>
> Felipe,
>
> Not sure if you found an answer to this, but I had the same problem and 
> found that my problem was corrupt certificate requests were generated while 
> the disk was full.  After I cleaned up the disk, I had to clear out the 
> /var/lib/puppet/ssl/ca/requests directory and then everything worked fine.
>
> Jason
>
> On Tuesday, May 7, 2013 1:24:08 PM UTC-4, Felipe Salum wrote:
>>
>> Hi guys,
>>
>> After a disk space issue puppet is complaining when agents are running.
>>
>> # puppet cert list --all
>> Error: header too long
>>
>> I think my certificates get corrupted, but the /var/lib/puppet/ssl 
>> directory seems to be ok.
>>
>> Have you seen this before ?
>>
>> Regards,
>> Felipe
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] puppet master and fileserver separate problem

[Aviar]

my environment：

192.168.0.13puppet.uc.local
192.168.0.14puppetca.uc.local
192.168.0.15report.uc.local
192.168.0.16fileserver.uc.local
192.168.0.17agent01.uc.local


i want run a master as fileserver (fileserver.uc.local)
the puppet.uc.local and fileserver.uc.local use one ca.pem

on puppet.uc.local, i wrote a class for test

class test {
notify { "hello world": }

file { '/home/puppet/hello':
owner => "root",
group => "root",
mode => 644,
ensure => "file",
source => "puppet://fileserver.uc.local/extra_files/hello",
}
}

but i found that, the agent fetch file_metadata from fileserver.uc.local 
and fetch file_content from puppet.uc.local

puppet.uc.local:

[2013-07-19 18:25:07] DEBUG accept: 192.168.0.17:43547
[2013-07-19 18:25:07] DEBUG Puppet::Network::HTTP::WEBrickREST is invoked.
[2013-07-19 18:25:07] 192.168.0.17 - - [19/Jul/2013:18:25:07 CST] "GET 
/production/node/agent01.uc.local? HTTP/1.1" 200 4032
[2013-07-19 18:25:07] - -> /production/node/agent01.uc.local?
[2013-07-19 18:25:07] DEBUG close: 192.168.0.17:43547
[2013-07-19 18:25:07] DEBUG accept: 192.168.0.17:43549
[2013-07-19 18:25:07] DEBUG Puppet::Network::HTTP::WEBrickREST is invoked.
[2013-07-19 18:25:07] 192.168.0.17 - - [19/Jul/2013:18:25:07 CST] "POST 
/production/catalog/agent01.uc.local HTTP/1.1" 200 1560
[2013-07-19 18:25:07] - -> /production/catalog/agent01.uc.local
[2013-07-19 18:25:07] DEBUG close: 192.168.0.17:43549
[2013-07-19 18:25:07] DEBUG accept: 192.168.0.17:43551
[2013-07-19 18:25:07] DEBUG Puppet::Network::HTTP::WEBrickREST is invoked.
[2013-07-19 18:25:07] 192.168.0.17 - - [19/Jul/2013:18:25:07 CST] "GET 
/production/file_content/extra_files/hello HTTP/1.1" 200 1300
[2013-07-19 18:25:07] - -> /production/file_content/extra_files/hello
[2013-07-19 18:25:07] DEBUG close: 192.168.0.17:43551
[2013-07-19 18:25:07] DEBUG accept: 192.168.0.17:43552
[2013-07-19 18:25:07] DEBUG Puppet::Network::HTTP::WEBrickREST is invoked.
[2013-07-19 18:25:07] 192.168.0.17 - - [19/Jul/2013:18:25:07 CST] "GET 
/production/file_content/extra_files/hello HTTP/1.1" 200 1300
[2013-07-19 18:25:07] - -> /production/file_content/extra_files/hello
[2013-07-19 18:25:07] DEBUG close: 192.168.0.17:43552



fileserver.uc.local:

[2013-07-19 18:25:07] DEBUG accept: 192.168.0.17:44945
[2013-07-19 18:25:07] DEBUG Puppet::Network::HTTP::WEBrickREST is invoked.
[2013-07-19 18:25:07] 192.168.0.17 - - [19/Jul/2013:18:25:07 CST] "GET 
/production/file_metadatas/plugins?links=manage&recurse=true&ignore=.svn&ignore=CVS&ignore=.git&checksum_type=md5
 
HTTP/1.1" 200 278
[2013-07-19 18:25:07] - -> 
/production/file_metadatas/plugins?links=manage&recurse=true&ignore=.svn&ignore=CVS&ignore=.git&checksum_type=md5
[2013-07-19 18:25:07] DEBUG close: 192.168.0.17:44945
[2013-07-19 18:25:07] DEBUG accept: 192.168.0.17:44947
[2013-07-19 18:25:07] DEBUG Puppet::Network::HTTP::WEBrickREST is invoked.
[2013-07-19 18:25:07] 192.168.0.17 - - [19/Jul/2013:18:25:07 CST] "GET 
/production/file_metadata/extra_files/hello?links=manage HTTP/1.1" 200 279
[2013-07-19 18:25:07] - -> 
/production/file_metadata/extra_files/hello?links=manage
[2013-07-19 18:25:07] DEBUG close: 192.168.0.17:44947


why? am i make a mistake
i wish you could understand, english is not my native language

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Package install error

[sneha more]

On Friday, July 19, 2013 12:45:50 AM UTC+5:30, Mark Hatch wrote:
>
> Here is my manifest...
>
> package { 'tractor blade':
> provider => 'rpm',
> ensure   => present,
> source   => 
> 'puppet:///modules/mpsvfx/tractor-blade-1.7_1191418-linuxFC12_gcc44icc121.x86_64.rpm',
> name => 
> 'tractor-blade-1.7_1191418-linuxFC12_gcc44icc121.x86_64.rpm',
> }
>
>
> Here is where that file is...
>
>
> ...modules/mpsvfx/files/tractor-blade-1.7_1191418-linuxFC12_gcc44icc121.x86_64.rpm
>
> Here is the error I get...
>
> Error: Execution of '/bin/rpm -i 
> puppet:///modules/mpsvfx/tractor-blade-1.7_1191418-linuxFC12_gcc44icc121.x86_64.rpm'
>  
> returned 1: error: open of 
> puppet:///modules/mpsvfx/tractor-blade-1.7_1191418-linuxFC12_gcc44icc121.x86_64.rpm
>  
> failed: No such file or directory
>
> Anybody know what I am doing wrong?
>
> Thanks.
> Mark
>

Hi Mark,
 John is right, in package resource you can not directly use source as 
puppet file server, 
 OR i think, you can solve this issue by first transferring the .rpm 
file by file resource and then installing it through exec resource by  rpm 
-ivh command.
 This is work around solution for what you are doing.

Regards,
Sneha.

 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Resolving duplicated resources

[Adam Cohen]

So I've run into a bit of a problem that has bitten many others in the 
past: I'm using module A and module B which both require package C, and I'm 
ending up with a duplicated resource definition for the mod_ssl package.  
In my case, the modules are puppet-rvm and 
puppetlabs-apache  which 
both require *mod_ssl*.

The problem stems from here:

in puppet-rvm:

puppet-rvm/manifests/passenger/apache/centos/pre.pp

class rvm::passenger::apache::centos::pre {
  # Dependencies
  if ! defined(Package['httpd'])   { package { 'httpd':   ensure => 
present } }
  if ! defined(Package['httpd-devel']) { package { 'httpd-devel': ensure => 
present } }
*  if ! defined(Package['mod_ssl']) { package { 'mod_ssl': ensure => 
present } }*
}


and in puppetlabs-apache:

puppetlabs-apache/manifests/params.pp:63

$mod_packages = { 
  'proxy_html' => 'mod_proxy_html', 
  'python' => 'mod_python',
  'shibboleth' => 'shibboleth',
*  'ssl' => 'mod_ssl', *
  'wsgi' => 'mod_wsgi',
  'dav_svn' => 'mod_dav_svn', 
   'xsendfile' => 'mod_xsendfile', 
}

puppetlabs-apache/modules/apache/manifests/mod.pp:35

package { $mod_packages: ensure => present, 
 require => Package['httpd'], 
  before => File["${mod_dir}/${mod}.load"], 
}

So the rvm module attempts to resolve a conflict by using "*! 
defined(Package['mod_ssl'})*", while the apache module just defines an 
array of packages and then requires them all.  This causes a failure if the 
apache module is included after the rvm module, since the apache module 
doesn't check to see if any of the packages are already defined.

It seems there are a few ways to remedy this, such as defining a new class 
for the mod_ssl 
packageand
 including that class in both modules.  However, I'd like to figure out 
if it's possible to rectify this situation without modifying either 
module.  I've tried in vain to use many different permutations of require 
and -> for resource ordering to ensure that the puppetlabs-apache module 
gets loaded first, but I just can't manage to get it to work. it seems no 
matter what I do, the rvm module is loaded first, which causes the 
puppetlabs-apache module to fail.

So can anyone tell me how I can get around this problem? I'd very much like 
to modify the puppetlabs-apache module, but since they use an array to 
define the required mod packages, it makes it a little tricky to check if 
each one is defined before using it, since as far as I know it's not very 
straight forward to iterate over an array in the puppet DSL.  Thanks for 
any suggestions!

Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Re: Package install error

[Ripunjay Godhani]

yes Sneha is right


On 19 July 2013 16:44, sneha more  wrote:

>
>
> On Friday, July 19, 2013 12:45:50 AM UTC+5:30, Mark Hatch wrote:
>>
>> Here is my manifest...
>>
>> package { 'tractor blade':
>> provider => 'rpm',
>> ensure   => present,
>> source   => 'puppet:///modules/mpsvfx/**
>> tractor-blade-1.7_1191418-**linuxFC12_gcc44icc121.x86_64.**rpm',
>> name => 'tractor-blade-1.7_1191418-**
>> linuxFC12_gcc44icc121.x86_64.**rpm',
>> }
>>
>>
>> Here is where that file is...
>>
>> ...modules/mpsvfx/files/**tractor-blade-1.7_1191418-**
>> linuxFC12_gcc44icc121.x86_64.**rpm
>>
>> Here is the error I get...
>>
>> Error: Execution of '/bin/rpm -i puppet:///modules/mpsvfx/**
>> tractor-blade-1.7_1191418-**linuxFC12_gcc44icc121.x86_64.**rpm' returned
>> 1: error: open of puppet:///modules/mpsvfx/**tractor-blade-1.7_1191418-**
>> linuxFC12_gcc44icc121.x86_64.**rpm failed: No such file or directory
>>
>> Anybody know what I am doing wrong?
>>
>> Thanks.
>> Mark
>>
>
> Hi Mark,
>  John is right, in package resource you can not directly use source as
> puppet file server,
>  OR i think, you can solve this issue by first transferring the .rpm
> file by file resource and then installing it through exec resource by  rpm
> -ivh command.
>  This is work around solution for what you are doing.
>
> Regards,
> Sneha.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Template not putting in new lines.

[mepunite]

That is exactly the problem ...
Thanks you saved me hours of head scratching.

On Wednesday, June 5, 2013 5:06:38 PM UTC+1, Javi Fontan wrote:
>
> I think that the problem is that you are converting the array into a 
> string: 
>
>  class { "test::v1_0" : 
> extra_hosts => "$extra_hosts", 
>   } 
>
> Try taking out the "; 
>
>  class { "test::v1_0" : 
> extra_hosts => $extra_hosts, 
>   } 
>
> On Wed, Jun 5, 2013 at 6:00 PM, mepunite > 
> wrote: 
> > hi all, 
> > Ive been having a bit of a trouble with something that should be pretty 
> > simple. 
> > My goal is to create a host file on a node with IP address and hostname 
> > (specified in the node manifest). I created the manifests and templates 
> > below but when I use them I get a hosts file without spaces or newlines, 
> > like below. 
> > 
> > Please help me figure out how do I add the spaces and new lines? 
> > 
> > Or where in the puppet code can I trace this back to find out what is 
> going 
> > wrong ? 
> > 
> > current hosts file: 
> > " 
> > 
> 10.24.43.20ds.blabla.net10.24.43.35static.blabla.net10.24.43.50alert.blabla.net10.24.43.50blocked.something.com
>  
> > " 
> > 
> > At the bottom of the topic is the list of versions and rpms 
> > 
> > The template file looks like this: 
> > test/templates/v1_0/templates/hosts.TEMPLATE 
> > 8<- 
> > 
> > <% extra_hosts.each do |ip,address| %> 
> > 
> > <%= ip %> <%= address %> 
> > 
> > <% end %> 
> > 
> > 8<--- 
> > 
> > my component manifest  file looks like this: 
> > test/v1_0/standard.pp 
> > 8<-- 
> > class test::v1_0::standard 
> > ( 
> >   $extra_hosts, 
> > ) 
> > { 
> >   class { "test::v1_0" : 
> > extra_hosts => "$extra_hosts", 
> >   } 
> >   file { "/opt/environment/" : 
> > ensure => directory, 
> > purge => true, 
> > recurse => true, 
> > force => true, 
> > mode => 0555, 
> > owner => root, 
> > group => root, 
> >   } 
> > } # end of class 
> > 8<-- 
> > 
> > the test/v1_0.pp module file 
> > 8<-- 
> > class test::v1_0 
> > ( 
> >   $extra_hosts, 
> > ) 
> > { 
> >   file { "/opt/environment/etc" : 
> > mode => "0555", 
> > owner => "root", 
> > group => "root", 
> > purge => true, 
> > recurse => true, 
> > force => true, 
> > ensure => directory, 
> >   } 
> >   file { "/opt/environment/etc/hosts" : 
> > content => 
> > 
> template('/var/components/test/templates/v1_0/templates/hosts.TEMPLATE'), 
> > mode => "0444", 
> > owner => "root", 
> > group => "root", 
> > ensure => present, 
> >   } 
> > } # end of class 
> > 8<--- 
> > 
> > 
> > And finally my node manifest: 
> > 8<--- 
> > ## Common variables 
> > ## 3rd octet of the environment 
> > $env_net   = "43" 
> > # Nodes 
> > node default { 
> >  class { 
> >"test::v1_0::standard" : 
> >extra_hosts=> [ 
> >[ "10.24.${env_net}.20" , 
> > "ds.blabla.net" ], 
> >[ "10.24.${env_net}.35" , 
> > "static.blabla.net" ], 
> >[ "10.24.${env_net}.50" , 
> > "alert.blabla.net" ], 
> >[ "10.24.${env_net}.50" , 
> > "blocked.something.com" ], 
> > ], 
> >  } 
> > 
> > } 
> > 8<- 
> > 
> > Versions: 
> > Ruby 1.8.7 
> > Puppet 3.2.1 
> > 
> > OS: 
> > Centos 6.3 
> > 
> > RPMs 
> > Ruby: 
> > ruby-1.8.7.352-10.el6_4.x86_64 
> > ruby-rdoc-1.8.7.352-10.el6_4.x86_64 
> > rubygem-json-1.5.5-1.el6.x86_64 
> > ruby-shadow-1.4.1-13.el6.x86_64 
> > ruby-augeas-0.4.1-1.el6.x86_64 
> > ruby-rgen-0.6.2-1.el6.noarch 
> > ruby-libs-1.8.7.352-10.el6_4.x86_64 
> > ruby-irb-1.8.7.352-10.el6_4.x86_64 
> > rubygems-1.3.7-1.el6.noarch 
> > libselinux-ruby-2.0.94-5.3.el6.x86_64 
> > 
> > Puppet: 
> > puppet-3.2.1-1.el6.noarch 
> > puppet-server-3.2.1-1.el6.noarch 
> > puppetlabs-release-6-6.noarch 
> > 
> > 
> > 
> > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Puppet Users" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to puppet-users...@googlegroups.com . 
> > To post to this group, send email to 
> > puppet...@googlegroups.com. 
>
> > Visit this group at http://groups.google.com/group/puppet-users?hl=en. 
> > For more options, visit https://groups.google.com/groups/opt_out. 
> > 
> > 
>
>
>
> -- 
> Javier Fontán Muiños 
> Project Engineer 
> OpenNebula - The Open Source Toolkit for Data Center Virtualization 
> www.OpenNebula.org | jfo...@opennebula.org  | @OpenNebula 
>

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

Re: [Puppet Users] Announce: Puppet 3.2.3 Available

[Moses Mendoza]

Hi Justin,

Yes, I'll try to get those up today.

Moses

On Wed, Jul 17, 2013 at 3:37 PM, Justin Brown  wrote:
> Moses,
>
> The Fedora 19 packages have not been updated. Could you issue packages for
> http://yum.puppetlabs.com/fedora/f19/?
>
> Thanks,
> Justin
>
>
> On Mon, Jul 15, 2013 at 2:18 PM, Moses Mendoza  wrote:
>>
>> 3.2.3 is a bugfix release of the Puppet 3.2 series. It fixes some
>> Windows bugs introduced in 3.2.0, as well as a few performance
>> problems and miscellaneous bugs.
>>
>> ===
>> ## Puppet 3.2.3 Downloads ##
>> ===
>>
>> Source: https://downloads.puppetlabs.com/puppet/puppet-3.2.3.tar.gz
>>
>> RPM and deb packages available in the Puppet Labs repositories at:
>> http://yum.puppetlabs.com and http://apt.puppetlabs.com
>>
>> Gems are available via rubygems at
>> https://rubygems.org/downloads/puppet-3.2.3.gem
>>   or by using `gem install puppet`
>>
>> Mac package is available at
>> https://downloads.puppetlabs.com/mac/puppet-3.2.3.dmg
>>
>> Windows package is available at
>> https://downloads.puppetlabs.com/windows/puppet-3.2.3.msi
>>
>> Please report feedback via the Puppet Labs Redmine site, using an
>> affected puppet version of 3.2.3:
>> https://projects.puppetlabs.com/projects/puppet/
>>
>> 
>> ## Puppet 3.2.3 Contributors ##
>> 
>>
>> Adrien Thebo, Andrew Parker, Dustin J. Mitchell, Josh Cooper, Josh
>> Partlow, Justin Stoller, Matthaus Owens, Moses Mendoza, Nick
>> Fagerlund, Patrick Carlisle
>>
>> =
>> ## Puppet 3.2.3 Release Notes ##
>> =
>>
>> ### Windows Fixes
>>
>> This release fixes several Windows bugs that couldn't be targeted for
>> earlier 3.2 releases.
>>
>> * [#20768: windows user provider can not manage password or home
>> directory](https://projects.puppetlabs.com/issues/20768) --- This was
>> a regression in 3.2.0/3.2.1.
>> * [#21043: setting in puppet.conf ignored on Windows in Puppet
>> 3.2.1](https://projects.puppetlabs.com/issues/21043) --- This was a
>> regression in 3.2.0/3.2.1.
>> * [#16080: Service provider broken in Windows Server
>> 2012](https://projects.puppetlabs.com/issues/16080) --- This affected
>> all previous Puppet versions.
>> * [#20787: 'puppet resource group' takes incredibly long on
>> Windows](https://projects.puppetlabs.com/issues/20787) --- This
>> affected all previous Puppet versions.
>> * [#20302: Windows File.executable? now returns false on ruby
>> 1.9](https://projects.puppetlabs.com/issues/20302)
>> * [#21280: Don't create c:\dev\null in windows
>> specs](https://projects.puppetlabs.com/issues/21280) --- This was only
>> relevant to Puppet developers.
>>
>> ### Logging and Reporting Fixes
>>
>> * [#20383: Bring back helpful error messages like prior to Puppet
>> 3](https://projects.puppetlabs.com/issues/20383) --- This was a
>> regression from 3.0.0, which caused file names and line numbers to
>> disappear from duplicate resource declaration errors.
>> * [#20900: tagmail triggers in --onetime mode without changes after
>> upgrade from 3.1.1 to
>> 3.2.1](https://projects.puppetlabs.com/issues/20900) --- This was a
>> regression in 3.2.0/3.2.1.
>> * [#20919: Logging behaviour issues in
>> 3.2.1](https://projects.puppetlabs.com/issues/20919) --- This was a
>> regression in 3.2.0/3.2.1, which caused noisy logging to the console
>> even if the `--logdest` option was set.
>>
>> ### Performance Fixes
>>
>> * [#21376: Stack level too deep after updating from 3.1.1 to
>> 3.2.2](https://projects.puppetlabs.com/issues/21376) --- This would
>> sometimes cause total failures when importing a large number of
>> manifest files (such as with the `import nodes/*.pp` idiom).
>> * [#21320: Puppet daemon may sleep for 100 years after receiving USR1
>> on 64 bit systems](https://projects.puppetlabs.com/issues/21320) ---
>> MCollective's Puppet plugin uses puppet agent's USR1 signal to trigger
>> a run if the agent is running; on 64-bit systems, this could cause
>> puppet agent to keep running, but stop doing scheduled configuration
>> runs. This was caused by a bug in Ruby \< 2.0, but we modified Puppet
>> to work around it.
>> * [#20901: `puppet --version` is unnecessarily
>> slow](https://projects.puppetlabs.com/issues/20901) --- This was a
>> regression in 3.2.0/3.2.1.
>>
>> ### Misc Fixes
>>
>> * [#21264: parser = future breaks executing functions as class
>> defaults](https://projects.puppetlabs.com/issues/21264)
>>
>> ### All 3.2.3 Changes
>>
>> [See here for a list of all changes in the 3.2.3
>> release.](https://projects.puppetlabs.com/versions/410)
>>
>> ==
>> ## Puppet 3.2.3 Changelog ##
>> ==
>>
>> Adrien Thebo (1):
>>   6a0127f (#20383) Provide location of duplicate resource in error
>>
>> Andrew Parker (2):
>>   f19c8f2 (Maint) Cleanup specs
>>   ec6b51a (#21264) Update rgen dependency to 0.6.5
>>
>> Dustin J. Mitchell (1):
>>   b1a5092 clean up doc

[Puppet Users] undefined method `use_ssl=' on Debian 7, Puppet Enterprise 3.0.0

[Mathias Kaufmann]

Hi,

I've tested puppet on Debian 7, 64bit. When I run "puppet node classify" I 
get an error as shown below. Is this a configuration-problem or a bug?

root@puppet:/etc/netboot# /opt/puppet/bin/puppet node classify 
--enc-server=localhost --enc-port=443 --enc-auth-user=console 
--enc-auth-passwd=password --node-group=app_server node-06.mydomain


Error: undefined method `use_ssl=' for 
#
Error: Try 'puppet help node classify' for usage

Thanks
Mathias



-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Resolving duplicated resources

[Paul Tötterman]

Hi,

It seems there are a few ways to remedy this, such as defining a new class 
> for the mod_ssl 
> packageand
>  including that class in both modules.  However, I'd like to figure out 
> if it's possible to rectify this situation without modifying either 
> module.  I've tried in vain to use many different permutations of require 
> and -> for resource ordering to ensure that the puppetlabs-apache module 
> gets loaded first, but I just can't manage to get it to work. it seems no 
> matter what I do, the rvm module is loaded first, which causes the 
> puppetlabs-apache module to fail.
>
> So can anyone tell me how I can get around this problem? I'd very much 
> like to modify the puppetlabs-apache module, but since they use an array to 
> define the required mod packages, it makes it a little tricky to check if 
> each one is defined before using it, since as far as I know it's not very 
> straight forward to iterate over an array in the puppet DSL.  Thanks for 
> any suggestions!
>

https://forge.puppetlabs.com/puppetlabs/stdlib -- check out 
ensure_packages().

Cheers,
Paul

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Announce: Puppet 3.2.3 Available

[Darin Perusich]

FWIW Puppet Labs could really simplify the creation of packages for
linux distributions by leveraging the Open Build Service, formerly
OpenSUSE Build Service. All you need to do to add a distribution is
check a box and which architectures and the systems will automagically
build and deploy the packages for you. For a company that deals in
automation I'd think such a tool would be right up your alley;-)

You can find the documentation and software http://openbuildservice.org/

--
Later,
Darin


On Fri, Jul 19, 2013 at 11:21 AM, Moses Mendoza  wrote:
> Hi Justin,
>
> Yes, I'll try to get those up today.
>
> Moses
>
> On Wed, Jul 17, 2013 at 3:37 PM, Justin Brown  
> wrote:
>> Moses,
>>
>> The Fedora 19 packages have not been updated. Could you issue packages for
>> http://yum.puppetlabs.com/fedora/f19/?
>>
>> Thanks,
>> Justin
>>
>>
>> On Mon, Jul 15, 2013 at 2:18 PM, Moses Mendoza  wrote:
>>>
>>> 3.2.3 is a bugfix release of the Puppet 3.2 series. It fixes some
>>> Windows bugs introduced in 3.2.0, as well as a few performance
>>> problems and miscellaneous bugs.
>>>
>>> ===
>>> ## Puppet 3.2.3 Downloads ##
>>> ===
>>>
>>> Source: https://downloads.puppetlabs.com/puppet/puppet-3.2.3.tar.gz
>>>
>>> RPM and deb packages available in the Puppet Labs repositories at:
>>> http://yum.puppetlabs.com and http://apt.puppetlabs.com
>>>
>>> Gems are available via rubygems at
>>> https://rubygems.org/downloads/puppet-3.2.3.gem
>>>   or by using `gem install puppet`
>>>
>>> Mac package is available at
>>> https://downloads.puppetlabs.com/mac/puppet-3.2.3.dmg
>>>
>>> Windows package is available at
>>> https://downloads.puppetlabs.com/windows/puppet-3.2.3.msi
>>>
>>> Please report feedback via the Puppet Labs Redmine site, using an
>>> affected puppet version of 3.2.3:
>>> https://projects.puppetlabs.com/projects/puppet/
>>>
>>> 
>>> ## Puppet 3.2.3 Contributors ##
>>> 
>>>
>>> Adrien Thebo, Andrew Parker, Dustin J. Mitchell, Josh Cooper, Josh
>>> Partlow, Justin Stoller, Matthaus Owens, Moses Mendoza, Nick
>>> Fagerlund, Patrick Carlisle
>>>
>>> =
>>> ## Puppet 3.2.3 Release Notes ##
>>> =
>>>
>>> ### Windows Fixes
>>>
>>> This release fixes several Windows bugs that couldn't be targeted for
>>> earlier 3.2 releases.
>>>
>>> * [#20768: windows user provider can not manage password or home
>>> directory](https://projects.puppetlabs.com/issues/20768) --- This was
>>> a regression in 3.2.0/3.2.1.
>>> * [#21043: setting in puppet.conf ignored on Windows in Puppet
>>> 3.2.1](https://projects.puppetlabs.com/issues/21043) --- This was a
>>> regression in 3.2.0/3.2.1.
>>> * [#16080: Service provider broken in Windows Server
>>> 2012](https://projects.puppetlabs.com/issues/16080) --- This affected
>>> all previous Puppet versions.
>>> * [#20787: 'puppet resource group' takes incredibly long on
>>> Windows](https://projects.puppetlabs.com/issues/20787) --- This
>>> affected all previous Puppet versions.
>>> * [#20302: Windows File.executable? now returns false on ruby
>>> 1.9](https://projects.puppetlabs.com/issues/20302)
>>> * [#21280: Don't create c:\dev\null in windows
>>> specs](https://projects.puppetlabs.com/issues/21280) --- This was only
>>> relevant to Puppet developers.
>>>
>>> ### Logging and Reporting Fixes
>>>
>>> * [#20383: Bring back helpful error messages like prior to Puppet
>>> 3](https://projects.puppetlabs.com/issues/20383) --- This was a
>>> regression from 3.0.0, which caused file names and line numbers to
>>> disappear from duplicate resource declaration errors.
>>> * [#20900: tagmail triggers in --onetime mode without changes after
>>> upgrade from 3.1.1 to
>>> 3.2.1](https://projects.puppetlabs.com/issues/20900) --- This was a
>>> regression in 3.2.0/3.2.1.
>>> * [#20919: Logging behaviour issues in
>>> 3.2.1](https://projects.puppetlabs.com/issues/20919) --- This was a
>>> regression in 3.2.0/3.2.1, which caused noisy logging to the console
>>> even if the `--logdest` option was set.
>>>
>>> ### Performance Fixes
>>>
>>> * [#21376: Stack level too deep after updating from 3.1.1 to
>>> 3.2.2](https://projects.puppetlabs.com/issues/21376) --- This would
>>> sometimes cause total failures when importing a large number of
>>> manifest files (such as with the `import nodes/*.pp` idiom).
>>> * [#21320: Puppet daemon may sleep for 100 years after receiving USR1
>>> on 64 bit systems](https://projects.puppetlabs.com/issues/21320) ---
>>> MCollective's Puppet plugin uses puppet agent's USR1 signal to trigger
>>> a run if the agent is running; on 64-bit systems, this could cause
>>> puppet agent to keep running, but stop doing scheduled configuration
>>> runs. This was caused by a bug in Ruby \< 2.0, but we modified Puppet
>>> to work around it.
>>> * [#20901: `puppet --version` is unnecessarily
>>> slow](https://projects.puppetlabs.com/issues/20901) --- This was a
>>> regression 

[Puppet Users] Re: hiera-gpg and 400 error

[Bernd Weber]

The solution lies in changing the ownership of the .gnupg folder to be 
owned by puppet.

chown -R puppet:puppet 

 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Unable to start heartbeat service

[Rahul Khengare]

HI,
There is no issue of puppet on editing /etc/sysconfig/network file.

Cause of problem :
Here, I edit template of   "/etc/sysconfig/network"  file in windows
machine so the line-feed character is of windows, on transferring that
template file on linux environment cause problem with network
configuration file because of mismatch of line-feed character.

Note : Avoid writing of template files for linux configuration on
windows machine and then copying on linux machine.

On 5/8/13, Rahul Khengare  wrote:
> Hi,
>I have two machine named puppetserver and db01 with CentOS-6.2(64-bit).
>
>On db01: I am configuring pacemaker and heartbeat using puppet manifests
>
> present on puppetserver. I am also automating the network settings using
> puppet,
> here i am adding the GATEWAY in "*/etc/sysconfig/network*" file using
> puppet manifests.
>
> After deploying the respective manifests pacemaker and heartbeat working
> fine.
> *But, after rebooting the machine, heartbeat service is unable to start (on
>
> db01).*
>
> *Discription of error log:*
> 
> May 08 11:52:27 db01 heartbeat: [3423]: info: respawn directive: root
> /usr/lib64/heartbeat/ifcheckd
> May 08 11:52:27 db01 heartbeat: [3423]: info: AUTH: i=1: key = 0x15b89b0,
> auth=0x7f5c36e15db0, authname=sha1
> May 08 11:52:27 db01 heartbeat: [3423]: ERROR: Current node [db01] not in
> configuration!
> May 08 11:52:27 db01 heartbeat: [3423]: info: By default, cluster nodes are
>
> named by `uname -n` and must be declared with a 'node' directive in the
> ha.cf file.
> May 08 11:52:27 db01 heartbeat: [3423]: info: See also:
> http://linux-ha.org/wiki/Ha.cf#node_directive
> May 08 11:52:27 db01 heartbeat: [3423]: WARN: Logging daemon is disabled
> --enabling logging daemon is recommended
> May 08 11:52:27 db01 heartbeat: [3423]: ERROR: Configuration error,
> heartbeat not started.
>
> If i add the GATEWAY parameter in the "/etc/sysconfig/network" file *
> manually*  then it works fine even after rebooting.
>
> *Queries:*
> *--*
> 1. If i change the '/etc/sysconfig/network' file using puppet manifests the
>
> heartbeat service not start.
>Is there any problem if i change "*/etc/sysconfig/network*" file using
> puppet manifests.
>
> 2. Somebody faced similar or any other problem on editing or transferring
> '*
> /etc/sysconfig/network*' file using puppet manifests.
>
> Any pointers or help!!!
>
> Thanks and Regards,
> Rahul Khengare
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/AEp7IuPthLQ/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] PuppetMaster LB on top of OCFS2

[Jakov Sosic]

On 07/19/2013 09:16 AM, Wil Cooley wrote:


   - Reports processed with "rrdgraph" seem like a big risk.


OK.



   - The CA store seems highly vulnerable to race conditions, unless you
have such a low rate of node provisioning you can guarantee serial
access -- but you probably would not need an HA setup in that case.


I thought that only problem in this case could be two nodes 
simoultanously sending certificate request, which could cause the certs 
to get same serial, but couldn't that be solved just by issuing 
revocation for that serial?



  - The filebucket I would expect to be risky -- seems like a high
probability of attempted concurrent writes of the same file.


While? If one client connects only to one master per run?



You might consider an active/passive setup with a front-end load
balancer, where one of the above data subsets is effectively read-only
for the passive server. You could distribute the load by taking
advantage of the ability to configure the various master roles
(fileserver, catalog, inventory, filebucket, CA, etc.) with different
hostnames and ports. It would still be a risk of corruption in a
split-brain situation, but that's often (always?) a danger with
shared-storage filesystems.


We don't have such a high volume environment but we do have two machines 
at our disposal. So why not set up LB instead of simple HA...


I'm still considering solutions, although one of the most easier to set 
up is simple HA through RHEL Cluster, with failover/failback in case of 
the primary node failure.



--
Jakov Sosic
www.srce.unizg.hr

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Perform action when exported resources change

[Sneha More]

Hi George,
  You can directly use the fact hostname as $hostname in your manifest. 
  So though the hostname changes, puppet will take the updated value of 
$hostname.
  Will you please elaborate about the scenario for new node? Do you 
want to use this hostname for certification signing or in manifest?   

Regards,
Sneha.
NTT DATA GTS. Pune.


On Thursday, July 18, 2013 8:04:10 PM UTC+5:30, George Brown wrote:
>
> Hello,
>
> I am trying to work out how to have one server perform an action when a 
> new host is added.
>
> Specifically it needs to execute a command containing the hostname of the 
> new node in order to accept a license. My questions are as follows
>
> 1) As I hostname is available as a fact is there a easy way to export this 
> rather than having an exec perform /bin/hostname?
>
> 2) When the resource is updated is their a way to show only the updated 
> contents? 
>
> Please let me know if I'm going the wrong way and if there's a better way 
> to do this
>
> Many thanks
> George
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: 3.2.2 on CentOS 6.3, and "Did not receive certificate"

[Forrie]

Output of puppet config print for SSL :

cacert = /var/lib/puppet/ssl/ca/ca_crt.pem
cacrl = /var/lib/puppet/ssl/ca/ca_crl.pem
cadir = /var/lib/puppet/ssl/ca
cakey = /var/lib/puppet/ssl/ca/ca_key.pem
capass = /var/lib/puppet/ssl/ca/private/ca.pass
caprivatedir = /var/lib/puppet/ssl/ca/private
capub = /var/lib/puppet/ssl/ca/ca_pub.pem
cert_inventory = /var/lib/puppet/ssl/ca/inventory.txt
certdir = /var/lib/puppet/ssl/certs
csrdir = /var/lib/puppet/ssl/ca/requests
hostcert = /var/lib/puppet/ssl/certs/ourserver.domain.com.pem
hostcrl = /var/lib/puppet/ssl/crl.pem
hostcsr = /var/lib/puppet/ssl/csr_ourserver.domain.com.pem
hostprivkey = /var/lib/puppet/ssl/private_keys/ourserver.domain.com.pem
hostpubkey = /var/lib/puppet/ssl/public_keys/ourserver.domain.com.pem
ldapssl = false
localcacert = /var/lib/puppet/ssl/certs/ca.pem
passfile = /var/lib/puppet/ssl/private/password
privatedir = /var/lib/puppet/ssl/private
privatekeydir = /var/lib/puppet/ssl/private_keys
publickeydir = /var/lib/puppet/ssl/public_keys
requestdir = /var/lib/puppet/ssl/certificate_requests
serial = /var/lib/puppet/ssl/ca/serial
signeddir = /var/lib/puppet/ssl/ca/signed
ssl_client_ca_auth =
ssl_client_header = HTTP_X_CLIENT_DN
ssl_client_verify_header = HTTP_X_CLIENT_VERIFY
ssl_server_ca_auth =
ssldir = /var/lib/puppet/ssl

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: 3.2.2 on CentOS 6.3, and "Did not receive certificate"

[Forrie]

Output from puppet config print for SSL configs:

cacert = /var/lib/puppet/ssl/ca/ca_crt.pem
cacrl = /var/lib/puppet/ssl/ca/ca_crl.pem
cadir = /var/lib/puppet/ssl/ca
cakey = /var/lib/puppet/ssl/ca/ca_key.pem
capass = /var/lib/puppet/ssl/ca/private/ca.pass
caprivatedir = /var/lib/puppet/ssl/ca/private
capub = /var/lib/puppet/ssl/ca/ca_pub.pem
cert_inventory = /var/lib/puppet/ssl/ca/inventory.txt
certdir = /var/lib/puppet/ssl/certs
csrdir = /var/lib/puppet/ssl/ca/requests
hostcert = /var/lib/puppet/ssl/certs/central.de-prod.harvard.edu.pem
hostcrl = /var/lib/puppet/ssl/crl.pem
hostcsr = /var/lib/puppet/ssl/csr_central.de-prod.harvard.edu.pem
hostprivkey = 
/var/lib/puppet/ssl/private_keys/central.de-prod.harvard.edu.pem
hostpubkey = /var/lib/puppet/ssl/public_keys/central.de-prod.harvard.edu.pem
ldapssl = false
localcacert = /var/lib/puppet/ssl/certs/ca.pem
passfile = /var/lib/puppet/ssl/private/password
privatedir = /var/lib/puppet/ssl/private
privatekeydir = /var/lib/puppet/ssl/private_keys
publickeydir = /var/lib/puppet/ssl/public_keys
requestdir = /var/lib/puppet/ssl/certificate_requests
serial = /var/lib/puppet/ssl/ca/serial
signeddir = /var/lib/puppet/ssl/ca/signed
ssl_client_ca_auth =
ssl_client_header = HTTP_X_CLIENT_DN
ssl_client_verify_header = HTTP_X_CLIENT_VERIFY
ssl_server_ca_auth =
ssldir = /var/lib/puppet/ssl


-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: 3.2.2 on CentOS 6.3, and "Did not receive certificate"

[Forrie]

I suppose I could just "start all over" and run through the systems and 
have them signed.  The configurations I have there will still work for the 
manifests (which I've not converted to proper modules yet).   This is 
probably an option.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Announce: Puppet 3.2.3 Available

[Matthaus Owens]

Puppet 3.2.3 packages are now available for f19 on yum.puppetlabs.com.

On Fri, Jul 19, 2013 at 9:24 AM, Darin Perusich  wrote:
> FWIW Puppet Labs could really simplify the creation of packages for
> linux distributions by leveraging the Open Build Service, formerly
> OpenSUSE Build Service. All you need to do to add a distribution is
> check a box and which architectures and the systems will automagically
> build and deploy the packages for you. For a company that deals in
> automation I'd think such a tool would be right up your alley;-)
>
> You can find the documentation and software http://openbuildservice.org/
>
> --
> Later,
> Darin
>
>
> On Fri, Jul 19, 2013 at 11:21 AM, Moses Mendoza  wrote:
>> Hi Justin,
>>
>> Yes, I'll try to get those up today.
>>
>> Moses
>>
>> On Wed, Jul 17, 2013 at 3:37 PM, Justin Brown  
>> wrote:
>>> Moses,
>>>
>>> The Fedora 19 packages have not been updated. Could you issue packages for
>>> http://yum.puppetlabs.com/fedora/f19/?
>>>
>>> Thanks,
>>> Justin
>>>
>>>
>>> On Mon, Jul 15, 2013 at 2:18 PM, Moses Mendoza  wrote:

 3.2.3 is a bugfix release of the Puppet 3.2 series. It fixes some
 Windows bugs introduced in 3.2.0, as well as a few performance
 problems and miscellaneous bugs.

 ===
 ## Puppet 3.2.3 Downloads ##
 ===

 Source: https://downloads.puppetlabs.com/puppet/puppet-3.2.3.tar.gz

 RPM and deb packages available in the Puppet Labs repositories at:
 http://yum.puppetlabs.com and http://apt.puppetlabs.com

 Gems are available via rubygems at
 https://rubygems.org/downloads/puppet-3.2.3.gem
   or by using `gem install puppet`

 Mac package is available at
 https://downloads.puppetlabs.com/mac/puppet-3.2.3.dmg

 Windows package is available at
 https://downloads.puppetlabs.com/windows/puppet-3.2.3.msi

 Please report feedback via the Puppet Labs Redmine site, using an
 affected puppet version of 3.2.3:
 https://projects.puppetlabs.com/projects/puppet/

 
 ## Puppet 3.2.3 Contributors ##
 

 Adrien Thebo, Andrew Parker, Dustin J. Mitchell, Josh Cooper, Josh
 Partlow, Justin Stoller, Matthaus Owens, Moses Mendoza, Nick
 Fagerlund, Patrick Carlisle

 =
 ## Puppet 3.2.3 Release Notes ##
 =

 ### Windows Fixes

 This release fixes several Windows bugs that couldn't be targeted for
 earlier 3.2 releases.

 * [#20768: windows user provider can not manage password or home
 directory](https://projects.puppetlabs.com/issues/20768) --- This was
 a regression in 3.2.0/3.2.1.
 * [#21043: setting in puppet.conf ignored on Windows in Puppet
 3.2.1](https://projects.puppetlabs.com/issues/21043) --- This was a
 regression in 3.2.0/3.2.1.
 * [#16080: Service provider broken in Windows Server
 2012](https://projects.puppetlabs.com/issues/16080) --- This affected
 all previous Puppet versions.
 * [#20787: 'puppet resource group' takes incredibly long on
 Windows](https://projects.puppetlabs.com/issues/20787) --- This
 affected all previous Puppet versions.
 * [#20302: Windows File.executable? now returns false on ruby
 1.9](https://projects.puppetlabs.com/issues/20302)
 * [#21280: Don't create c:\dev\null in windows
 specs](https://projects.puppetlabs.com/issues/21280) --- This was only
 relevant to Puppet developers.

 ### Logging and Reporting Fixes

 * [#20383: Bring back helpful error messages like prior to Puppet
 3](https://projects.puppetlabs.com/issues/20383) --- This was a
 regression from 3.0.0, which caused file names and line numbers to
 disappear from duplicate resource declaration errors.
 * [#20900: tagmail triggers in --onetime mode without changes after
 upgrade from 3.1.1 to
 3.2.1](https://projects.puppetlabs.com/issues/20900) --- This was a
 regression in 3.2.0/3.2.1.
 * [#20919: Logging behaviour issues in
 3.2.1](https://projects.puppetlabs.com/issues/20919) --- This was a
 regression in 3.2.0/3.2.1, which caused noisy logging to the console
 even if the `--logdest` option was set.

 ### Performance Fixes

 * [#21376: Stack level too deep after updating from 3.1.1 to
 3.2.2](https://projects.puppetlabs.com/issues/21376) --- This would
 sometimes cause total failures when importing a large number of
 manifest files (such as with the `import nodes/*.pp` idiom).
 * [#21320: Puppet daemon may sleep for 100 years after receiving USR1
 on 64 bit systems](https://projects.puppetlabs.com/issues/21320) ---
 MCollective's Puppet plugin uses puppet agent's USR1 signal to trigger
 a run if the agent is running; on 64-bit systems, this could cause
 puppet agent to keep running, but stop doi

[Puppet Users] Re: 3.2.2 on CentOS 6.3, and "Did not receive certificate"

[Forrie]

I did some poking around and I think I found a better hint as to what may 
be the issue (feel free to confirm).

in /etc/puppet/auth.conf, I had:

# allow nodes to request a new certificate
path /certificate_request
auth any
method find, save
allow *

But the installation has "certificate_requests" (corrected).

Next, I see the actual requests are being cached in:

/var/lib/puppet/ssl/ca/requests

which I believe is wrong for 3.x... ?   There is one outstanding request in 
there from another machine I accessed a while ago.

For sake of clarity, here is the complete content of my auth.conf file, 
which until recently hasn't been changed since the initial installation:


path ~ ^/catalog/([^/]+)$
method find
allow $1

path ~ ^/node/([^/]+)$
method find
allow $1

path /certificate_revocation_list/ca
method find
allow *

path ~ ^/report/([^/]+)$
method save
allow $1

path /file
allow *


path /certificate/ca
auth any
method find
allow *

path /certificate/
auth any
method find
allow *

path /certificate_requests
auth any
method find, save
allow *

path /
auth any


The auth.conf on the client:

path /run
auth any
method save
allow our.serverdomain.com

path /
auth any

I'm going to keep looking, but I wonder if I'm close to figuring this 
out..


Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] rspec-puppet: how to pass undef as parameter value?

[Andreas Haerter]

Hi all,

is there a way to pass the Puppets undef [1] value as parameter? I got a
module with a package_provider parameter, allowing the user two things:
1. specify a specific package provider to use; 2. pass "undef" to let
Puppet decide which provider to use instead of the module.

Something like:

> class example(
>   $package_provider = $example::params::package_provider,
> ) inherits example::params {
>
>   [...]
>
>   package { 'foobar'
> ensure   => 'present',
> provider => $package_provider,
>   }
> }


Now I want to test if passing undef works:

> context 'with parameter(s): package_provider => undef' do
>   let(:params) {{
> :package_provider => [WAY-TO-PASS-UNDEF-HERE],
>   }}
> 
>   it 'contains a package with parameter(s): provider => unset' do
> should contain_package('blueprint').with({
>   'provider' => [WAY-TO-CHECK-FOR-UNDEF-HERE,
> })
>   end
> end



But my test doesn't work. What I tried so far is:

1) undef (results in RSpec/Ruby parsing error)
> context 'with parameter(s): foo => undef' do
>   let(:params) {{
> :foo => undef,
>   }}
>
>   [...]
> end

2) :undef (results in Puppet error: "Syntax error at':'; expected '}'" )
> context 'with parameter(s): foo => undef' do
>   let(:params) {{
> :foo => :undef,
>   }}
>
>   [...]
> end

3) nil (does not result in an Puppet or Ruby error, but the
.with_foo(nil) or .without_foo matchers do not seem to work as the
string "nil" was passed tho puppet
> context 'with parameter(s): foo => undef' do
>   let(:params) {{
> :foo => nil,
>   }}
>
>   [...]
> end

Any hints? Thanks in advance :-)


[1]


-- 
Andreas 



signature.asc
Description: OpenPGP digital signature

[Puppet Users] Re: 3.2.2 on CentOS 6.3, and "Did not receive certificate"

[Forrie]

I spent the afternoon re-doing my puppet master, tested it with just 2 new 
clients and I got the same exact problem.   I restored my old 
/var/lib/puppet so that other agents can work.

This is either a bug in Puppet itself or a bizarre configuration issue.


-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] PuppetMaster LB on top of OCFS2

[Wil Cooley]

On Jul 19, 2013 11:34 AM, "Jakov Sosic"  wrote:
>
> On 07/19/2013 09:16 AM, Wil Cooley wrote:
>>- The CA store seems highly vulnerable to race conditions, unless you
>> have such a low rate of node provisioning you can guarantee serial
>> access -- but you probably would not need an HA setup in that case.
>
>
> I thought that only problem in this case could be two nodes
simoultanously sending certificate request, which could cause the certs to
get same serial, but couldn't that be solved just by issuing revocation for
that serial?

Assuming that file is updated safely, that is, copy to temp, modify,
rename, then that might be OK. The agent no doubt takes care to update file
resources that way, but its extra work and I wouldn't assume other parts
that were not intended for concurrent access do that. You'd want to test
carefully or read the code, at least.

>
>>   - The filebucket I would expect to be risky -- seems like a high
>> probability of attempted concurrent writes of the same file.
>
> While? If one client connects only to one master per run?

Often one file is distributed to many clients and when that file is changed
there is a fairly narrow window of time that most of those clients will
update; and most of those have the same old file, with the same checksum,
so there is a high probability of concurrent writes.

> We don't have such a high volume environment but we do have two machines
at our disposal. So why not set up LB instead of simple HA...
>

*shrug* Complexity like that tends to fail in the most surprising of ways.
More than once I've seen active/active redundant systems fail worse and
more frequently than non-redundant or active/passive systems. (OTOH,
secomdary systems that are not used have a way of being overlooked and not
there when you need them.)

> I'm still considering solutions, although one of the most easier to set
up is simple HA through RHEL Cluster, with failover/failback in case of the
primary node failure.
>

That would probably be safest and easiest. I have often lamented that HA
cluster systems don't seem to support two nodes that are "differently"
active (2 VIPs for 2 DNS servers, for example). Or at least, I've not found
clear and obvious docs supporting that.

Wil

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.