Re: [Puppet Users] Re: Puppet Dashboard - Directory Index Forbidden

[Felipe Salum]

I had the same issue too, so I had to make a few changes on my virtualhost
to work. Try changing your Options to None and confirm that your
PassengerRoot and module path are correct.

I'm attaching my working virtualhost for you to compare:


LoadModule passenger_module /usr/lib/apache2/modules/mod_passenger.so
PassengerRoot /usr
PassengerRuby /usr/bin/ruby


SetEnv RAILS_ENV production
RackBaseURI /

ServerName X.X.X.X
DocumentRoot /usr/share/puppet-dashboard/public/

Options None
Order allow,deny
allow from all




Felipe

On Mon, Mar 19, 2012 at 7:52 AM, Antidot SAS  wrote:

> HI,
>
> I had exactly the same issue last week when I wanted to create a vhost for
> the puppet dashboard, I finally wasn't able to resolve the issue. And if
> you change the directive in '+Indexes', the ruby code is not correctly
> executed.
>
>
> Any help is alos appareached.
>
> Regards,
> JM
>
>
> On Mon, Mar 19, 2012 at 1:34 PM, theirpuppet wrote:
>
>> Thanks, however this still doesn't work.
>>
>> From error log:
>> [Mon Mar 19 12:29:00 2012] [error] [client X.X.X.X] Directory index
>> forbidden by Options directive: /usr/share/puppet-dashboard/public/
>>
>> And the current apache configuration:
>>
>> root:~# cat /etc/apache2/sites-enabled/010-dashboard.conf
>> # UPDATE THESE PATHS TO SUIT YOUR ENVIRONMENT
>> LoadModule passenger_module
>> /var/lib/gems/1.8/gems/passenger-2.2.11/ext/apache2/mod_passenger.so
>> #PassengerRoot /var/lib/gems/1.8/gems/passenger-2.2.11
>> PassengerRoot /usr/lib/phusion_passenger
>> PassengerRuby /usr/bin/ruby
>>
>> # you may want to tune these settings
>> PassengerHighPerformance on
>> PassengerMaxPoolSize 12
>> PassengerPoolIdleTime 1500
>> # PassengerMaxRequests 1000
>> PassengerStatThrottleRate 120
>> RailsAutoDetect On
>>
>> 
>> ServerName X.X.X
>> ServerAlias X.X.X.X
>> DocumentRoot /usr/share/puppet-dashboard/public/
>> RailsBaseURI /
>> SetEnv Rails_ENV production
>> PassengerEnabled on
>> 
>> Options -MultiViews -Indexes FollowSymLinks
>> Order allow,deny
>> allow from all
>> 
>>   #ErrorLog /var/log/apache2/dashboard.example.com_error.log
>>   LogLevel warn
>>   #CustomLog /var/log/apache2/dashboard.example.com_access.log combined
>>   ServerSignature On
>> 
>>
>>
>>  --
>> 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/-/fgfDMT0_1xMJ.
>>
>> 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 3.0 on Debian Lenny

[Felipe Salum]

Hi guys.

I don't see the latest puppet 3.0 on the puppetlabs debian repository for 
lenny and also the latest puppet dashboard.

Aren't you guys adding the new versions to the deprecated Debian Lenny 
anymore ?

Can I grab the puppet 3.0 agent from squeeze to use on Lenny ?

Regards,
Felipe

-- 
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/-/uLwlJAd5VIIJ.
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] Exec resource and environment parameter

[Felipe Salum]

I'm trying to use the environment parameter on Exec but it is not working. 
Any idea what's wrong ?

exec { 'test':
 path=> 
'/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin',
 environment => ["HOME=test", "HOME2=test2"],
command=> "echo $HOME > /tmp/key",
user=> 'root',
group  => 'root',
   }

I'm using Puppet 3.0

Thanks,
Felipe

-- 
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/-/2F-pxT-TA2wJ.
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 on Debian Lenny

[Felipe Salum]

Hi Christian,

My libaugeas0 is 0.7.2 from backports: 
http://archive.debian.org/debian-backports/pool/main/a/augeas/libaugeas0_0.7.2-1~bpo50+1_amd64.deb

Install puppet from backports first so it will bring all the dependencies, 
then upgrade to puppet from puppetlabs. That is how I do on Lenny.

apt-get -t lenny-backports install -y puppet
apt-get -t puppetlabs install -y puppet 

Regards,
Felipe

On Friday, October 12, 2012 9:40:45 AM UTC-7, Christian Page wrote:
>
> Felipe,
>
> Perhaps you can answer a question for me, I am in a similar boat as you 
> with having to continue to support Lenny after EOL. I am trying to install 
> puppet but I have an unmet dependency of libaugeas0. It appears that only 
> version 0.2.2-1 is in the backports repository on archive.debian.org, and 
> puppet from apt.puppetlabs.com requires version 0.6.0. What did you have 
> to do to get this dependency met?
>
> Thanks for your help,
>
> Christian
>
> On Tuesday, October 9, 2012 12:29:22 PM UTC-6, Felipe Salum wrote:
>>
>> Hi guys.
>>
>> I don't see the latest puppet 3.0 on the puppetlabs debian repository for 
>> lenny and also the latest puppet dashboard.
>>
>> Aren't you guys adding the new versions to the deprecated Debian Lenny 
>> anymore ?
>>
>> Can I grab the puppet 3.0 agent from squeeze to use on Lenny ?
>>
>> Regards,
>> Felipe
>>
>

-- 
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/-/q72d2w1UjaoJ.
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: apt.puppetlabs.com for Debian Lenny is broken ?

[Felipe Salum]

I just answered it in another thread :)

Install the Lenny Backports Repository, install puppet from there to bring 
all dependencies and then install it again from puppetlabs. Lenny is a mess 
:)

apt-get -t lenny-backports install -y puppet
apt-get -t puppetlabs install -y puppet 

and the backports repo if you don't have:

deb http://archive.debian.org/debian-backports lenny-backports main

On Friday, October 12, 2012 6:48:28 AM UTC-7, Hien Phan wrote:
>
> Hello list, 
>
> I try to install puppet agent on Debian Lenny. I got following error. 
> Seems the repo is broken : 
>
> ---
>  
>
>
> node001:~# wget http://apt.puppetlabs.com/puppetlabs-release-lenny.deb 
> --2012-10-1202:12:12--
>   
> http://apt.puppetlabs.com/puppetlabs-release-lenny.deb 
> Resolving apt.puppetlabs.com... 96.126.116.126, 
> 2600:3c00::f03c:91ff:fe93:711a 
> Connecting to apt.puppetlabs.com|96.126.116.126|:80... connected. 
> HTTP request sent, awaiting response... 200 OK 
> Length: 3396 (3.3K) [application/x-debian-package] 
> Saving to: `puppetlabs-release-lenny.deb' 
> 100%[==>]
>  
>
> 3,396   --.-K/s   in 0s 
> 2012-10-12 02:12:18 (426 MB/s) - `puppetlabs-release-lenny.deb' saved 
> [3396/3396] 
> node001:~# dpkg -i puppetlabs-release-lenny.deb 
> Selecting previously deselected package puppetlabs-release. 
> (Reading database ... 21509 files and directories currently installed.) 
> Unpacking puppetlabs-release (from puppetlabs-release-lenny.deb) ... 
> Setting up puppetlabs-release (1.0-5) ... 
> node001:~# cat /etc/apt/sources.list.d/puppetlabs.list 
> # Puppetlabs products 
> deb http://apt.puppetlabs.com lenny main 
> deb-src http://apt.puppetlabs.com lenny main 
> # Puppetlabs devel (uncomment to activate) 
> # deb http://apt.puppetlabs.com lenny devel 
> # deb-src http://apt.puppetlabs.com lenny devel 
> node001:~# apt-get install puppet 
> Reading package lists... Done 
> Building dependency tree 
> Reading state information... Done 
> Some packages could not be installed. This may mean that you have 
> requested an impossible situation or if you are using the unstable 
> distribution that some required packages have not yet been created 
> or been moved out of Incoming. 
> The following information may help to resolve the situation: 
> The following packages have unmet dependencies: 
> puppet: Depends: puppet-common (= 2.7.19-1puppetlabs2) but it is not 
> going to be installed 
> E: Broken packages 
> node001:~# apt-get update 
> Hit http://debian.securedservers.com lenny Release.gpg 
> Hit http://apt.puppetlabs.com lenny Release.gpg 
> Ign http://apt.puppetlabs.com lenny/main Translation-en_US 
> Hit http://apt.puppetlabs.com lenny Release 
> Ign http://debian.securedservers.com lenny/main Translation-en_US 
> Ign http://apt.puppetlabs.com lenny/main Packages/DiffIndex 
> Ign http://apt.puppetlabs.com lenny/main Sources/DiffIndex 
> Hit http://debian.securedservers.com lenny Release 
> Hit http://apt.puppetlabs.com lenny/main Packages 
> Ign http://debian.securedservers.com lenny/main Packages/DiffIndex 
> Hit http://apt.puppetlabs.com lenny/main Sources 
> Ign http://debian.securedservers.com lenny/main Sources/DiffIndex 
> Hit http://debian.securedservers.com lenny/main Packages 
> Hit http://debian.securedservers.com lenny/main Sources 
> Reading package lists... Done 
> node001:~# apt-get install puppet 
> Reading package lists... Done 
> Building dependency tree 
> Reading state information... Done 
> Some packages could not be installed. This may mean that you have 
> requested an impossible situation or if you are using the unstable 
> distribution that some required packages have not yet been created 
> or been moved out of Incoming. 
> The following information may help to resolve the situation: 
> The following packages have unmet dependencies: 
> puppet: Depends: puppet-common (= 2.7.19-1puppetlabs2) but it is not 
> going to be installed 
> E: Broken packages 
> --
>  
>
>
> Any chances got puppet works in debian lenny ? Thanks in advance. 
>
> -- 
> Best regards, 
> Phan Quoc Hien 
>

-- 
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/-/-9lA84pFTa0J.
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: Are my expectations misaligned?

[Felipe Salum]

I would love to see puppet forge as we have the distribution repositories.. 
Modules audited, tested and maybe fixed by PuppetLabs and then officially 
released on puppet forge under the puppetlabs account.

I see some scenarios that puppetlabs could consider:

1. puppetlabs is taking a lot of time to check pull requests on their forge 
modules and release new versions. I sent a pull request some days ago for 
one of their modules and I noticed there were other pull requests for the 
same module submitted a few "months ago" that weren't merged yet.

2. Users could create modules following the modules standard by creating 
documentation, parameterized modules, etc and then Puppetlabs could easily 
onboard those modules under their account and start supporting the module 
officially. I try to use only puppetlabs modules on puppet forge because I 
know they have great quality.

Regards,
Felipe

On Sunday, October 14, 2012 9:53:12 AM UTC-7, yersinia.spiros wrote:
>
> Everyone had ever used the puppet forge know this. The forge today are 
> collection of modules, with a different degree of quality. But this 
> quality is not enforced by a external authority, there is not any 
> review. Think about it : it is a forge. Like sf.net for some open 
> source software, some project are good, other less. It is totally 
> different from the repos that the distributions offer, that contain 
> packages that had a quality control, formal review, mantainer, a bus 
> tracking system and so on. 
>
> My 2cent. Best regards 
>
> 2012/10/14, Mister Guru >: 
> > Good Afternoon All, 
> > 
> > I'm just pondering - I think that my expectations of the forge are not 
> 100% 
> > aligned, or I'm still rubbish with puppet! 
> > 
> > I imagine the forge to be used in the following scenario/way 
> > 
> > I'm in a situation where I need to provision package X in a particular 
> way. 
> > I fire up my terminal: 
> > 
> > $ puppet module search packageX 
> > Searching https://forge.puppetlabs.com ... 
> > NAME   DESCRIPTION  AUTHOR 
> > KEYWORDS 
> > author-packageX  Function Y@author 
> > packageX 
> > 
> > Great! Someone has already published a module for my package - So I 
> install 
> > it 
> > 
> > $ puppet module install author-packageX 
> > 
> > I fire up my puppet dashboard, and I create a new class, and I add it to 
> my 
> > test rig 
> > 
> > At this point my expectation is that I should get a basic vanilla 
> > install/configuration of that package and dependencies. For example, if 
> the 
> > package is MySql, I'm expecting to have a working default install of 
> MySql 
> > after my test rig checks in. My faith starts to shake when I'm looking 
> at 
> > modules like wordpress. Picture the scene. 
> > 
> > Now, If I'm building a wordpress module, it's going to have a few 
> > dependencies, MySQL, and Apache etc - By chance, I already have some of 
> my 
> > own modules that install MySQL and Apache, I'll just reuse those in my 
> > wordpress module. After two days I give up, and notice that there is a 
> > module on the forge for wordpress. Now I'm stuck, because I'm assuming 
> that 
> > the author has done similar work to what I did - I'm going to spend 
> quite 
> > some time making sure the forge modules play nice with my custom ones. 
> > 
> > Using the forge feels like installing packages from a repository, and 
> one 
> > thing that I think we all expect, is that all the packages in a 
> repository 
> > work together - Which is not the case with the forge, as anyone can 
> publish 
> > anything at anytime. (I may be wrong, but this is how I'm reasoning 
> through 
> > my paranoia!) 
> > 
> > This causes a mental stumbling block for me, because 
> > 
> > $ puppet module install packageX 
> > 
> > doesn't invoke the same sense of security as 
> > 
> > $ apt-get/yum update packageX 
> > 
> > even though they are both essentially doing the same thing - pulling in 
> open 
> > source code from the outside world to configure my system. 
> > 
> > I'm hoping that my reasoning is flawed, and that a few of you are 
> chuckling 
> > as you read this calling me a NooBie Donkey! Is the forge suppose to a 
> place 
> > for people to post examples, and am I then expected to edit that code 
> > accordingly to fit my environment? If so, then what would be the 
> motivation 
> > to push my changes back? 
> > 
> > Sorry if I sound incoherent here - I'm trying to determine how best to 
> make 
> > use of the forge, otherwise I'll end up just reinventing the wheel and 
> > writing up manifests from scratch, which to me defeats the purpose. 
> > 
> > Discuss :) 
> > 
> > -- 
> > 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 th

