[Puppet Users] puppetmaster fails to start
Hi all. i have puppet 2.6.8 + passenger installed on centos 5.6 server for some obscure reason, puppetmaster stopped working - i am not aware of any changes done on that server i have tried starting puppetmaster as a service which also failed. checked gems and same configuration on another server works fine. this is the error and gem list, idea would be much appreciated! *** LOCAL GEMS *** activerecord (2.1.1) activesupport (2.1.1) fastthread (1.0.7) json (1.4.3) mime-types (1.16) passenger (2.2.11) rack (1.1.0) rake (0.8.7) rest-client (1.6.1) sqlite3-ruby (1.2.4) # puppetmasterd --no-daemonize --trace /usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:171:in `fail' /usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:257:in `validate' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:300:in `should=' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:300:in `each' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:300:in `should=' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:337:in `value=' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:416:in `[]=' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1773:in `set_parameters' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1767:in `each' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1767:in `set_parameters' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1749:in `initialize' /usr/lib/ruby/site_ruby/1.8/puppet/resource.rb:285:in `new' /usr/lib/ruby/site_ruby/1.8/puppet/resource.rb:285:in `to_ral' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:553:in `send' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:553:in `to_catalog' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:531:in `each' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:531:in `to_catalog' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:468:in `to_ral' /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:621:in `use' /usr/lib/ruby/1.8/sync.rb:229:in `synchronize' /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:615:in `use' /usr/lib/ruby/site_ruby/1.8/puppet/application/master.rb:139:in `setup' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:420:in `hook' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:411:in `exit_on_fail' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' /usr/sbin/puppetmasterd:4 /usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:171:in `fail' /usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:257:in `validate' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:300:in `should=' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:300:in `each' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:300:in `should=' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:337:in `value=' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:416:in `[]=' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1773:in `set_parameters' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1767:in `each' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1767:in `set_parameters' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1749:in `initialize' /usr/lib/ruby/site_ruby/1.8/puppet/resource.rb:285:in `new' /usr/lib/ruby/site_ruby/1.8/puppet/resource.rb:285:in `to_ral' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:553:in `send' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:553:in `to_catalog' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:531:in `each' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:531:in `to_catalog' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:468:in `to_ral' /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:621:in `use' /usr/lib/ruby/1.8/sync.rb:229:in `synchronize' /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:615:in `use' /usr/lib/ruby/site_ruby/1.8/puppet/application/master.rb:147:in `setup' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:420:in `hook' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:411:in `exit_on_fail' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' /usr/sbin/puppetmasterd:4 /usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:171:in `fail' /usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:257:in `validate' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:300:in `should=' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:300:in `each' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:300:in `should=' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:337:in `value=' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:416:in `[]=' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1773:in `set_parameters' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1767:in `each' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1767:in `set_parameters' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1749:in `initialize' /usr/lib/ruby/site_ruby/1.8/puppet/resource.rb:285:in `new' /usr/lib/ruby/site_ruby/1.8/puppet/resource.rb:285:in `to_ral'
Re: [Puppet Users] Re: Announce: PuppetDB 0.9.0 (first release) is available
On Tue, May 22, 2012 at 11:20 PM, Walter Heck walterh...@gmail.com wrote: On Tue, May 22, 2012 at 12:02 AM, Marc Zampetti marc.zampe...@gmail.com wrote: Is Puppet Labs saying they are ending support of MySQL and instead will only support PostgreSQL? That is going to be a big problems for shops that do not support PostgresSQL, or are only allowed to run DB systems on an approved list. Why wouldn't a DB-agnostic model be used? Right now, I can say that due to these types of issues, I cannot even evaluate PuppetDB, and will not be able to for the foreseeable future. (cc'd the mysql list as I'm pretty sure the boys over there have some interest in this) As a provider of puppet consulting I can say it will be a harder sell to clients if we need them to use postgres instead of MySQL in order to use PuppetDB. It's not impossible of course, but introducing an additional barrier for puppet will give us additional trouble convincing our clients :) I sympathize, and that's why this is an optional component; it's not required in any way for Puppet to function. ActiveRecord-based storeconfigs isn't going away any time soon (and certainly not without more dialogue with the community); it remains an entirely supported option. For customers who feel the improved scalability and performance aren't worth the opportunity cost, they can continue to use the existing storeconfigs backend to which they're accustomed. That remains a fully-supported way to deploy Puppet. You mentioned degraded performance, do you have any numbers on what kind of performance degradation we are talking about? I wouldn't mind some degraded performance if that means we can keep smaller clients on MySQL. Also, have you looked at MariaDB 5.5? it is a drop-in replacement for MySQL with much better performance for any query optimiser related things (which I'm pretty sure the nested joins are also part of). While we don't have immediate plans to support MySQL or MariaDB ourselves, I would very much encourage others to create such backends for PuppetDB. Our wire formats are documented and versioned, and the PuppetDB terminus code that handles translation from Puppet's data structures into the wire format is 100% reusable to that end. These layers of abstraction were put into place specifically to enable such interoperability and to prevent alternate backends from becoming second-class citizens of the puppet ecosystem. We'd be happy to assist in these endeavors however we can! deepak -- Walter Heck -- Check out my startup: Puppet training and consulting @ http://www.olindata.com Follow @olindata on Twitter and/or 'Like' our Facebook page at http://www.facebook.com/olindata -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] puppetmaster fails to start
Hi, Common culprits are rack and activerecord. Can't remember the versions to target off the top of my head, but try first downgrading activerecord. Cheers Den On 23/05/2012, at 18:04, Oren Marmor oren.mar...@gmail.com wrote: Hi all. i have puppet 2.6.8 + passenger installed on centos 5.6 server for some obscure reason, puppetmaster stopped working - i am not aware of any changes done on that server i have tried starting puppetmaster as a service which also failed. checked gems and same configuration on another server works fine. this is the error and gem list, idea would be much appreciated! *** LOCAL GEMS *** activerecord (2.1.1) activesupport (2.1.1) fastthread (1.0.7) json (1.4.3) mime-types (1.16) passenger (2.2.11) rack (1.1.0) rake (0.8.7) rest-client (1.6.1) sqlite3-ruby (1.2.4) # puppetmasterd --no-daemonize --trace /usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:171:in `fail' /usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:257:in `validate' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:300:in `should=' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:300:in `each' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:300:in `should=' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:337:in `value=' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:416:in `[]=' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1773:in `set_parameters' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1767:in `each' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1767:in `set_parameters' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1749:in `initialize' /usr/lib/ruby/site_ruby/1.8/puppet/resource.rb:285:in `new' /usr/lib/ruby/site_ruby/1.8/puppet/resource.rb:285:in `to_ral' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:553:in `send' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:553:in `to_catalog' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:531:in `each' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:531:in `to_catalog' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:468:in `to_ral' /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:621:in `use' /usr/lib/ruby/1.8/sync.rb:229:in `synchronize' /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:615:in `use' /usr/lib/ruby/site_ruby/1.8/puppet/application/master.rb:139:in `setup' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:420:in `hook' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:411:in `exit_on_fail' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' /usr/sbin/puppetmasterd:4 /usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:171:in `fail' /usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:257:in `validate' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:300:in `should=' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:300:in `each' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:300:in `should=' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:337:in `value=' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:416:in `[]=' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1773:in `set_parameters' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1767:in `each' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1767:in `set_parameters' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1749:in `initialize' /usr/lib/ruby/site_ruby/1.8/puppet/resource.rb:285:in `new' /usr/lib/ruby/site_ruby/1.8/puppet/resource.rb:285:in `to_ral' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:553:in `send' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:553:in `to_catalog' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:531:in `each' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:531:in `to_catalog' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:468:in `to_ral' /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:621:in `use' /usr/lib/ruby/1.8/sync.rb:229:in `synchronize' /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:615:in `use' /usr/lib/ruby/site_ruby/1.8/puppet/application/master.rb:147:in `setup' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:420:in `hook' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:411:in `exit_on_fail' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' /usr/sbin/puppetmasterd:4 /usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:171:in `fail' /usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:257:in `validate' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:300:in `should=' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:300:in `each' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:300:in `should=' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:337:in `value=' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:416:in `[]=' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1773:in `set_parameters'
[Puppet Users] starting puppetmaster - what's the best way?
Dear all, I've moved away from WEBrick to Apache/passenger on puppetmaster, so not /etc/init.d/ script anymore to start the master. As, (AFAIU) *puppetmasterd*is still required to be running, what's the best why of doing that. I don't think I should expect that apache should start that when *httpd* is [re]started or, should I? I can use /etc/rc.local for that but I was wondering if I'm doing it right. Cheers, San -- 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/-/WeeclOAX6SQJ. 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] starting puppetmaster - what's the best way?
- Original Message - From: Sans r.santanu@gmail.com To: puppet-users@googlegroups.com Sent: Wednesday, May 23, 2012 10:02:46 AM Subject: [Puppet Users] starting puppetmaster - what's the best way? Dear all, I've moved away from WEBrick to Apache/passenger on puppetmaster, so not /etc/init.d/ script anymore to start the master. As, (AFAIU) puppetmasterd is still required to be running, what's the best why of doing that. I don't think I should expect that apache should start that when httpd is [re]started or, should I? I can use /etc/rc.local for that but I was wondering if I'm doing it right. yes, apache manages it under passenger for you. you should not start the puppetmaster by hand in any way then -- 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: puppetmaster fails to start
Hi Dan. i have tested the same configuration on another server and had no problems. also, this configuration worked until couple of days with no changes i can think of.. nevertheless, i would check active record downgrade. thanks, Oren. On May 23, 11:50 am, Denmat tu2bg...@gmail.com wrote: Hi, Common culprits are rack and activerecord. Can't remember the versions to target off the top of my head, but try first downgrading activerecord. Cheers Den On 23/05/2012, at 18:04, Oren Marmor oren.mar...@gmail.com wrote: Hi all. i have puppet 2.6.8 + passenger installed on centos 5.6 server for some obscure reason, puppetmaster stopped working - i am not aware of any changes done on that server i have tried starting puppetmaster as a service which also failed. checked gems and same configuration on another server works fine. this is the error and gem list, idea would be much appreciated! *** LOCAL GEMS *** activerecord (2.1.1) activesupport (2.1.1) fastthread (1.0.7) json (1.4.3) mime-types (1.16) passenger (2.2.11) rack (1.1.0) rake (0.8.7) rest-client (1.6.1) sqlite3-ruby (1.2.4) # puppetmasterd --no-daemonize --trace /usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:171:in `fail' /usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:257:in `validate' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:300:in `should=' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:300:in `each' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:300:in `should=' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:337:in `value=' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:416:in `[]=' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1773:in `set_parameters' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1767:in `each' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1767:in `set_parameters' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1749:in `initialize' /usr/lib/ruby/site_ruby/1.8/puppet/resource.rb:285:in `new' /usr/lib/ruby/site_ruby/1.8/puppet/resource.rb:285:in `to_ral' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:553:in `send' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:553:in `to_catalog' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:531:in `each' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:531:in `to_catalog' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:468:in `to_ral' /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:621:in `use' /usr/lib/ruby/1.8/sync.rb:229:in `synchronize' /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:615:in `use' /usr/lib/ruby/site_ruby/1.8/puppet/application/master.rb:139:in `setup' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:420:in `hook' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:411:in `exit_on_fail' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' /usr/sbin/puppetmasterd:4 /usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:171:in `fail' /usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:257:in `validate' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:300:in `should=' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:300:in `each' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:300:in `should=' /usr/lib/ruby/site_ruby/1.8/puppet/property.rb:337:in `value=' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:416:in `[]=' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1773:in `set_parameters' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1767:in `each' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1767:in `set_parameters' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1749:in `initialize' /usr/lib/ruby/site_ruby/1.8/puppet/resource.rb:285:in `new' /usr/lib/ruby/site_ruby/1.8/puppet/resource.rb:285:in `to_ral' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:553:in `send' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:553:in `to_catalog' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:531:in `each' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:531:in `to_catalog' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:468:in `to_ral' /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:621:in `use' /usr/lib/ruby/1.8/sync.rb:229:in `synchronize' /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:615:in `use' /usr/lib/ruby/site_ruby/1.8/puppet/application/master.rb:147:in `setup' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:420:in `hook' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:411:in `exit_on_fail' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' /usr/sbin/puppetmasterd:4 /usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:171:in `fail' /usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:257:in
[Puppet Users] Assign multipe PublicKeys to multiple System Users
Hi,
I'm trying to assign PublicKeys from a set of users to multiple System
Users like
node example.example.com {
include ssh::auth
ssh::auth::server { [thomas, peter, steve, ]: user =
appuser }
ssh::auth::server { [thomas, peter, ]: user = admin }
}
I got following error:
Could not retrieve catalog from remote server: Error 400 on SERVER:
Duplicate definition: Ssh::Auth::Server[thomas] is already defined in
file /etc/puppet/manifests/nodes.pp
Does anyone knows a workaround for this?
Thanks
Thomas
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Announce: PuppetDB 0.9.0 (first release) is available
On May 22, 7:24 pm, Sean Millichamp s...@bruenor.org wrote:
On Mon, 2012-05-21 at 15:39 -0600, Deepak Giridharagopal wrote:
1) The data stored in PuppetDB is entirely driven by puppetmasters
compiling catalogs for agents. If your entire database exploded and
lost all data, everything will be 100% repopulated within around
$runinterval minutes.
I think that this is a somewhat dangerous line of thinking. Please
correct me if my understanding of storedconfigs are wrong, but if I am
managing a resource with resources { 'type': purge = true } (or a
purged directory populated file resources) and any subset of those
resources are exported resources then, if my entire database exploded,
would I not have Puppet purging resources that haven't repopulated
during this repopulation time? They would obviously be replaced, but if
those were critical resources (think exported Nagios configs, /etc/hosts
entries, or the like) then this could be a really big problem.
That understanding of storeconfigs looks right, but I think the
criticism is misplaced. It is not Deepak's line of thinking that is
dangerous, but rather the posited strategy of purging (un)collected
resources. Indeed, I rate resource purging as a bit dangerous *any*
way you do it. Moreover, the consequences of a storeconfig DB blowing
up are roughly the same regardless of the DBMS managing it or the
middleware between it an the Puppetmaster. I don't see how the
existence of that scenario makes PuppetDB any better or worse.
To me storedconfigs are one of the killer features in Puppet. We are
using them for a handful of critical things and I plan to only expand
their use. I'm glad that Puppet Labs is focusing some attention on them,
but this attitude of we can wait out a repopulation has me worried.
If you cannot afford to wait out a repopulation of some resource, then
you probably should not risk purging its resource type. If you do not
purge, then a storeconfig implosion just leaves your resources
unmanaged. If you choose to purge anyway then you need to understand
that you thereby assume some risk in exchange for convenience;
mitigating that risk probably requires additional effort elsewhere
(e.g. DB replication and failover, backup data center, ...).
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Digest for puppet-users@googlegroups.com - 17 Messages in 10 Topics
-- 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] could not retrieve information from environment
Greetings. I am trying to set up a test puppet server in my environment to evaluate windows clients. On the server side, I am using puppet 2.7.14 (from the repos). I'm using the 2.7.14 windows 64 bit on the client (windows 2008 R2). I have another puppetmaster already using puppet hostname in DNS (running a very old version of puppet - can't upgrade yet for various reasons), so on the client side I am specifying the myserver01.example.com as part of the install. I am getting the following errors on my windows client: err: /File[C:/ProgramData/PuppetLabs/puppet/var/lib]: Could not evaluate: Could not retrieve information from environment production source(s) puppet://myserver01.example.com/plugins err: /Stage[main]//File[C:/myfiles/engine/engine.exe]: Failed to generate additional resources using 'eval_generate: Server hostname 'myserver01' did not match serv er certificate; expected one of myserver01.example.com, DNS:myserver01.example.com, DNS: puppet, DNS:puppet.example.com Any help would be greatly appreciated. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] could not retrieve information from environment
On Wed, May 23, 2012 at 9:14 AM, Matt F mfan2...@gmail.com wrote: Greetings. I am trying to set up a test puppet server in my environment to evaluate windows clients. On the server side, I am using puppet 2.7.14 (from the repos). I'm using the 2.7.14 windows 64 bit on the client (windows 2008 R2). I have another puppetmaster already using puppet hostname in DNS (running a very old version of puppet - can't upgrade yet for various reasons), so on the client side I am specifying the myserver01.example.com as part of the install. I am getting the following errors on my windows client: err: /File[C:/ProgramData/PuppetLabs/puppet/var/lib]: Could not evaluate: Could not retrieve information from environment production source(s) puppet://myserver01.example.com/plugins err: /Stage[main]//File[C:/myfiles/engine/engine.exe]: Failed to generate additional resources using 'eval_generate: Server hostname 'myserver01' did not match serv er certificate; expected one of myserver01.example.com, DNS:myserver01.example.com, DNS: puppet, DNS:puppet.example.com Looking at this it appears there is a mis match between the server's name and the name the agent is using to contact the server. Could you run puppet agent with --trace and paste the output? Also, could you run this command on the master: puppet master --configprint certname And on the agent: puppet agent --configprint server And paste the output. This information will help us diagnose the problem. Thanks, -Jeff -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: could not retrieve information from environment
Sure: puppet master --configprint certname myserver01.example.com C:\Windows\system32puppet agent --trace C:/Program Files (x86)/Puppet Labs/Puppet/sys/ruby/lib/ruby/1.8/net/ http.rb:560:in `initialize' C:/Program Files (x86)/Puppet Labs/Puppet/sys/ruby/lib/ruby/1.8/net/ http.rb:560:in `open' C:/Program Files (x86)/Puppet Labs/Puppet/sys/ruby/lib/ruby/1.8/net/ http.rb:560:in `connect' C:/Program Files (x86)/Puppet Labs/Puppet/sys/ruby/lib/ruby/1.8/ timeout.rb:67:in `timeout' C:/Program Files (x86)/Puppet Labs/Puppet/sys/ruby/lib/ruby/1.8/ timeout.rb:101:in `timeout' C:/Program Files (x86)/Puppet Labs/Puppet/sys/ruby/lib/ruby/1.8/net/ http.rb:560:in `connect' C:/Program Files (x86)/Puppet Labs/Puppet/sys/ruby/lib/ruby/1.8/net/ http.rb:553:in `do_start' C:/Program Files (x86)/Puppet Labs/Puppet/sys/ruby/lib/ruby/1.8/net/ http.rb:542:in `start' C:/Program Files (x86)/Puppet Labs/Puppet/sys/ruby/lib/ruby/1.8/net/ http.rb:1035:in `request' C:/Program Files (x86)/Puppet Labs/Puppet/sys/ruby/lib/ruby/1.8/net/ http.rb:772:in `get' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/indirector/ rest.rb:94:in `send' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/indirector/ rest.rb:94:in `http_request' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/indirector/ rest.rb:76:in `http_get' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/indirector/ rest.rb:139:in `search' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/indirector/ indirection.rb:256:in `search' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/type/ file.rb:621:in `perform_recursion' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/type/ file.rb:588:in `recurse_remote' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/type/ file.rb:587:in `collect' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/type/ file.rb:587:in `recurse_remote' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/type/ file.rb:517:in `recurse' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/type/ file.rb:407:in `eval_generate' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/ transaction.rb:152:in `eval_generate' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/ transaction.rb:384:in `traverse' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/ transaction.rb:99:in `evaluate' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/resource/ catalog.rb:141:in `apply' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/configurer/ downloader.rb:32:in `evaluate' C:/Program Files (x86)/Puppet Labs/Puppet/sys/ruby/lib/ruby/1.8/ timeout.rb:67:in `timeout' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/configurer/ downloader.rb:31:in `evaluate' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/configurer/ plugin_handler.rb:19:in `download_plugins' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/ configurer.rb:77:in `prepare' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/ configurer.rb:138:in `run' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb: 43:in `run' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent/ locker.rb:21:in `lock' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb: 43:in `run' C:/Program Files (x86)/Puppet Labs/Puppet/sys/ruby/lib/ruby/1.8/ sync.rb:230:in `synchronize' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb: 43:in `run' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb: 95:in `with_client' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb: 41:in `run' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/ application.rb:172:in `call' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/ application.rb:172:in `controlled_run' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb: 39:in `run' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/daemon.rb: 187:in `run_event_loop' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/daemon.rb: 149:in `loop' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/daemon.rb: 149:in `run_event_loop' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/daemon.rb: 127:in `start' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/ application/agent.rb:357:in `main' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/ application/agent.rb:312:in `run_command' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/ application.rb:309:in `run' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/ application.rb:416:in `hook' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/ application.rb:309:in `run' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/ application.rb:407:in `exit_on_fail' C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/ application.rb:309:in `run' C:/Program Files
Re: [Puppet Users] Re: could not retrieve information from environment
On Wed, May 23, 2012 at 9:56 AM, Matt F mfan2...@gmail.com wrote: Sure: puppet master --configprint certname myserver01.example.com C:\Windows\system32puppet agent --trace How about puppet agent --configprint server ? And sorry for being unclear, could you instead please try puppet agent --test --trace --debug ? I think we lost the error messages themselves and instead only got the stack traces. Also, if you're able could you paste it in a non-line-wrapping manner? Maybe gist.github.com? -Jeff -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: could not retrieve information from environment
Thanks Jeff. Sorry, my security people block github... C:\Windows\system32puppet agent --configprint server myserver01.example.com C:\Windows\system32puppet agent --test --trace --debug debug: Failed to load library 'syslog' for feature 'syslog' debug: Failed to load library 'selinux' for feature 'selinux' debug: Puppet::Type::File::ProviderPosix: feature posix is missing debug: Failed to load library 'ldap' for feature 'ldap' debug: Failed to load library 'shadow' for feature 'libshadow' debug: /File[C:/ProgramData/PuppetLabs/puppet/var/state/graphs]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var/state] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/client_data]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/state/classes.txt]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var/state] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/certs]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc/ssl] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/state/ last_run_report.yaml]: Autorequiring File[C:/ProgramData/PuppetLabs/ puppet/var/state] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/public_keys]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc/ssl] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/state/state.yaml]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var/state] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/certs/ devsttst01.pem]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/ etc/ssl/certs] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/private_keys/ devsttst01.pem]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/ etc/ssl/private_keys] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/run]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/log]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/state/ resources.txt]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/ var/state] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/client_yaml]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/certs/ca.pem]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/certs] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/ certificate_requests]: Autorequiring File[C:/ProgramData/PuppetLabs/ puppet/etc/ssl] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/lib]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/clientbucket]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/state/ last_run_summary.yaml]: Autorequiring File[C:/ProgramData/PuppetLabs/ puppet/var/state] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/private]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc/ssl] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/state]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/private_keys]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc/ssl] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/public_keys/ devsttst01.pem]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/ etc/ssl/public_keys] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/crl.pem]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc/ssl] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/puppet.conf]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/facts]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var] debug: Finishing transaction 130254168 debug: /File[C:/ProgramData/PuppetLabs/puppet/var/lib]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/certs/ca.pem]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/certs] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/log]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/ certificate_requests]: Autorequiring File[C:/ProgramData/PuppetLabs/ puppet/etc/ssl] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/run]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/crl.pem]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc/ssl] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/private_keys]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc/ssl] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/private_keys/ devsttst01.pem]: Autorequiring
Re: [Puppet Users] Re: could not retrieve information from environment
On Wed, May 23, 2012 at 11:04 AM, Matt F mfan2...@gmail.com wrote: Thanks Jeff. Sorry, my security people block github... C:\Windows\system32puppet agent --configprint server myserver01.example.com Good, this matches up with the certname configured on the puppet master. err: /File[C:/ProgramData/PuppetLabs/puppet/var/lib]: Failed to generate additional resources using 'eval_generate: No connection could be made because the target machine actively refused it. - connect(2) This looks like a different problem than the original post. Is the puppet master actually running, and if so are any firewalls actively blocking the connection? -Jeff -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Announcing Windows registry module initial release
On Wed, May 16, 2012 at 4:53 PM, Josh Cooper j...@puppetlabs.com wrote: Hello, We're pleased to announce the first release of the Windows registry module, version 0.1.0. The 0.1.0 release contained a bug that prevented default values from being managed correctly. We've just released 0.1.1 to the forge which corrects this problem. http://forge.puppetlabs.com/puppetlabs/registry Please let us know if you try out the module and have ideas for how it can be improved. -Jeff -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: could not retrieve information from environment
Yeah, looks like the puppetmasterd stopped at some point. There is no firewall. Here's the new client outout. Per the errors below, I just verified that the times are in sync between the client and the server. C:\Windows\system32puppet agent --test --trace --debug debug: Failed to load library 'syslog' for feature 'syslog' debug: Failed to load library 'selinux' for feature 'selinux' debug: Puppet::Type::File::ProviderPosix: feature posix is missing debug: Failed to load library 'ldap' for feature 'ldap' debug: Failed to load library 'shadow' for feature 'libshadow' debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/public_keys]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc/ssl] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/facts]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/state/last_run_summary.yaml]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var/state] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/state/graphs]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var/state] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/state]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/client_data]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/private_keys]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc/ssl] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/public_keys/devsttst01.pem]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/public_keys] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/log]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/certs/devsttst01.pem]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/certs] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/clientbucket]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/state/state.yaml]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var/state] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/client_yaml]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/run]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/state/resources.txt]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var/state] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/crl.pem]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc/ssl] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/puppet.conf]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/certs]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc/ssl] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/state/last_run_report.yaml]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var/state] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/certs/ca.pem]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/certs] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/private]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc/ssl] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/lib]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/private_keys/devsttst01.pem]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/private_keys] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/certificate_requests]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc/ssl] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/state/classes.txt]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var/state] debug: Finishing transaction 130022952 debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/private_keys]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc/ssl] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/lib]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/certs/devsttst01.pem]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/certs] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/certificate_requests]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc/ssl] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/run]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var] debug: /File[C:/ProgramData/PuppetLabs/puppet/var/facts]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/var] debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/public_keys]: Autorequiring File[C:/ProgramData/PuppetLabs/puppet/etc/ssl]
Re: [Puppet Users] Announcing Windows registry module initial release
On Wed, May 16, 2012 at 7:53 PM, Josh Cooper j...@puppetlabs.com wrote:
Hello,
We're pleased to announce the first release of the Windows registry
module, version 0.1.0.
This release provides the ability to manage registry keys and values
on Windows 2003, 2003R2, 7, 2008, and 2008R2 systems. It supports the
most commonly used registry value types (REG_SZ, REG_MULTI_SZ,
REG_EXPAND_SZ, REG_DWORD, REG_QWORD, REG_BINARY), as well as purging
unmanaged registry values from a specified key. The module can manage
redirected registry keys and values when running on a 64-bit version
of Windows.
For example:
registry_key { 'HKLM\System\CurrentControlSet\Services\Puppet':
ensure = present,
}
registry_value {
'HKLM\System\CurrentControlSet\Services\Puppet\Description':
ensure = present,
type = string,
data = The Puppet Agent service periodically manages your
configuration,
}
The best way to install this module is with the puppet module subcommand
or the puppet-module Gem.
puppet module install puppetlabs-registry
More information about the module is available here:
http://forge.puppetlabs.com/puppetlabs/registry
Josh
--
Josh Cooper
Developer, Puppet Labs
You guys are on it, and double kudos for kicking ass on Windows.
--
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.
--
Kelsey Hightower
Developer
Puppet Labs
(678) 4719501
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: could not retrieve information from environment
On Wed, May 23, 2012 at 12:30 PM, Matt F mfan2...@gmail.com wrote: Yeah, looks like the puppetmasterd stopped at some point. There is no firewall. Here's the new client outout. Per the errors below, I just verified that the times are in sync between the client and the server. I'm not exactly sure what the root cause of the problem, but each post has contained slightly different errors. I recommend deleting the agent SSL directory and cleaning the certificate on the master at this point. So, remove C:/ProgramData/PuppetLabs/puppet/etc/ssl/ on the agent And run puppet cert clean devsttst01 on the master. Then re-run the agent and re-sign the certificate on the master. This should get you going. Were you switching between multiple puppet masters at some point? -Jeff -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: could not retrieve information from environment
I deleted regenerated the cert. Now I'm getting the errors below. I have never switched puppetmaster servers, but I do have another puppetmaster server that has the dns alias 'puppet'. However, the client should not be accessing that server. Running Puppet agent on demand ... info: Retrieving plugin info: Caching certificate_revocation_list for ca err: /File[C:/ProgramData/PuppetLabs/puppet/var/lib]: Could not evaluate: Could not retrieve information from environment production source(s) puppet://myserver01.example.com/plugins info: Caching catalog for devsttst01 info: Applying configuration version '1337805313' err: /Stage[main]//File[C:/myfiles/engine/engine.exe]: Failed to generate additional resources using 'eval_generate: Server hostname 'myserver01' did not match server certificate; expected one of myserver01.example.com, DNS:myserver01.example.com, DNS:puppet, DNS:puppet.example.com err: /Stage[main]//File[C:/myfiles/engine/engine.exe]: Could not evaluate: Server hostname 'myserver01' did not match server certificate; expected one of myserver01.example.com, DNS:myserver01.example.com, DNS:puppet, DNS:puppet.example.com Could not retrieve file metadata for puppet://myserver01/files/engine/engine.exe: Server hostname 'myserver01' did not match server certificate; expected one of myserver01.example.com, DNS:myserver01.example.com, DNS:puppet, DNS:puppet.example.com at /etc/puppet/manifests/site.pp:8 notice: Finished catalog run in 0.28 seconds -- 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/-/YpNoTmvmY0MJ. 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] Installing Jenkins with Puppet fails to import GPG key
Well dug Dan :) On 24/05/2012, at 3:27, Dan Carley dan.car...@gmail.com wrote: On 27 April 2012 06:15, denmat tu2bg...@gmail.com wrote: Normally what happens is that if it is 'assumed yes', yum will automatically accept the public key via the url - I don't know why Jenkins is different - but it appears to install a new repo file and try to import the pubkey again on install - maybe this confuses yum? Just speculating - not going to investigate further :) The problem stems from Yum on EL5 not being able to parse user attributes within key. It can be worked around a bit more cleanly by removing the attribute from the public key. I've written a blog post with more details: http://dan.carley.co/blog/2012/05/22/yum-gpg-keys-for-jenkins/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: could not retrieve information from environment
Hi Matt, On Wed, May 23, 2012 at 1:46 PM, Matt F mfan2...@gmail.com wrote: I deleted regenerated the cert. Now I'm getting the errors below. I have never switched puppetmaster servers, but I do have another puppetmaster server that has the dns alias 'puppet'. However, the client should not be accessing that server. Running Puppet agent on demand ... This tells me you're running puppet through the desktop shortcut. info: Retrieving plugin info: Caching certificate_revocation_list for ca err: /File[C:/ProgramData/PuppetLabs/puppet/var/lib]: Could not evaluate: Could not retrieve information from environment production source(s) puppet://myserver01.example.com/plugins info: Caching catalog for devsttst01 info: Applying configuration version '1337805313' err: /Stage[main]//File[C:/myfiles/engine/engine.exe]: Failed to generate additional resources using 'eval_generate: Server hostname 'myserver01' did not match server certificate; expected one of myserver01.example.com, DNS:myserver01.example.com, DNS:puppet, DNS:puppet.example.com err: /Stage[main]//File[C:/myfiles/engine/engine.exe]: Could not evaluate: Server hostname 'myserver01' did not match server certificate; expected one of myserver01.example.com, DNS:myserver01.example.com, DNS:puppet, DNS:puppet.example.com Could not retrieve file metadata for puppet://myserver01/files/engine/engine.exe: Server hostname 'myserver01' did not match server certificate; expected one of myserver01.example.com, DNS:myserver01.example.com, DNS:puppet, DNS:puppet.example.com at /etc/puppet/manifests/site.pp:8 notice: Finished catalog run in 0.28 seconds Can you stop the puppet agent, e.g. net stop puppet, delete the ssl certificates as Jeff described, perform the steps described in the 'Start Command Prompt with Puppet'[1], and run 'puppet agent --test --debug' Thank you, Josh [1] http://docs.puppetlabs.com/windows/running.html -- Josh Cooper Developer, Puppet Labs -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Announce: PuppetDB 0.9.0 (first release) is available
On Wed, 2012-05-23 at 06:24 -0700, jcbollinger wrote: That understanding of storeconfigs looks right, but I think the criticism is misplaced. It is not Deepak's line of thinking that is dangerous, but rather the posited strategy of purging (un)collected resources. Indeed, I rate resource purging as a bit dangerous *any* way you do it. Moreover, the consequences of a storeconfig DB blowing up are roughly the same regardless of the DBMS managing it or the middleware between it an the Puppetmaster. I don't see how the existence of that scenario makes PuppetDB any better or worse. Indeed, it *is* dangerous, but so are many things we do as system administrators. The key is in gauging the risk and then choosing the right path accordingly. In my environment I am not always able to know the complete history of resources as changes may come from unexpected places. It is less than ideal, but it is one aspect of my reality. In that situation, the selective use of purging becomes quite key in keeping things that need to be cleaned up cleaned up. I don't put anything in exported resources with purging that would be capable of bringing down a production application, thankfully, but there is quite a bit that could quite possibly cause a variety of headaches, alerts, and tickets on a massive scale for a while during the reconvergence. In additioanl, we are in a transition to PE and the Compliance tool will allow me another way of handling that in a more manual admin-review approach (to catch resources that get added outside of Puppet's knowledge). What I really need is some tool by which I can mark exported resources as absent instead of purging them from the database when they are no longer needed (such as deleting a host). That would eliminate most, if not all, of the intersections of purging and exported resources that I have. Right now I use a Ruby script I found quite a while back to delete removed nodes and all of their data. I'm sure there is a way to mark the resources as ensure = absent instead, but I've not gone digging into the DB structure. If you cannot afford to wait out a repopulation of some resource, then you probably should not risk purging its resource type. If you do not purge, then a storeconfig implosion just leaves your resources unmanaged. If you choose to purge anyway then you need to understand that you thereby assume some risk in exchange for convenience; mitigating that risk probably requires additional effort elsewhere (e.g. DB replication and failover, backup data center, ...). Indeed, as I said above, it is about risk management. Deepak's statement I had responded to wasn't the first time I had read the oh, just wait for it to repopulate statement and I wanted to be certain that wasn't actually something that was considered in the design with regards to updates, etc. on the stability of the storeconfigs data. At some point you have to trust tools that have earned that trust (either via testing or real world use or both) to do the job that they say they are going to do. Puppet has years of earning that trust with me. Could something corrupt and destroy the database and cause me a lot of trouble? Sure, but that could be said of many tools. That's why we have backups, DR systems, etc. even though the in the now when it fails can be painful as heck. However, as long as Puppet Labs is designing it to be dependable and upgrade-safe (which it sounds like they are) then I'll continue to trust it (with prudent testing, of course) because they've earned it. Sean -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Announce: PuppetDB 0.9.0 (first release) is available
On Wed, May 23, 2012 at 7:30 PM, Sean Millichamp s...@bruenor.org wrote: On Wed, 2012-05-23 at 06:24 -0700, jcbollinger wrote: That understanding of storeconfigs looks right, but I think the criticism is misplaced. It is not Deepak's line of thinking that is dangerous, but rather the posited strategy of purging (un)collected resources. Indeed, I rate resource purging as a bit dangerous *any* way you do it. Moreover, the consequences of a storeconfig DB blowing up are roughly the same regardless of the DBMS managing it or the middleware between it an the Puppetmaster. I don't see how the existence of that scenario makes PuppetDB any better or worse. Indeed, it *is* dangerous, but so are many things we do as system administrators. The key is in gauging the risk and then choosing the right path accordingly. In my environment I am not always able to know the complete history of resources as changes may come from unexpected places. It is less than ideal, but it is one aspect of my reality. In that situation, the selective use of purging becomes quite key in keeping things that need to be cleaned up cleaned up. I don't put anything in exported resources with purging that would be capable of bringing down a production application, thankfully, but there is quite a bit that could quite possibly cause a variety of headaches, alerts, and tickets on a massive scale for a while during the reconvergence. In additioanl, we are in a transition to PE and the Compliance tool will allow me another way of handling that in a more manual admin-review approach (to catch resources that get added outside of Puppet's knowledge). What I really need is some tool by which I can mark exported resources as absent instead of purging them from the database when they are no longer needed (such as deleting a host). That would eliminate most, if not all, of the intersections of purging and exported resources that I have. Right now I use a Ruby script I found quite a while back to delete removed nodes and all of their data. I'm sure there is a way to mark the resources as ensure = absent instead, but I've not gone digging into the DB structure. We don't yet have such a tool for PuppetDB, but it's definitely on our radar. The current `puppet node clean --unexport` reaches directly into the ActiveRecord storeconfigs database to make ad hoc changes to resources, which is inappropriate for PuppetDB, which has a strict catalog lifecycle. We're working to figure out an appropriate way to provide the same functionality. If you cannot afford to wait out a repopulation of some resource, then you probably should not risk purging its resource type. If you do not purge, then a storeconfig implosion just leaves your resources unmanaged. If you choose to purge anyway then you need to understand that you thereby assume some risk in exchange for convenience; mitigating that risk probably requires additional effort elsewhere (e.g. DB replication and failover, backup data center, ...). Indeed, as I said above, it is about risk management. Deepak's statement I had responded to wasn't the first time I had read the oh, just wait for it to repopulate statement and I wanted to be certain that wasn't actually something that was considered in the design with regards to updates, etc. on the stability of the storeconfigs data. We definitely didn't take safe repopulation as a given. We know many if not most storeconfigs users will likely suffer at least some inconvenience or at worst some outages if their data has to be repopulated; we're not blasé about the issue. We haven't cut any corners in PuppetDB around safeguarding your data. It's simply a design ideal we would like to promote. When it's reasonable to design your exports/collects thusly, it's beneficial for storeconfigs data to be easily regenerable. After all, that's what Puppet purports to allow you to do with your infrastructure, and it would be great not to allow storeconfigs to disrupt that ability. And on that note, where you find a case that this just isn't possible today, let us know. I'd love for this to be the norm. Mostly the reason for mentioning it is because many people hear database and automatically think oh great now I have to set up replication, backups, failover, etc. But before going off and doing all that work, it's important to ensure this really is data you care about replicating, backing up, making highly available, etc. Depending on your needs (for instance, if you're not a storeconfigs user at all), the answer *may* be no. At some point you have to trust tools that have earned that trust (either via testing or real world use or both) to do the job that they say they are going to do. Puppet has years of earning that trust with me. Could something corrupt and destroy the database and cause me a lot of trouble? Sure, but that could be said of many tools. That's why we have backups, DR systems, etc. even though the
Re: [Puppet Users] Announcing Razor
On 05/23/2012 05:10 PM, James Turnbull wrote: Puppet Labs is really thrilled to announce, in conjunction with EMC, our new open source bare metal provisioning tool: Razor. Razor is next generation provisioning software that handles bare metal hardware and virtual server provisioning with inventory discovery and tagging, rule-based policy management, and extensible broker plugin integration. It integrates closely with Puppet and Facter. The full announcement and a module to install it is on the Puppet Labs blog: http://puppetlabs.com/blog/puppet-razor-module/ This excellent post from Nick Weaver, the EMC guy behind the original idea, takes you through the history, background and workflow of Razor: http://nickapedia.com/2012/05/21/lex-parsimoniae-cloud-provisioning-with-a-razor/ And finally - being open source - you can find the code at: https://github.com/puppetlabs/Razor Regards James Turnbull I take it the actual microkernel isn't open source? All I can find is a ISO image. -- Russell A. Jackson r...@csub.edu Network Analyst California State University, Bakersfield -- 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.
