On Friday, March 3, 2017 at 8:31:00 AM UTC-5, Michael Watters wrote:
>
> This would be the ideal but you *can* use the rpm provider when needed. 
>  For example:
>
> package { 'jdk':
>     ensure  => installed,
>     provider => 'rpm',
>     source  => '/pub/oracle/jdk-8-linux-x64.rpm',
> }
>
>
> This will install the rpm using the defined source path.  In our 
> environment the /pub directory is available to all nodes via nfs
>

But it won't handle a number of issues in the original post-- RPM 'a' 
before 'b', and invoke script 'c' once packages a and b are installed.  Of 
course, you can do that with a number of puppet metaparameters.

I agree with everyone else that the "Right Way" is to create a yum repo, 
and install the packages via the package provider.  You can use notify / 
subscribe to control sequencing, or use the chaining arrows.

However, a long time ago, I solved this problem the wrong way-- and if 
you're going to do it the wrong way, you should at least do it right.  ;)

My original use was installing 2 .rpm or .deb files (depending on OS), 
without storing binaries in my git repo (the amount of pain it took to 
excise the vmware-tools installer out of my git repo was... enlightening. 
 If wisdom comes from making mistakes, I could compete with Solomon).  I 
had a second use case of a set of lab workstations installing an arbitrary 
number of RPM files containing various custom software applications, and 
that turned out to be something I'm still using this method for today.

I created a second "mount point" in puppet via fileserver.conf, pointing to 
a location outside the puppet git tree, so I could use 
"puppet:///downloads/<directory>" as a source, synchronized that directory 
to a local directory on the workstation using "ensure => directory", 
"recurse => true", and "purge => true", then had that resource notify an 
exec of "yum install -y *rpm"-- because yum will automatically handle 
dependencies, sequence, and upgrades.

Then any time you drop a new rpm into the directory on the puppet server, 
the client automatically downloads and installs and/or upgrades the 
packages.

Not the "Right Way", no, but it does work, and takes less work to add new 
packages (my way, drop new RPM in location accessible only by puppet-- 
yum/package way, add package to http:// accessible repo, update repo 
metadata, and (if needed) add package to node catalog if it's a new package 
vs. an upgraded existing package).

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/12e5a418-cce9-4a1d-b39b-139a9b2859ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to