Re: [Puppet Users] Puppet Forge: Are my expectations misaligned?

[Felipe Salum]

I would love to have time for that :) but I will try to help converting the 
modules I made to use on my company to the forge standard. I wrote my first 
forge module last week, added documentation, everything on parameterized 
classes and easy to use and install.

I appreciate any feedbacks so I can make that a standard to move all my 
other modules.

https://forge.puppetlabs.com/fsalum/newrelic

Regards,
Felipe

On Sunday, October 14, 2012 12:15:53 PM UTC-7, Christopher Wood wrote:
>
> On Sun, Oct 14, 2012 at 11:53:41AM -0700, Felipe Salum wrote: 
> >I would love to see puppet forge as we have the distribution 
> >repositories.. Modules audited, tested and maybe fixed 
>
> (SNIP) 
>
> Sounds like you just volunteered. 
>

-- 
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/-/8mj-T8lQ6uUJ.
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: Not authorized to call find on /file_metadata, more issues?

[Felipe Salum]

Is this related to the same error I have when I run the puppet agent on my 
nodes ?

Nov 11 01:40:09 squeeze puppet-agent[8683]: Could not send report: Error 
403 on SERVER: Forbidden request: puppetdb1.puppet.test(192.168.168.12) 
access to /report/puppetdb1.puppet.test [save] authenticated  at :67

I'm using Puppet 3.0.1

On Monday, October 1, 2012 5:48:25 PM UTC-7, Forrie wrote:
>
> I've seen mention of this error in several places, with different causes. 
>  So before I posted here, I attempted to resolve this on my own.
>
> I corrected the change from puppet:///files to puppet:/// in my manifests 
> *.pp files.  
>
> No changes were made to the auth.conf file, and I did note in the 
> ChangeLog that:
>
> Auth.conf differentiates between names and IPs – There’s a new allow_ip 
> keyword 
>> in auth.conf if you want to permit IP addresses. (PR991)
>
>
> But I see no mention of that on the docs page at 
> http://docs.puppetlabs.com/guides/rest_auth_conf.html.  
>
> Our auth.conf is simple, and basically has either "allow $1" or "allow *" 
> both which appear to still be valid in 3.0.
>
> Here's an example, a simple example, an ntp.conf file:
>
> class ntp-client {
> file { "/etc/ntp.conf":
> owner   => root,
> group   => root,
> mode=> 644,
> source  => "puppet:///etc/ntp.conf",
> require => [ Package["ntp"] ],
> notify  => Service["ntpd"],
> }
> package { "ntp": 
> ensure => latest,
> }
> service { "ntpd":
> ensure => running,
> hasrestart => true,
> subscribe  => File["/etc/ntp.conf"],
> }
> } # ntp-client
>
>
> The error I'm seeing in the puppet.log, on the client system:
>
>
> Oct  1 20:02:28 test-fms puppet-agent[11062]: Starting Puppet client 
>> version 2.7.17
>> Oct  1 20:02:31 test-fms puppet-agent[11062]: 
>> (/Stage[main]/Ntp-client/File[/etc/ntp.conf]) Could not evaluate: Error 400 
>> on SERVER: Not authorized to call find on /file_metadata/etc/ntp.conf Could 
>> not retrieve file metadata for puppet:///etc/ntp.conf: Error 400 on SERVER: 
>> Not authorized to call find on /file_metadata/etc/ntp.conf at 
>> /etc/puppet/manifests/classes/ntp-client.pp:10
>
>
>  
> The permissions from /etc/puppet/files are correct:
>
> -rw-r--r--. 1 puppet puppet 446 Mar 31  2011 etc/ntp.conf
>
>
> The client puppet.conf file doesn't have any custom references other than 
> the basics.
>
> [main]
>> server = ourpuppet.server.com
>> vardir = /var/lib/puppet
>> logdir = /var/log/puppet
>> rundir = /var/run/puppet
>> ssldir = $vardir/ssl
>> [agent]
>> classfile = $vardir/classes.txt
>> localconfig = $vardir/localconfig
>> syslogfacility = local4
>> report = true
>> listen = true
>
>
> I ran puppet master in verbose mode and got these diagnostics:
>
> Starting Puppet master version 3.0.0
> Info: access[^/catalog/([^/]+)$]: allowing 'method' find
> Info: access[^/catalog/([^/]+)$]: allowing $1 access
> Info: access[/certificate_revocation_list/ca]: allowing 'method' find
> Info: access[/certificate_revocation_list/ca]: allowing * access
> Info: access[/report]: allowing 'method' save
> Info: access[/report]: allowing * access
> Info: access[/file]: allowing * access
> Info: access[/certificate/ca]: adding authentication no
> Info: access[/certificate/ca]: allowing 'method' find
> Info: access[/certificate/ca]: allowing * access
> Info: access[/certificate/]: adding authentication no
> Info: access[/certificate/]: allowing 'method' find
> Info: access[/certificate/]: allowing * access
> Info: access[/certificate_request]: adding authentication no
> Info: access[/certificate_request]: allowing 'method' find
> Info: access[/certificate_request]: allowing 'method' save
> Info: access[/certificate_request]: allowing * access
> Info: access[/]: adding authentication any
> Info: Inserting default '~ ^/node/([^/]+)$' (auth true) ACL
> Info: Inserting default '/status' (auth true) ACL
> Warning: Host is missing hostname and/or domain: one-host.ourdomain.com
> Compiled catalog for one-host.ourdomain.com in environment production in 
> 1.16 seconds
> Info: mount[files]: allowing 10.101.0.0/24 access
> Error: Error parsing fileserver configuration: wrong number of arguments 
> (3 for 1); using old configuration
> Error: Not authorized to call find on /file_metadata/etc/ntp.conf
> Error: Not authorized to call find on /file_metadata/etc/sudoers
> Error: Not authorized to call find on 
> /file_metadata/files/etc/ssh/ssh_known_hosts
> Error: Not authorized to call find on 
> /file_metadata/files/etc/ssh/sshd_config
> Error: Not authorized to call find on 
> /file_metadata/etc/puppet/namespaceauth.conf
> Error: Not authorized to call find on 
> /file_metadata/etc/puppet/puppet.conf.agent
> Error: Not authorized to call find on /file_metadata/etc/puppet/auth.conf
> Error: Not authorized to call find on /file_metadata/etc/resolv.conf.test
>  
> I reviewed the docs at http://docs.puppetla

Re: [Puppet Users] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?

[Felipe Salum]

Hi Nick.

Actually this is a new environment I'm setting up using vagrant, puppet 3
and the default auth.conf.

I had to add allow_ip to the /reports request to make it work. Not sure why
but it sometimes fail when using the puppet server provider from vagrant.

Thanks,
Felipe

On Mon, Nov 12, 2012 at 4:22 PM, Nick Fagerlund <
nick.fagerl...@puppetlabs.com> wrote:

>
>
> On Saturday, November 10, 2012 5:43:48 PM UTC-8, Felipe Salum wrote:
>>
>> Is this related to the same error I have when I run the puppet agent on
>> my nodes ?
>>
> Nov 11 01:40:09 squeeze puppet-agent[8683]: Could not send report: Error
> 403 on SERVER: Forbidden request: puppetdb1.puppet.test(192.168.
> **168.12) access to /report/puppetdb1.puppet.test [save] authenticated
> at :67
>
>
> No, other than that they're both related to authentication in auth.conf.
> If you were upgrading from 2.6, note that the default value of the 'report'
> setting changed between 2.6 and 2.7:
>
> http://docs.puppetlabs.com/references/2.7.latest/configuration.html#report
> http://docs.puppetlabs.com/references/2.6.latest/configuration.html#report
>
> So if your auth.conf file doesn't allow authenticated nodes to send save
> requests to /report, you will get errors. Examine your auth.conf file and
> compare it to the one here:
>
> https://github.com/puppetlabs/puppet/blob/master/conf/auth.conf
>
> You should have AT LEAST all the same rules, although your site may have
> some extra rules as well. Be aware that order matters in this file.
>
> --
> 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/-/rcFTBsu-IqkJ.
> 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: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?

[Felipe Salum]

I'm also having the same issue on the other locations. Not sure what's 
wrong since this is a default installation of puppet 3 with the original 
auth.conf

Error: /Stage[main]/Puppetdb::Master::Routes/File[/etc/puppet/routes.yaml]: 
Could not evaluate: Error 403 on SERVER: Forbidden request: 
puppet2.puppet.test(192.168.168.10) access to 
/file_metadata/modules/puppetdb/routes.yaml [find] at :102 Could not 
retrieve file metadata for puppet:///modules/puppetdb/routes.yaml: Error 
403 on SERVER: Forbidden request: puppet2.puppet.test(192.168.168.10) 
access to /file_metadata/modules/puppetdb/routes.yaml [find] at :102

Error: Could not retrieve catalog from remote server: Error 403 on SERVER: 
Forbidden request: puppet2.puppet.test(192.168.168.10) access to 
/catalog/puppet2.puppet.test [find] at :101
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

Error: Could not send report: Error 403 on SERVER: Forbidden request: 
puppet2.puppet.test(192.168.168.10) access to /report/puppet2.puppet.test 
[save] at :102


Maybe it is a naming resolution issue ? I'm using /etc/hosts since this is 
a vagrant environment only for testing purposes.

If I start updating auth.conf to use 'auth no' everywhere it passes.

I don't see the problem on my production servers, so it worries me more :)

On Monday, November 12, 2012 4:27:41 PM UTC-8, Felipe Salum wrote:
>
> Hi Nick.
>
> Actually this is a new environment I'm setting up using vagrant, puppet 3 
> and the default auth.conf.
>
> I had to add allow_ip to the /reports request to make it work. Not sure 
> why but it sometimes fail when using the puppet server provider from 
> vagrant.
>
> Thanks,
> Felipe
>
> On Mon, Nov 12, 2012 at 4:22 PM, Nick Fagerlund <
> nick.fagerl...@puppetlabs.com> wrote:
>
>>
>>
>> On Saturday, November 10, 2012 5:43:48 PM UTC-8, Felipe Salum wrote:
>>>
>>> Is this related to the same error I have when I run the puppet agent on 
>>> my nodes ?
>>>
>> Nov 11 01:40:09 squeeze puppet-agent[8683]: Could not send report: Error 
>> 403 on SERVER: Forbidden request: puppetdb1.puppet.test(192.168.
>> **168.12) access to /report/puppetdb1.puppet.test [save] authenticated  
>> at :67
>>
>>
>> No, other than that they're both related to authentication in auth.conf. 
>> If you were upgrading from 2.6, note that the default value of the 'report' 
>> setting changed between 2.6 and 2.7: 
>>
>> http://docs.puppetlabs.com/references/2.7.latest/configuration.html#report
>> http://docs.puppetlabs.com/references/2.6.latest/configuration.html#report
>>
>> So if your auth.conf file doesn't allow authenticated nodes to send save 
>> requests to /report, you will get errors. Examine your auth.conf file and 
>> compare it to the one here: 
>>
>> https://github.com/puppetlabs/puppet/blob/master/conf/auth.conf
>>
>> You should have AT LEAST all the same rules, although your site may have 
>> some extra rules as well. Be aware that order matters in this file. 
>>
>> -- 
>> 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/-/rcFTBsu-IqkJ.
>> 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 view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/53V32bKqFYMJ.
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] Load Balance Puppet 3 masters with PuppetDB backend

[Felipe Salum]

Hi there.

I'm setting up a Puppet 3 + PuppetDB environment with the following 
architecture:

2 x puppetmaster/passenger with apache using Proxy Balance
1 x puppetdb 

Following the Pro Puppet book, I set Apache on both puppetmasters to proxy 
the CA requests to just 1 puppetmaster server, and anything else between 
the 2 puppetmaster servers (call them workers).

Also both puppetmaster servers is set to use the puppetdb storeconfig 
backend.

Everything looks fine when I hit the puppetmaster running as the CA, but if 
my request is balanced to the 2nd puppetmaster worker I got the errors 
below:

root@puppetdb1:/# puppet agent --test --server puppet.puppet.test
Warning: Unable to fetch my node definition, but the agent run will 
continue:
Warning: Error 400 on SERVER: Could not retrieve facts for 
puppetdb1.puppet.test: Failed to submit 'replace facts' command for 
puppetdb1.puppet.test to PuppetDB at puppetdb1.puppet.test:8081: 
SSL_connect SYSCALL returned=5 errno=0 state=SSLv3 read finished A
Info: Retrieving plugin
Info: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb
Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb
Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb
Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb
Info: Loading facts in /var/lib/puppet/lib/facter/iptables.rb
Info: Loading facts in 
/var/lib/puppet/lib/facter/postgres_default_version.rb
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Failed to submit 'replace facts' command for puppetdb1.puppet.test to 
PuppetDB at puppetdb1.puppet.test:8081: SSL_connect SYSCALL returned=5 
errno=0 state=SSLv3 read finished A
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

