[Puppet Users] Re: ssh_authorized_key completely ignoring "require"
Scott, Can you pastie the simplest code to reproduce and maybe attach the files created by --graph to see what the relationships look like. Is anyone else seeing a problem like this? On Tue, Apr 21, 2009 at 9:02 PM, Scott wrote: > > Hi, so I'm running into a problem since upgrading to 0.24.8 where > puppet is trying to create an authorized key for users that don't > exist because it doesn't do the require ( require => "/etc/passwd" ) > first. > > I've tried making the require a default parameter for > "ssh_autohrized_key" (yes, in the same scope), I've tried making the > passwd file a requirement for every "ssh_authorized_key" and I've > tried to use "before" with the passwd resource ( before => Class > [ users::ssh_keys ] ) and yet puppet insists on trying to create the > key before doing any of the prerequisites. > > One other note, the ssh_authorized_key isn't always for the same > person, so it's not a particular key that's causing the problem. > Also, this was never a problem with 0.24.7. > > Cheers, > Scott > > > --~--~-~--~~~---~--~~ 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: Should we really expect puppetd to die randomly? (Was: Puppet watching puppet)
Hi, You can find a "working" daemon here: http://github.com/ohadlevy/puppet/tree/puppetlisten under the ext/puppetlisten subdir. It doesn't use inetd as ruby socket implementation does not work inet, I'm considering rewriting it in c but no real reason / time for now... search the mailing list for previous usage instruction (but its kinda straight forward..) Ohad On Tue, Apr 21, 2009 at 7:35 PM, Stasheck wrote: > > Ohad, I remember you were saiyng something about running puppet from > inetd - can you share some info? I really think that cron+inetd > combination would suit my company better than puppetd (which is > restarted every hour via cron) > > /br > Stanislaw > > On Apr 21, 10:03 am, Ohad Levy wrote: > > We are using puppetd though cron, and it seems to me much more reliable > and > > much less resource hungry.. > > > > if you have more than a few clients, switch to mongrel/passenger. > > WAN is not a real issue if its stable, of course it takes longer runs > but... > > > > cheers, > > Ohad > > > > On Tue, Apr 21, 2009 at 3:19 PM, Jean-Baptiste Quenot >wrote: > > > > > > > > > 2009/4/6 Mike Renfro : > > > > > > I'd normally expect that to work, but I just have puppet keep cron > > > > running, and have a periodic cron job that checks if puppet has died, > > > > and if so, restarts it: > > > > > Interesting, but why would you expect Puppet to die? Would you expect > > > Apache, Nginx or worse MySQL to die randomly like this? > > > > > I'm a Puppet user since nearly two years now, and in the big picture > > > of my web servers I find that puppetd is not the most reliable piece > > > of software. It dies every day, and my colleagues complain about this > > > regularly because their installed packages are not uptodate as they > > > expect. So I have to start it again and again on all machines. Is > > > Puppetd dying because of network problems? I believe so, but I think > > > it should be fixed instead of finding creative ways to keep puppetd > > > running, especially since I request it to run every 5 minutes as a > > > daemon. > > > > > Is anyone using puppetd in a WAN setup with default Webrick server > > > successfully? Shall I switch the HTTP server to Mongrel to gain > > > reliability? I'll test this setup. But if puppetd fails on the > > > client side, I'm not certain that changing the server's HTTP server > > > would actually prevent the client to fail at all... > > > > > I'm a bit eager with this, and I'm really looking forward to find a > > > solution, community-wise. Your comments are welcome. > > > -- > > > Jean-Baptiste Quenot > > >http://jbq.caraldi.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] ssh_authorized_key completely ignoring "require"
Hi, so I'm running into a problem since upgrading to 0.24.8 where puppet is trying to create an authorized key for users that don't exist because it doesn't do the require ( require => "/etc/passwd" ) first. I've tried making the require a default parameter for "ssh_autohrized_key" (yes, in the same scope), I've tried making the passwd file a requirement for every "ssh_authorized_key" and I've tried to use "before" with the passwd resource ( before => Class [ users::ssh_keys ] ) and yet puppet insists on trying to create the key before doing any of the prerequisites. One other note, the ssh_authorized_key isn't always for the same person, so it's not a particular key that's causing the problem. Also, this was never a problem with 0.24.7. Cheers, Scott --~--~-~--~~~---~--~~ 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] merging reports
I upgraded my puppetmaster hardware a couple of weeks ago, and I didn't copy over the rrd reports. So now my rrd reports just show the last two weeks worth of data. I have all the yaml reports for my hosts, so I assume I can walk through those and rebuild the rrd files, right? What is the easiest way to do that? -- Chad M. Huneycutt --~--~-~--~~~---~--~~ 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: puppetd no longer doingautomatic runs after updating to 0.24.8
Building a rpm of the facter 1.5.5rc1, using the EPEL 1.5.4 spec file with a small mod or two (removing the permissions and not installing the non existance COPYING file) and installing it fixes the problem in my test environment as well, am going to fan it out today and confirm its all good. for the sake of completeness, running it in no deamonize mode doesn't change anything, after startup it just sits there. On Apr 22, 7:38 am, Avi Miller wrote: > On 21/04/2009, at 11:39 PM, Daniel Dekok wrote: > > > Last week we upgraded a bunch of our machines to 0.24.8, using the > > 1.el4.1 rpm from epel/redhat, and ever since then, it looks like > > they're no longer doing any runs on the half hour. > > I think you are hitting the same Facter bug that I did with EL4. > Essentially, Facter hangs trying to read /proc/uptime and /proc/ > virtual (on my XenU guests). You should try the new Facter 1.5.5 RC1 > which has the fixes for these to see if that resolves the problem. > > I actually had to manually fix all my servers because Puppet had > stopped working. Also, when upgrading Facter, make sure you restart > Puppet (if you're running a daemon), otherwise you can also run into > problems I've discovered. > > cYa, > Avi --~--~-~--~~~---~--~~ 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: copying files back to puppet master?
On Apr 21, 2009, at 4:25 PM, Simon J Mudd wrote: > > brice-pup...@daysofwonder.com (Brice Figureau) writes: > > ... > >>> If I'm not mistaken it's not possible to use the file resource for >>> copying files back to the puppet master. Is that correct? >> >> Yes it is correct. > > ok. > > ... > >> I think you should have a look to the filebucket[1]. It might not be >> exactly what you are asking for, but it might still help you. > > No, not really but thanks for the pointer. As I said my idea would be > to use this to "manage" local configuration files, but to manage them > "centrally". > > In a previous job using cvs and cfengine I used this to allow us to > maintain local configuration files normally pushed to the central > server, but under configuration control could also be used to push out > the same files on to a different box for example to replace a failed > server. > > To be fair I don't expect puppet to do all of this, but it would be > nice if the current file: resource/protocol could potentially work in > both directions. This would open up a lot of possibilities. This will at least be possible internally with the code in 0.25 (which looks like it'll go rc1 this week, I think just one more ticket), but I don't know how it would actually be useful for the client. I've been thinking about what you're looking for, though, and I think it would make more sense to directly integrate filebuckets into a version control system - the client would back modified files up to the server, the server would automagically check those files into a version control repository (into a branch named after the host, I assume), and then you could do whatever comparisons you wanted to your heart's content. I've actually got a basic proof of concept of at least replacing the filebucket store with git done[1]. It's just the client-side pieces, you'd need to add the server-side pieces that created the branch and such, but I don't think that would be a ton of work, and it'd provide everything you want while integrating nicely with how Puppet already backs files up to the server. 1 - http://gist.github.com/77811 -- When one admits that nothing is certain one must, I think, also admit that some things are much more nearly certain than others. -- Bertrand Russell - Luke Kanies | http://reductivelabs.com | http://madstop.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] Puppet daemon performance problems
Recently I've seen people post about performance problems for the puppetd daemon. What I see is that the daemon uses resources even when it should be "asleep" waiting for the next scheduled run. If you attach to a "sleeping" daemon, you'll see it's in a tight loop where it's constantly calling nanosleep() (on my Fedora linux workstation). I did some looking around, and I suspect it is a Ruby bug, related to this thread: http://www.ruby-forum.com/topic/164574 As far as I can tell, before any threads are used, ruby will sleep for long periods without constantly causing interrupts. But once ruby threads are used, even after the last thread exits, the timer is still set for a really short loop. Has anyone tried running puppetd with the patched version of Ruby? Does it improve the daemon's performance? It looks like it'll be included in 1.8.8, when that is released. -- Jonathan Billings The College of Language, Science, and the Arts LS&A IT - Research Systems and Support --~--~-~--~~~---~--~~ 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: copying files back to puppet master?
brice-pup...@daysofwonder.com (Brice Figureau) writes: ... > > If I'm not mistaken it's not possible to use the file resource for > > copying files back to the puppet master. Is that correct? > > Yes it is correct. ok. ... > I think you should have a look to the filebucket[1]. It might not be > exactly what you are asking for, but it might still help you. No, not really but thanks for the pointer. As I said my idea would be to use this to "manage" local configuration files, but to manage them "centrally". In a previous job using cvs and cfengine I used this to allow us to maintain local configuration files normally pushed to the central server, but under configuration control could also be used to push out the same files on to a different box for example to replace a failed server. To be fair I don't expect puppet to do all of this, but it would be nice if the current file: resource/protocol could potentially work in both directions. This would open up a lot of possibilities. Simon --~--~-~--~~~---~--~~ 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: puppetd no longer doingautomatic runs after updating to 0.24.8
On 21/04/2009, at 11:39 PM, Daniel Dekok wrote: > Last week we upgraded a bunch of our machines to 0.24.8, using the > 1.el4.1 rpm from epel/redhat, and ever since then, it looks like > they're no longer doing any runs on the half hour. I think you are hitting the same Facter bug that I did with EL4. Essentially, Facter hangs trying to read /proc/uptime and /proc/ virtual (on my XenU guests). You should try the new Facter 1.5.5 RC1 which has the fixes for these to see if that resolves the problem. I actually had to manually fix all my servers because Puppet had stopped working. Also, when upgrading Facter, make sure you restart Puppet (if you're running a daemon), otherwise you can also run into problems I've discovered. cYa, Avi --~--~-~--~~~---~--~~ 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: realizing virtual ssh_authorized_key
Ah ha. After a long time debugging this on irc (thanks guys!) I found
my typo. I had defined unixadmins twice, and one was wrong. Though if
people have suggestions for a better way to implement this sort of
thing, I'd love to hear them.
seph
On Apr 21, 4:00 pm, seph wrote:
> I'm trying to use ssh_authorized_key to manage my user's ssh keys. I
> basically have this (across a couple of files):
>
> class user::virtual {
> @user { "seph":
> ensure => "present",
> uid => "2001",
> comment => "seph",
> home => "/home/seph",
> shell => "/bin/bash",
> allowdupe => false,
> managehome => true,
> }
>
> @ssh_authorized_key { "seph-2008":
> ensure => present,
> key => "...",
> type => "ssh-dss",
> name => "s...@macbook-2008",
> user => seph,
> }
> }
>
> class user::unixadmins inherits user::virtual {
> realize(
> User["seph"],
> ssh_authorized_key["seph-2008"],
> )
> }
>
> node test {
> include user::unixadmins
> }
>
> I correctly get the user seph, but not the ssh authorized key. If I
> switch to a real ssh_authorized_key by removing the @, then it creates
> /home/seph/.ssh/authorized_keys correctly. But I can't figure out how to
> realize it when it's a virtual resource. I've tried a couple of ways.
>
> Any suggestions for how to do this? Or if there's some better approach
> here?
>
> thanks
> seph
--~--~-~--~~~---~--~~
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] realizing virtual ssh_authorized_key
I'm trying to use ssh_authorized_key to manage my user's ssh keys. I
basically have this (across a couple of files):
class user::virtual {
@user { "seph":
ensure => "present",
uid=> "2001",
comment=> "seph",
home => "/home/seph",
shell => "/bin/bash",
allowdupe => false,
managehome => true,
}
@ssh_authorized_key { "seph-2008":
ensure => present,
key => "...",
type=> "ssh-dss",
name=> "s...@macbook-2008",
user=> seph,
}
}
class user::unixadmins inherits user::virtual {
realize(
User["seph"],
ssh_authorized_key["seph-2008"],
)
}
node test {
include user::unixadmins
}
I correctly get the user seph, but not the ssh authorized key. If I
switch to a real ssh_authorized_key by removing the @, then it creates
/home/seph/.ssh/authorized_keys correctly. But I can't figure out how to
realize it when it's a virtual resource. I've tried a couple of ways.
Any suggestions for how to do this? Or if there's some better approach
here?
thanks
seph
--~--~-~--~~~---~--~~
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: Think I might the idea of puppet
Ralsh is a great starting point, but you will still need to have enough tribal knowledge of the OSs you are moving between to make it work. On Tue, Apr 21, 2009 at 11:03 AM, Nigel Kersten wrote: > > On Tue, Apr 21, 2009 at 10:00 AM, Michael Semcheski > wrote: > > > > On Tue, Apr 21, 2009 at 7:38 AM, The IT Guru > wrote: > >> • Can I use puppet to pull the current configuration from a > server? > >> • Can I use puppet to replicate the current configuration from a > >> server, to another that has a different OS? > > > > A puppet client (e.g., running on a server) can pull a configuration > > from the puppet master (e.g, a different server) and apply it. > > > > However, unless I'm mistaken, it will not replicate the current > configuration. > > You can experiment with using ralsh to take the current state of > resources and generate puppet manifests with them though. > > It's not perfect puppet syntax, but it's quite good for a lot of the types. > > > > > > Mike > > > > > > > > > > > -- > 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: Should we really expect puppetd to die randomly? (Was: Puppet watching puppet)
On Apr 21, 2009, at 2:19 AM, Jean-Baptiste Quenot wrote: > > 2009/4/6 Mike Renfro : > >> I'd normally expect that to work, but I just have puppet keep cron >> running, and have a periodic cron job that checks if puppet has died, >> and if so, restarts it: > > Interesting, but why would you expect Puppet to die? Would you expect > Apache, Nginx or worse MySQL to die randomly like this? > > I'm a Puppet user since nearly two years now, and in the big picture > of my web servers I find that puppetd is not the most reliable piece > of software. It dies every day, and my colleagues complain about this > regularly because their installed packages are not uptodate as they > expect. So I have to start it again and again on all machines. Is > Puppetd dying because of network problems? I believe so, but I think > it should be fixed instead of finding creative ways to keep puppetd > running, especially since I request it to run every 5 minutes as a > daemon. I agree, these problems shouldn't exist, and when they do they should be fixed. The problem is that we can't seem to find anyone who has the time or interest in debugging the problem, and we not-too-surprisingly can't reproduce it ourselves. Everyone who has the problem just shrugs and switches to cron, and pretty much stops responding to our emails asking for help fixing the problem. What we really need is someone who's having these problems and is willing to spend some time investigating. I expect it's not that complicated, it just needs to be hunted down. And, for the record, I think this got a lot better in 0.24.8 (or maybe 0.24.7?). We found a few cases where errors could propagate far enough to kill the client, and I think we've eradicated nearly all of them. > Is anyone using puppetd in a WAN setup with default Webrick server > successfully? Shall I switch the HTTP server to Mongrel to gain > reliability? I'll test this setup. But if puppetd fails on the > client side, I'm not certain that changing the server's HTTP server > would actually prevent the client to fail at all... We need to add logs or something to clarify this, but you should *definitely* switch away from Webrick if you're having any kind of performance or reliability problems. Or if you're not. -- Death and taxes are inevitable; at least death doesn't get worse every year. - Luke Kanies | http://reductivelabs.com | http://madstop.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: puppetd no longer doingautomatic runs after updating to 0.24.8
On Apr 21, 2009, at 8:39 AM, Daniel Dekok wrote: > > Hi, > > Last week we upgraded a bunch of our machines to 0.24.8, using the > 1.el4.1 rpm from epel/redhat, and ever since then, it looks like > they're no longer doing any runs on the half hour. If we run manually > as a oneshot or a test via the init.d script, there's no problems, but > there's no activity on the logs of active runs. I've tested running > puppetd with --ignorecache, and also disabling and enableing --splay > (we keep it enabled normally) with no change, and in recent tests > dropped the runinterval to 60, but also with no difference. Even with > debug, the client logs are quite simply blank and there's no activity, > the debug logs on the puppetmaster only have some basic connections > upon first run. > > Not sure if to take it to redhat or not, but there could be a > correlation between this feature and the fact these machines are on > RHEL4, we've got some RHEL5/centos 5 machines that seem to be ok. > > Cant think of any other tests to try, as its in the internal > scheduling, not forcing a update/run, and ideas would be appreciated. What happens if you run in debug mode with --no-daemonize? I've not seen this, and I'd think you'd get at least some kind of message somewhere. -- It is said that power corrupts, but actually it's more true that power attracts the corruptible. The sane are usually attracted by other things than power. -- David Brin - Luke Kanies | http://reductivelabs.com | http://madstop.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: Should we really expect puppetd to die randomly? (Was: Puppet watching puppet)
On Tue, Apr 21, 2009 at 05:30:54PM +0200, Jean-Baptiste Quenot wrote: > > > Are you hitting the OOM killer? It sounds like you might be. > > I don't think so because there is nothing in syslog. The last > message from puppetd is "Starting catalog run". And then it dies. The OOM killer isn't a message from puppetd, and probably isn't even in syslog; it's a kernel message. On my box I'd expect to see it in /var/log/kern.log -Robin -- They say: "The first AIs will be built by the military as weapons." And I'm thinking: "Does it even occur to you to try for something other than the default outcome?" See http://shrunklink.com/cdiz http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/ --~--~-~--~~~---~--~~ 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: Facter 1.5.5rc1
R.I.Pienaar wrote: > - The file 'COPYING' is not included anymore, the redhat spec file still > mentions it though, either add the file or just remove it from line 63 of > conf/redhat/facter.spec Noted thanks. > An unmentioned fix of this version is that facter --puppet now does what it's > supposed too, first time I've seen this work and its great! Sorry - yes add: Fixed #1918 - facter --puppet doesn't work when puppet's vardir or libdir are modified Fixed #2011 - virtual fact reports always vserver_host if /proc/virtual even if xenu Fixed #2021 - Returning boolean not always possible to the list of fixes. This slipped through the CHANGELOG. 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/) signature.asc Description: OpenPGP digital signature
[Puppet Users] Re: ANNOUNCE: Facter 1.5.5rc1
Hello, - "James Turnbull" wrote: > A new Facter release candidate is available - 1.5.5rc1. This is > primarily a maintenance release combining a number of fixes > including: > > Can we ask as many people as possible to please test the release and > the fixes. - The file 'COPYING' is not included anymore, the redhat spec file still mentions it though, either add the file or just remove it from line 63 of conf/redhat/facter.spec An unmentioned fix of this version is that facter --puppet now does what it's supposed too, first time I've seen this work and its great! I've made a RPM for RHEL5 sans the COPYING file, find it here: http://nephilim.ml.org/~rip/puppet/facter-1.5.5rc1-1.el5.noarch.rpm to help people who want to test it. -- R.I.Pienaar --~--~-~--~~~---~--~~ 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] ANNOUNCE: Facter 1.5.5rc1
A new Facter release candidate is available - 1.5.5rc1. This is primarily a maintenance release combining a number of fixes including: * Added EC2 facts * Fixed #2132 - Support for named interfaces under Linux * Fixed #2080 - IPAddress resolutions should be reordered * Fixed #2078 - ip.rb errors command not found * Fixed #2058 - Redirecting stderr doesn't work on all systems * Fixed #2081 - Fixed interfaces fact for vlan subinterfaces * Fixed #2063 - added kernelmajversion fact * Fixed #2055 - SunoS Interface error * Fixed #2044 - fixed virtual fact * Fixed lib install permissions * Fixed #2040 - Facter should provide a macosx_productversion_major fact * Fixed #2003 - Added is_virtual fact * Fixed #2035 - Missing brace for OSX preflight * Fixed #2032 - file.open hanging on /proc/uptime on some platform You can get the new release at: http://reductivelabs.com/downloads/facter/facter-1.5.5rc1.tgz Can we ask as many people as possible to please test the release and the fixes. Please log any bugs to Redmine (http://projects.reductivelabs.com) Thanks 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/) signature.asc Description: OpenPGP digital signature
[Puppet Users] Re: Think I might the idea of puppet
On Tue, Apr 21, 2009 at 10:00 AM, Michael Semcheski wrote: > > On Tue, Apr 21, 2009 at 7:38 AM, The IT Guru wrote: >> • Can I use puppet to pull the current configuration from a server? >> • Can I use puppet to replicate the current configuration from a >> server, to another that has a different OS? > > A puppet client (e.g., running on a server) can pull a configuration > from the puppet master (e.g, a different server) and apply it. > > However, unless I'm mistaken, it will not replicate the current configuration. You can experiment with using ralsh to take the current state of resources and generate puppet manifests with them though. It's not perfect puppet syntax, but it's quite good for a lot of the types. > > Mike > > > > -- 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: Think I might the idea of puppet
Mr. Gabriel, > • Can I use puppet to pull the current configuration from a server? Yes, this is the default behavior. > > • Can I use puppet to replicate the current configuration from a > server, to another that has a different OS? > Sort of, but there is no such thing as a free lunch. You can model the services in such a way that the differences between OS can be handled, but those differences must be handled explicitly, for example differences in package names or default locations for configuration files from platform to platform must be specified. > --~--~-~--~~~---~--~~ 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: Think I might the idea of puppet
On Tue, Apr 21, 2009 at 7:38 AM, The IT Guru wrote: > • Can I use puppet to pull the current configuration from a server? > • Can I use puppet to replicate the current configuration from a > server, to another that has a different OS? A puppet client (e.g., running on a server) can pull a configuration from the puppet master (e.g, a different server) and apply it. However, unless I'm mistaken, it will not replicate the current configuration. Mike --~--~-~--~~~---~--~~ 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] puppetd no longer doingautomatic runs after updating to 0.24.8
Hi, Last week we upgraded a bunch of our machines to 0.24.8, using the 1.el4.1 rpm from epel/redhat, and ever since then, it looks like they're no longer doing any runs on the half hour. If we run manually as a oneshot or a test via the init.d script, there's no problems, but there's no activity on the logs of active runs. I've tested running puppetd with --ignorecache, and also disabling and enableing --splay (we keep it enabled normally) with no change, and in recent tests dropped the runinterval to 60, but also with no difference. Even with debug, the client logs are quite simply blank and there's no activity, the debug logs on the puppetmaster only have some basic connections upon first run. Not sure if to take it to redhat or not, but there could be a correlation between this feature and the fact these machines are on RHEL4, we've got some RHEL5/centos 5 machines that seem to be ok. Cant think of any other tests to try, as its in the internal scheduling, not forcing a update/run, and ideas would be appreciated. Thanks, Daniel --~--~-~--~~~---~--~~ 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] Think I might the idea of puppet
Dear all, Thanks for taking the time to read my msg :) I have two questions, • Can I use puppet to pull the current configuration from a server? • Can I use puppet to replicate the current configuration from a server, to another that has a different OS? If I can do these two tasks, that is pull the current config from a server, and then replicate it elsewhere – I’ll be a hero! --- Kind Regards, Mr Gabriel --~--~-~--~~~---~--~~ 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: Should we really expect puppetd to die randomly? (Was: Puppet watching puppet)
2009/4/21 Bjørn Dyre Dyresen : > We had this problem when we hit the scaling wall running webrick. We then > moved our puppetmaster to a beefy server (dual quadcore with 16 GB ram). > Here we run six puppetmasterds with mongrel and stored config. On the same > server we run nginx. With this setup we can loop over a lot of servers > restarting puppet client without any trouble at all. I tried doing more than > 100 at the time without any trouble. So it certainly performs. > > After setting this up the problem with dead puppet clients seemed to vanish. > I have no idea how many servers you are running, but when pulling every > fifth minute they sure should get some traffic. You will hit the scaling > wall earlier. If you have 50 servers you need a setup that other people > would use for a two/three hundred server setup. Are you really sure you need > to pull that often? If scaling was involved I would expect Puppetd to be slow, not to die. I have about 12 servers that hit a single puppetmasterd through the Internet, with a lot of puppet:// resources, and every 5 minutes. Anyway, I'll try that setup if it worked for you, especially as you mention that "dead puppet clients" disappeared. Thanks! -- Jean-Baptiste Quenot http://jbq.caraldi.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: Should we really expect puppetd to die randomly? (Was: Puppet watching puppet)
2009/4/21 Trevor Vaughan : > > I haven't had any problems with the client stability. > > But, I'm also not using the 'file' type to copy files over the > 'puppet://' protocol. I'm using the puppet:// protocol extensively yes. As I noticed it was very slow especially with recurse=>true, I tend to put my files in Debian packages when possible. > Are you hitting the OOM killer? It sounds like you might be. I don't think so because there is nothing in syslog. The last message from puppetd is "Starting catalog run". And then it dies. -- Jean-Baptiste Quenot http://jbq.caraldi.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: Should we really expect puppetd to die randomly? (Was: Puppet watching puppet)
On Tue, Apr 21, 2009 at 6:56 AM, Mike Renfro wrote: > > Jean-Baptiste Quenot wrote: >> 2009/4/6 Mike Renfro : >> >>> I'd normally expect that to work, but I just have puppet keep cron >>> running, and have a periodic cron job that checks if puppet has died, >>> and if so, restarts it: >> >> Interesting, but why would you expect Puppet to die? Would you expect >> Apache, Nginx or worse MySQL to die randomly like this? Why not? Isn't that why we have sitters and puppet ensuring services are running? :) my 2c is that we had persistent performance and reliability problems with puppetd as a daemon, and switched to cron/launchd jobs that simply run puppetd --onetime --no-daemonize instead. > > At the time I put together that recipe, I didn't particularly expect > puppet to die randomly, but I knew there was a similar practice for > cfengine users. And though I wouldn't *expect* any of those other > services to die randomly, I'd certainly monitor all of them with Nagios > and write puppet manifests to restart them if they're found to be not > running. > > I have had some puppetd's die and get restarted from cron. On the few > dozen systems I have with puppetd, I don't think it happens even once > per day for the entire group. > > -- > Mike Renfro / R&D Engineer, Center for Manufacturing Research, > 931 372-3601 / Tennessee Technological University -- ren...@tntech.edu > > > > -- 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
I'm probably not the only one from a company that has severly restricted the budget for travel and conferences, so while I would personally prefer an East Coast locale, I could still likely swing a West Coast mini-conference if 1) it's scheduled soon so I can take advantage of early booking air fares 2) the venue is well-situated with respect to public transit so I could stay wherever has the best rates, and not shell out for an auto rental My $0.02. Cheers, Peter --~--~-~--~~~---~--~~ 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
On Sun, 2009-04-19 at 13:23 -0600, Andrew Shafer wrote: > > We are organizing a Puppet mini conf. You mean something formal with speakers/sessions/keynotes and so on? > The time frame is Septemberish, but no locations or dates are set, > which is essentially the point of this email. Not sure the time frame will match for me. > For locations, I'm proposing Salt Lake City, UT, Portland, OR, or > somewhere in or around SF/Silicon Valley with my list of pros and > cons. My own preference would be SF/Bay Area/SJ (direct flights from SFO on Air France), this would allow me to combine the conference with a trip to my company US office (but I'll have to convince my employer to pay me the trip :-)). -- Brice Figureau My Blog: http://www.masterzen.fr/ --~--~-~--~~~---~--~~ 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 Meet with Luke - London Monday 27th April
I'm in... Derek On Apr 21, 9:18 am, Matt wrote: > Drat, i'm hoping to be inLondonthe day after (28th) for the Amazon > AWS event. Anyone else going to this? > > Matt > > 2009/4/20 Mike Pountney : > > > > > > > Count me in Paul... Definitely need to buy the man a beer or two. > > > Should be able to get there from Brighton by about 19:00... > > > On 19 Apr 2009, at 21:45, Paul Nasrat wrote: > > >> Luke is going to be in town, and I thought it'd be good to arrange a > >> meet for beer/discussion and maybe some food afterwards. > > >> I was thinking of the Veggie Indian places along Drummond St for > >> Dosa, etc. > > >> Meet in the Bree Louise near Euston > >>http://www.beerintheevening.com/pubs/s/40/4034/Bree_Louise/Eustonfor > >> some real ale from 18:30 > > >> Paul- Hide quoted text - > > - Show quoted text - --~--~-~--~~~---~--~~ 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: Should we really expect puppetd to die randomly? (Was: Puppet watching puppet)
Jean-Baptiste Quenot wrote: > 2009/4/6 Mike Renfro : > >> I'd normally expect that to work, but I just have puppet keep cron >> running, and have a periodic cron job that checks if puppet has died, >> and if so, restarts it: > > Interesting, but why would you expect Puppet to die? Would you expect > Apache, Nginx or worse MySQL to die randomly like this? At the time I put together that recipe, I didn't particularly expect puppet to die randomly, but I knew there was a similar practice for cfengine users. And though I wouldn't *expect* any of those other services to die randomly, I'd certainly monitor all of them with Nagios and write puppet manifests to restart them if they're found to be not running. I have had some puppetd's die and get restarted from cron. On the few dozen systems I have with puppetd, I don't think it happens even once per day for the entire group. -- Mike Renfro / R&D Engineer, Center for Manufacturing Research, 931 372-3601 / Tennessee Technological University -- ren...@tntech.edu --~--~-~--~~~---~--~~ 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: strategies for plugins with environments?
On Mon, Apr 20, 2009 at 8:13 PM, Nigel Kersten wrote: > On Mon, Apr 20, 2009 at 8:08 PM, Nigel Kersten wrote: >> On Mon, Apr 20, 2009 at 6:11 PM, Jason Rojas >> wrote: >>> >>> With the use of the >>> [production] >>> and >>> [development] sections of the puppetmaster config, you can specify a >>> plugin path, you can have it either be shared, or the same directory just >>> checked out from the development branch in subversion, in my case it is: >>> >>> [production] >>> pluginpath=/opt/puppet/production/plugins >>> [development] >>> pluginpath=/opt/puppet/development/plugins >>> >>> both the directories production and development are different branches in >>> my svn repo. >> >> Have you tested this Jason? This certainly never used to work... >> You'd always get the plugins from the default environment no matter >> what pluginpath specified >> >> /me runs off to test again. > > And it is definitely working now... although plugins in modules in > environments are still non functional. > > Awesome, that answers this question... :) > Actually, I just rediscovered the problem, and I'm curious how you're dealing with this Jason. This works for providing a source for the clients to synchronize their plugins from, but you're still left with the problem of ensuring the plugins are in the *server* Ruby loadpath in order for it to parse the manifests that include your custom plugins. >From memory, others solve this in a similar way to the way we do, with a symlink in /var/lib/puppet/lib to one of the plugins sources, or alternatively they run puppet on the server to populate the plugins so they are in the server load path. This still means you only have one plugin source as far as the server is concerned, but you are in fact distributing different pluginpaths for different environments. I can imagine all sorts of incompatibilities if you're using environments as a release process and have a custom type 'foo' that has quite different attributes in the different pluginpaths. Did that make sense? I haven't quite had enough coffee yet -- 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: copying files back to puppet master?
On Tue, 2009-04-21 at 10:50 +0200, Simon J Mudd wrote: > Hi all, > > Puppet is used mainly for managing resources on the servers it manages, > and as such files and software may be distributed from the puppet master > to the clients as part of the management or configuration process. > > That's fine. > > The puppet installation where I work has evolved starting from a site > with no puppet to a site where most of the servers are puppetised with > the intention being on doing a complete deploy exclusively using puppet. > > However, as not all aspects of all resources on the server are managed > by puppet there is room for the administators to make mistakes. As such > we often want to version control configuration information on the server > which protects against mistakes but also allows us to see when changes > were made, either automatically (by puppet) or manually. > > If I'm not mistaken it's not possible to use the file resource for > copying files back to the puppet master. Is that correct? Yes it is correct. > This functionality would be most useful, especially if we combine > this with some revision control system. If we did something like > this the files to be returned back to the puppet master (assuming > they change) would need to be copied back to a location like > /puppet_master_path/site_and_hostname/host_path/filename. The advantage of > doing this in puppet is that you don't need to ensure that extra firewall > holes are opened, and that in principal at least the same file resource > could be used. It might be necesssary to additionally qualify/authorise > "back to master" transfers for security reasons. > > A feature like this is much easier to manage than doing this outside of > puppet. It is also much easier to compare the configuration of a number of > different "similar" servers if the files are located on the same server, > especially as the number of managed servers increases. > > So is this possible at the moment in puppet, and if not is it a feature > that might be interesting to others? How are others tackling problems > like this? I think you should have a look to the filebucket[1]. It might not be exactly what you are asking for, but it might still help you. The filebucket is a way to backup files that are changed by puppet to the master (or locally). There is also an accompanying application (called filebucket) that can be used to get back the various "bucketed" files. [1]: http://reductivelabs.com/trac/puppet/wiki/TypeReference#id356 -- Brice Figureau My Blog: http://www.masterzen.fr/ --~--~-~--~~~---~--~~ 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: Should we really expect puppetd to die randomly? (Was: Puppet watching puppet)
Ohad, I remember you were saiyng something about running puppet from inetd - can you share some info? I really think that cron+inetd combination would suit my company better than puppetd (which is restarted every hour via cron) /br Stanislaw On Apr 21, 10:03 am, Ohad Levy wrote: > We are using puppetd though cron, and it seems to me much more reliable and > much less resource hungry.. > > if you have more than a few clients, switch to mongrel/passenger. > WAN is not a real issue if its stable, of course it takes longer runs but... > > cheers, > Ohad > > On Tue, Apr 21, 2009 at 3:19 PM, Jean-Baptiste Quenot > wrote: > > > > > 2009/4/6 Mike Renfro : > > > > I'd normally expect that to work, but I just have puppet keep cron > > > running, and have a periodic cron job that checks if puppet has died, > > > and if so, restarts it: > > > Interesting, but why would you expect Puppet to die? Would you expect > > Apache, Nginx or worse MySQL to die randomly like this? > > > I'm a Puppet user since nearly two years now, and in the big picture > > of my web servers I find that puppetd is not the most reliable piece > > of software. It dies every day, and my colleagues complain about this > > regularly because their installed packages are not uptodate as they > > expect. So I have to start it again and again on all machines. Is > > Puppetd dying because of network problems? I believe so, but I think > > it should be fixed instead of finding creative ways to keep puppetd > > running, especially since I request it to run every 5 minutes as a > > daemon. > > > Is anyone using puppetd in a WAN setup with default Webrick server > > successfully? Shall I switch the HTTP server to Mongrel to gain > > reliability? I'll test this setup. But if puppetd fails on the > > client side, I'm not certain that changing the server's HTTP server > > would actually prevent the client to fail at all... > > > I'm a bit eager with this, and I'm really looking forward to find a > > solution, community-wise. Your comments are welcome. > > -- > > Jean-Baptiste Quenot > >http://jbq.caraldi.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: Should we really expect puppetd to die randomly? (Was: Puppet watching puppet)
We had this problem when we hit the scaling wall running webrick. We then moved our puppetmaster to a beefy server (dual quadcore with 16 GB ram). Here we run six puppetmasterds with mongrel and stored config. On the same server we run nginx. With this setup we can loop over a lot of servers restarting puppet client without any trouble at all. I tried doing more than 100 at the time without any trouble. So it certainly performs. After setting this up the problem with dead puppet clients seemed to vanish. I have no idea how many servers you are running, but when pulling every fifth minute they sure should get some traffic. You will hit the scaling wall earlier. If you have 50 servers you need a setup that other people would use for a two/three hundred server setup. Are you really sure you need to pull that often? 2009/4/21 Ohad Levy > We are using puppetd though cron, and it seems to me much more reliable and > much less resource hungry.. > > if you have more than a few clients, switch to mongrel/passenger. > WAN is not a real issue if its stable, of course it takes longer runs > but... > > cheers, > Ohad > > > On Tue, Apr 21, 2009 at 3:19 PM, Jean-Baptiste Quenot > wrote: > >> >> 2009/4/6 Mike Renfro : >> >> > I'd normally expect that to work, but I just have puppet keep cron >> > running, and have a periodic cron job that checks if puppet has died, >> > and if so, restarts it: >> >> Interesting, but why would you expect Puppet to die? Would you expect >> Apache, Nginx or worse MySQL to die randomly like this? >> >> I'm a Puppet user since nearly two years now, and in the big picture >> of my web servers I find that puppetd is not the most reliable piece >> of software. It dies every day, and my colleagues complain about this >> regularly because their installed packages are not uptodate as they >> expect. So I have to start it again and again on all machines. Is >> Puppetd dying because of network problems? I believe so, but I think >> it should be fixed instead of finding creative ways to keep puppetd >> running, especially since I request it to run every 5 minutes as a >> daemon. >> >> Is anyone using puppetd in a WAN setup with default Webrick server >> successfully? Shall I switch the HTTP server to Mongrel to gain >> reliability? I'll test this setup. But if puppetd fails on the >> client side, I'm not certain that changing the server's HTTP server >> would actually prevent the client to fail at all... >> >> I'm a bit eager with this, and I'm really looking forward to find a >> solution, community-wise. Your comments are welcome. >> -- >> Jean-Baptiste Quenot >> http://jbq.caraldi.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: Should we really expect puppetd to die randomly? (Was: Puppet watching puppet)
I haven't had any problems with the client stability. But, I'm also not using the 'file' type to copy files over the 'puppet://' protocol. It might be related, but it might not. Are you hitting the OOM killer? It sounds like you might be. I *would* expect Apache and MySQL to die like this (and I've seen it) if they're hitting resource limits and the OS decides that they need to die. The last time I saw it with Apache was due to a badly written plugin that ate all of the memory in the system which caused Apache to be nuked. Trevor On Tue, Apr 21, 2009 at 03:19, Jean-Baptiste Quenot wrote: > > 2009/4/6 Mike Renfro : > >> I'd normally expect that to work, but I just have puppet keep cron >> running, and have a periodic cron job that checks if puppet has died, >> and if so, restarts it: > > Interesting, but why would you expect Puppet to die? Would you expect > Apache, Nginx or worse MySQL to die randomly like this? > > I'm a Puppet user since nearly two years now, and in the big picture > of my web servers I find that puppetd is not the most reliable piece > of software. It dies every day, and my colleagues complain about this > regularly because their installed packages are not uptodate as they > expect. So I have to start it again and again on all machines. Is > Puppetd dying because of network problems? I believe so, but I think > it should be fixed instead of finding creative ways to keep puppetd > running, especially since I request it to run every 5 minutes as a > daemon. > > Is anyone using puppetd in a WAN setup with default Webrick server > successfully? Shall I switch the HTTP server to Mongrel to gain > reliability? I'll test this setup. But if puppetd fails on the > client side, I'm not certain that changing the server's HTTP server > would actually prevent the client to fail at all... > > I'm a bit eager with this, and I'm really looking forward to find a > solution, community-wise. Your comments are welcome. > -- > Jean-Baptiste Quenot > http://jbq.caraldi.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: iptables anyone?
Howdy, Iptables management can be implemented quite easily, i use a modified version of the following: http://reductivelabs.com/trac/puppet/wiki/Recipes/ModuleIptables Cheers Quoting Matt : > > About to start looking at managing iptables on our CentOS 5.2 systems, > anyone know if a type/solution already exists for this? > > Thanks, > > Matt > > > > --~--~-~--~~~---~--~~ 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] iptables anyone?
About to start looking at managing iptables on our CentOS 5.2 systems, anyone know if a type/solution already exists for this? Thanks, Matt --~--~-~--~~~---~--~~ 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] copying files back to puppet master?
Hi all, Puppet is used mainly for managing resources on the servers it manages, and as such files and software may be distributed from the puppet master to the clients as part of the management or configuration process. That's fine. The puppet installation where I work has evolved starting from a site with no puppet to a site where most of the servers are puppetised with the intention being on doing a complete deploy exclusively using puppet. However, as not all aspects of all resources on the server are managed by puppet there is room for the administators to make mistakes. As such we often want to version control configuration information on the server which protects against mistakes but also allows us to see when changes were made, either automatically (by puppet) or manually. If I'm not mistaken it's not possible to use the file resource for copying files back to the puppet master. Is that correct? This functionality would be most useful, especially if we combine this with some revision control system. If we did something like this the files to be returned back to the puppet master (assuming they change) would need to be copied back to a location like /puppet_master_path/site_and_hostname/host_path/filename. The advantage of doing this in puppet is that you don't need to ensure that extra firewall holes are opened, and that in principal at least the same file resource could be used. It might be necesssary to additionally qualify/authorise "back to master" transfers for security reasons. A feature like this is much easier to manage than doing this outside of puppet. It is also much easier to compare the configuration of a number of different "similar" servers if the files are located on the same server, especially as the number of managed servers increases. So is this possible at the moment in puppet, and if not is it a feature that might be interesting to others? How are others tackling problems like this? Simon --~--~-~--~~~---~--~~ 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 Meet with Luke - London Monday 27th April
Drat, i'm hoping to be in London the day after (28th) for the Amazon AWS event. Anyone else going to this? Matt 2009/4/20 Mike Pountney : > > Count me in Paul... Definitely need to buy the man a beer or two. > > Should be able to get there from Brighton by about 19:00... > > > On 19 Apr 2009, at 21:45, Paul Nasrat wrote: > >> >> Luke is going to be in town, and I thought it'd be good to arrange a >> meet for beer/discussion and maybe some food afterwards. >> >> I was thinking of the Veggie Indian places along Drummond St for >> Dosa, etc. >> >> Meet in the Bree Louise near Euston >> http://www.beerintheevening.com/pubs/s/40/4034/Bree_Louise/Euston for >> some real ale from 18:30 >> >> 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: Should we really expect puppetd to die randomly? (Was: Puppet watching puppet)
We are using puppetd though cron, and it seems to me much more reliable and much less resource hungry.. if you have more than a few clients, switch to mongrel/passenger. WAN is not a real issue if its stable, of course it takes longer runs but... cheers, Ohad On Tue, Apr 21, 2009 at 3:19 PM, Jean-Baptiste Quenot wrote: > > 2009/4/6 Mike Renfro : > > > I'd normally expect that to work, but I just have puppet keep cron > > running, and have a periodic cron job that checks if puppet has died, > > and if so, restarts it: > > Interesting, but why would you expect Puppet to die? Would you expect > Apache, Nginx or worse MySQL to die randomly like this? > > I'm a Puppet user since nearly two years now, and in the big picture > of my web servers I find that puppetd is not the most reliable piece > of software. It dies every day, and my colleagues complain about this > regularly because their installed packages are not uptodate as they > expect. So I have to start it again and again on all machines. Is > Puppetd dying because of network problems? I believe so, but I think > it should be fixed instead of finding creative ways to keep puppetd > running, especially since I request it to run every 5 minutes as a > daemon. > > Is anyone using puppetd in a WAN setup with default Webrick server > successfully? Shall I switch the HTTP server to Mongrel to gain > reliability? I'll test this setup. But if puppetd fails on the > client side, I'm not certain that changing the server's HTTP server > would actually prevent the client to fail at all... > > I'm a bit eager with this, and I'm really looking forward to find a > solution, community-wise. Your comments are welcome. > -- > Jean-Baptiste Quenot > http://jbq.caraldi.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] Should we really expect puppetd to die randomly? (Was: Puppet watching puppet)
2009/4/6 Mike Renfro : > I'd normally expect that to work, but I just have puppet keep cron > running, and have a periodic cron job that checks if puppet has died, > and if so, restarts it: Interesting, but why would you expect Puppet to die? Would you expect Apache, Nginx or worse MySQL to die randomly like this? I'm a Puppet user since nearly two years now, and in the big picture of my web servers I find that puppetd is not the most reliable piece of software. It dies every day, and my colleagues complain about this regularly because their installed packages are not uptodate as they expect. So I have to start it again and again on all machines. Is Puppetd dying because of network problems? I believe so, but I think it should be fixed instead of finding creative ways to keep puppetd running, especially since I request it to run every 5 minutes as a daemon. Is anyone using puppetd in a WAN setup with default Webrick server successfully? Shall I switch the HTTP server to Mongrel to gain reliability? I'll test this setup. But if puppetd fails on the client side, I'm not certain that changing the server's HTTP server would actually prevent the client to fail at all... I'm a bit eager with this, and I'm really looking forward to find a solution, community-wise. Your comments are welcome. -- Jean-Baptiste Quenot http://jbq.caraldi.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 -~--~~~~--~~--~--~---
