[Puppet Users] Re: Puppet Camp
I vote for the week before the Velocity conference, as a lot of people will be in the Bay Area and staying a few extra days is easy for us "out of towners" cheers, /Martin On Apr 27, 9:39 am, Andrew Shafer wrote: > And decent Mexican food... > > Get it all arranged and tell me the dates... ;) > > On Sun, Apr 26, 2009 at 4:08 PM, Allan Marcus wrote: > > > I vote for Albuquerque, New Mexico! > > > Cheap flights from the west cost and easier for the east cost folks. > > > Plus, relatively cheap. > > > Plus, I can drive there :-) > > > -Allan --~--~-~--~~~---~--~~ 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: camptocamp puppet-iptables constantly applying changes?
Hi,
> The same set of rules are applied on each run. I used numbers as the
> names to sort the rules accordingly since iptables rules' order does
> matter. Has anyone been using this module/plugin? I havent tried
> using a-z for the names of the rules, and there are no specified
> dependencies of each rule (requires,before,after).
It is an issue I am aware of, is irritating me, and must investigate.
Using a-z names instead of numbers shouldn't solve the problem.
I've only noticed this on hosts with a fair amount of iptable resources
declared. So I believe one or several rules built by puppet don't match
the output of iptables-save. This leads puppet to think something has
changed.
I previously used regular require/before/after dependencies but I
switched to alphabetical ordering because of another "always running"
issue. Unless you declared strictly linear dependencies (first rule
before 2nd rule, 2nd rule before 3rd rule, etc) you depended on
puppet's random ordering of resources. And in this case, a different
ordering might mean something completely different, maybe even the
opposite of what is intended.
This wasn't too much of an issue when all resources were declared in
the same file (for instance inside a node{}). But my idea was to
include different iptable{} resources in different modules, which
weren't all included on each node. And this led to loads of failed
dependencies.
I'll try to have a look at this issue soon.
Thanks for the feedback !
Marc
--~--~-~--~~~---~--~~
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: Assign variable with content of a file?
On May 1, 7:28 pm, James Turnbull wrote: > On the master you can use the generate function to populate a variable > value. That looks promising. However, in this particular situation, I cannot use the regular puppetmasterd/puppetd arrangement. I must use the stand-alone puppet instead. Will this still work? > Otherwise you should use a fact. I hadn't realized that I could create custom facts. --~--~-~--~~~---~--~~ 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: long catalog run times and random connection timeouts
are you using webrick? On Mon, May 4, 2009 at 10:41 PM, Michael Conigliaro < mconigli...@fandotech.com> wrote: > > Hello, > > I've been seeing some strange behavior for the last few days, and I'm > not sure what else to do to troubleshoot it. It started when two of my > puppet clients (always the same two) suddenly began to take forever to > finish their catalog runs. I'm not sure what changed around 5pm last > Thursday to cause this, but well, check out the logs... > > Apr 30 16:50:50 emsdb01 puppetd[11363]: Finished catalog run in 4.59 > seconds Apr 30 17:26:29 emsdb01 puppetd[11363]: Finished catalog run in > 292.65 seconds > > Apr 30 16:43:05 emsweb01 puppetd[1345]: Finished catalog run in 4.47 > seconds Apr 30 17:18:27 emsweb01 puppetd[1345]: Finished catalog run in > 292.53 seconds > > Now when emsdb01 and emsweb01 are checking in, all the other clients > seem to queue up behind them. So I end up seeing... > > Conection timeout calling puppetmaster.getconfig: execution expired > > And... > > Could not retrieve catalog: Connection Timeout > > from all the other clients. For those that don't time out, I see a > flurry of "finished catalog run" as they all complete at the same time > (but with excessive catalog run times, presumably because everyone else > got held up by emsdb01 and emsweb01). > > When I run "puppetd --test --debug" on emsdb01 and emsweb01, I don't see > anything unusual happening. Both servers are basically idle while the > catalog run is happening. What I do see is that they get hung up on > these tasks for some reason: > > debug: Calling puppetmaster.getconfig > debug: Calling fileserver.describe > > When I look at the puppetmaster as this is going on, I don't see > anything unusual in regards to server load there either. At first, I > suspected some kind of network connectivity issue, but I have run > several tcpdumps, and everything seems to be connecting fine. Is there > something else I should be looking at to determine the cause of this > problem? > > -- > Michael Conigliaro > Computer Analyst > Fuss & O'Neill Technologies > www.fandotech.com > > > > > > --~--~-~--~~~---~--~~ 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-dev] ANNOUNCE: 0.25.0beta1 release!
2009/5/4 James Turnbull : > > > This is the beta1 release of Puppet 0.25.0. > > It is available at: > > http://reductivelabs.com/downloads/puppet/puppet-0.25.0beta1.tar.gz Note this naming means that we need gem >= 1.3.2 due to version string for running top level rakefile else you get Malformed version number string error: * Gem::Version now understands prerelease versions using letters. paul-nasrats-macbook:puppet pnasrat$ rake --trace (in /Users/pnasrat/Development/puppet) rake aborted! Malformed version number string 0.25.0beta1 /Library/Ruby/Site/1.8/rubygems/version.rb:53:in `initialize' /Library/Ruby/Site/1.8/rubygems/version.rb:44:in `new' /Library/Ruby/Site/1.8/rubygems/version.rb:44:in `create' /Library/Ruby/Site/1.8/rubygems/specification.rb:1130:in `version=' /Users/pnasrat/Development/puppet/tasks/rake/reductive.rb:495:in `mkgemtask' /Library/Ruby/Site/1.8/rubygems/specification.rb:443:in `initialize' /Users/pnasrat/Development/puppet/tasks/rake/reductive.rb:490:in `new' /Users/pnasrat/Development/puppet/tasks/rake/reductive.rb:490:in `mkgemtask' /Users/pnasrat/Development/puppet/Rakefile:44 --~--~-~--~~~---~--~~ 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: long catalog run times and random connection timeouts
I'm actually not sure. How do I determine that? I just use the redhat rpms from the epel repository, and I don't remember seeing an option for that anywhere. -- Michael Conigliaro Computer Analyst Fuss & O'Neill Technologies www.fandotech.com -Original Message- From: puppet-users@googlegroups.com [mailto:puppet-us...@googlegroups.com] On Behalf Of Ohad Levy Sent: Monday, May 04, 2009 10:48 AM To: puppet-users@googlegroups.com Subject: [Puppet Users] Re: long catalog run times and random connection timeouts are you using webrick? On Mon, May 4, 2009 at 10:41 PM, Michael Conigliaro wrote: Hello, I've been seeing some strange behavior for the last few days, and I'm not sure what else to do to troubleshoot it. It started when two of my puppet clients (always the same two) suddenly began to take forever to finish their catalog runs. I'm not sure what changed around 5pm last Thursday to cause this, but well, check out the logs... Apr 30 16:50:50 emsdb01 puppetd[11363]: Finished catalog run in 4.59 seconds Apr 30 17:26:29 emsdb01 puppetd[11363]: Finished catalog run in 292.65 seconds Apr 30 16:43:05 emsweb01 puppetd[1345]: Finished catalog run in 4.47 seconds Apr 30 17:18:27 emsweb01 puppetd[1345]: Finished catalog run in 292.53 seconds Now when emsdb01 and emsweb01 are checking in, all the other clients seem to queue up behind them. So I end up seeing... Conection timeout calling puppetmaster.getconfig: execution expired And... Could not retrieve catalog: Connection Timeout from all the other clients. For those that don't time out, I see a flurry of "finished catalog run" as they all complete at the same time (but with excessive catalog run times, presumably because everyone else got held up by emsdb01 and emsweb01). When I run "puppetd --test --debug" on emsdb01 and emsweb01, I don't see anything unusual happening. Both servers are basically idle while the catalog run is happening. What I do see is that they get hung up on these tasks for some reason: debug: Calling puppetmaster.getconfig debug: Calling fileserver.describe When I look at the puppetmaster as this is going on, I don't see anything unusual in regards to server load there either. At first, I suspected some kind of network connectivity issue, but I have run several tcpdumps, and everything seems to be connecting fine. Is there something else I should be looking at to determine the cause of this problem? -- Michael Conigliaro Computer Analyst Fuss & O'Neill Technologies www.fandotech.com --~--~-~--~~~---~--~~ 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: long catalog run times and random connection timeouts
what versions of puppet and facter are you using? On Mon, May 4, 2009 at 7:41 AM, Michael Conigliaro wrote: > > Hello, > > I've been seeing some strange behavior for the last few days, and I'm > not sure what else to do to troubleshoot it. It started when two of my > puppet clients (always the same two) suddenly began to take forever to > finish their catalog runs. I'm not sure what changed around 5pm last > Thursday to cause this, but well, check out the logs... > > Apr 30 16:50:50 emsdb01 puppetd[11363]: Finished catalog run in 4.59 > seconds Apr 30 17:26:29 emsdb01 puppetd[11363]: Finished catalog run in > 292.65 seconds > > Apr 30 16:43:05 emsweb01 puppetd[1345]: Finished catalog run in 4.47 > seconds Apr 30 17:18:27 emsweb01 puppetd[1345]: Finished catalog run in > 292.53 seconds > > Now when emsdb01 and emsweb01 are checking in, all the other clients > seem to queue up behind them. So I end up seeing... > > Conection timeout calling puppetmaster.getconfig: execution expired > > And... > > Could not retrieve catalog: Connection Timeout > > from all the other clients. For those that don't time out, I see a > flurry of "finished catalog run" as they all complete at the same time > (but with excessive catalog run times, presumably because everyone else > got held up by emsdb01 and emsweb01). > > When I run "puppetd --test --debug" on emsdb01 and emsweb01, I don't see > anything unusual happening. Both servers are basically idle while the > catalog run is happening. What I do see is that they get hung up on > these tasks for some reason: > > debug: Calling puppetmaster.getconfig > debug: Calling fileserver.describe > > When I look at the puppetmaster as this is going on, I don't see > anything unusual in regards to server load there either. At first, I > suspected some kind of network connectivity issue, but I have run > several tcpdumps, and everything seems to be connecting fine. Is there > something else I should be looking at to determine the cause of this > problem? > > -- > Michael Conigliaro > Computer Analyst > Fuss & O'Neill Technologies > www.fandotech.com > > > > > > -- Nigel Kersten nig...@google.com System Administrator Google, Inc. --~--~-~--~~~---~--~~ 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: long catalog run times and random connection timeouts
[r...@emsdb01 ~]# puppetd --version 0.24.8 [r...@emsdb01 ~]# facter --version 1.5.2 -- Michael Conigliaro Computer Analyst Fuss & O'Neill Technologies www.fandotech.com -Original Message- From: puppet-users@googlegroups.com [mailto:puppet-us...@googlegroups.com] On Behalf Of Nigel Kersten Sent: Monday, May 04, 2009 11:35 AM To: puppet-users@googlegroups.com Subject: [Puppet Users] Re: long catalog run times and random connection timeouts what versions of puppet and facter are you using? On Mon, May 4, 2009 at 7:41 AM, Michael Conigliaro wrote: > > Hello, > > I've been seeing some strange behavior for the last few days, and I'm > not sure what else to do to troubleshoot it. It started when two of my > puppet clients (always the same two) suddenly began to take forever to > finish their catalog runs. I'm not sure what changed around 5pm last > Thursday to cause this, but well, check out the logs... > > Apr 30 16:50:50 emsdb01 puppetd[11363]: Finished catalog run in 4.59 > seconds Apr 30 17:26:29 emsdb01 puppetd[11363]: Finished catalog run in > 292.65 seconds > > Apr 30 16:43:05 emsweb01 puppetd[1345]: Finished catalog run in 4.47 > seconds Apr 30 17:18:27 emsweb01 puppetd[1345]: Finished catalog run in > 292.53 seconds > > Now when emsdb01 and emsweb01 are checking in, all the other clients > seem to queue up behind them. So I end up seeing... > > Conection timeout calling puppetmaster.getconfig: execution expired > > And... > > Could not retrieve catalog: Connection Timeout > > from all the other clients. For those that don't time out, I see a > flurry of "finished catalog run" as they all complete at the same time > (but with excessive catalog run times, presumably because everyone else > got held up by emsdb01 and emsweb01). > > When I run "puppetd --test --debug" on emsdb01 and emsweb01, I don't see > anything unusual happening. Both servers are basically idle while the > catalog run is happening. What I do see is that they get hung up on > these tasks for some reason: > > debug: Calling puppetmaster.getconfig > debug: Calling fileserver.describe > > When I look at the puppetmaster as this is going on, I don't see > anything unusual in regards to server load there either. At first, I > suspected some kind of network connectivity issue, but I have run > several tcpdumps, and everything seems to be connecting fine. Is there > something else I should be looking at to determine the cause of this > problem? > > -- > Michael Conigliaro > Computer Analyst > Fuss & O'Neill Technologies > www.fandotech.com > > > > > > -- Nigel Kersten nig...@google.com System Administrator Google, Inc. --~--~-~--~~~---~--~~ 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 Camp
Hmm, Velocity is in about 6 weeks away and runs Monday - Wednesday (followed by Structure) and is in San Jose, so how would those logistics work? Where would we meetup and when? I'd be up for meeting up with whoever was interested and Luke has a Puppet workshop at the conference. On Mon, May 4, 2009 at 1:14 AM, martin wrote: > > I vote for the week before the Velocity conference, as a lot of people > will be in the Bay Area and staying a few extra days is easy for us > "out of towners" > > cheers, > /Martin > > On Apr 27, 9:39 am, Andrew Shafer wrote: > > And decent Mexican food... > > > > Get it all arranged and tell me the dates... ;) > > > > On Sun, Apr 26, 2009 at 4:08 PM, Allan Marcus wrote: > > > > > I vote for Albuquerque, New Mexico! > > > > > Cheap flights from the west cost and easier for the east cost folks. > > > > > Plus, relatively cheap. > > > > > Plus, I can drive there :-) > > > > > -Allan > > > --~--~-~--~~~---~--~~ 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] long catalog run times and random connection timeouts
Hello, I've been seeing some strange behavior for the last few days, and I'm not sure what else to do to troubleshoot it. It started when two of my puppet clients (always the same two) suddenly began to take forever to finish their catalog runs. I'm not sure what changed around 5pm last Thursday to cause this, but well, check out the logs... Apr 30 16:50:50 emsdb01 puppetd[11363]: Finished catalog run in 4.59 seconds Apr 30 17:26:29 emsdb01 puppetd[11363]: Finished catalog run in 292.65 seconds Apr 30 16:43:05 emsweb01 puppetd[1345]: Finished catalog run in 4.47 seconds Apr 30 17:18:27 emsweb01 puppetd[1345]: Finished catalog run in 292.53 seconds Now when emsdb01 and emsweb01 are checking in, all the other clients seem to queue up behind them. So I end up seeing... Conection timeout calling puppetmaster.getconfig: execution expired And... Could not retrieve catalog: Connection Timeout from all the other clients. For those that don't time out, I see a flurry of "finished catalog run" as they all complete at the same time (but with excessive catalog run times, presumably because everyone else got held up by emsdb01 and emsweb01). When I run "puppetd --test --debug" on emsdb01 and emsweb01, I don't see anything unusual happening. Both servers are basically idle while the catalog run is happening. What I do see is that they get hung up on these tasks for some reason: debug: Calling puppetmaster.getconfig debug: Calling fileserver.describe When I look at the puppetmaster as this is going on, I don't see anything unusual in regards to server load there either. At first, I suspected some kind of network connectivity issue, but I have run several tcpdumps, and everything seems to be connecting fine. Is there something else I should be looking at to determine the cause of this problem? -- Michael Conigliaro Computer Analyst Fuss & O'Neill Technologies www.fandotech.com --~--~-~--~~~---~--~~ 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: Cron presence based on file content
On May 2, 10:29 am, Pete Emerson wrote: > Ah I see a new thread, "Assign variable with content of a file?" that lines > up with my needs, I'll check out the suggestions there. Yeah, it's mine! I found yours when I was looking for my own solution -- it sounds like we're both trying to achieve something rather similar. :-) --~--~-~--~~~---~--~~ 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: Assign variable with content of a file?
On May 1, 5:59 pm, Brandon Evans wrote: > no-can-do. What exactly are you trying to get done? Apologies for leaving that out -- I'd hoped to not muddy the water with the details, but now it seems I must. I want to install a home-built package whose application runs on a virtual console exclusively. Which VC specifically is controlled by that app's conf file. This app must be able to run on a VC that is normally occupied by a getty so therefore prior to app startup, it is necessary to tell upstart to disable that getty. I want puppet to do all of this, of course. The basic steps and required sequence are: 1. install package 2. install conf file for package 3. extract VC number from conf file, say as $ttynum 4. exec "initctl stop tty$ttynum" 5. exec "app" Puppet does NOT know what VC number is in the conf file -- it must extract this. (The reasons are way beyond the scope here.) Now, I've made step 3 a bit easier by revising the package so that it's possible to run "app --show-vc" and it'll parse the conf file and send the number to stdout. I cannot run this command directly with the generate function because of the embedded space character. So I thought I'd cheat and have puppet generate a temp file that is essentially a one-line shell script to run that command and have the generate function call this temporary file instead. Now it becomes a question of how to ensure that puppet creates the temp script before the generate function calls it. This is starting to look like a real headache. Unless someone sees an easier way to do something like this, I think I'll just revise the app to do step 4 itself -- although that is rather icky in itself. --~--~-~--~~~---~--~~ 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: long catalog run times and random connection timeouts
On Mon, May 4, 2009 at 7:55 AM, Michael Conigliaro wrote: > > I'm actually not sure. How do I determine that? I just use the redhat > rpms from the epel repository, and I don't remember seeing an option for > that anywhere. If you aren't sure what you are using, you are using webrick. The problem you're running into is probably the scalability wall. How many clients are you running? Take a look at the http://reductivelabs.com/trac/puppet/wiki/PuppetScalability page. I have had great success with Mongrel+Nginx, but Passenger also looks promising. --Paul --~--~-~--~~~---~--~~ 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: long catalog run times and random connection timeouts
On Mon, May 4, 2009 at 12:40 PM, Paul Lathrop wrote: > > On Mon, May 4, 2009 at 7:55 AM, Michael Conigliaro > wrote: >> >> I'm actually not sure. How do I determine that? I just use the redhat >> rpms from the epel repository, and I don't remember seeing an option for >> that anywhere. > > If you aren't sure what you are using, you are using webrick. The > problem you're running into is probably the scalability wall. How many > clients are you running? > > Take a look at the > http://reductivelabs.com/trac/puppet/wiki/PuppetScalability page. I > have had great success with Mongrel+Nginx, but Passenger also looks > promising. We're seeing an incredible difference under very heavy load with Passenger. Passenger is a much simpler setup to maintain as well, and you get all the existing stuff around Apache for free, which makes capacity planning a lot simpler. -- Nigel Kersten nig...@google.com System Administrator Google, Inc. --~--~-~--~~~---~--~~ 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] Conditionally install a file resource
I keep finding that I wish onlyif was a meta-parameter; right now I
want it on the file resource type.
I need to install a file, but only if the source exists. It's a
really simple file resource that works great when the source exists,
but fails when it doesn't. I don't care if it fails, but I do not
want it to terminate the whole dependency chain. Here's what I'm
working with:
define network($interface_name) {
file { "ifcfg-$interface_name":
group => root,
mode=> 644,
owner => root,
path=> "/etc/sysconfig/network-scripts/ifcfg-
$interface_name",
source => [ "$puppeteer_cache/ifcfg-$interface_name" ],
}
service { "network":
enable => true,
ensure => running,
hasrestart => true,
status => "test -e /var/lock/subsys/network",
subscribe => [
File["ifcfg-$interface_name"],
],
}
}
The contents of the $puppeteer_cache directory are independently
populated by rsync and are based upon the system's MAC address. So
puppet doesn't know if the the file source is there or not.
Just to be clear, another resource depends on Service["network"] and I
want it run regardless of whether a "$puppeteer_cache/ifcfg-
$interface_name" file exists or not. Most of the systems this runs on
are using DHCP, which will work fine given the default content of this
file. I only want to deploy this file this way for those systems that
need a static address.
Do I have to kludge this with an exec type or is there some way to use
the file type that I'm missing?
--~--~-~--~~~---~--~~
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: tweaking Passenger/Rack for performance.
On Apr 30, 7:20 pm, Nigel Kersten wrote: > so here are my unorganized thoughts on Passenger settings. > > * PassengerMaxPoolSize > > This depends a lot on two primary variables. a) How much RAM you have. > b) How much resident memory is needed for your environments/modules. > Only way to determine this is with tweaking, and you'll need to be > much more conservative than the suggested settings on the Passenger > docs as your app takes up a lot more memory than your average site. Sure; the puppetmaster processes are quite heavy. Right now I'm running with a MaxPoolSize of 10, fitting nicely into the 2.5GB of reserved memory. > * PassengerStatThrottleRate 600 > I haven't noticed this make a *huge* difference, but logically we > don't need to stat for the relevant files at all really. I think it's best to actually disable RackAutoDetect & RailsAutoDetect, but I'm not sure if disabling them will avoid the stats. > * PassengerHighPerformance > Turning this on appears to reduce performance for me. Interesting. From the docs I'm not seeing how this could decrease performance. Anyway, hosting puppetmaster doesn't need any rewrites or something, so turning it on/off shouldn't hurt operations. > * PassengerMaxRequests > I'm trying to work out at the moment whether we're leaking memory at > all with 0.24.8, but even if we're not, I can imagine this making a > big difference for certain usage patterns. I'm thinking of say having > a lot of different environments that all puppet regularly, but then an > overnight period where only one or two environments are being used. If > I understand how this works correctly, this should reduce memory > usage. This probably depends heavily on your environment. On my setup the puppetmaster processes stay between 200-300M VIRT, and don't grow larger, so I haven't looked at this at all. > * PassengerPoolIdleTime > The default is 300 seconds. I'm yet to look into this setting. I'm running with the default here, but still get long lived puppetmaster processes. Probably they never get idle. > * RailsSpawnMethod > * PassengerUseGlobalQueue Haven't touched these at all. Thanks for your feedback! Christian --~--~-~--~~~---~--~~ 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: tweaking Passenger/Rack for performance.
Have you tried the 0.25 beta with Passenger? For the life of me I can't get it to work on dapper or hardy. [ pid=17005 file=ext/common/ApplicationPoolServerExecutable.cpp:307 time=2009-05-04 14:17:27.451 ]: Client 0x667060: SpawnException occured (with error page) and am yet to obtain useful debugging anywhere On Mon, May 4, 2009 at 2:07 PM, wrote: > > On Apr 30, 7:20 pm, Nigel Kersten wrote: >> so here are my unorganized thoughts on Passenger settings. >> >> * PassengerMaxPoolSize >> >> This depends a lot on two primary variables. a) How much RAM you have. >> b) How much resident memory is needed for your environments/modules. >> Only way to determine this is with tweaking, and you'll need to be >> much more conservative than the suggested settings on the Passenger >> docs as your app takes up a lot more memory than your average site. > > Sure; the puppetmaster processes are quite heavy. > Right now I'm running with a MaxPoolSize of 10, fitting nicely into > the 2.5GB of reserved memory. > >> * PassengerStatThrottleRate 600 >> I haven't noticed this make a *huge* difference, but logically we >> don't need to stat for the relevant files at all really. > > I think it's best to actually disable RackAutoDetect & > RailsAutoDetect, but I'm not sure if disabling them will avoid the > stats. > >> * PassengerHighPerformance >> Turning this on appears to reduce performance for me. > > Interesting. From the docs I'm not seeing how this could decrease > performance. Anyway, hosting puppetmaster doesn't need any rewrites or > something, so turning it on/off shouldn't hurt operations. > >> * PassengerMaxRequests >> I'm trying to work out at the moment whether we're leaking memory at >> all with 0.24.8, but even if we're not, I can imagine this making a >> big difference for certain usage patterns. I'm thinking of say having >> a lot of different environments that all puppet regularly, but then an >> overnight period where only one or two environments are being used. If >> I understand how this works correctly, this should reduce memory >> usage. > > This probably depends heavily on your environment. On my setup the > puppetmaster processes stay between 200-300M VIRT, and don't grow > larger, so I haven't looked at this at all. > >> * PassengerPoolIdleTime >> The default is 300 seconds. I'm yet to look into this setting. > > I'm running with the default here, but still get long lived > puppetmaster processes. Probably they never get idle. > >> * RailsSpawnMethod >> * PassengerUseGlobalQueue > > Haven't touched these at all. > > Thanks for your feedback! > > Christian > > > > -- Nigel Kersten nig...@google.com System Administrator Google, Inc. --~--~-~--~~~---~--~~ 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: long catalog run times and random connection timeouts
Ok guys, this was a tough nut to crack, but I think I figured it out. This problem only occurred on clients that lived within a certain security zone behind my firewall. When a client was on the same vlan as the puppetmaster, everything worked fine. As soon as I moved it into any one of a particular set of vlans (all within the same security zone on my firewall), I got this slowness problem. I spent most of my time trying to figure out why/how my firewall could be causing things to be slow rather than just denying the connections altogether. But I digress... The root cause was that I did not have reverse dns records set up for any of these vlans. Using tcpdump, I was able to see that every time a client connects, the puppetmaster attempts a reverse dns lookup on the client's ip. I'm not exactly sure why yet, but dns lookups against nonexistent in-addr.arpa domains take *for-freaking-ever* on my network. Once I set up the reverse lookup zone and added the necessary ptr records, catalog runs were completing in a few seconds again. I hope someone out there benefits from this thread, because I was pulling my hair out over this problem! -- Michael Conigliaro Computer Analyst Fuss & O'Neill Technologies www.fandotech.com -Original Message- From: puppet-users@googlegroups.com [mailto:puppet-us...@googlegroups.com] On Behalf Of Paul Lathrop Sent: Monday, May 04, 2009 3:41 PM To: puppet-users@googlegroups.com Subject: [Puppet Users] Re: long catalog run times and random connection timeouts On Mon, May 4, 2009 at 7:55 AM, Michael Conigliaro wrote: > > I'm actually not sure. How do I determine that? I just use the redhat > rpms from the epel repository, and I don't remember seeing an option for > that anywhere. If you aren't sure what you are using, you are using webrick. The problem you're running into is probably the scalability wall. How many clients are you running? Take a look at the http://reductivelabs.com/trac/puppet/wiki/PuppetScalability page. I have had great success with Mongrel+Nginx, but Passenger also looks promising. --Paul --~--~-~--~~~---~--~~ 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: tweaking Passenger/Rack for performance.
On May 4, 11:20 pm, Nigel Kersten wrote: > Have you tried the 0.25 beta with Passenger? Passenger support has been completely redone for 0.25, check ext/rack in the sources. If upgrading from 0.24.x, you at least need to update the config.ru file. > For the life of me I can't get it to work on dapper or hardy. > > [ pid=17005 file=ext/common/ApplicationPoolServerExecutable.cpp:307 > time=2009-05-04 14:17:27.451 ]: > Client 0x667060: SpawnException occured (with error page) > > and am yet to obtain useful debugging anywhere You should be able to get some - maybe useful - output by pointing a browser to https://puppetmaster:8140/ It probably gives a colorful Passenger error page in your case. Christian --~--~-~--~~~---~--~~ 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-dev] ANNOUNCE: 0.25.0beta1 release!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Nasrat wrote: > 2009/5/4 James Turnbull : >> >> This is the beta1 release of Puppet 0.25.0. >> >> It is available at: >> >> http://reductivelabs.com/downloads/puppet/puppet-0.25.0beta1.tar.gz > > Note this naming means that we need gem >= 1.3.2 due to version string > for running top level rakefile else you get Malformed version number > string error: > > * Gem::Version now understands prerelease versions using letters. Yeah I know - we did a tarball for this reason. I/Luke are going to hack some bits out of the Rakefile to fix this sometime soon. It needs a few other things too - pull out the EPM stuff for example. If you do want gems you can upgrade gems, patch Gem::Version to fix (which is what I did *sigh*), or you can also manually update the version in puppet.rb too. Regards James Turnbull - -- Author of: * Pro Linux Systems Administration (http://www.amazon.com/gp/product/1430219122/) * Pulling Strings with Puppet (http://www.amazon.com/gp/product/1590599780/) * Pro Nagios 2.0 (http://www.amazon.com/gp/product/1590596099/) * Hardening Linux (http://www.amazon.com/gp/product/159059/) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ/2S09hTGvAxC30ARAqNPAJ9Ek/1l1OZHDxNTNqRiU0Hrow1lDACgnlza YH9jSYiweIQOc5SmeL/bFr8= =z0t5 -END PGP SIGNATURE- --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: tweaking Passenger/Rack for performance.
On Mon, May 4, 2009 at 2:48 PM, wrote: > > > > On May 4, 11:20 pm, Nigel Kersten wrote: >> Have you tried the 0.25 beta with Passenger? > > Passenger support has been completely redone for 0.25, check ext/rack > in the sources. If upgrading from 0.24.x, you at least need to update > the config.ru file. Yep. I really like the way it's been distributed as a puppet manifest. ++ > >> For the life of me I can't get it to work on dapper or hardy. >> >> [ pid=17005 file=ext/common/ApplicationPoolServerExecutable.cpp:307 >> time=2009-05-04 14:17:27.451 ]: >> Client 0x667060: SpawnException occured (with error page) >> >> and am yet to obtain useful debugging anywhere > > You should be able to get some - maybe useful - output by pointing a > browser to https://puppetmaster:8140/ > It probably gives a colorful Passenger error page in your case. ahah! now why couldn't I get that to actually log somewhere useful... ta. -- Nigel Kersten nig...@google.com System Administrator Google, Inc. --~--~-~--~~~---~--~~ 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: Conditionally install a file resource
On Tuesday 05 May 2009 08:58:53 John Florian wrote: > I keep finding that I wish onlyif was a meta-parameter; right now I > want it on the file resource type. I think this would be good, too. I encountered exactly the same situation yesterday. -- Robin JabberID: http://www.kallisti.net.nz/blog ||| http://identi.ca/eythian PGP Key 0xA99CEB6D = 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D signature.asc Description: This is a digitally signed message part.
[Puppet Users] Re: [Puppet-dev] ANNOUNCE: 0.25.0beta1 release!
James Turnbull wrote: > This is the beta1 release of Puppet 0.25.0. > > It is available at: > > http://reductivelabs.com/downloads/puppet/puppet-0.25.0beta1.tar.gz > > This is not production ready code - it is a beta release for > testing. The beta is largely feature complete and the extent of > testing and issues will determine how soon we move to a release > candidate. So we would ask everyone to test and report issues with > the beta. FWIW, Fedora and EPEL packages are available for testing at: http://tmz.fedorapeople.org/repo/puppet/ (For those that dislike the augeus and selinux dependencies, you can now rebuild using --without augeas and/or --without selinux to avoid them.) -- ToddOpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ Disobedience: The silver lining to the cloud of servitude. -- Ambrose Bierce pgpc0KwNKjQ94.pgp Description: PGP signature
[Puppet Users] reducing logging
Hi there, I'd like to reduce log traffic by stopping entries such as: Starting configuration run Finished configuration run in 1.23 seconds What is the appropriate config option to disable this? Thanks! -- Please remember that an email is just like a postcard; it is not confidential nor private nor secure and can be read by many other people than the intended recipient. A postcard can be read by anyone at the mail sorting office and expecting what is written on it to be private and secret is not realistic. Please hold no higher expectation of email. If you need to send confidential information in an email you need to use encryption. PGP is Pretty good for this. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] new puppet server using passenger and having issues
Hello I am working on migrating from a working mongrel based puppet server to a passenger based puppet server and I need some help. I am still getting some errors that I can't explain and I hope someone knows what I am doing wrong. I have installed the following to setup passenger gem list *** LOCAL GEMS *** fastthread (1.0.5) Optimized replacement for thread.rb primitives passenger (2.1.2) Apache module for Ruby on Rails support. rake (0.8.1) Ruby based make-like utility. I am using the following puppet rpms with 64bit RHEL5.2 rpm -qa | grep puppet puppet-0.24.6-1.el5 puppet-server-0.24.6-1.el5 This is my puppet.conf [main] vardir = /var/lib/puppet logdir = /var/log/puppet rundir = /var/run/puppet ssldir = $vardir/ssl factpath = /opt/puppet/facter modulepath = /opt/puppet/modules server = x-dev-puppet.xxx.com certname = x-dev-puppet.xxx.com pluginsync = true factsync = true [puppetmasterd] certname = x-dev-puppet.xxx.com reports = log,store I followed the install directions on the wiki and ran puppetmaster before I started passenger up and I also did some testing to make sure puppetmaster works with this config. When I do startup passenget and run the first instance of puppetd I get the following May 4 22:50:40 atl01osd101 puppetd[30102]: Reopening log files May 4 22:50:40 atl01osd101 puppetd[30102]: Starting Puppet client version 0.24.6 May 4 22:50:40 atl01osd101 puppetd[30102]: Could not call fileserver.list: # May 4 22:50:40 atl01osd101 puppetd[30102]: (/File[/var/lib/puppet/lib]) Failed to generate additional resources during transaction: HTTP-Error: 500 Internal Server Error May 4 22:50:40 atl01osd101 puppetd[30102]: Could not call fileserver.describe: # May 4 22:50:40 atl01osd101 puppetd[30102]: (/File[/var/lib/puppet/lib]) Failed to retrieve current state of resource: HTTP-Error: 500 Internal Server Error Could not describe /plugins: HTTP-Error: 500 Internal Server Error May 4 22:50:40 atl01osd101 puppetd[30102]: Could not call fileserver.list: # May 4 22:50:40 atl01osd101 puppetd[30102]: (/File[/var/lib/puppet/facts]) Failed to generate additional resources during transaction: HTTP-Error: 500 Internal Server Error May 4 22:50:40 atl01osd101 puppetd[30102]: Could not call fileserver.describe: # May 4 22:50:40 atl01osd101 puppetd[30102]: (/File[/var/lib/puppet/facts]) Failed to retrieve current state of resource: HTTP-Error: 500 Internal Server Error Could not describe /facts: HTTP-Error: 500 Internal Server Error May 4 22:50:41 atl01osd101 puppetd[30102]: Could not call puppetmaster.getconfig: # May 4 22:50:41 atl01osd101 puppetd[30102]: Could not retrieve catalog: HTTP-Error: 500 Internal Server Error May 4 22:50:41 atl01osd101 puppetd[30102]: Starting catalog run May 4 22:50:41 atl01osd101 puppetd[30102]: (//Node[default]/test_class/File[/tmp/testfile]/ensure) created May 4 22:50:41 atl01osd101 puppetd[30102]: Finished catalog run in 0.03 seconds Notice that even with the errors the catalog still runs and the default class executes. Any idea what is generating these errors? I dont understand where some of the paths are coming from since these paths are not in my puppet.conf. What is overriding the variables I have already set? Thanks in advance for any ideas. Ed --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
