Puppet users - Apr 2008 - Best Practice: How you handle config files?

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/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

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

On Saturday 12 April 2008, Larry Ludwig wrote:
> 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.
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-----

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

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.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Wed, Apr 16, 2008 at 9:46 AM, jtimberman <grumpysmurf@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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

>  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 :-)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

--On Wednesday, April 16, 2008 9:56 AM -0500 Evan Hisey <ehisey@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.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

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.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---