Puppet users - Oct 2008 - Install configs initially then stop managing those files

Hello All,
 I am trying to build up some dev boxes. These boxes are obviously
very different from our other production/QA environments.

 I have a need to allow developers to configure certain config files
such as httpd.conf. What I need to do is have puppet push out the
config file at installation and then allow the dev users to configure
it there after.

 Does anyone have a suggestion on how to implement this?
Thank you very much for your time!
-Tom
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Hi Everyone,
 I found the previous query
http://groups.google.com/group/puppet-users/browse_thread/thread/673c7ed71fe51564/896a4e46f3438930?lnk=gst&q=config+#896a4e46f3438930
dealing with the very same issue.

 The folks that replied to the message said to use the replace
parameter. i.e.

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

 I would need to replace it initially at installation time, but then
stop "replacement" afterward.

 Does anyone have a suggestion on implementing this?

 Thanks a lot!
-Tom

On Oct 21, 4:49 pm, TomTom <mcgona...@gmail.com>
wrote:
> Hello All,
>  I am trying to build up some dev boxes. These boxes are obviously
> very different from our other production/QA environments.
>
>  I have a need to allow developers to configure certain config files
> such as httpd.conf. What I need to do is have puppet push out the
> config file at installation and then allow the dev users to configure
> it there after.
>
>  Does anyone have a suggestion on how to implement this?
> Thank you very much for your time!
> -Tom
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

TomTom writes:
 > 
 > Hello All,
 >  I am trying to build up some dev boxes. These boxes are obviously
 > very different from our other production/QA environments.
 > 
 >  I have a need to allow developers to configure certain config files
 > such as httpd.conf. What I need to do is have puppet push out the
 > config file at installation and then allow the dev users to configure
 > it there after.
 > 
 >  Does anyone have a suggestion on how to implement this?

If you''re not going to use Puppet for ongoing management of a file,
there''s probably not much point to using Puppet to install the file in
the first place.

There are potentially a number of good arguments you could use to
encourage your developers to also use Puppet and version control
software as part of their development process.

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Manage the file from source control, make the developers edit the file in
the repo and let puppet replace it.

You get an added bonus for change management, the file is already/always
under source control.

If you really really really need to have developers changing httpd.conf so
much that puppet would add significant overhead, I would probably just run
puppet once to put things in a known state, then turn it off.  Turn the devs
loose and when the experiment is over rebuild to the known state. Of course,
you need some way to handle promoting changes, both towards QA/Production,
and back into the base dev builds.

Does that make sense?



On Tue, Oct 21, 2008 at 3:06 PM, TomTom <mcgonagle@gmail.com> wrote:
>
> Hi Everyone,
>  I found the previous query
>
>
http://groups.google.com/group/puppet-users/browse_thread/thread/673c7ed71fe51564/896a4e46f3438930?lnk=gst&q=config+#896a4e46f3438930
> dealing with the very same issue.
>
>  The folks that replied to the message said to use the replace
> parameter. i.e.
>
> file { "/my/file":
>    source  => "/path/in/nfs/or/something",
>    replace => false,
> }
>
>  I would need to replace it initially at installation time, but then
> stop "replacement" afterward.
>
>  Does anyone have a suggestion on implementing this?
>
>  Thanks a lot!
> -Tom
>
> On Oct 21, 4:49 pm, TomTom <mcgona...@gmail.com> wrote:
> > Hello All,
> >  I am trying to build up some dev boxes. These boxes are obviously
> > very different from our other production/QA environments.
> >
> >  I have a need to allow developers to configure certain config files
> > such as httpd.conf. What I need to do is have puppet push out the
> > config file at installation and then allow the dev users to configure
> > it there after.
> >
> >  Does anyone have a suggestion on how to implement this?
> > Thank you very much for your time!
> > -Tom
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

I think you need a better definition of "dev".  Are these machines
that sysadmins will be using to develop files that will eventually be
deployed with puppet?  Or are these machines that you, as a sysadmin,
are providing to a team of developers who perform application
development?

If the former, then puppet probably shouldn''t manage that file and you
should keep it in source control.  If the latter, then puppet probably
shouldn''t manage the file, but the developers should keep it in source
control and deploy it as part of their software deployment plan when
doing a release.

Too often we refer to systems as "dev", when really from a sysadmin
point of view they are production.  Just because a developer is using
them, it doesn''t mean they can go down on a whim.  That''s what
"dev"
means from the sysadmin side.


On Tue, Oct 21, 2008 at 4:49 PM, TomTom <mcgonagle@gmail.com>
wrote:
>
> Hello All,
>  I am trying to build up some dev boxes. These boxes are obviously
> very different from our other production/QA environments.
>
>  I have a need to allow developers to configure certain config files
> such as httpd.conf. What I need to do is have puppet push out the
> config file at installation and then allow the dev users to configure
> it there after.
>
>  Does anyone have a suggestion on how to implement this?
> Thank you very much for your time!
> -Tom
>
--~--~---------~--~----~------------~-------~--~----~
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 Tue, Oct 21, 2008 at 2:06 PM, TomTom <mcgonagle@gmail.com>
wrote:
>  The folks that replied to the message said to use the replace
> parameter. i.e.
>
> file { "/my/file":
>    source  => "/path/in/nfs/or/something",
>    replace => false,
> }
>
>  I would need to replace it initially at installation time, but then
> stop "replacement" afterward.
>
>  Does anyone have a suggestion on implementing this?
You need to have two classes for your dev systems.  The first gets
applied once, at build time, say "developer-defaults".  Once the
system is laid down, just remove that class from the workstation -
that way, moving forward, it will no longer attempt to manage those
files.

This also gives you the benefit of being able to go back to defaults
on a workstation just by changing the classes applied to the node.

Regards,
Adam

-- 
HJK Solutions - We Launch Startups - http://www.hjksolutions.com
Adam Jacob, Senior Partner
T: (206) 508-4759 E: adam@hjksolutions.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
-~----------~----~----~----~------~----~------~--~---