----- Original Message ----- | On 07/05/2013 02:46 PM, David Schmitt wrote: | | > One of the big arguments for puppet is the unifying aspect of devs | > and | > ops to use the same tool/language/process, which improves | > cooperation, | > agility and quality of the work. This indicates that your | > application | > deployment should be integrated into your puppet manifests and | > those | > manifests should be integrated into the application | > development/release | > cycle. | | But how are they integrated in your environment? What would you do in | my | case?
In my environment we choose the right tool for the job, point blank. We put as much into puppet as we can, but we understand that it isn't the be-all-end-all tool. Understanding where the lines of delineation are is an important aspect to configuration management. It does require some extra work to ensure that we're not stepping over each others toes all the time, but it also helps each group understand what each other is trying to achieve. Where we can make use of puppet instead of some other tool we decide during a meeting so everyone knows who's responsible for what. | > Another big point in puppet's favor is that it doesn't want to be | > the | > be-all-end-all. If there's a tool that is better suited to a task | > (the | > prime example being package managers) then *please* use that. This | > indicates that if capistrano is a good match for your | > organization's | > application deployment (especially in the area of orchestration | > across | > nodes and rollback it leaves puppet in the dust), then you should | > leverage those capabilities. | | And that's exactly why are we using another tool for the job. Assuming there have been the proper discussions made this is not an issue whatsoever. In fact it's good. <snip> | > This is a non-issue as the deployment process will always be able | > to | > push the changes it needs into the system. So a subversion (no pun | > intended) of the deployment process will always be a death knell, | > independent of the used tool. So either the devs have the need and | > right | > to modify those configuration files, or they don't. If they have | > the | > need and right, then they also share the responsibility for the | > system. | | Yeah, but things have to stay pretty tight. For example: if you | enable | some user account to push files into dot-d directory, not-if-but-when | that account gets broken into, you have a possibility of privilege | escalation. | | So, allowing the write privilege for that directory obviously is not | a | good choice. Whether that push has been done via puppet or some other tool is irrelevant. If the account is compromised it's been compromised. You need to ask yourself if using puppet vs some other tool changes this fact in *ANY* way. If something is wrong, it was wrong from the time of deployment and has therefore *ALWAYS* been wrong. I don't know of any tool that can stop this. Mitigate maybe, but stop it entirely, not a chance. Just my 2c. -- James A. Peltier Manager, IT Services - Research Computing Group Simon Fraser University - Burnaby Campus Phone : 778-782-6573 Fax : 778-782-3045 E-Mail : jpelt...@sfu.ca Website : http://www.sfu.ca/itservices “A successful person is one who can lay a solid foundation from the bricks others have thrown at them.” -David Brinkley via Luke Shaw -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
