Multiple execs within a class

[Mike Reed]

Hello all,

I'm looking to run multiple commands via exec within a single class like so:

class boost_install {
        # This will place the gzip locally in /tmp.  File is pulled from puppet.
        file { "/tmp/boost_1_41_0.tar.bz2" :
                source  => "puppet:///boost_install/boost_1_41_0.tar.bz2" ,
                ensure  => present ,
        }

        # This will extract the boost gzip to the /tmp directory.
        # This will untar only if the /tmp/boost_1_41_0 directory does not exist.
        exec { "tar -xjvf /tmp/boost_1_41_0.tar.bz2" :
                cwd     => "/tmp/" ,
                creates => "/tmp/boost_1_41_0" ,
                path    => ["/bin" , "/usr/sbin"] ,
        }

        # This will run the boost bootstrapper. bjam should be run after this.
        # This will only run if the ls command returns a 1.
        # The unless will have to be redone because we have no way of upgrading easily and this is sloppy.
        exec    { "/tmp/boost_1_41_0/bootstrap.sh" :
                unless  => 'ls /usr/local/include/boost' ,
                path    => ["/bin/" , "/sbin/" , "/usr/bin/" , "/usr/sbin/"] ,
        }

        # This will run the boost bjam modifier and should run only after the bootstrap.sh has been run
        # This will only run if the ls command returns a 1.
        # This unless  will have to be redone because we have no way of upgrading easily and this is sloppy.
        exec { "/tmp/boost_1_41_0/bjam cxxflags=-fPIC install" :
                unless  => 'ls /usr/local/include/boost' ,
                path    => ["/bin/" , "/sbin/" , "/usr/bin/" , "/usr/sbin/"]  ,
        }
}

However, after running the above class, I get the following:

err: /Stage[main]/Boost_install/Exec[/tmp/boost_1_41_0/bootstrap.sh]/returns: change from notrun to 0 failed: /tmp/boost_1_41_0/bootstrap.sh returned 1 instead of one of [0] at /etc/puppet/modules/boost_install/manifests/init.pp:18
err: /Stage[main]/Boost_install/Exec[/tmp/boost_1_41_0/bjam cxxflags=-fPIC install]/returns: change from notrun to 0 failed: /tmp/boost_1_41_0/bjam cxxflags=-fPIC install returned 1 instead of one of [0] at /etc/puppet/modules/boost_install/manifests/init.pp:21
notice: Finished catalog run in 1.31 seconds

I was under the impression that I should be getting the "install returned 1" output but it's usually silent and the command doesn't run.  I'm assuming that neither the bootstrap or bjam commands should run as the /usr/local/include/boost directories exist on the machine and I'm expecting the "ls" to return a 0; which it does on the machine because those directories exist.

I'm obviously missing something here and I'm looking for some direction.

I do suspect that this can be done in a more elegant fashion especially since the bjam command is dependent upon the bootstrap.sh script running but I was hoping to at least get this working.

Thanks in advance for the thoughts.

Cheers,

Mike

[Peter Bukowinski]

Puppet manifests do not run in a top-down manner, but instead run semi-randomly. Because your file and exec resources need to run in a specific order, you need to define that order specifically. You can accomplish this by keeping the order you have and simply adding a 'require' parameter to each that points to the previous resource.

Even better would be to convert the entire thing into a single package/rpm that you keep in a repository and have puppet install it with a single 'package' resource.

--
Peter Bukowinski

[jcbollinger]

On Friday, July 6, 2012 6:52:01 AM UTC-5, pmbuko wrote:

Puppet manifests do not run in a top-down manner, but instead run semi-randomly. Because your file and exec resources need to run in a specific order, you need to define that order specifically. You can accomplish this by keeping the order you have and simply adding a 'require' parameter to each that points to the previous resource.

Right.
 

Even better would be to convert the entire thing into a single package/rpm that you keep in a repository and have puppet install it with a single 'package' resource.

+1

In fact, boost packages in particular are available pre-built for many systems, so you might not even need to build one.

Packages are far better not only for convenience, but as an administrative best practice.  With very few exceptions, I do not install unpackaged software on my systems.  I do build a fair number of packages, however.


John

[Mike Reed]

Hey Guys,

Thank you Peter and John for your continued input into this one.   I absolutely agree with both of you about building our own packages and as I've been working with puppet and trying to configure these systems, it's become apparent that our own internal repository would be beneficial for a number of reasons.

With that said, I'm quite new to the 'nix world and I suspect building out packages/repository would take a little time and probably a few days of googl'in.  So for the very immediate future, I'd like to get this working so I can get our initial puppet build going.  packages/repository are definitely on my list tho.

I'd like to quickly mention that the impetus behind this is that I'd like to run this against machines that we've built up without puppet and if possible, I'd like to refrain from things like the below manifest being run on a machine which already has boost installed, albeit manually without puppet.

I changed the class to the following:

class boost_install {
        # This will place the gzip locally in /tmp.  File is pulled from puppet.
        file { "/tmp/boost_1_41_0.tar.bz2" :
                source  => "puppet:///boost_install/boost_1_41_0.tar.bz2" ,
                ensure  => present ,
        }

