On Mar 2, 3:29 am, "luke.bigum" <[email protected]> wrote: > Puppet will not do anything you don't tell it to do. Try think of it > more along the lines of your modules and manifests describing how a > server should be and only how it should be.
That point deserves emphasis, for it is one of the keys to understanding Puppet and using it effectively. Many Puppet newbies think of Puppet as if it were a scripting engine with an obtuse syntax. This thought pattern is reflected by questions framed as "How do I tell Puppet to _do_ XYZ?" In fact, Puppet is a state management service with an instruction syntax geared specifically to that role. Questions framed as "How do I tell Puppet that the node should (not) _be_/_have_ UVW?" reflect a clearer understanding. My #1 rule of Puppet is "Puppet is not a script engine." > So if you don't tell it > NOT to be something, it's just going to ignore anything else that > exists on the system - this is why you haven't needed to tell Puppet > to install the packages kernel, and core-utils, it's not going to undo > anything that already exists that it doesn't know about otherwise > Puppet manifests would be massively redundant :) Of course you *can* specify, for example, an exhaustive list of the packages that should be installed. If you do so, you can even tell Puppet that no unlisted packages should be present (see the "Resources" resource). Ditto for other resource types. Few people seem to adopt such a locked-down approach, however. My #2 rule of Puppet is "Unmanaged means 'I don't care'." The corrolary is "Say 'absent' when that's what you want." John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
