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.
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
> 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.
> - 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
> - 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.
> 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
On Mon, Feb 23, 2009 at 4:45 PM, Peter Meier <peter.me...@immerda.ch> wrote:
> 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
Jeremy Pruitt wrote:
> 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
> If there is a better way out there, I'm all ears! :)
> Anyways, I hope that helped in some way.
> - Jeremy
> On Feb 23, 7:40 am, "Michael L. Artz" <mla...@gmail.com> wrote:
>> 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
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.