I think that either 1. Using the full path to the executable in the execute statement, or 2. Appending the necessary path to the PATH environment variable and passing this to the resource via the environment resource attributes are the most straightforward solution to this problem. In the end, this sounds like a bug in the cookbook that you might want to file at http://tickets.opscode.com under the COOK project.

It appears that the opscode-maintained community cookbooks for these three pieces of software have not been generalized to allow you to install any version. However, you can use these cookbooks as a starting place for installing the specific versions you need. If the version you need is contained in your linux distributions repository, you could modify the recipes of each of these cookbooks to pass the `version` resource attribute to the package resource that is installing the recipe. For more information about the package resource, see the following wiki page: http://wiki.opscode.com/display/chef/Resources#Resources-Package The above documentation has examples of using the package resource to install a specific version of software. In most cases, you will want to make the version an attribute that you pass to the resource. This allows you to change the version you need installed simply by changing an attribute. If the version you need isn't in your distributions repository, you may need to install it from source. The PHP::source recipe has a good example of how you can do this: https://github.com/opscode/cookbooks/blob/master/php/recipes/source.rb In fact, for PHP itself, you can likely install the version you need by modifying the attributes highlighted here: https://github.com/opscode/cookbooks/blob/master/php/attributes/default.rb#L44-47 If you are interested in learning more about how recipes are written in general, you might want to check out http://wiki.opscode.com/display/chef/Guide+to+Creating+A+Cookbook+and+Writing+A+Recipe

The problem you are running into is the result of how attributes are loaded during a Chef run. In order to maintain the documented attribute precedence. Attributes from roles and environments are loaded after attribute files are loaded. Thus at the time you are accessing that attribute within the attribute file, the role has not yet been loaded. We typically recommend that interactions between attributes (such as concatenation) are done inside recipes to ensure that the final attribute value is being used. However, this does sometime interfere with the most straightforward way to define your attributes. Other then moving the interaction to a recipe, it is possible to force the role and environment attributes to be evaluated using the following at the top of your attribute file: apply_expansion_attributes(expand!) However, we do not typically recommend this as it ties your recipes to an particular implementation detail of the current version of Chef (which could easily change) and since it means that you may run into situations in which your chef client run is not applying attributes with the documented precedence.