JRendell <juliangrend...@gmail.com> writes:
> sorry if this is an obvious question, but I'm trying to evaluate
> puppet on paper before we commit to an experimental deployment.
> Aside: We're using Centos 5.4, so this is RPM/yum specific.
>
> How are updated RPMs in a manifest detected on the puppetmaster side?
They are not: the puppetmaster compiles a configuration that includes
instructions (that you write) like "install version N of package M", or
"install the latest version of package M".
The client then runs, and uses yum to carry out those instructions.
> What we are trying to achieve:
> Set up a puppetmaster with multiple environments <- documentation is
> clear on this/can find examples.
> Each environment will specify a base set of required applications,
> varied by machine type <- mostly understood/can find examples.
> Configuration files will be pushed from the puppetmaster to puppet
> clients, when a difference in md5 is detected <- understood.
Not quite: the client *pulls* the configuration from puppetmaster, rather than
the puppetmaster pushing. The practical difference is small, but since you
are not the first person to have that confusion...
> We also want to be able to push updates to our custom (application
> executable code) RPMs in a controlled way. How does the puppetmaster
> determine the version of an rpm source file?
It doesn't; the client does, and it does that by passing the version you
specify to yum, or asking yum to define "latest" appropriately.
This is, not coincidentally, exactly what would happen if you entered the same
yum commands on the client by hand...
[...]
> Guess at a puppet module:
>
> package { our_app_part1:
> source =>
> http://our_file_repo/env_xx/release_yy/our_app_part1_ver##_rel##.noarch.rpm,
> ensure => ver##_rel##.noarch,
> require => [Package[list, of, needed, packages],
> Files[our_app1_config, ...]]
> }
# If you use the YUM provider...
package { "our_app_part_1": ensure => 'specific-version-number' }
# ...and whatever configuration is needed for yum to find the repository that
# contains your RPM better be in puppet too. :)
> # Is the subscribe line below needed to ensure the config file is
> (re)deployed if the package is (re)installed?
> file { "/etc/our_app1.config":
> source => "puppet://server/module/our_app1.config",
> require => [Package[our_app_part1_ver##_rel##.noarch.rpm]],
> subscribe => [Package[our_app_part1]]
> }
No: puppet doesn't "act once, then ignore changes", it acts every time it
runs. If you say "the source of this file is XXX", every time puppet runs it
will check if the configuration file *is* identical to XXX, and replace it if
not.
> exec { "/etc/init.d/our_app restart":
> path => ["/usr/bin", "/usr/sbin"],
> subscribe => File["/etc/our_app1.config"],
> refreshonly => true
> }
service { "our_app": ensure => running, enable => true ... }
That knows about starting applications the platform way (eg: service foo
start), which is what you want to use.
[...]
> exec { "chkconfig our_app on":
> path => ["/usr/bin", "/usr/sbin"],
> subscribe => ?????,
> refreshonly => true
> }
It does this too. :)
Daniel
Hint: if you find yourself using 'exec' something may well have gone wrong. :)
--
✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +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 puppet-us...@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.
