Best Practice: How you handle config files?

[Larry Ludwig]

Hi guys,

We are primarily a CentOS/RHEL shop (but expect to have more distros
in the future) What's the best way to handle config files that are
initially installed by rpms? Before Puppet we used to create our own
what we called 'supplemental' rpms that would diff the config file and
place it's changes into the config file and restart the service (if
needed) Based upon now using Puppet we are going to stay with using
the stock distro as much as possible and use puppet to make our
customizations to the config files.

I see sysadmins dealing with three issues in software mgt.
1 Consistency/Installs - making sure installations are repeatable and
the same for all installs, even across platforms
2 Updates - Ability update applications and configurations on all
nodes
3 Customizations/Special cases - dealing with exceptions to config
files and/or applications

I see Puppet great for 1 and 2 but like any automation tool #3 is hard
to pin down and how Puppet deals with them.

My question is:
How can Puppet allow for config files that installed and updated by
Puppet, yet also allow any customizations on that specific node? ie.
the config file is edited locally by someone and Puppet should not
clobber the changes, even after puppet does an update. Is there a
method to throw an exception? ie don't update this file if the
previous version doesn't match what we had previously with Puppet.

For what we've done previously is if the application allows it store
our config info in a seperate file and not touch the main config
file. Another option I see is somehow create recipes that allow for
any customizations (within reason) via templates.

Correct me if I'm wrong but it almost sounds like Puppet should have
some method of version control on installed config files? Keeping
track of changes and roll backs? Something like this would definitely
be needed if Puppet becomes fully transactional with roll backs.

I'm not expecting puppet to be easily solve this real sysadmin issue
but seeing if there is any insight into this.

I'm curious how (if?) others have handled this with Puppet.

Thanks in advance..

-L
--
Larry Ludwig
Empowering Media
1-866-792-0489 x600
Managed and Unmanaged Xen VPSes
http://www.hostcube.com/

[David Schmitt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Run puppetd --noop. This reduces puppet to a very intelligent change tracking
mechanism. The goal has to be IMHO that a server can be setup from bare metal
+ data backups to the last running state.

> For what we've done previously is if the application allows it store
> our config info in a seperate file and not touch the main config
> file. Another option I see is somehow create recipes that allow for
> any customizations (within reason) via templates.
>
> Correct me if I'm wrong but it almost sounds like Puppet should have
> some method of version control on installed config files? Keeping
> track of changes and roll backs? Something like this would definitely
> be needed if Puppet becomes fully transactional with roll backs.
>
> I'm not expecting puppet to be easily solve this real sysadmin issue
> but seeing if there is any insight into this.
>
> I'm curious how (if?) others have handled this with Puppet.

Require all changes on the systems go through puppet.

Regards, DavidS
- --
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
- -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIAc/S/Pp1N6Uzh0URAvmjAJ99+QF/uPl6u60U2cYDJjEZk00BzwCfQBTt
PcMsfJ86EBTy30HxRNiXhDE=
=E/2U
-----END PGP SIGNATURE-----

[jtimberman]

On Apr 12, 11:16 am, Larry Ludwig <larry...@gmail.com> wrote:
>
> My question is:
> How can Puppet allow for config files that installed and updated by
> Puppet, yet also allow any customizations on that specific node? ie.
> the config file is edited locally by someone and Puppet should not
> clobber the changes, even after puppet does an update. Is there a
> method to throw an exception? ie don't update this file if the
> previous version doesn't match what we had previously with Puppet.

You might consider the "replace" parameter for file resources.

http://reductivelabs.com/trac/puppet/wiki/TypeReference#file

> Correct me if I'm wrong but it almost sounds like Puppet should have
> some method of version control on installed config files? Keeping
> track of changes and roll backs? Something like this would definitely
> be needed if Puppet becomes fully transactional with roll backs.

Puppet stores previous versions of files in the filebucket.

http://reductivelabs.com/trac/puppet/wiki/TypeReference#filebucket

We are also a CentOS/RHEL shop and we replace plenty of prepackaged
configuration files via Puppet. Generally we include a comment header
to the effect of "managed by puppet, manual changes will be removed in
30 minutes". All files and Puppet manifests are stored in an SVN
repository, so we have full version history of every file edit.

[Evan Hisey]

On Wed, Apr 16, 2008 at 9:46 AM, jtimberman <grump...@gmail.com> wrote:
>
> On Apr 12, 11:16 am, Larry Ludwig <larry...@gmail.com> wrote:
> >
> > My question is:
> > How can Puppet allow for config files that installed and updated by
> > Puppet, yet also allow any customizations on that specific node? ie.
> > the config file is edited locally by someone and Puppet should not
> > clobber the changes, even after puppet does an update. Is there a
> > method to throw an exception? ie don't update this file if the
> > previous version doesn't match what we had previously with Puppet.
>
> You might consider the "replace" parameter for file resources.
>
> http://reductivelabs.com/trac/puppet/wiki/TypeReference#file
>
>

In practice how are you using replace? The description is a bit vague
on how it actaully works or an example usage.

Evan

[Larry Ludwig]

> We are also a CentOS/RHEL shop and we replace plenty of prepackaged
> configuration files via Puppet. Generally we include a comment header
> to the effect of "managed by puppet, manual changes will be removed in
> 30 minutes".

GREAT IDEA. You know how some sysadmins are :-)

[Digant C Kasundra]

--On Wednesday, April 16, 2008 9:56 AM -0500 Evan Hisey <ehi...@gmail.com>
wrote:

>> You might consider the "replace" parameter for file resources.
>>
>> http://reductivelabs.com/trac/puppet/wiki/TypeReference#file
>>
>>
> In practice how are you using replace? The description is a bit vague
> on how it actaully works or an example usage.
>
> Evan

It would look like a normal file block with the additional replace =>
false. So the following:

file { "/my/file":
source => "/path/in/nfs/or/something",
replace => false,
}

means to create the file /my/file using the specified source only if it
doesn't exist. If the file /my/file already exists, do nothing.

[jtimberman]

On Apr 16, 8:56 am, "Evan Hisey" <ehi...@gmail.com> wrote:
>
> In practice how are you using replace? The description is a bit vague
> on how it actaully works or an example usage.

We're not actually using the replace parameter in our configuration.
I've tested it though and what Digant mentioned works.