Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We're in the process of researching a configuration/systems management implementation and we've done quite a lot of demoing of Puppet. Puppet seems to excel at the somewhat simple "ensure this package is installed, this config file exists, and that this service is running."

I can't seem to find a good real world example of managing software that doesn't play so nicely. Some examples:

  • IBM DB2 (distributed via tarball with installer, "fixpacks" are similiar)
  • Simpana CommVault (uses an installer with an ncurses interface, but will accept an "answer" file if coaxed)
  • AccuRev (binary installer, with "answer" file support)
  • VMWare Tools (binary installer)

What approach have Puppet users taken to integrate software like this into their environments?

share|improve this question
VMware tools can be taken off the list as VMware now provides a YUM repository allowing the packages to be managed using the platforms tools. – mtinberg Jun 29 '11 at 18:03
mtinberg: Are you referring to open-vm-tools? – Kyle Smith Jun 29 '11 at 21:46
No, I am talking about the VMware managed YUM repos at – mtinberg Jul 5 '11 at 20:59
@mtinberg - Good info, thanks for that! – Kyle Smith Jul 6 '11 at 4:17
up vote 5 down vote accepted

I maintain a server with locally created files, and make .deb or .rpm packages for such softwares myself.

In a few cases where I haven't bothered to do anything about it, I do an exec wget to download the file, and an exec with the extraction method, whatever it may be, with the creates attribute pointing to the main binary. It won't handle updates, however.

To handle update, make the installation exec a refreshonly => true, and put a notify on the exec for wget.


exec { "/usr/bin/wget http://fileserver.domain/jboss/jboss-${version}.prd.tar.gz -O /tmp/jboss.tgz":
    creates => '/tmp/jboss.tgz',
    require => Package['wget'],
    alias   => 'wget_jboss',

exec { '/bin/tar xzvf /tmp/jboss.tgz':
    cwd     => '/opt',
    creates => "/opt/jboss-${version}/bin",
    user    => 'jboss',
    group   => 'jboss',
    require => [ User['jboss'], Exec['wget_jboss'], File["/opt/jboss-${version}"], ],
    before  => Service['jboss'],
    alias   => 'untar_jboss',
share|improve this answer
I like the custom package suggestion, +1. – Shane Madden Jun 29 '11 at 22:07
I also like custom packages but getting Puppet into place is the priority, and tuning it in the future to handle our internal software distribution in a (more?) sane manner is just going to slow the project down. Still reading this answer trying to understand how this works. You probably have a green checkmark incoming shortly. – Kyle Smith Jun 30 '11 at 14:29

The exec resource is kinda the catch-all for managing anything that doesn't fit nicely into one of the other package types.

If you can get something to go unattended on the command line, and you can check for a file's existence to confirm the installation, then you should be able to get puppet to handle it.

One of your examples, VMware Tools, has a module on the puppet module forge site, here. As you can see from the init.pp file (here), the install process is done mainly via exec resources.

share|improve this answer

Well, you could just run installed on one machine and place installed files to tar/rpm/deb. Of course, sometimes it won't be easy.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.