Re: [Puppet Users] Re: EC2 autoscaling reusing hostnames
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 h...@fanduel.com 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 AS group name-hex digits from 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.comhttps://groups.google.com/d/msgid/puppet-users/45c97a85-6783-4239-b04d-bf7b378bfa2c%40googlegroups.com?utm_medium=emailutm_source=footer . 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.
[Puppet Users] Re: EC2 autoscaling reusing hostnames
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
I have prod, qa, staging all using autoscaling and my master uses node regex based on the hostgroup-instance-id 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 jeremy.bo...@undergrid.net 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.
[Puppet Users] facter doesn't show ec2 facts on aws vpc
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] config.ru location changed in puppet 3.4
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] Re: Help with configuring Puppet Proxies using Apache
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.
Re: [Puppet Users] Pulling my hair out with CA proxying
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 fatm...@gmail.comjavascript: 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 javascript:. To post to this group, send email to puppet...@googlegroups.comjavascript:. 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] puppet dashboard failed tasks every night
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
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 pmb...@gmail.com wrote: Do you have any daily cron jobs that occur overnight? -- Peter On Aug 27, 2013, at 1:08 PM, Felipe Salum fsa...@gmail.com 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.
[Puppet Users] Problem running rake node:del for Puppet Dashboard databse hosted on RDS
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
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
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 ramin-l...@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/unsubscribehttps://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.compuppet-users%2bunsubscr...@googlegroups.com . To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/**group/puppet-usershttp://groups.google.com/group/puppet-users . For more options, visit https://groups.google.com/**groups/opt_outhttps://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
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 ramin-l...@badapple.net 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 ramin-l...@badapple.net mailto:ramin-list@badapple.**net ramin-l...@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/unsubscribehttps://groups.google.com/d/__topic/puppet-users/7-__sjp1Ef1p0/unsubscribe https://groups.google.com/d/**topic/puppet-users/7-** sjp1Ef1p0/unsubscribehttps://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.comhttp://googlegroups.com mailto:puppet-users%**2bunsubscr...@googlegroups.compuppet-users%252bunsubscr...@googlegroups.com **. To post to this group, send email to puppet-users@googlegroups.com mailto:puppet-users@**googlegroups.compuppet-users@googlegroups.com . Visit this group at http://groups.google.com/__**group/puppet-usershttp://groups.google.com/__group/puppet-users http://groups.google.com/**group/puppet-usershttp://groups.google.com/group/puppet-users . For more options, visit https://groups.google.com/__**groups/opt_outhttps://groups.google.com/__groups/opt_out https://groups.google.com/**groups/opt_outhttps://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+unsubscribe@**googlegroups.compuppet-users%2bunsubscr...@googlegroups.com . To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/**group/puppet-usershttp://groups.google.com/group/puppet-users . For more options, visit https://groups.google.com/**groups/opt_outhttps://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/7-**sjp1Ef1p0/unsubscribehttps://groups.google.com/d/topic/puppet-users/7-sjp1Ef1p0/unsubscribe . To unsubscribe from this group
Re: [Puppet Users] Re: puppet cert error
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 binary...@gmail.com 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] puppetlabs-dashboard module failing on puppet 3.2.1
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 % VirtualHost *:%= @dashboard_port % ServerName %= @name % DocumentRoot %= @docroot % RailsBaseURI %= @rails_base_uri % Directory %= @docroot % 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: High Availability of Puppet server for separate geographical location
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 opsma...@gmail.com 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 erik.gustav.da...@gmail.com wrote: On 10 May 2013 19:52, Ramin K ramin-l...@badapple.net 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.
Re: [Puppet Users] Re: High Availability of Puppet server for separate geographical location
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 ramin-l...@badapple.net wrote: On 5/9/2013 1:51 PM, Martin Langhoff wrote: On Thu, May 9, 2013 at 2:31 PM, Ramin K ramin-l...@badapple.net 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/7ZpAMrMb2NQhttps://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=enhttps://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.compuppet-users%2bunsubscr...@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=enhttp://groups.google.com/group/puppet-users?hl=en . For more options, visit https://groups.google.com/**groups/opt_outhttps://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] Re: High Availability of Puppet server for separate geographical location
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 john.bollin...@stjude.org To: puppet...@googlegroups.com javascript: 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 javascript:. To post to this group, send email to puppet...@googlegroups.comjavascript:. 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] Re: High Availability of Puppet server for separate geographical location
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 fsa...@gmail.com javascript: 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.
[Puppet Users] puppet cert error
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.
[Puppet Users] Re: how do you test and release puppet changes?
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] Re: Design pattern for exported resources from EC2 autoscaled instances
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: Announce: Module puppetalbs/puppetdb 1.2.1 Available
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.
Re: [Puppet Users] PuppetDB api - deactivate command
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 k...@puppetlabs.comjavascript: 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 a.gr...@gmail.comjavascript: 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 javascript:. To post to this group, send email to puppet...@googlegroups.comjavascript:. 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
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 fsa...@gmail.comjavascript: 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/5254512https://gist.github.com/kbarber/5254512 On Wed, Mar 27, 2013 at 2:19 PM, Ken Barber k...@puppetlabs.com wrote: Try: curl -vv -G -H Accept: application/json 'http://localhost:8080/v2/**commandshttp://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 a.gr...@gmail.com 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-1http://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=enhttp://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/**groups/opt_outhttps://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 javascript:. To post to this group, send email to puppet...@googlegroups.comjavascript: . 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] puppet module satisfy dependencies issue
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 r...@puppetlabs.com wrote: Hi Felipe, Comment in-line. On Mon, Mar 25, 2013 at 4:06 PM, Felipe Salum fsa...@gmail.com 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.
[Puppet Users] Re: Puppet in EC2
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 instance_id-puppetclass- environment - http://bit.ly/YitdC3 -Use http://bit.ly/YitdC3-Use the instance security group as reference - http://bit.ly/YitdC3 -Use http://bit.ly/YitdC3-Use the user-data, populate with JSON and parse on the puppet master side - http://bit.ly/13MsfGe -Use 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] AWS OpsWorks announcement using Chef
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.
Re: [Puppet Users] Puppet dashboard stuck pending jobs
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 jrh...@netconsonance.comjavascript: 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 javascript:. To post to this group, send email to puppet...@googlegroups.comjavascript: . 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 javascript:. To post to this group, send email to puppet...@googlegroups.comjavascript: . 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: puppet creating AWS EC instances
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.
[Puppet Users] Re: Need a solution for puppet node clean (puppet v3.0.2)
I was searching about these some days ago and I found somewhere that the 'puppet node deactivate nodename' 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 '%hostname%' delete from resource_params where value like '%hostname%' 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
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: Reusable Puppet config for Vagrant
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.
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
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 kalyan...@gmail.comwrote: 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.htmlhttp://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: 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
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.
[Puppet Users] Re: hiera values issue
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
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=truechecksum_type=md5links=manageignore=---+%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?
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: puppet DB for inventory
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] Load Balance Puppet 3 masters with PuppetDB backend
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=truechecksum_type=md5links=manageignore=---+%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.
Re: [Puppet Users] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
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.
Re: [Puppet Users] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
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.
[Puppet Users] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
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.puppetlabs.com/guides/file_serving.htmland our config looks fine. Reading through the issue at http://projects.puppetlabs.com/issues/16667, I'm not clear what the fix
Re: [Puppet Users] Puppet Forge: Are my expectations misaligned?
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 on Debian Lenny
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 ?
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-12http://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.
[Puppet Users] Exec resource and environment parameter
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] Puppet 3.0 on Debian Lenny
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.
Re: [Puppet Users] Re: Puppet Dashboard - Directory Index Forbidden
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 VirtualHost *:3000 SetEnv RAILS_ENV production RackBaseURI / ServerName X.X.X.X DocumentRoot /usr/share/puppet-dashboard/public/ Directory /usr/share/puppet-dashboard/public/ Options None Order allow,deny allow from all /Directory /VirtualHost Felipe On Mon, Mar 19, 2012 at 7:52 AM, Antidot SAS antidot...@gmail.com 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 theirpup...@gmail.comwrote: 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 VirtualHost *:3000 ServerName X.X.X ServerAlias X.X.X.X DocumentRoot /usr/share/puppet-dashboard/public/ RailsBaseURI / SetEnv Rails_ENV production PassengerEnabled on Directory /usr/share/puppet-dashboard/public/ Options -MultiViews -Indexes FollowSymLinks Order allow,deny allow from all /Directory #ErrorLog /var/log/apache2/dashboard.example.com_error.log LogLevel warn #CustomLog /var/log/apache2/dashboard.example.com_access.log combined ServerSignature On /VirtualHost -- 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.