For some reason when my puppetmaster2 worker receives the request from any 
of my puppet agent nodes the facts fail.

192.168.168.9 - - [16/Nov/2012:13:15:10 -0800] "GET 
/production/node/puppetdb1.puppet.test? HTTP/1.1" 400 513 "-" "-"
192.168.168.9 - - [16/Nov/2012:13:15:16 -0800] "GET 
/production/file_metadatas/plugins?recurse=true&checksum_type=md5&links=manage&ignore=---+%0A++-+%22.svn%22%0A++-+CVS%0A++-+%22.git%22&
 
HTTP/1.1" 200 40597 "-" "-"
192.168.168.9 - - [16/Nov/2012:13:15:18 -0800] "POST 
/production/catalog/puppetdb1.puppet.test HTTP/1.1" 400 461 "-" "-"

Can I use the architecture I described above and still have every 
puppetmaster from my load balance talking to PuppetDB ?

I tried to delete the ssl certificates, generate them again, run 
puppetdb-ssl-setup, etc but still same results.

Thanks,
Felipe

-- 
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/-/Jz9sEtlR35UJ.
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 DB for inventory

[Felipe Salum]

http://docs.puppetlabs.com/puppetdb/1/using.html#using-the-inventory-service

If you are using puppetdb backend you just need to enable the dashboard 
inventory service and it will automatically get the inventory information 
from puppetdb. No more need to add those mysql settings on puppet.conf for 
the inventory service.

On Sunday, November 18, 2012 8:19:29 AM UTC-8, vioilly wrote:
>
> I am a little confused :) Couple of questions:
>
> Is the puppet DB the same as the inventory DB ? 
>
> If so, can I have all my puppet masters pointing to the same DB and point 
> dashboard at this DB so I can see all my puppet nodes and inventory through 
> one puppet-dashboard?
>
> If not, then what is the difference between the puppet DB and the 
> inventory DB?
>
>
> Thanks in advance
>
> Cheers,
> Oli
>

-- 
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/-/YSZ06laQGHQJ.
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 values issue

[Felipe Salum]

Try:

:hierarchy:
  - "%{certname}"
  - common

Felipe

On Tuesday, November 20, 2012 8:14:10 AM UTC-8, Félix Barbeira wrote:
>
> Hi, I have a puppetmaster - agent architecture. I have a module for the 
> vsftpd configuracion in the agents. The configuration of the value 
> 'max_per_ip' in the agents may vary. This is a line of the manifest:
>
> $max_per_ip = hiera('max_per_ip',10)
>
> I want to specify different values for each agent using hiera. The problem 
> is I am only able to specify the 'common' values, not the values using the 
> the variable 'clientcert'. This is my configuration in the puppetmaster:
>
> The '/etc/hiera.yaml' file:
>
> ---
> :backend:
>   - yaml
> :hierarchy:
>   - ${certname}
>   - common
> :yaml:
> # datadir is empty here, so hiera uses its defaults:
> # - /var/lib/hiera on *nix
> # - %CommonAppData%\PuppetLabs\hiera\var on Windows
> # When specifying a datadir, make sure the directory exists.
>   :datadir:
>
> I created the file '/var/lib/hiera/c108.dfgserver.com.yaml' with the 
> following content:
>
> ---
> #vsftpd
> max_per_ip: 20
>
> But this doesn´t work. The agent ignores the value 'max_per_ip' 
> established on the file. If I rename the file 
> '/var/lib/hiera/c108.dfgserver.com.yaml' 
> to 'common.yaml', then it works. At the beginning I thought it could be an 
> issue with the variable 'certname' but if I execute the following in the 
> agent it returns the fact correctly:
>
> root@c108:/etc/puppet# puppet apply -ve 'notify {"My certname is: 
> ${settings::certname}":}'
> Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/iptables.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/iptables.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb
> Info: Applying configuration version '1353427613'
> My certname is: c108.dfgserver.com
> /Stage[main]//Notify[My certname is: c108.dfgserver.com]/message: defined 
> 'message' as 'My certname is: c108.dfgserver.com'
> Finished catalog run in 0.07 seconds
> root@c108:/etc/puppet#
>
> So the namefile must be '$certname'.yaml right?
>
> I have the last versions of the repo 'apt.puppetlabs.com'. Both machines 
> are ubuntu 10.04 LTS (lucid) with the last stable packages.
>
>

-- 
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/-/Bmcthk_lSTkJ.
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: Load Balance Puppet 3 masters with PuppetDB backend

[Felipe Salum]

Following the 
http://docs.puppetlabs.com/guides/scaling_multiple_masters.html actually 
worked better. The Pro Puppet was missing the part of running puppet agent 
in the 2nd master with the dns_alt_names or I missed that part, anyway it 
is working now :)

Felipe

On Friday, November 16, 2012 1:33:03 PM UTC-8, Felipe Salum wrote:
>
> Hi there.
>
> I'm setting up a Puppet 3 + PuppetDB environment with the following 
> architecture:
>
> 2 x puppetmaster/passenger with apache using Proxy Balance
> 1 x puppetdb 
>
> Following the Pro Puppet book, I set Apache on both puppetmasters to proxy 
> the CA requests to just 1 puppetmaster server, and anything else between 
> the 2 puppetmaster servers (call them workers).
>
> Also both puppetmaster servers is set to use the puppetdb storeconfig 
> backend.
>
> Everything looks fine when I hit the puppetmaster running as the CA, but 
> if my request is balanced to the 2nd puppetmaster worker I got the errors 
> below:
>
> root@puppetdb1:/# puppet agent --test --server puppet.puppet.test
> Warning: Unable to fetch my node definition, but the agent run will 
> continue:
> Warning: Error 400 on SERVER: Could not retrieve facts for 
> puppetdb1.puppet.test: Failed to submit 'replace facts' command for 
> puppetdb1.puppet.test to PuppetDB at puppetdb1.puppet.test:8081: 
> SSL_connect SYSCALL returned=5 errno=0 state=SSLv3 read finished A
> Info: Retrieving plugin
> Info: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/iptables.rb
> Info: Loading facts in 
> /var/lib/puppet/lib/facter/postgres_default_version.rb
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
> Failed to submit 'replace facts' command for puppetdb1.puppet.test to 
> PuppetDB at puppetdb1.puppet.test:8081: SSL_connect SYSCALL returned=5 
> errno=0 state=SSLv3 read finished A
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
>
> For some reason when my puppetmaster2 worker receives the request from any 
> of my puppet agent nodes the facts fail.
>
> 192.168.168.9 - - [16/Nov/2012:13:15:10 -0800] "GET 
> /production/node/puppetdb1.puppet.test? HTTP/1.1" 400 513 "-" "-"
> 192.168.168.9 - - [16/Nov/2012:13:15:16 -0800] "GET 
> /production/file_metadatas/plugins?recurse=true&checksum_type=md5&links=manage&ignore=---+%0A++-+%22.svn%22%0A++-+CVS%0A++-+%22.git%22&
>  
> HTTP/1.1" 200 40597 "-" "-"
> 192.168.168.9 - - [16/Nov/2012:13:15:18 -0800] "POST 
> /production/catalog/puppetdb1.puppet.test HTTP/1.1" 400 461 "-" "-"
>
> Can I use the architecture I described above and still have every 
> puppetmaster from my load balance talking to PuppetDB ?
>
> I tried to delete the ssl certificates, generate them again, run 
> puppetdb-ssl-setup, etc but still same results.
>
> Thanks,
> Felipe
>

-- 
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/-/bd11TLhzqCwJ.
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 3.0: Not authorized to call find on /file_metadata, more issues?

[Felipe Salum]

I found out that I was missing a change in puppet.conf due using 
Puppetmaster Passenger:

from:
ssl_client_header = SSL_CLIENT_S_DN

to:
ssl_client_header = HTTP_X_SSL_SUBJECT

Now the permission issues are gone.

Weird enough that my Puppetmaster 2.7.x environment works without this 
change.

Felipe


On Tuesday, November 13, 2012 2:28:29 PM UTC-8, Felipe Salum wrote:
>
> I'm also having the same issue on the other locations. Not sure what's 
> wrong since this is a default installation of puppet 3 with the original 
> auth.conf
>
> Error: 
> /Stage[main]/Puppetdb::Master::Routes/File[/etc/puppet/routes.yaml]: Could 
> not evaluate: Error 403 on SERVER: Forbidden request: 
> puppet2.puppet.test(192.168.168.10) access to 
> /file_metadata/modules/puppetdb/routes.yaml [find] at :102 Could not 
> retrieve file metadata for puppet:///modules/puppetdb/routes.yaml: Error 
> 403 on SERVER: Forbidden request: puppet2.puppet.test(192.168.168.10) 
> access to /file_metadata/modules/puppetdb/routes.yaml [find] at :102
>
> Error: Could not retrieve catalog from remote server: Error 403 on SERVER: 
> Forbidden request: puppet2.puppet.test(192.168.168.10) access to 
> /catalog/puppet2.puppet.test [find] at :101
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
>
> Error: Could not send report: Error 403 on SERVER: Forbidden request: 
> puppet2.puppet.test(192.168.168.10) access to /report/puppet2.puppet.test 
> [save] at :102
>
>
> Maybe it is a naming resolution issue ? I'm using /etc/hosts since this is 
> a vagrant environment only for testing purposes.
>
> If I start updating auth.conf to use 'auth no' everywhere it passes.
>
> I don't see the problem on my production servers, so it worries me more :)
>
> On Monday, November 12, 2012 4:27:41 PM UTC-8, Felipe Salum wrote:
>>
>> Hi Nick.
>>
>> Actually this is a new environment I'm setting up using vagrant, puppet 3 
>> and the default auth.conf.
>>
>> I had to add allow_ip to the /reports request to make it work. Not sure 
>> why but it sometimes fail when using the puppet server provider from 
>> vagrant.
>>
>> Thanks,
>> Felipe
>>
>> On Mon, Nov 12, 2012 at 4:22 PM, Nick Fagerlund <
>> nick.fagerl...@puppetlabs.com> wrote:
>>
>>>
>>>
>>> On Saturday, November 10, 2012 5:43:48 PM UTC-8, Felipe Salum wrote:
>>>>
>>>> Is this related to the same error I have when I run the puppet agent on 
>>>> my nodes ?
>>>>
>>> Nov 11 01:40:09 squeeze puppet-agent[8683]: Could not send report: Error 
>>> 403 on SERVER: Forbidden request: puppetdb1.puppet.test(192.168.
>>> **168.12) access to /report/puppetdb1.puppet.test [save] authenticated  
>>> at :67
>>>
>>>
>>> No, other than that they're both related to authentication in auth.conf. 
>>> If you were upgrading from 2.6, note that the default value of the 'report' 
>>> setting changed between 2.6 and 2.7: 
>>>
>>>
>>> http://docs.puppetlabs.com/references/2.7.latest/configuration.html#report
>>>
>>> http://docs.puppetlabs.com/references/2.6.latest/configuration.html#report
>>>
>>> So if your auth.conf file doesn't allow authenticated nodes to send save 
>>> requests to /report, you will get errors. Examine your auth.conf file and 
>>> compare it to the one here: 
>>>
>>> https://github.com/puppetlabs/puppet/blob/master/conf/auth.conf
>>>
>>> You should have AT LEAST all the same rules, although your site may have 
>>> some extra rules as well. Be aware that order matters in this file. 
>>>
>>> -- 
>>> 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/-/rcFTBsu-IqkJ.
>>> 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 view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/PJt_eVvvh9gJ.
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: Thu Nov 29 10:17:51 +0000 2012 Puppet (err): Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to submit 'replace facts' command for XXX to PuppetDB at pupp

[Felipe Salum]

I had the same setup issue.

Go to your CA server and copy the puppet master unique certname .pem  from 
/var/lib/puppet/ssl/{certs,private_key/ to both your puppet master workers 
and restart apache.

Also make sure to follow this: 
http://docs.puppetlabs.com/guides/scaling_multiple_masters.html

The dns_alt_names part is very important:

 $ sudo puppet agent --test --dns_alt_names 
"master2.example.com,puppet,puppet.example.com"


I hope it helps, I spent a few hours until I got it figured out :)

Regards,
Felipe

On Thursday, November 29, 2012 3:31:59 AM UTC-8, Kalyana sundaram wrote:
>
> I have set up two puppet masters (load balanced) with a separate ca 
> server(ca is set false on masters). I brought up a new server for puppetDB. 
> It got certs signed from ca_server and ran puppet agent without any issue. 
> But when I started puppetdb and changed puppet master's conf to use 
> puppetdb(as per docs for puppetdb). This error started to come and 
> basically stopped puppet run
>  
>
>> Thu Nov 29 10:17:51 + 2012 Puppet (err): Could not retrieve catalog 
>> from remote server: Error 400 on SERVER: Failed to submit 'replace facts' 
>> command for XXX to PuppetDB at puppetdb.aus-tx.colo:8081: SSL_connect 
>> SYSCALL returned=5 errno=0 state=SSLv3 read finished A
>
>
> The puppetdb log throws
>   
>
>>[qtp665563146-341] [io.nio] javax.net.ssl.SSLHandshakeException: null 
>> cert chain
>
>
> I tested a https curl using command
>
>>  curl -H "Accept: application/json" 'https://puppetdb:8081/facts' 
>> --cacert /var/lib/puppet/ssl/certs/ca.pem --cert 
>> /var/lib/puppet/ssl/certs/puppetmaster.pem --key 
>> /var/lib/puppet/ssl/private_keys/puppetmaster.pem 
>
>   
> The curl didnt throw any error
>
> I am struck here for a long time. Pls do share your expertise
>