        # This will extract the boost gzip to the /tmp directory.

        exec { "untar_boost" :
                command => "tar -xjvf /tmp/boost_1_41_0.tar.bz2" ,

                cwd     => "/tmp/" ,
                creates => "/tmp/boost_1_41_0" ,
                path    => ["/bin" , "/usr/sbin"] ,

                require => File["/tmp/boost_1_41_0.tar.bz2"] ,

        }

        # This will run the boost bootstrapper

        exec { "/tmp/boost_1_41_0/bootstrap.sh" :
                subscribe => Exec["untar_boost"] ,
        }
}

From the above code, I expect a few things to happen:
1. The exec "untar_boost" should only fire if "/tmp/boost_1_41_0.tar.bz2" is present
2. The exec "/tmp/boost_1_41_0/bootstrap.sh" should only fire if the untar boost occurs, which I believe is dependent upon the file being in that location.  (I'm thinking this will work as a temporary dependency as I'm not sure how to make a dependency for the initial file being pulled down.  In other words, I expect the file to be pulled down on every run which I guess is something I'll have to fix later).  I'm thinking if I change from /tmp to something like /usr/src/puppet_pkgs then the files won't be deleted upon reboot and I can use them as a temporary placeholder until I figure out a more elegant solution to this hack that I've put together.

I'm sorry for writing the novel above and I very much appreciate your help and support on this one.

Cheers,

Mike

[Peter Bukowinski]

On Jul 6, 2012, at 3:26 PM, Mike Reed wrote:

Hey Guys,

Thank you Peter and John for your continued input into this one.   I absolutely agree with both of you about building our own packages and as I've been working with puppet and trying to configure these systems, it's become apparent that our own internal repository would be beneficial for a number of reasons.

With that said, I'm quite new to the 'nix world and I suspect building out packages/repository would take a little time and probably a few days of googl'in.  So for the very immediate future, I'd like to get this working so I can get our initial puppet build going.  packages/repository are definitely on my list tho.

I get need to prioritize your to-do list, but do it sooner rather than later. :)

I'd like to quickly mention that the impetus behind this is that I'd like to run this against machines that we've built up without puppet and if possible, I'd like to refrain from things like the below manifest being run on a machine which already has boost installed, albeit manually without puppet.

I changed the class to the following:

class boost_install {
        # This will place the gzip locally in /tmp.  File is pulled from puppet.
        file { "/tmp/boost_1_41_0.tar.bz2" :
                source  => "puppet:///boost_install/boost_1_41_0.tar.bz2" ,
                ensure  => present ,
        }

        # This will extract the boost gzip to the /tmp directory.
        exec { "untar_boost" :
                command => "tar -xjvf /tmp/boost_1_41_0.tar.bz2" ,
                cwd     => "/tmp/" ,
                creates => "/tmp/boost_1_41_0" ,
                path    => ["/bin" , "/usr/sbin"] ,
                require => File["/tmp/boost_1_41_0.tar.bz2"] ,
        }

        # This will run the boost bootstrapper
        exec { "/tmp/boost_1_41_0/bootstrap.sh" :
                subscribe => Exec["untar_boost"] ,
        }
}

From the above code, I expect a few things to happen:
1. The exec "untar_boost" should only fire if "/tmp/boost_1_41_0.tar.bz2" is present

Correct, and because of your 'creates' parameter, it won't run again on consecutive runs.

2. The exec "/tmp/boost_1_41_0/bootstrap.sh" should only fire if the untar boost occurs, which I believe is dependent upon the file being in that location.

Correct.

(I'm thinking this will work as a temporary dependency as I'm not sure how to make a dependency for the initial file being pulled down.  In other words, I expect the file to be pulled down on every run which I guess is something I'll have to fix later).  I'm thinking if I change from /tmp to something like /usr/src/puppet_pkgs then the files won't be deleted upon reboot and I can use them as a temporary placeholder until I figure out a more elegant solution to this hack that I've put together.

The file won't be pulled down on every run unless is gets removed from /tmp. Because you can't count on files sticking around in /tmp, I don't like to use it as a destination for any of my file resources. Your /usr/src/puppet_pkgs idea is a good one -- at least until you start packaging your software deployments. I recommend putting "start using fpm" on your to-do list, as well: https://github.com/jordansissel/fpm/ -- It's a huge time-saver and makes package creation dead-simple.

--

Peter Bukowinski

[Felix Frank]

Hi,

sorry for the late nitpicking.

On 07/06/2012 10:54 PM, Peter Bukowinski wrote:
> # This will run the boost bootstrapper
> exec { "/tmp/boost_1_41_0/bootstrap.sh" :
> subscribe => Exec["untar_boost"] ,
> }

>> 2. The exec "/tmp/boost_1_41_0/bootstrap.sh" should only fire if the
>> untar boost occurs, which I believe is dependent upon the file being
>> in that location.
>
> Correct.

...not. Unless I'm mistaken :)

Yes, the exec does consume events from the untar exec. However, there is
no configuration that tells the bootstrap *not* to run in the absence of
such an event.

What I'm getting at is the missing 'refreshonly => true' parameter.

HTH,
Felix