If you really don't want ongoing configuration management then Puppet
may not be your tool of choice. Cobbler perhaps?
On Tue, Dec 20, 2011 at 10:41 AM, Craig White <craig.wh...@ttiltd.com> wrote:
>
> On Dec 20, 2011, at 9:49 AM, Swampcritter wrote:
>
>> We are developing in-house RHEL VM provisioning (similar to Satellite/
>> Spacewalk) along with a customized kickstart template, but also
>> including Puppet to handle the actual configuration of the
>> environment. One thing we need to see is does Puppet have a variable
>> that will deploy one module only once and not check against it just in
>> case the configuration file it has created has been altered or not and
>> try to revert back.
>>
>> Example: Boot using PXEBoot w/ DHCP, build RHEL VM using custom
>> kickstart configuration, create local repo file with pointers to in-
>> house repository and comment out the variables to use the RHN driven
>> one, download from the repo and apply the RHN/Errata updates, then
>> reconfigure the rc.local to install Puppet on the reboot and apply the
>> actual environment requirements (i.e. check to see if its a Apache web
>> server, Oracle database, Weblogic/JBoss portal, etc).
>>
>> The last part is the deciding factor -- as this part of the
>> requirements are quite possibly going to change via the developers
>> that are actually using the environment for testing and tweaking the
>> RHEL OS memory and TCP communication needs (/etc/sysctl.conf) or the
>> Apache /etc/httpd/httpd.conf code. We don't want Puppet to revert back
>> the code variables as these are being modified by hand and not using
>> SVN or any other type of code version control at this time.
>>
>> Anyone know if module exclusion is possible for a "deploy once, don't
>> touch again" scenario?
> ----
> this sort of goes against the grain of what puppet intends but this is what I
> do for a few things... (watch out for mail driven line wrapping)
>
> class mod_puppet::deployment_files {
> exec{ "Make /etc/puppet/deployment_files":
> command => "/bin/mkdir /etc/puppet/deployment_files",
> unless => "/bin/ls -l /etc/puppet/deployment_files",
> }
> }
>
> class postfix::configure {
> include mod_puppet::deployment_files
> file{"/etc/puppet/deployment_files/postfix-main.cf":
> ensure => present,
> owner => postfix,
> group => postfix,
> mode => 0664,
> content => template("postfix/main.cf.erb"),
> require => Class["postfix::install", "mod_puppet::deployment_files"],
> notify => Class["postfix::service"],
> }
> exec{"Deploy postfix/main.cf from template":
> command => "/bin/cp /etc/postfix/main.cf /etc/postfix/main.cf-backup;
> /bin/cat /etc/puppet/deployment_files/postfix-main.cf > /etc/postfix/main.cf;
> /bin/touch /etc/puppet/deployment_files/postfix-main.cf-deployed",
> unless => "/bin/ls -l
> /etc/puppet/deployment_files/postfix-main.cf-deployed",
> require => File["/etc/puppet/deployment_files/postfix-main.cf"] ,
> }
> }
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