-- 
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/-/0g0BjWoGEnoJ.
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: Thu Nov 29 10:17:51 +0000 2012 Puppet (err): Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to submit 'replace facts' command for XXX to PuppetDB at

[Felipe Salum]

I'm not sure if I'm correct but what I understood after spending a few
hours on it:

Let's suppose you have:

certname: puppet.example.com

puppet_ca.example.com
puppet_worker1.example.com
puppet_worker2.example.com
puppetdb1.example.com

Your PuppetDB registered with your CA using the certname puppet.example.com,
but your puppet workers only have their own certnames (
puppet_worker1.example.com and puppet_worker2.example.com). When they talk
with PuppetDB to fetch/replace the facts, PuppetDB doesn't accept their
certificates because it was registered to the certname puppet.example.com.

Copying the puppet.example.com certificate from CA to the workers make them
to use it when responding to a puppet run under that certname.

Felipe

On Fri, Nov 30, 2012 at 12:09 PM, Kalyana sundaram wrote:

> Thanks Felipe
> Syncing certs privatekeys with ca_server worked
> But could somebody help me understand why each masters should have ca
> server's private key?
> How exactly this authentication process works?
>
> On Thursday, November 29, 2012 11:55:08 PM UTC+5:30, Felipe Salum wrote:
>>
>> I had the same setup issue.
>>
>> Go to your CA server and copy the puppet master unique certname .pem
>> from /var/lib/puppet/ssl/{certs,**private_key/ to both your puppet
>> master workers and restart apache.
>>
>> Also make sure to follow this: http://docs.puppetlabs.com/**
>> guides/scaling_multiple_**masters.html<http://docs.puppetlabs.com/guides/scaling_multiple_masters.html>
>>
>> The dns_alt_names part is very important:
>>
>>  $ sudo puppet agent --test --dns_alt_names 
>> "master2.example.com,puppet,pu**ppet.example.com <http://puppet.example.com>"
>>
>>
>> I hope it helps, I spent a few hours until I got it figured out :)
>>
>> Regards,
>> Felipe
>>
>>  --
> 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/-/dleFJ_6wh-EJ.
> 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: puppet master REST API returns 403 when running under passenger works when running from command line

[Felipe Salum]

On Apache/Passenger I have set a few headers:

  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

And then updated puppet.conf as below:

[master]

ssl_client_header = HTTP_X_SSL_SUBJECT

Does it fail if you use --server devops.X.com ? 
You should use the --server hostname as the same certname name used on the 
puppetmaster.

Regards,
Felipe


On Monday, December 10, 2012 5:32:33 AM UTC-8, Anadi Misra wrote:
>
> Hi! Everyone,
>
> puppet agent is not able to fetch any files, plugins or post catalog, 
> reports to the master. both puppet agent and master are on version 3.0.l, 
> passenger version 3.0.18 ,
>
> nginx version: nginx/1.3.9
> built by gcc 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) 
> TLS SNI support enabled
> configure arguments: --prefix=/apps/nginx 
> --conf-path=/apps/nginx/nginx.conf --pid-path=/apps/nginx/run/nginx.pid 
> --error-log-path=/apps/nginx/logs/error.log 
> --http-log-path=/apps/nginx/logs/access.log --with-http_ssl_module 
> --with-http_gzip_static_module 
> --add-module=/usr/lib/ruby/gems/1.8/gems/passenger-3.0.18/ext/nginx 
> --add-module=/apps/Downloads/nginx/nginx-auth-ldap-master/
>
> the agent command shows this output
>
> [amisr1@blramisr195602 ~]$ sudo puppet agent --no-daemonize --verbose 
> --server bangvmpllda02.XX.com
> Starting Puppet client version 3.0.1
> Warning: Unable to fetch my node definition, but the agent run will 
> continue:
> Warning: Error 403 on SERVER: Forbidden request: 
> 10.209.47.31(10.209.47.31) access to /certificate_revocation_list/ca [find] 
> at :106
> Info: Retrieving plugin
> Error: /File[/var/lib/puppet/lib]: Failed to generate additional resources 
> using 'eval_generate: Error 403 on SERVER: Forbidden request: 
> 10.209.47.31(10.209.47.31) access to /file_metadata/plugins [search] at :106
> Error: /File[/var/lib/puppet/lib]: Could not evaluate: Error 403 on 
> SERVER: Forbidden request: 10.209.47.31(10.209.47.31) access to 
> /file_metadata/plugins [find] at :106 Could not retrieve file metadata for 
> puppet://bangvmpllda02.XX.com/plugins: Error 403 on SERVER: Forbidden 
> request: 10.209.47.31(10.209.47.31) access to /file_metadata/plugins [find] 
> at :106
> Error: Could not retrieve catalog from remote server: Error 403 on SERVER: 
> Forbidden request: 10.209.47.31(10.209.47.31) access to /catalog/
> blramisr195602.XX.com [find] at :106
> Using cached catalog
> Error: Could not retrieve catalog; skipping run
> Error: Could not send report: Error 403 on SERVER: Forbidden request: 
> 10.209.47.31(10.209.47.31) access to /report/blramisr195602.XX.com[save] 
> at :106
>
> and on master logs I see
>
> [amisr1@blramisr195602 ~]$ sudo puppet agent --no-daemonize --verbose 
> --server bangvmpllda02.XX.com
> Starting Puppet client version 3.0.1
> Warning: Unable to fetch my node definition, but the agent run will 
> continue:
> Warning: Error 403 on SERVER: Forbidden request: 
> 10.209.47.31(10.209.47.31) access to /certificate_revocation_list/ca [find] 
> at :106
> Info: Retrieving plugin
> Error: /File[/var/lib/puppet/lib]: Failed to generate additional resources 
> using 'eval_generate: Error 403 on SERVER: Forbidden request: 
> 10.209.47.31(10.209.47.31) access to /file_metadata/plugins [search] at :106
> Error: /File[/var/lib/puppet/lib]: Could not evaluate: Error 403 on 
> SERVER: Forbidden request: 10.209.47.31(10.209.47.31) access to 
> /file_metadata/plugins [find] at :106 Could not retrieve file metadata for 
> puppet://bangvmpllda02.XX.com/plugins: Error 403 on SERVER: Forbidden 
> request: 10.209.47.31(10.209.47.31) access to /file_metadata/plugins [find] 
> at :106
> Error: Could not retrieve catalog from remote server: Error 403 on SERVER: 
> Forbidden request: 10.209.47.31(10.209.47.31) access to /catalog/
> blramisr195602.XX.com [find] at :106
> Using cached catalog
> Error: Could not retrieve catalog; skipping run
> Error: Could not send report: Error 403 on SERVER: Forbidden request: 
> 10.209.47.31(10.209.47.31) access to /report/blramisr195602.XX.com[save] 
> at :106
>
>
> I am not sure why is it evaluating things on IP?
>
> I also changed agent setup to following
>
> [main]
> # The Puppet log directory.
> # The default value is '$vardir/log'.
> logdir = /var/log/puppet
>
> # Where Puppet PID files are kept.
> # The default value is '$vardir/run'.
> rundir = /var/run/puppet
>
> # Where SSL certificates are kept.
> # The default value is '$confdir/ssl'.
> ssldir = $vardir/ssl
> report = true
> pluginsync = true
> server = devops.XX.com
> certname = blramisr195602.XX.com
> dns_alt_names = 10.209.47.31
> modulepath = /etc/puppet/modules
>
> and resigned certifcates on master after clean up, but the puppet master 
> still blocks it. However If I run through puppet master daemon (without 
> nginx + passenger) all re

[Puppet Users] Re: Reusable Puppet config for Vagrant

[Felipe Salum]

I have done something similar, installing puppet master, puppetdb and a few 
nodes for testing, everything via vagrant.

https://github.com/fsalum/vagrant-puppet

Felipe


On Tuesday, January 29, 2013 6:42:42 AM UTC-8, blalor wrote:
>
> I took an hour this morning to document how I use Vagrant and Puppet 
> together to provision development VMs as well as more production-like 
> systems.  This may be entirely elementary to folks who are more fluent with 
> Puppet, but this is an example I thought was lacking. 
>
> https://github.com/blalor/vagrant-puppet-example 
>
> I welcome feedback and criticism of this setup.  I'm looking to minimize 
> the difference between local development environments and production 
> systems as much as possible. 
>
> Thanks, 
> Brian

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Need a solution for "puppet node clean" (puppet v3.0.2)

[Felipe Salum]

I was searching about these some days ago and I found somewhere that the 
'puppet node deactivate ' would do the tricky.

I haven't tried it yet, so I can't confirm it works.

On Thursday, January 31, 2013 12:55:54 PM UTC-8, Chris Price wrote:
>
> David,
>
> Are you using PuppetDB?  There was a thread on this list recently about 
> the same topic, and there was some example SQL that could be used in the 
> short-term.  We have a few open tickets around coming up with better 
> solutions for this and we expect to be addressing them Very Soon Now.  If 
> you are using PuppetDB and you are interested in links (to either the 
> tickets or the previous thread) let me know and I'll dig them up.
>
> Thanks!
> Chris
>
> On Thursday, January 31, 2013 10:26:18 AM UTC-8, David Kerr wrote:
>>
>> My environment heavily depends on exported resources to detect our mongo 
>> instances and to populate our haproxies. 
>>
>> When we bring up and down nodes in AWS "puppet node clean" isn't cleaning 
>> up the exported resources so we get ghost
>> machines loaded into those config files.
>>
>> Up until today I've attempted to limp along by doing:
>> puppet node clean
>> sudo puppet cert clean
>> delete from catalog_resources where title like '%%'
>> delete from resource_params where value like '%%'
>>
>> That's been "pretty good", but today I ran into a problem where even that 
>> didn't work.
>>
>> I'm comfortable working in the DB, but what's tough is trying to match 
>> the 
>> hashed ID's across tables (the data model doesn't make it exactly clear 
>> what's going on)
>>
>> If someone's already tackled this beast and has a script that does it 
>> right, that would be fantastic.
>> I also understand that this is solved in 3.1, but I'm not too keen on 
>> upgrading to an RC just to
>> get exported resources working correctly.
>>
>> If someone has insight into the data model and can help me fill the gaps 
>> that would be wonderful
>>
>> 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Installing fog -0.7.2 for CloudProvisioner

[Felipe Salum]

I had the same problems some days ago and here are my notes to install it:

yum install -y gcc ruby-devel libxml2 libxml2-devel libxslt libxslt-devel 
make

When using fog 0.7.2 I got a lot of warnings while using puppet node_aws.. 
so I updated to latest fog and everything is working correctly now.

Felipe


On Wednesday, January 30, 2013 12:11:17 PM UTC-8, PuppetUser wrote:
>
> Hi,
>
> I am trying to install fog which is required for cloud provisioner. 
> > gem install fog -v 0.7.2
> I am getting the following error
>
> Building native extensions.  This could take a while...
>
> 
> ERROR:  Error installing fog:
> ERROR: Failed to build gem native extension.
>
> /usr/bin/ruby extconf.rb
> creating Makefile
>
> make
> /usr/lib/ruby/site_ruby/1.8/rubygems/ext/builder.rb:31:in `exec': No such 
> file or directory - make (Errno::ENOENT)
> from /usr/lib/ruby/site_ruby/1.8/rubygems/ext/builder.rb:31:in 
> `get_status_of_forked_command'
> from /usr/lib/ruby/site_ruby/1.8/rubygems/ext/builder.rb:23:in 
> `fork'
> from /usr/lib/ruby/site_ruby/1.8/rubygems/ext/builder.rb:23:in 
> `get_status_of_forked_command'
> from /usr/lib/ruby/site_ruby/1.8/rubygems/ext/builder.rb:84:in 
> `make'
> from /usr/lib/ruby/site_ruby/1.8/rubygems/ext/builder.rb:82:in 
> `each'
> from /usr/lib/ruby/site_ruby/1.8/rubygems/ext/builder.rb:82:in 
> `make'
> from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/ext/ext_conf_builder.rb:18:in `build'
> from /usr/lib/ruby/site_ruby/1.8/rubygems/installer.rb:532:in 
> `build_extensions'
> from /usr/lib/ruby/site_ruby/1.8/rubygems/installer.rb:531:in 
> `chdir'
> from /usr/lib/ruby/site_ruby/1.8/rubygems/installer.rb:531:in 
> `build_extensions'
> from /usr/lib/ruby/site_ruby/1.8/rubygems/installer.rb:505:in 
> `each'
> from /usr/lib/ruby/site_ruby/1.8/rubygems/installer.rb:505:in 
> `build_extensions'
> from /usr/lib/ruby/site_ruby/1.8/rubygems/installer.rb:180:in 
> `install'
> from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:297:in 
> `install'
> from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in 
> `each_with_index'
> from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `each'
> from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in 
> `each_with_index'
> from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in 
> `install'
> from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:121:in 
> `execute'
> from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in 
> `each'
> from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in 
> `execute'
> from /usr/lib/ruby/site_ruby/1.8/rubygems/command.rb:278:in 
> `invoke'
> from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:147:in 
> `process_args'
> from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:117:in `run'
> from /usr/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:65:in `run'
> from /usr/bin/gem:21
>
>
> Gem files will remain installed in /usr/lib/ruby/gems/1.8/gems/json-1.7.6 
> for inspection.
> Results logged to 
> /usr/lib/ruby/gems/1.8/gems/json-1.7.6/ext/json/ext/generator/gem_make.out
>
> Help me out in fixing the problem
>
> Regards
>
> Puppet User
>
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: puppet creating AWS EC instances

