Bugs happen in any service. This is the classical dilemma of plugging out your computer from the network vs connectivity (usability in this case). From my perspective high security risk bugs happen rarely enough to use both puppet and any other service I use.
IMHO misconfiguration has a bigger chance of happening when you configure each server by hand as opposed to changing and testing and retesting a manifest. I personally have a higher chance of doing mistakes in a copy/paste scenario rather than in writing a manifest scenario. In a normal puppet workflow any configuration change may be reviewed by other sysadmins. Personally I see more risks on not being able to review changes made by other admins (we all are human and make mistakes after all), and not knowing who and why made a change. berber wrote: > This doesn't sound very professional. You would risk your production > environment because it's uncomfortable for the sys admin to remember > he needs to roll back a change in 10 minutes or 10 hours? > > Assume we are talking about a business that looses tens of thousands > of $$$ for any small downtime. Does this change the picture? > Not at all. You lose more $$$ for paying 10 times more admins. You are able to audit the security of the network, and know that it stands on all the computers. In the classical case you would say that it should be done in a way, but it probably won't be done that way, which might lead to a lot more $$$ lost. You should also have an emergency night admin, one that could resolve the problems if/when they pop up, if your service is that important. Or an oncall admin which receives a sms or something if a service is down. > Just because it's hard to follow procedure and deploy changes to > production in an orderly manner, some system admins just get puppet to > run every hour and then they can forget that they made a temporary > change to a system. > Don't understand me wrong. Local changes should be done only in emergency cases. But without puppet you would do any change via a local login, and as in any workplace distractions occur, weather it's the boss or whatever. Changes should be done via puppet, and with the development -> testing -> production workflow, with the sole exception of critical changes, which should have a tighter release schedule. But a reinstall workflow is kind of slow, maybe I don't understand your scenario. As an alternative you could allow puppet to run only when admins are around if you are that scared of puppet running though the night. > I'm starting to wonder, put bluntly so don’t get mad, if “Lazy” system > admins run puppet continuously in production, while putting their > systems in harm way due to a possible bug in puppet, corruption of the > source, accidental changes to the manifest, etc… just so they don’t > have to follow tiring procedures or keep track of manual changes to > > > > I'm begging to believe that you are trolling :-) > > > the servers (damn that was long). > > Is this the case or am I missing out on the big picture? Since when > does “being productive” come before production integrity? > > > Pretty much with puppet running always you can concentrate on the real problem not on copy/pasting the configs, or waiting for an install to finish. I'm not mad, I take pride in my laziness, I'm more efficient that way. Cheers and good luck for the new year, Silviu -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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.
