On Jan 20, 4:34 am, Alessandro Franceschi <a...@lab42.it> wrote:
> I add my 2 cents.
> The alternatives proposed in the replies are ok for me, just would like to
> express an alternative approach that I''ve used in some situations.
> It's due to different factors:
> - Many packages to manage (but not necessarily)
> - Option to include a module in an existing module set, where you don't
> know if and how the packages you want to use are already defined as
> resources.
> - The fact that these packages generally don't need extra management
> (service or configuration files) and they do not harm if they are just
> installed and "forgotten"
> So the approach is to install them not as Puppet resources but via an exec:
>
> class oracle::packages {
>
> require oracle::params
>
> file { "install_oracle_dependency.sh":
> mode => 750, owner => root, group => root,
> content => $operatingsystem ? {
> centos => template("oracle/install_oracle_dependency.sh-redhat"),
> redhat => template("oracle/install_oracle_dependency.sh-redhat"),
> debian => template("oracle/install_oracle_dependency.sh-debian"),
> ubuntu => template("oracle/install_oracle_dependency.sh-debian"),
> suse => template("oracle/install_oracle_dependency.sh-suse"),
> },
> path => "${oracle::params::workdir}/install_oracle_dependency.sh",
> }
>
> exec { "install_oracle_dependency.sh":
> subscribe => File["install_oracle_dependency.sh"],
> refreshonly => true,
> timeout => 3600,
> command =>
> "${oracle::params::workdir}/install_oracle_dependency.sh",
> }
>
> }
>
> where the template install_oracle_dependency.sh-redhat is something like
>
> #!/bin/sh
> # File Managed by Puppet
> # Installs the packages required for installing Oracle applications
> <% if $architecture=="i386" %>
> yum install -y binutils compat-db compat-libstdc++ compat-libstdc++-33
> elfutils-libelf elfutils-libelf-devel elfutils-libelf-devel-static gcc
> gcc-c++ glibc glibc-common glibc-devel glibc-headers kernel-headers ksh
> libaio libaio-devel libgcc libgomp libstdc++ libstdc++-devel make
> numactl-devel pdksh sysstat unixODBC unixODBC-devel
> yum groupinstall -y "X Window System"
> <% else %>
> yum install -y binutils compat-db compat-libstdc++ compat-libstdc++.i386
> compat-libstdc++-33 compat-libstdc++-33.i386 elfutils-libelf
> elfutils-libelf-devel elfutils-libelf-devel-static gcc gcc-c++ glibc
> glibc.i386 glibc-common glibc-devel glibc-devel.i386 glibc-headers
> kernel-headers ksh libaio libaio.i386 libaio-devel libaio-devel.i386 libgcc
> libgcc.i386 libgomp libstdc++ libstdc++.i386 libstdc++-devel make
> numactl-devel pdksh sysstat unixODBC unixODBC.i386 unixODBC-devel.i386
> yum groupinstall -y "X Window System"
> <% end %>
>
> Opinions on this approach?
1) Many of the packages you mention are pretty fundamental. If you
want to manage them then it would be better to group them into a
module for your standard environment, instead of allowing various
other modules to manage them.
2) It would be better to let the package management system handle
finding and installing depenencies. Where the software you want to
install is not available pre-packaged and cannot easily be packaged
locally, it would still be better to build a requirements-only package
(e.g. "oracle-dependencies") and manage that.
3) If you want to name the packages explicitly in your Puppet
configuration, then it would be better to declare them in some central
place as virtual Package resources. Modules that want them would then
*realize* them instead of declaring them. It is not a problem for a
virtual resource to be realized many times for the same node.
John
--
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.