[Felipe Salum]

Upgrade to latest fog and the errors are gone.

On Friday, February 1, 2013 1:34:50 AM UTC-8, PuppetUser wrote:
>
> Hi,
>  
> I have installed fog 0.7.2 on linux amazon ami. Created ~/.fog file and 
> gave AWS credentials in the file.
> For verification i used
>  
> >ruby -rubygems -e 'require "fog"' -e 'puts Fog::Compute.new(:provider => 
> "AWS").servers.length >= 0'
> This returns true but with the following error.
>  
> Excon requests with a block are deprecated, pass :response_block instead 
> (/usr/lib/ruby/gems/1.8/gems/fog-0.7.2/lib/fog/core/connection.rb:20:in 
> `request')
> true
> When i use 
> puppet node_aws create --image ami-0011e069   --keyname puppet --type 
> m1.large for creating an instance, the instance is created but it gets 
> terminated. 
>  
> I get the following error in the console repeatedly
>  
> Excon requests with a block are deprecated, pass :response_block instead 
> (/usr/lib/ruby/gems/1.8/gems/fog-0.7.2/lib/fog/core/connection.rb:20:in 
> `request')
>  
> At end the instance will get created.
> In the console if i see the instance, the instance is terminated.
>  
> Can any one say what would be the issue. Waiting for the response
>  
> Regards
>  
> Srinivas
>
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Puppet dashboard stuck pending jobs

[Felipe Salum]

Are you having the problem after running 'puppet agent --test' a few times 
or it just happens without any manual run ?

I was having the same problem some days ago, in my case because I was 
running 'puppet agent --test', more specifically the --show_diff that is 
used in --test was automatically generating a lot of output and causing the 
puppet dashboard workers to fail and increase the processing queue.

Look at /usr/share/puppet-dashboard/log/delayed_job.log (or whatever your 
dashboard location is) and check what error it is giving.

You can clean the queue manually without reinstalling everything:

service puppet-dashboard-workers stop
cd /usr/share/puppet-dashboard
rm -f spool/*
rake jobs:clear RAILS_ENV=production
service puppet-dashboard-workers start

Regards,
Felipe

On Saturday, February 9, 2013 7:11:04 PM UTC-8, Jagga Soorma wrote:
>
> Anyone out there run into this issue before or have any idea about how to 
> troubleshoot such a problem?  Any help would be appreciated.  I can't keep 
> rebuilding puppet dashboard every time this happens.
>
> Thanks
>
> On Friday, February 8, 2013 2:37:55 PM UTC-8, Jagga Soorma wrote:
>>
>> Yes, the workers are definitely running and I have tried restarting 
>> puppet-dashboard-workers a few times as well as rebooting the vm completely 
>> without any luck.  Something seems to be stuck somewhere but I can't figure 
>> out what.  This has happened a few times now and I have just been 
>> recreating from scratch to get it functional again.  Are there any logs for 
>> the workers that might tell us why these pending jobs are stuck or not 
>> finishing?
>>
>> Thanks.
>>
>> On Fri, Feb 8, 2013 at 2:27 PM, Jo Rhett 
>> 
>> > wrote:
>>
>>> Make sure that your dashboard workers are running. If you are using 
>>> CentOS then "service puppet-dashboard-workers status" will tell you.
>>>
>>> On Feb 8, 2013, at 1:53 PM, Jagga Soorma wrote:
>>>
>>> I am a new puppet user and wanted some type of monitoring for puppet so 
>>> deployed puppet-dashboard.  It has been working very well for a few days 
>>> not, but all of a sudden I start getting pending tasks and they never 
>>> finish even after restarting all processes.  They keep accumulating and 
>>> never seem to finish even though the clients are running fine.  I have the 
>>> puppet-dashboard running on a different server than my puppetmaster.  Is 
>>> there any way to troubleshoot what seems to be stuck and how to I get it 
>>> going without having to destroy the dashboard mysql db and recreating it 
>>> again?  That is the only way I have got it working again but that is not 
>>> the correct way of doing this :)  Any help would be appreciated.
>>>
>>> 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...@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.
>>>  
>>>  
>>>
>>>
>>>  -- 
>>> 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 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.
>>>  
>>>  
>>>
>>
>>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] AWS OpsWorks announcement using Chef

[Felipe Salum]

I wonder if PuppetLabs will work with Amazon to try to add Puppet as an 
option to OpsWorks as well ?

I don't think people using Puppet with AWS in a stable fashion would try to 
move to OpsWorks and migrate everything to Chef, but new customers/startups 
would think twice in choosing Puppet if the service offered in AWS OpsWorks 
is based on Chef.

I haven't tried OpsWorks yet, so I can't say much.

Any thoughts ?

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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Puppet in EC2

[Felipe Salum]

I use an in-house bootstrap script that:

- launch an ec2 instance
- sets the hostname
- add to route53
- install puppet
- run puppet agent --server my-puppetmaster

My puppetmaster only accepts requests from ec2 instances from my aws 
account and auto sign the certificate, also installs puppet.conf and all 
the packages needed
based in the hostname regex of the nodes already defined in my nodes.pp.

./bootstrap.rb --name web1.mydomain --type m1.small ...etc

And in 10 minutes I have a fully deployed server with the right hostname, 
dns, security group and onboarded on puppet.

btw: I tried to use Puppet Cloud Provisioner but it really didn't do the 
job I needed, like it should be really easy for it to correct the hostname, 
but it doesn't, also fails 
if you use auto sign, and a lot of open issues and pull requests :(

Felipe


On Friday, March 8, 2013 10:41:04 PM UTC-8, sylvainkalache wrote:
>
> Hello! 
>
> I'm looking for the best way to integrate Puppet with EC2, I read 
> posts on that group but they are all old, I wanted to know if things 
> have changed since then. 
>
> So far here are the possibilities I found to tight EC2 with Puppet: 
>
> -Use the instance name as reference like  -- 
>  - http://bit.ly/YitdC3 
> -Use  the instance security group as reference 
> - http://bit.ly/YitdC3 
> -Use  the user-data, populate with JSON and 
> parse on the puppet master 
> side - http://bit.ly/13MsfGe 
> -Use  the user-data, but parse on client side 
> with facter - http://bit.ly/XZlVXD 
>
> I don't like to use the name or security as reference at these data 
> has not been designed for this. 
> I don't like user-data because you can't change them after the 
> instance is launched. 
>
> Finally I found all the approach kind of dirty for something which is 
> widely used. Are they other possibilities? 
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] puppet module satisfy dependencies issue

[Felipe Salum]

Hi guys,

I'm trying to understand the error below, but I'm stuck on it. 

root@puppet1:~# puppet module install ispavailability-logstash --modulepath 
/etc/puppet/modules-0/
Notice: Preparing to install into /etc/puppet/modules-0 ...
Notice: Downloading from https://forge.puppetlabs.com ...
Error: Could not install module 'ispavailability-logstash' (latest: v0.1.0)
  No version of 'puppetlabs-stdlib' will satisfy dependencies
'ispavailability-logstash' (v0.1.0) requires 'puppetlabs-stdlib' (>= 
3.0.0)
'puppetlabs-activemq' (v0.1.6) requires 'puppetlabs-stdlib' (>= 0.1.6)
'puppetlabs-apache' (v0.4.0) requires 'puppetlabs-stdlib' (>= 2.2.1)
'puppetlabs-apt' (v0.0.4) requires 'puppetlabs-stdlib' (>= 2.2.1)
'puppetlabs-java' (v0.2.0) requires 'puppetlabs-stdlib' (>= 0.1.6)
'puppetlabs-mysql' (v0.5.0) requires 'puppetlabs-stdlib' (>= 2.2.1)
'puppetlabs-nginx' (v0.0.1) requires 'puppetlabs-stdlib' (>= 0.1.6)
'puppetlabs-ntp' (v0.2.0) requires 'puppetlabs-stdlib' (>= 0.1.6)
'puppetlabs-postgresql' (v1.0.0) requires 'puppetlabs-stdlib' (v2.x)
Use `puppet module install --ignore-dependencies` to install only this 
module

Puppet module shows my stdlib as invalid

├── puppetlabs-stdlib (v3.2.0)  invalid

I remember I used --force last time to upgrade stdlib because of the same 
dependencies issue above.

Any help is welcome.

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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] puppet module satisfy dependencies issue

[Felipe Salum]

Thanks Ryan.

After a few upgrades (inifile,puppetdb,postgresql and a few others) I got
my dependency issue fixed :)

Regards,
Felipe

On Mon, Mar 25, 2013 at 4:17 PM, Ryan Coleman  wrote:

> Hi Felipe,
>
> Comment in-line.
>
>
> On Mon, Mar 25, 2013 at 4:06 PM, Felipe Salum  wrote:
>
>> Hi guys,
>>
>> I'm trying to understand the error below, but I'm stuck on it.
>>
>> root@puppet1:~# puppet module install ispavailability-logstash
>> --modulepath /etc/puppet/modules-0/
>> Notice: Preparing to install into /etc/puppet/modules-0 ...
>> Notice: Downloading from https://forge.puppetlabs.com ...
>> Error: Could not install module 'ispavailability-logstash' (latest:
>> v0.1.0)
>>   No version of 'puppetlabs-stdlib' will satisfy dependencies
>> 'ispavailability-logstash' (v0.1.0) requires 'puppetlabs-stdlib' (>=
>> 3.0.0)
>> 'puppetlabs-activemq' (v0.1.6) requires 'puppetlabs-stdlib' (>= 0.1.6)
>> 'puppetlabs-apache' (v0.4.0) requires 'puppetlabs-stdlib' (>= 2.2.1)
>> 'puppetlabs-apt' (v0.0.4) requires 'puppetlabs-stdlib' (>= 2.2.1)
>> 'puppetlabs-java' (v0.2.0) requires 'puppetlabs-stdlib' (>= 0.1.6)
>> 'puppetlabs-mysql' (v0.5.0) requires 'puppetlabs-stdlib' (>= 2.2.1)
>> 'puppetlabs-nginx' (v0.0.1) requires 'puppetlabs-stdlib' (>= 0.1.6)
>> 'puppetlabs-ntp' (v0.2.0) requires 'puppetlabs-stdlib' (>= 0.1.6)
>> 'puppetlabs-postgresql' (v1.0.0) requires 'puppetlabs-stdlib' (v2.x)
>>
>
> It's breaking because logstash requires stdlib version 3 or greater but
> puppetlabs-postgresql requires something in the 2.x series.
>
> Version 1.2.1 of postgresql looks like it removes this restriction.
> https://github.com/puppetlabs/puppet-postgresql/blob/master/Modulefile#L10
> If you try again, are you getting the latest version of postgresql? Given
> the output provided, I don't see why you're getting 1.0.0 of postgresql.
>
> As you noted, you can use --ignore-dependencies to skip this validation
> and manually install the modules you need.
>
>
>> Use `puppet module install --ignore-dependencies` to install only
>> this module
>>
>> Puppet module shows my stdlib as invalid
>>
>> ├── puppetlabs-stdlib (v3.2.0)  invalid
>>
>> I remember I used --force last time to upgrade stdlib because of the same
>> dependencies issue above.
>>
>> Any help is welcome.
>>
>> 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?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>
>
> --
> Ryan Coleman | Modules & Forge | @ryanycoleman | ryancoleman in #puppet
>
>
>  --
> 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/DMl5OPNvtfQ/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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] PuppetDB api - deactivate command

[Felipe Salum]

Right time for this :)

If I'm running this outside the localhost, do I need any specific auth 
permission ?

Regards,
Felipe

On Wednesday, March 27, 2013 7:21:09 AM UTC-7, Ken Barber wrote:
>
> Here is a better working example as a gist, with what you should see 
> in the puppetdb.log if it was successful: 
>
> https://gist.github.com/kbarber/5254512 
>
> On Wed, Mar 27, 2013 at 2:19 PM, Ken Barber 
> > 
> wrote: 
> > Try: 
> > 
> > curl -vv -G -H "Accept: application/json" 
> > 'http://localhost:8080/v2/commands' --data-urlencode 
> > 'payload={"command":"deactivate node","version": 
> > 1,"payload":"\"yournodename\""}' 
> > 
> > The command needs to be submitted with the form parameter 'payload'. 
> > The 'payload' part of the command is itself a JSON serialised string 
> > (hence the extra quotes and escaping). 
> > 
> > ken. 
> > 
> > On Wed, Mar 27, 2013 at 6:46 AM, Alexander Grushin 
> > > 
> wrote: 
> >> Hello, all 
> >> 
> >> I'm trying to use puppetdb's deactivate api call but can't find how to 
> >> correctly pass node name via payload. 
> >> 
> >> Calls like 
> >> `curl -G -H "Accept: application/json" '
> http://localhost:8080/v2/commands' 
> >> --data-urlencode '{ "command": "deactivate node", "version": 1, 
> "payload": { 
> >> "name": "nodename.domain.tld" } }'` 
> >> returns 'missing payload' error. 
> >> 
> >> Perhaps, key name is wrong, but in the documentation there are just 
> 'JSON 
> >> string', without any key names. 
> >> 
> http://docs.puppetlabs.com/puppetdb/1.1/api/commands.html#deactivate-node-version-1
>  
> >> 
> >> Could anybody give the real example how to use this call? 
> >> 
> >> Thanks! 
> >> 
> >> --- 
> >> Alexander Grushin 
> >> 
> >> -- 
> >> 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. 
> >> 
> >> 
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] PuppetDB api - deactivate command

[Felipe Salum]

Great, thanks Deepak.

On Thursday, March 28, 2013 9:25:49 AM UTC-7, Deepak Giridharagopal wrote:
>
> On Thu, Mar 28, 2013 at 10:20 AM, Felipe Salum 
> > wrote:
>
>> Right time for this :)
>>
>> If I'm running this outside the localhost, do I need any specific auth 
>> permission ?
>>
>
> Yes, you'll need to hit PuppetDB's HTTPS port (8081 by default) and you'll 
> have to supply a client certificate. Here's the relevant section from the 
> manual:
>
>
> http://docs.puppetlabs.com/puppetdb/1.1/api/query/curl.html#using-curl-from-remote-hosts-sslhttps
>
> deepak
>  
>
>>
>> Regards,
>> Felipe
>>
>>
>> On Wednesday, March 27, 2013 7:21:09 AM UTC-7, Ken Barber wrote:
>>
>>> Here is a better working example as a gist, with what you should see 
>>> in the puppetdb.log if it was successful: 
>>>
>>> https://gist.github.com/**kbarber/5254512<https://gist.github.com/kbarber/5254512>
>>>  
>>>
>>> On Wed, Mar 27, 2013 at 2:19 PM, Ken Barber  
>>> wrote: 
>>> > Try: 
>>> > 
>>> > curl -vv -G -H "Accept: application/json" 
>>> > 'http://localhost:8080/v2/**commands<http://localhost:8080/v2/commands>' 
>>> --data-urlencode 
>>> > 'payload={"command":"**deactivate node","version": 
>>> > 1,"payload":"\"yournodename\""**}' 
>>> > 
>>> > The command needs to be submitted with the form parameter 'payload'. 
>>> > The 'payload' part of the command is itself a JSON serialised string 
>>> > (hence the extra quotes and escaping). 
>>> > 
>>> > ken. 
>>> > 
>>> > On Wed, Mar 27, 2013 at 6:46 AM, Alexander Grushin  
>>> wrote: 
>>> >> Hello, all 
>>> >> 
>>> >> I'm trying to use puppetdb's deactivate api call but can't find how 
>>> to 
>>> >> correctly pass node name via payload. 
>>> >> 
>>> >> Calls like 
>>> >> `curl -G -H "Accept: application/json" 'http://localhost:8080/v2/**
>>> commands <http://localhost:8080/v2/commands>' 
>>> >> --data-urlencode '{ "command": "deactivate node", "version": 1, 
>>> "payload": { 
>>> >> "name": "nodename.domain.tld" } }'` 
>>> >> returns 'missing payload' error. 
>>> >> 
>>> >> Perhaps, key name is wrong, but in the documentation there are just 
>>> 'JSON 
>>> >> string', without any key names. 
>>> >> http://docs.puppetlabs.com/**puppetdb/1.1/api/commands.**
>>> html#deactivate-node-version-1<http://docs.puppetlabs.com/puppetdb/1.1/api/commands.html#deactivate-node-version-1>
>>>  
>>> >> 
>>> >> Could anybody give the real example how to use this call? 
>>> >> 
>>> >> Thanks! 
>>> >> 
>>> >> --- 
>>> >> Alexander Grushin 
>>> >> 
>>> >> -- 
>>> >> 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<http://groups.google.com/group/puppet-users?hl=en>.
>>>  
>>>
>>> >> For more options, visit 
>>> >> https://groups.google.com/**groups/opt_out<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...@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.
>>  
>>  
>>
>
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Announce: Module puppetalbs/puppetdb 1.2.1 Available

[Felipe Salum]

Ken,

Looks like the new parameters (report_ttl, node_ttl, node_purge_ttl) are 
not working. It is not being sent by the puppetdb::server class to the 
database_ini class. Neither from the puppetdb main class to the 
puppetdb::server class.

It is also not being used in database_ini as it is set to use only the 
values coming from the params.

I sent a pull request to fix it 
https://github.com/puppetlabs/puppetlabs-puppetdb/pull/49

Let me know if that helps.

Thanks,
Felipe

On Monday, April 8, 2013 10:21:12 AM UTC-7, Ken Barber wrote:
>
> A new release of the puppetlabs/puppetdb module is now available on the 
> Forge: 
>
> http://forge.puppetlabs.com/puppetlabs/puppetdb/1.2.1 
>
> This is a bugfix releases that solves the PuppetDB startup exception: 
>
> java.lang.AssertionError: Assert failed: (string? s) 
>
> This was due to the default `node-ttl` and `node-purge-ttl` settings 
> not having a time suffix by default. These settings required 's', 'm', 
> 'd' etc. to be suffixed, even if they are zero. 
>
> Changes 
>  
>
> * (Dominic Cleal) Add unit suffix to TTL settings to avoid issue #20099 
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Design pattern for exported resources from EC2 autoscaled instances

[Felipe Salum]

I did an autoscaling pilot some months ago and I needed something similar 
to this. For the pilot to work (far from the best solution), I was 
triggering a puppet run on the server (DAS in your case) from the new 
launched autoscaling instance, using mco as you noted if you have mco 
working in your instance, or via ssh in my case.

This was just a pilot and I don't need to say the security issues of having 
mco client enabled on every instance or ssh private keys.

On Sunday, April 21, 2013 4:31:57 PM UTC-7, Shiva Narayanaswamy wrote:
>
> My setup has an EC2 autoscaling group of clustered glassfish application 
> servers. Each glassfish instance will register itself with a DAS (Domain 
> Administration Server) to become a member of the cluster, and deregister 
> itself when it is killed. I was intending to orchestrate this via puppet 
> exported resources. However I am stuck with trying to figure out how to get 
> the DAS server to apply puppet configuration everytime an instance is born 
> in the autoscaling group. 
> I can schedule puppet to run on the DAS server every 30 minutes, but I 
> cant afford to wait 30 minutes. I would like to do this as soon as an 
> instance is provisioned. The only way I can think of doing this is using 
> mcollective. Am I overlooking something?
>
> If I havent made myself very clear, please let me know, and I can try to 
> explain better.
>
> Looking forward to some design patterns from some experienced gurus!
>
> Thanks,
> Shiva
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: how do you test and release puppet changes?

[Felipe Salum]

I'm basically doing the same.

I have replicated my production environment in Vagrant, that means the 
puppetmaster/puppetdb setup as well as the app,db,cache,api layers are 
identical to production in the vagrant setup.

After all tests are done in Vagrant, destroying and re-creating the VMs 
from scratch to make sure any new change or manifests do not break when 
installing a new machine from scratch we submit a pull request of the 
change to a specific branch, somebody else in the team reviews and merges 
it. The requester pull the changes in the production puppetmaster in a 
specific environment, connect to a few nodes in production and run puppet 
agent --environment to validate it. 

Once we are satisfied, we merge that branch into master and pull it into 
the puppetmaster production environment which all nodes use by default.

Any tips to improve this process is welcome :)

Felipe

On Friday, April 26, 2013 10:03:47 AM UTC-7, Derek Olsen wrote:
>
>
> We are in the process of evaluating our puppet related test and 
> release process and interested in knowing what other folks are doing. 
>
> We are in a position that is not ideal but is not unique from what I 
> can tell.   Our current testing process is basically the 
> responsibility of each person making a change.   Small changes are 
> committed and pushed to dev/qa/prod in one swoop with the committer 
> spot checking the results manually.Larger changes are tested by 
> running a node against a puppet environment which is pointed to the 
> change branch and the desired behavior is manually verified. 
>
> What we would like to do is start with implementing some basic control 
> points which require passing tests before the changes move along. 
> With the goal of being able to increase the test coverage over time to 
> protect ourselves from ourselves. 
>
> One thought we had as an initial step is to just verify catalog 
> compilation for some number of nodes against the proposed changes and 
> block the changes if catalog compilation fails.   This raises the next 
> question around tooling.   We could script up a catalog compiler test 
> calling the the puppet binaries but should we use this as an 
> opportunity to get familiar with rspec-puppet? 
>
> Are people using catalog diffs at all in their release process?   It 
> would seem nice to provide an automated catalog diff for people making 
> 'small' changes so they can make sure their change didn't accidentally 
> drop or change a large number of resources. 
>
> So please share what you find works or doesn't work at your shop. 
>
> TIA> 
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] puppet cert error

[Felipe Salum]

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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Re: High Availability of Puppet server for separate geographical location

[Felipe Salum]

Is Puppetlabs planning some easy solution for this ?

The real problem I see is that you can't separate the Puppet CA from the 
Puppet Master. So even that you can have multiple puppet masters, the CA 
must run in one of them. So if that server goes down your multiple puppet 
master setup is screwed as well.

I would love to see a Puppet CA high availability solution out of the box.

On Tuesday, April 30, 2013 6:43:08 AM UTC-7, R.I. Pienaar wrote:
>
>
>
> - Original Message - 
> > From: "jcbollinger"  
> > To: puppet...@googlegroups.com  
> > Sent: Tuesday, April 30, 2013 2:39:52 PM 
> > Subject: [Puppet Users] Re: High Availability of Puppet server for 
> separate geographical location 
> > 
> > 
> > 
> > On Monday, April 29, 2013 8:55:39 AM UTC-5, shyam sundar Keshari wrote: 
> > > 
> > > Hi Team, 
> > > 
> > > I have to configure puppet server in Primary-Secondary mode for 2 
> > > distributed location . 
> > > 
> > > Site A is already running 1 Puppet server .Now I need to configure 
> > > another puppet secondary server at site B ,so that 
> > > 
> > > all client at location B ,only connect to that server .And site A 
> > > puppet client only connect to site A . 
> > > 
> > > But mine requirement is of that suppose site A server goes down then 
> > > Site B server handle all client request and 
> > > 
> > > same if Site B server down then server A handles all . 
> > > 
> > > Kindly guide me to implement this scenario . 
> > > 
> > > 
> > For the most part, this is outside Puppet's scope.  You need to stand up 
> > some kind appliance or service in front of your Puppet servers to 
> monitor 
> > when one goes down, so as to redirect traffic to the other when needed. 
> > That cannot be part of Puppet, else it would go down with Puppet if ever 
> > Puppet went down. 
> > 
> > With an external failover system in place, there would still be a few 
> > things to arrange on the Puppet side.  In order for site B to properly 
> > serve site A's nodes, it must have 
> > 
> >- site A's SSL certificate, or at least a certificate that site A's 
> >nodes will trust; 
> >- ENC and/or node declarations for site A's nodes, matching those on 
> >site A; 
> >- modules (and standalone classes, if any) matching those on site A; 
> >- external data (if applicable) appropriate for site A's nodes; and 
> >- stored configs for site A, if applicable. 
>
> SRV goes a long way towards solving some of this, it is possible to share 
> a CA between masters too which solves some of that.  Gets a lot harder 
> when 
> you involve PuppetDB. 
>
> http://docs.puppetlabs.com/guides/scaling_multiple_masters.html 
>
>
> > 
> > I see two reasonably good approaches here: 
> > 
> >1. the site A and B masters are maintained as a mirrored pair.  This 
> has 
> >the effect that from Puppet's perspective, physical sites A and B are 
> >meaningless partitions of a single large, federated site.  A shared, 
> >central certificate authority would be required (and that would need 
> to be 
> >the site A master if you want to avoid issuing new certificates to 
> all the 
> >site A nodes). 
> >2. A mirror of site A's master is maintained as a hot spare at site 
> B, 
> >and vice versa.  Each spare could run on the same (possibly virtual) 
> >hardware as the local master (but on a different port), or it could 
> run on 
> >different hardware and merely be geographically colocated.  This 
> would 
> >maintain a logical distinction between sites A and B, and would be 
> overall 
> >easier to set up and maintain. 
> > 
> > If you consider option 2, however, you should soon realize that in that 
> > case you don't get any particular advantage from putting the spare 
> masters 
> > on the same machine as the local site's main master.  Indeed, it might 
> be 
> > easier to set them up as ordinary nodes (for the site in which they are 
> > actually located), and even to let the local site's masters have 
> > responsibility for maintaining the spares' puppet master config, each as 
> a 
> > mirror of the other site's master. 
> > 
> > 
> > John 
> > 
> > -- 
> > 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. 
> > 
> > 
> > 
>

-- 
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/pup

Re: [Puppet Users] Re: High Availability of Puppet server for separate geographical location

[Felipe Salum]

Yes it works perfectly, I run 2 puppet servers and one of them is the CA 
using a CNAME as well for the puppet master/ca.

After it is set and working it is wonderful, however until you figure out 
that you need to remove the ssldir, then run puppet with dns_alt_names, 
then sign with dns_alt_names in the other side, then start the 
apache2/passenger, then do a lot of more other tricks until you get out of 
the certificate error messages it is a headache :)

Easy solution would be something that would be easier to setup, or maybe it 
is just me trying to complicate things. :)

On Wednesday, May 8, 2013 4:58:21 PM UTC-7, John Warburton wrote:
>
> On 9 May 2013 05:57, Felipe Salum > wrote:
>
>> Is Puppetlabs planning some easy solution for this ?
>>
>
> I run 12 puppet servers around the world. They work in a multiple puppet 
> master solution where any client from any location can work with any puppet 
> server in any location with dns_alt_names. We have an easy/simple solution:
>
> One puppet server is designated puppet-ca.example.com. All client's 
> configuration files look like this:
>
> ca_server = puppet-ca.example.com
>
> A second puppet server is randomly chosen to be puppet-ca2.example.com. A 
> rsync job runs every minute on puppet-ca2 to only suck down the 
> .../etc/ssl/ca directory from puppet-ca
>
> If puppet-ca becomes unavailable, we move the puppet-ca CNAME to 
> puppet-ca2. That lag is acceptable to us. You may chose to use other load 
> balancing options like an F5
>
> John
>  

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Re: High Availability of Puppet server for separate geographical location

[Felipe Salum]

I'm trying to make a manifest to auto setup Puppet High Availability, but
it is the chicken-egg issue here. As for your secondary/tertiary/etc
puppetmasters, you need to copy the private key and certificate used by
your puppet1 server in order for it to accept the requests coming from
puppet.yourcompanydomain.com or whatever you choose there.

Also you need to maintain the /var/lib/puppet/ssl/ca in sync between all
puppetmasters so you can easily failover if puppet1 is down to any other.

Since Puppet is about automation, when I mentioned something easier to
setup I was expecting a puppet module to implement it, not manual changes.
As the implementation is not very straightforward it is not easy to
automate it IMHO.



On Fri, May 10, 2013 at 10:52 AM, Ramin K  wrote:

> On 5/9/2013 1:51 PM, Martin Langhoff wrote:
>
>> On Thu, May 9, 2013 at 2:31 PM, Ramin K  wrote:
>>
>>> Hubris, today thy name is Martin. :-)
>>>
>>
>> Fair enough. I am happy about the tool I am writing (almost finished!)
>> but, as the followup post makes clear, it isn't about the designe of
>> ppg. It is about the design of git.
>>
>
> This is where I think we diverge. :-) As someone with a fair
> amount of operational experience it's not about the design of git, it's
> about the implementation created on top of git. Or Puppet.
>
>
>  I'd argue that people have stressed about DNS availability for just
>>> under three decades and that we are currently enjoying the fruits of that
>>> labor. Personally, I have yet to work at a company where DNS has not
>>> caused
>>> a significant outage.
>>>
>>
>> I am really surprised at your statement. Of course mishaps can happen,
>> or someone can mess up configuration DNS royally. But setting up a
>> primary and secondary setup is trivial.
>>
>> SMTP and LDAP are also examples where resilience was baked into the
>> design. With those two, the quality of implementation, and
>> complications in setup make for a lot more breakage.
>>
>> Compare to HTTP, databases etc where there's a whole industry of tools
>> to make things somewhat reliable.
>>
>> Maybe we are talking about different things.
>>
>
> Not different things, but perspectives.
>
> I'd agree that your simple primary/secondary name server is easy
> to setup and it'll probably work just fine. However it supports a very
> limited number of use cases and traffic levels.
>
> My experience with DNS and administrating it in various
> incarnations since the bad old days of Bind 4 informs me that it can be
> incredibly fragile. It is only the implementation of the current DNS system
> that is reasonably resilient or at least able to localize failure.
> Certainly some designs and technology are better than others, but
> implementation always matters.
>
> The same goes for just about system/protocol you'd care to name.
>
>
>  Your ppg tooling does look interesting, but there is a large trade
>>> off in functionality
>>>
>>
>> What is the loss of functionality you see? Anything that you use in
>> practice?
>>
>> (Reading here https://groups.google.com/**forum/?fromgroups=#!topic/**
>> puppet-users/7ZpAMrMb2NQ
>> I can't spot anything major, but I may be missing something...)
>>
>> cheers,
>> m
>>
>
> Masterless Puppet with git as a distribution method does have some
> things going for it as a design. You are giving up things like collected
> resources and standard reporting which may or may not matter you.
> Additionally you're building a distribution system of some sort even if
> it's just git and ssh where you'd need to decide how to deal with the
> failure of the parts.
>
> In any case I'd like to see more discussion on highly available
> Puppet regardless of way it's implemented.
>
> Ramin
>
>
> --
> 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/**Ze5QFJ95y3E/unsubscribe?hl=en
> .
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscribe@**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?hl=en.
For more op

Re: [Puppet Users] Re: High Availability of Puppet server for separate geographical location

[Felipe Salum]

If you don't need to backup your puppetca, how do you carry over to a
standby puppetca server your client signed certificates and revocation list
in case of failure in the production puppetca ?


On Tue, May 14, 2013 at 8:04 AM, Mason Turner  wrote:

> We have a similar setup, minus the SRV records (although that looks quire
> interesting, gotta get off of 2.7). And we push SVN checkouts instead of
> git, but that's not a big difference.
>
> I have been thinking about the CA, and how to make it more available. My
> first thought is, do we have to save the generated client certs at all? I
> brought this up a few weeks ago and the general answer was "there is no
> technical reason to keep the certs", so I am considering deleting them
> immediately. Now I don't have to worry about backing up the puppetca!
>
> Next, and this is where my SSL weakness  will shine, could you have all of
> your HA-puppetmasters run as CAs, too, and then have multiple CA certs on
> trusted list on the puppet masters? Something like this:
> 1. foo-east01 comes up, and gets an auto-signed vert from pm-east01.
> 2. pm-east01 hit by asteroid, so foo-east01 automatically fails over to
> foo-west01
> 3. pm-west01 knows to trust the pm-east-01 signed cert.
> 4. We stand up a pm-east0.new1, generate a new vert for it and append said
> cert to the trusted list for all clients/PMs.
> 5. foo-east01 starts using pm-east01.new again
> 6. foo-east02 comes up, gets a cert from pm-east01.new
> (This is starting to feel like a certificate rotation strategy in some
> weird way).
>
> One thing I wonder is if I'll actually be a little more secure. Instead of
> having to have a single CA with a huge FW configuration (we have a lot of
> independent networks across the 'net), each PM/CA has only a very specific
> FW ruleset.
>
> On May 14, 2013, at 7:35 AM, Erik Dalén 
> wrote:
>
>
>
>
> On 10 May 2013 19:52, Ramin K  wrote:
>
>>
>> In any case I'd like to see more discussion on highly available
>> Puppet regardless of way it's implemented.
>
>
> We are using SRV records for running multiple puppetmasters and selecting
> a site local but allowing fallback to others in case it is down.
> We have 6 puppetmasters for the production environment running in this way
> currently. Each normally handling 500-1000 nodes. The git repository is
> push replicated to each one of them.
>
> But only one is CA, it is backed up. If it would crash we are fine with
> having a outage on installing new nodes until we have restored that part to
> another node. But we have looked into some solutions for maybe making it
> more resilient though.
>
> For PuppetDB we have two service nodes and a master and hot standby for
> the postgres database.
>
> --
> Erik Dalén
>
> --
> 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?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>  --
> 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/Ze5QFJ95y3E/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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] puppetlabs-dashboard module failing on puppet 3.2.1

[Felipe Salum]

Hi guys,

After upgrading my puppetmaster from 3.1.1 to 3.2.1 I'm getting the error 
below:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Failed to parse template dashboard/passenger-vhost.erb:
  Filepath: /usr/lib/ruby/vendor_ruby/puppet/parser/templatewrapper.rb
  Line: 81
  Detail: Could not find value for 'dashboard_port' at 
/etc/puppet/modules-0/dashboard/templates/passenger-vhost.erb:1
 at /etc/puppet/modules-0/apache/manifests/vhost.pp:117 on node 
puppet1.puppet.test
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

It works if I edit the passenger-vhost.erb and add a @ in all variables:

Listen <%= @dashboard_port %>

>
  ServerName <%= @name %>
  DocumentRoot <%= @docroot %>
  RailsBaseURI <%= @rails_base_uri %>
  >

Is this expected behavior in Puppet 3.2.1 ?

Here is my class definition:

  class {'dashboard':
dashboard_ensure=> 'present',
dashboard_user  => 'www-data',
dashboard_group => 'www-data',
dashboard_db=> 'dashboard_prod',
dashboard_charset   => 'utf8',
dashboard_port  => '8080',
passenger   => true,
  }

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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Re: puppet cert error

[Felipe Salum]

Hi Jason,

Yes I did something similar but I just recovered a snapshot from my volume
before the corrupted certs happened and replace everything.

Regards,
Felipe
On Jul 10, 2013 10:13 AM, "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 a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/V4DSH0wofVA/unsubscribe.
> 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.
> 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.

[Puppet Users] Problem running rake node:del for Puppet Dashboard databse hosted on RDS

[Felipe Salum]

Hi guys,

The command below was working when my puppet dashboard mysql database was 
running in the same machine as the puppet master.

rake RAILS_ENV=production -f /usr/share/puppet-dashboard/Rakefile node:del 
name=my-app-server

However now I moved the mysql database to RDS and it doesn't work anymore, 
my database.yml reflects the change and the Puppet Dashboard web interface 
works fine accessing the RDS database, but the rake task to delete is 
broken. Interesting is that node:list works and list all my nodes.

production:
  database: dashboard_production
  username: username
  password: password
  host: something.at.rds.amazonaws.com
  encoding: utf8
  adapter: mysql

Did I miss something during the local mysql to RDS migration ?

Thanks,
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] Re: Problem running rake node:del for Puppet Dashboard databse hosted on RDS

[Felipe Salum]

I had a friend helping me to debug and looks like it is taking forever to 
delete the entries from resource status table (a lot of entries).

Is that something we can improve ?

On Wednesday, July 24, 2013 11:42:26 AM UTC-7, Felipe Salum wrote:
>
> Hi guys,
>
> The command below was working when my puppet dashboard mysql database was 
> running in the same machine as the puppet master.
>
> rake RAILS_ENV=production -f /usr/share/puppet-dashboard/Rakefile node:del 
> name=my-app-server
>
> However now I moved the mysql database to RDS and it doesn't work anymore, 
> my database.yml reflects the change and the Puppet Dashboard web interface 
> works fine accessing the RDS database, but the rake task to delete is 
> broken. Interesting is that node:list works and list all my nodes.
>
> production:
>   database: dashboard_production
>   username: username
>   password: password
>   host: something.at.rds.amazonaws.com
>   encoding: utf8
>   adapter: mysql
>
> Did I miss something during the local mysql to RDS migration ?
>
> Thanks,
> 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.

Re: [Puppet Users] Re: Problem running rake node:del for Puppet Dashboard databse hosted on RDS

[Felipe Salum]

I actually do for 2 weeks.

rake RAILS_ENV=production reports:prune upto=2 unit=wk



On Wed, Jul 24, 2013 at 2:03 PM, Ramin K  wrote:

> On 7/24/2013 1:49 PM, Felipe Salum wrote:
>
>> I had a friend helping me to debug and looks like it is taking forever
>> to delete the entries from resource status table (a lot of entries).
>>
>> Is that something we can improve ?
>>
>
> env RAILS_ENV=production rake reports:prune upto=5 unit=day
> env RAILS_ENV=production rake reports:prune:orphaned
>
> You can change the RAILS_ENV and number of day, weeks, months, etc to
> match your system and its needs.
>
> Sounds like you've never pruned so it's going to be slow going. Try
> walking it forward like so.
>
> env RAILS_ENV=production rake reports:prune upto=3 unit=mon
> env RAILS_ENV=production rake reports:prune upto=1 unit=mon
> env RAILS_ENV=production rake reports:prune upto=2 unit=wk
> env RAILS_ENV=production rake reports:prune upto=5 unit=day
>
> Don't forget to add this to your crontab with the retentions settings that
> best fit your system.
>
> Ramin
>
> --
> 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/7-**sjp1Ef1p0/unsubscribe<https://groups.google.com/d/topic/puppet-users/7-sjp1Ef1p0/unsubscribe>
> .
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscribe@**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<http://groups.google.com/group/puppet-users>
> .
> For more options, visit 
> https://groups.google.com/**groups/opt_out<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] Re: Problem running rake node:del for Puppet Dashboard databse hosted on RDS

[Felipe Salum]

I understood, what I wanted to say is that I run a cron job every day for
the 2 weeks prune.. and I have less than 2 weeks data in the database right
now since I moved it recently to a new server.

I'm running a optimize task, the resource_statuses is really big.


On Wed, Jul 24, 2013 at 3:21 PM, Ramin K  wrote:

> Doesn't matter, it's the size of the data and the amount you're
> deleting.
>
> Let's say that your reports:prune upto=2 unit=wk is ultimately going to
> delete 100k records because you've never pruned the database before.
>
> reports:prune upto=2 unit=wk, 100k, time: 3600s
>
> By breaking it up, it'll run faster because large deletes can cause poor
> performance in Mysql.
>
> reports:prune upto=9 unit=wk, deletes: 9k, time: 280s
> reports:prune upto=8 unit=wk, deletes: 11k, time: 250s
> reports:prune upto=7 unit=wk, deletes: 10k, time: 251s
> reports:prune upto=6 unit=wk, deletes: 12k, time: 239s
> reports:prune upto=5 unit=wk, deletes: 11k, time: 205s
> reports:prune upto=4 unit=wk, deletes: 11k, time: 180s
> reports:prune upto=2 unit=wk, deletes: 22k, time: 200s
>
> Running it nightly with a fully prune data set.
> reports:prune upto=2 unit=wk, deletes: 1.5k, time: 25s
>
> ** I made up all these numbers up, but the performance ratio should be
> roughly correct based on past experience. ymmv. **
>
> Also the Rake task will load the id of the records it plans to delete into
> memory. This can be quite large and is another reason to break it into
> smaller chunks.
>
> Ramin
>
>
> On 7/24/2013 2:08 PM, Felipe Salum wrote:
>
>> I actually do for 2 weeks.
>>
>> rake RAILS_ENV=production reports:prune upto=2 unit=wk
>>
>>
>>
>> On Wed, Jul 24, 2013 at 2:03 PM, Ramin K > <mailto:ramin-list@badapple.**net >> wrote:
>>
>> On 7/24/2013 1:49 PM, Felipe Salum wrote:
>>
>> I had a friend helping me to debug and looks like it is taking
>> forever
>> to delete the entries from resource status table (a lot of
>> entries).
>>
>> Is that something we can improve ?
>>
>>
>> env RAILS_ENV=production rake reports:prune upto=5 unit=day
>> env RAILS_ENV=production rake reports:prune:orphaned
>>
>> You can change the RAILS_ENV and number of day, weeks, months, etc
>> to match your system and its needs.
>>
>> Sounds like you've never pruned so it's going to be slow going. Try
>> walking it forward like so.
>>
>> env RAILS_ENV=production rake reports:prune upto=3 unit=mon
>> env RAILS_ENV=production rake reports:prune upto=1 unit=mon
>> env RAILS_ENV=production rake reports:prune upto=2 unit=wk
>> env RAILS_ENV=production rake reports:prune upto=5 unit=day
>>
>> Don't forget to add this to your crontab with the retentions
>> settings that best fit your system.
>>
>> Ramin
>>
>> --
>> 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/7-__**
>> sjp1Ef1p0/unsubscribe<https://groups.google.com/d/__topic/puppet-users/7-__sjp1Ef1p0/unsubscribe>
>> <https://groups.google.com/d/**topic/puppet-users/7-**
>> sjp1Ef1p0/unsubscribe<https://groups.google.com/d/topic/puppet-users/7-sjp1Ef1p0/unsubscribe>
>> >.
>>
>> To unsubscribe from this group and all its topics, send an email to
>> puppet-users+unsubscribe@__goo**glegroups.com<http://googlegroups.com>
>> 
>> <mailto:puppet-users%**2bunsubscr...@googlegroups.com
>> **>.
>>
>> To post to this group, send email to puppet-users@googlegroups.com
>> <mailto:puppet-users@**googlegroups.com
>> >.
>> Visit this group at 
>> http://groups.google.com/__**group/puppet-users<http://groups.google.com/__group/puppet-users>
>> 
>> <http://groups.google.com/**group/puppet-users<http://groups.google.com/group/puppet-users>
>> >.
>> For more options, visit 
>> https://groups.google.com/__**groups/opt_out<https://groups.google.com/__groups/opt_out>
>> 
>> <https://groups.google.com/**groups/opt_out<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 receiv

[Puppet Users] puppet dashboard failed tasks every night

[Felipe Salum]

Hi guys.

I'm trying to find the root cause of my puppet dashboard report failed 
tasks that happen every night. It works without any error all day long but 
when I connect in the morning to check it has around 3000 failed tasks from 
the night before.

Any advice what could be impacting puppet dashboard reports only during the 
night ?

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.

Re: [Puppet Users] puppet dashboard failed tasks every night

[Felipe Salum]

I checked that, nothing that could impact this. But I'm probably missing
something since it is every night no exception.


On Tue, Aug 27, 2013 at 10:15 AM, Peter Bukowinski  wrote:

> Do you have any daily cron jobs that occur overnight?
>
> --
> Peter
>
> On Aug 27, 2013, at 1:08 PM, Felipe Salum  wrote:
>
> Hi guys.
>
> I'm trying to find the root cause of my puppet dashboard report failed
> tasks that happen every night. It works without any error all day long but
> when I connect in the morning to check it has around 3000 failed tasks from
> the night before.
>
> Any advice what could be impacting puppet dashboard reports only during
> the night ?
>
> 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.
>
>
>  --
> 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/uH7XQqY1GAM/unsubscribe.
> 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.
> 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] Pulling my hair out with CA proxying

[Felipe Salum]

Can you paste your /etc/httpd/conf.d/puppetmaster.conf ?

On Wednesday, October 2, 2013 5:35:58 AM UTC-7, Pete Hartman wrote:
>
> I do not have responsibility for the F5's and I'm not sure what my 
> networking team would be willing to do in terms of custom rules no 
> matter how simple. 
>
> The use of the apache proxy service on the masters is a configuration 
> documented and recommended (at least as one alternative) by 
> PuppetLabs; now that I have found what I was missing, I plan to stick 
> with that. 
>
> On Wed, Oct 2, 2013 at 2:08 AM, Gavin Williams 
> > 
> wrote: 
> > Pete 
> > 
> > I've not done this before, however am familiar with Puppet, and know a 
> lot more about F5s... 
> > 
> > I note that you say that you're expecting apache on the masters to proxy 
> onto the CA server. 
> > Is there any reason you couldn't use the F5 to select the CA server for 
> any CA requests? 
> > Should be a fairly straight forward iRule to do pool selection based on 
> the URI. 
> > 
> > Thoughts? 
> > 
> > Gav 
> > 
> > -- 
> > 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/xY5xnOU09Qg/unsubscribe. 
> > To unsubscribe from this group and all its topics, 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. 
> > 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.

[Puppet Users] Re: Help with configuring Puppet Proxies using Apache

[Felipe Salum]

This is how I do it here

https://github.com/fsalum/vagrant-puppet/blob/master/puppetmaster/templates/etc/apache2/sites-available/puppetmaster_balancer.erb
https://github.com/fsalum/vagrant-puppet/blob/master/puppetmaster/files/etc/apache2/sites-available/puppetmaster_ca
https://github.com/fsalum/vagrant-puppet/blob/master/puppetmaster/files/etc/apache2/sites-available/puppetmaster_worker

Felipe

On Monday, November 18, 2013 12:38:41 PM UTC-8, kschafer2598 wrote:
>
> Hi All,
>
> I have an environment with multiple network environments separated by 
> firewalls. I would like to proxy Puppet traffic from these network 
> environments to a central Puppet master server. 
>
> I've had a great experience with Puppet overall, though it has been rather 
> trying to find documentation on the subject of proxying puppet traffic. 
>
> Can anyone point me in the right direction for how to approach this? I'm 
> assuming I would do this with Apache but I'm open to other methods as well. 
>
> Any help is appreciated.
>
> Regards,
>
> Karl
>

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

[Puppet Users] config.ru location changed in puppet 3.4

[Felipe Salum]

Hi guys.

Wondering if there was a reason to change the location for the config.ru 
between the puppet 3.3.x and 3.4.x  ?

3.3.x: /usr/share/puppet/ext/rack/files/config.ru
3.4.x: /usr/share/puppet/ext/rack/config.ru

It just broke my auto setup of puppetmaster since I run a exec to copy the 
file to the appropriate location.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/2aa90593-39fd-4ed3-a333-dc77bccb88d8%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] facter doesn't show ec2 facts on aws vpc

[Felipe Salum]

I searched around about this but couldn't find if puppetlabs is working in 
a fix or not.

facter running in AWS VPC doesn't show ec2 facts:

# facter --version
2.0.1
# facter -p virtual
xenhvm
# facter -p | grep ec2

Returns nothing.

Thanks,
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/2f3b3613-1180-4f74-875b-317ed172194b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: EC2 autoscaling reusing hostnames

[Felipe Salum]

I work around this by using a cloudinit script during the autoscale 
instance launch that gets the instance-id of the instance, rename the 
hostname and update /etc/hosts before running puppet.

On Friday, May 23, 2014 10:54:04 PM UTC-7, Bad Tux wrote:
>
> So I'm using Amazon's amazing EC2 autoscaling service and hey, this is 
> pretty cool. Traffic on the web site constellation goes up, Amazon slowly 
> spawns new instances of our web application to handle the traffic and 
> attaches them to the load balancer for our site. Puppet runs, pulls in the 
> application from the PuppetMaster (which was designated at scaling group 
> creation time), spins it up, load balancer asks it "hey are you there", the 
> application says "yep", and traffic starts getting split out to the new 
> instance. Traffic goes back down, after a while Amazon slowly spins the 
> excess instances back down. 
>
> So I sit there for a few weeks watching traffic yoyo up and down and 
> watching the scaling notifications crawl across my inbox, then suddenly my 
> Nagios alarms go off telling me that the application is offline. WTF? 
> There's instances up there! I attach an elastic IP to the ssh gateway 
> instance and log into a couple of the application instances via ssh and 
> sure enough, no Tomcat is installed or running, nevermind the web app that 
> Tomcat is supposed to be running. Okay, is my puppetmaster offline? Nope, 
> it's online and listening. So I manually run puppet on one of the instances 
> and... "invalid certificate for this hostname".
>
> Wha?
>
> Then I realize: Amazon gave this instance the same IP address and hostname 
> as a prior instance that'd been part of the constellation! Which is 
> inevitable when you're running inside a VPC (Virtual Private Cloud), 
> because you have only a /16 to play with, which must be divided between 
> multiple availability groups and multiple security zones. And the 
> puppetmaster's SSL sez, "nope, no way, I seen you before and you had a 
> different certificate, go away." 
>
> Uhm, okay. So I need to solve this problem so that my new instances can 
> get deployed. Only thing I can think of is to trash the ssl directories on 
> both the puppet master and all of the clients, and then run puppet again. 
> Note that all the instances and puppet are in a "puppet" network security 
> group that was created by CloudFormation, and instances not part of the 
> "puppet" security group cannot connect to the puppet master, so we *know* 
> that we're talking to the puppet master, and the puppet master *knows* 
> we're actual hosts that can talk to it, and besides all of these instances 
> are inside a virtual private cloud that is inaccessible to the wider 
> Internet except via port 8080 between the load balancer and the application 
> instances (again enforced by the security groups mechanism) so there's no 
> way an outsider could talk to the puppet server anyhow, but... puppet 
> insists on validating these SSL certificates before letting the instances 
> talk to it. Even though that's a totally useless exercise given that 
> Amazon's enforcing the ACL's at the virtual network (firewall) layer to 
> prevent anybody unauthorized from getting anywhere near that puppet port or 
> puppet IP address.
>
> Am I missing a configuration option in the manual to somehow disable SSL 
> certificate validation? Does everybody add a cron job to their puppet 
> master to stop the puppetmaster daemon and blow away its SSL directory then 
> restart it at exactly 12:00AM every day, and the same on the instances at 
> exactly 12:02AM every day? Or are we the only people on the planet who 
> actually use Amazon's auto-scaling feature *plus* use Puppet at the same 
> time? Curious penguins are... curious!
>
>
>
>

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

Re: [Puppet Users] Re: EC2 autoscaling reusing hostnames

[Felipe Salum]

I have prod, qa, staging all using autoscaling and my master uses node
regex based on the - hostnames to apply the right
roles modules. I have been using it for a long time and no issue at all to
use the full power of the cloud and autoscale :)



On Tue, May 27, 2014 at 8:34 AM, Jeremy T. Bouse  wrote:

> On 27.05.2014 11:06, Felipe Salum wrote:
>
>> I work around this by using a cloudinit script during the autoscale
>> instance launch that gets the instance-id of the instance, rename the
>> hostname and update /etc/hosts before running puppet.
>>
>>
> Cloud-init helps but there are limitations. I use cloud-init to deploy a
> script that generates the extra attributes file prior to puppet being
> deployed to include the instance id in the CSR and this works if your
> master can then otherwise determine how to configure the host. If the
> master is deterministic on the client cert name (read: hostname) then you
> can override that with cloud-init but it fails to be useful when using the
> full power of the cloud architecture and use auto scaling groups.
>
> --
> 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/m_fffsKR9aM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/puppet-users/85960579c1c0eab21f9068aa33299130%40undergrid.net.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CALNTNeMWR9Tuibd-UYdg5wQ4r_MO4V9%2Bu7pw2kEzhxFP5yj%3D-A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: EC2 autoscaling reusing hostnames

[Felipe Salum]

I use a different approach to clean up certificates and the node on the
puppet dashboard, but it is a ugly hack. I'm writing something in python to
read the autoscaling termination message posted to SNS->SQS and I should
have something up tonight. I will share here and get feedback, I'm planning
to replace my ugly hack by this python script.


On Wed, May 28, 2014 at 3:05 AM, Hugh Cole-Baker  wrote:

> Here is the code that we use to pull Auto Scaling messages off an SQS
> queue and add/remove the respective nodes to autosign.conf and sign or
> clean up their certificates.
>
> https://gist.github.com/sigmaris/bda78c1857034031eb76
>
> It's copied and pasted out of a larger application that handles various
> events from Auto Scaling and applies changes to other systems than Puppet,
> so some parts may be missing, but it should be understandable... It assumes
> that all the instance hostnames will be - instance ID> and the domain appended will be based on the AWS region like
> 'east.internal'. You'd have to change the code in message.py to alter that
> behaviour.
>
> --
> 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/m_fffsKR9aM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/45c97a85-6783-4239-b04d-bf7b378bfa2c%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CALNTNeMGNQaXaa9ofVDH8j27cjSHGh6J_AW%3D%2B7ZQsmJMy%3D4W9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.