Patrick <[email protected]> writes:
> On Nov 23, 2010, at 4:53 PM, Adam Nielsen wrote:
>
>> I've been reading up on Puppet but there are a few things I am unsure of,
>> and I'm hoping someone here can advise.
>>
>> As I understand it the idea behind Puppet is to describe how a machine
>> should be configured in a single place, and then let Puppet handle the
>> actual set up of the machine.
>>
>> How specific is this?
It varies: puppet has a whole bunch of "types" and "providers", which
provide a high level way to interact with a bunch of system stuff. You can
also get modules from the Puppet Forge that other folks have written to do the
same, or write your own.
However, you are likely to still end up doing some things through "copy this
file into this place" commands inside puppet. (All in puppet, though - you
don't need *another* system beside it.)
>> For example, I use Exim as an e-mail MTA, with some custom config rules
>> related to SpamAssassin. Do I describe all these in Puppet configuration
>> files, so that Puppet can produce the correct Exim config file?
I don't know of a good Exim provider, so you would probably end up with a
combination of copying in config files in puppet, and using the regular
service and package management types.
>> I'm also about to migrate a server onto new hardware and I would like to
>> upgrade the OS at the same time (change Linux distribution actually.) Would
>> it be possible to configure Puppet on the old server, run it in debug mode
>> to see what would be changed, then tweak the configuration until *nothing*
>> would be changed (so that the Puppet config exactly matches the current
>> server config) then apply that to the new server?
Yes. It would be a huge amount of work, though, probably on the order of a
couple of weeks per machine if you intend to capture the current state.
>> Would this result in the new server being set up exactly the same as the
>> old one, with the same software installed (albeit newer versions) and the
>> same config set?
Maybe: puppet only does what you tell it, so if you missed something (as
Patrick says) you would end up with a broken system. I am a touch less
dubious about the possibility of success than him, but agree that it is not
the best way to do that.
> Nice idea, but not going to work. The problem is that an empty puppet
> config will also give you no changes. Doing this is a good idea, but you
> are almost sure to miss files that need to be changed that puppet is not
> changing because you didn't tell it to.
[...]
> Basically, I would try this, but expect that the new server will need a lot
> of runs with catalog treaking each time until it works. Once it works
> though, it makes disaster recovery much easier. (Although you still need a
> good backup plan for data.)
A much, much better approach is to work out what you want the server to do.
Once you know that you can instruct puppet, and it will implement what you
tell it to do. Then, once you are comfortable you can just replace the old
server with the new one.
I know it doesn't sound much different - but there is a huge amount of work in
trying to replicate something, while it is usually much easier to sit down and
document exactly what you want a machine to do.
Daniel
--
✣ Daniel Pittman ✉ [email protected] ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
--
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.
