Puppet Idioms for distributing RPMs and/or buildign source tarballs?

121 views
Skip to first unread message

Michael L. Artz

unread,
Feb 23, 2009, 10:40:57 AM2/23/09
to Puppet Users
Sorry for the topic confluence, but I was wondering if there were
common puppet "idioms" for either:

- distributing an RPM to a series of clients (namely RabbitMQ) and
installing the package? I realize that I can do it naively by pulling
the file from the puppetmaster and then using the package resource to
install it via RPM, but I was wondering if there was a better way to
do this. I would love to be able to install via RPM with a URL (i.e.
rpm -Uvh http://....), but the command that actually gets executed
with puppet (something like 'rpm -i --oldpackage http://....) doesn't
seem to be idempotent, i.e. it fails after the package is already
installed. Also, I would rather not have all of my puppets calling
out to the rpm url every 2 minutes.

- distributing and compiling a tarball? Its a pretty standard
autoconf/automake tarball (i.e. './configure --prefix=/usr; make; make
install') ... is there a "standard" way to do this with puppet. I'm
also using a source-built Ruby and RubyGems, which would be nice to
manage with puppet.

I've looked through a bunch of existing modules, but I haven't seen
this sort of thing.

Thanks for any help,
-Mike

Jeremy Pruitt

unread,
Feb 23, 2009, 4:43:37 PM2/23/09
to Puppet Users
In response to your first comment, it certainly should be idempotent.
Puppet should be able to determine that the rpm is already installed,
and I believe that is just a local "rpm -q" or something. So, I don't
think it should hit the URL unless it doesn't think it's installed.
This can happen, though, when the name of the resource doesn't match
the name that "rpm -qa" returns. Perhaps you can provide the output of
one of the non-idempotent puppet runs with the --debug and --trace
options.

I also occasionally use something like this for packages that have a
different name when you install vs when you query. FreeBSD is full of
this:
http://pastie.org/397847

What's not clear to me is how to tell rpm to do an "-U" update instead
of an "-i" install. I believe I have used execs to get around this in
the past.

As far as building from source, I just create a puppet definition like
so:
http://pastie.org/397821

And I use it like this:
http://pastie.org/397827

If there is a better way out there, I'm all ears! :)

Anyways, I hope that helped in some way.

- Jeremy

Mike Renfro

unread,
Feb 23, 2009, 5:35:15 PM2/23/09
to puppet...@googlegroups.com
On 2/23/2009 9:40 AM, Michael L. Artz wrote:

> - distributing an RPM to a series of clients (namely RabbitMQ) and
> installing the package? I realize that I can do it naively by pulling
> the file from the puppetmaster and then using the package resource to
> install it via RPM, but I was wondering if there was a better way to
> do this.

Make a regular http- or ftp-accessible repository (instead of using the
puppetmaster's file distribution facility), and use one of the
higher-level rpm-based package providers with the puppet package type
(yum, aptrpm, etc.). You might also be able to do this just with rpm and
a repository (I'm Redhat-illiterate). But the important thing would be
to ensure you can check if a package is already installed before you
attempt another rpm installation. Even if you had to fall back to an

exec { "install-rabbit":
command => "rpm -Uvh http://path/to/rabbit.rpm"
}

you could make that idempotent with an unless parameter:

exec { "install-rabbit":
command => "rpm -Uvh http://path/to/rabbit.rpm",
unless => "rpm -qsomethingsomething rabbit | grep -q installed"
}

> - distributing and compiling a tarball? Its a pretty standard
> autoconf/automake tarball (i.e. './configure --prefix=/usr; make; make
> install') ... is there a "standard" way to do this with puppet. I'm
> also using a source-built Ruby and RubyGems, which would be nice to
> manage with puppet.

I use GNU stow and a stowedpackage definition:
http://blogs.cae.tntech.edu/mwr/2008/02/01/the-autostow-is-dead-long-live-stowedpackage/
-- this wouldn't exactly work for things you insist on building per
node, but could be modified. It'd be very similar to what Jeremy pointed
to in the other reply.

--
Mike Renfro / R&D Engineer, Center for Manufacturing Research,
931 372-3601 / Tennessee Technological University

Peter Meier

unread,
Feb 23, 2009, 7:45:55 PM2/23/09
to puppet...@googlegroups.com
Hi

> Make a regular http- or ftp-accessible repository (instead of using the
> puppetmaster's file distribution facility), and use one of the
> higher-level rpm-based package providers with the puppet package type
> (yum, aptrpm, etc.). You might also be able to do this just with rpm and
> a repository (I'm Redhat-illiterate). But the important thing would be
> to ensure you can check if a package is already installed before you
> attempt another rpm installation. Even if you had to fall back to an
>
> exec { "install-rabbit":
> command => "rpm -Uvh http://path/to/rabbit.rpm"
> }
>
> you could make that idempotent with an unless parameter:
>
> exec { "install-rabbit":
> command => "rpm -Uvh http://path/to/rabbit.rpm",
> unless => "rpm -qsomethingsomething rabbit | grep -q installed"
> }

package{'rabbit':
ensure => present,
source => "http://path/to/rabbit.rpm",
privater => rpm,
}

works as well.
However managing your own yum repository is easy and imho the best way
to go.

cheers pete

Jeffrey Hulten

unread,
Feb 23, 2009, 8:11:15 PM2/23/09
to puppet...@googlegroups.com
Sourcing to a HTTP address works? Since when?

Peter Meier

unread,
Feb 23, 2009, 8:14:13 PM2/23/09
to puppet...@googlegroups.com
Hi

> Sourcing to a HTTP address works? Since when?

always.

package is not file.

cheers pete

Joe McDonagh

unread,
Feb 24, 2009, 10:18:21 AM2/24/09
to puppet...@googlegroups.com
I wrote a definition when I first started to use puppet for a
source_package that puts it under /usr/src then subsequently builds it
based on a string of cfg_opts and make_opts, and uses onlyif to serve
out and execute the build based on a test or two... it's a little hairy
and usually best to distribute things through the distro's PM, but I
wanted to do it as an academic exercise more than anything. I can try to
unearth it if you express interest.
Reply all
Reply to author
Forward
0 new messages