how to add an evironment variable to puppet agent execution?

[Luca Gioppo]

I'm creating a module for the WSO2 products and the tool needs to find the JAVA_HOME that is not set.

Java get installed but than the wso2server complains about the missing JAVA_HOM.

Checked java -version in shell and it works, but as expected executing echo $JAVA_HOME returns null.

So the problem is setting the JAVA_HOME to the user (in this case root).

Tryed to append info to .bash_profile but obviously it has to be reloaded and it seems that even with this exec:
exec {
    "reload_${name}_env" :
      command => "source ~/.bash_profile",
      cwd => "/root",
      provider => 'shell',
      require => Exec["add_java_home_${name}"]
  }

the reload is not good for the step where the exec of the wso2 is done, so no way to send the new env var to the final exec.

How is possible in a easy and working way to set env vars with puppet in a way that  get known to following steps?
Thanks
Luca

[nicolas vigier]

On Wed, 16 Jan 2013, Luca Gioppo wrote:

>
> How is possible in a easy and working way to set env vars with puppet in a
> way that get known to following steps?

You can set environment variables for an exec using the environment
parameter :
http://docs.puppetlabs.com/references/latest/type.html#exec

[jcbollinger]

On Wednesday, January 16, 2013 5:19:43 AM UTC-6, Luca Gioppo wrote:

I'm creating a module for the WSO2 products and the tool needs to find the JAVA_HOME that is not set.

Java get installed but than the wso2server complains about the missing JAVA_HOM.

Checked java -version in shell and it works, but as expected executing echo $JAVA_HOME returns null.

So the problem is setting the JAVA_HOME to the user (in this case root).

Tryed to append info to .bash_profile but obviously it has to be reloaded and it seems that even with this exec:
exec {
    "reload_${name}_env" :
      command => "source ~/.bash_profile",
      cwd => "/root",
      provider => 'shell',
      require => Exec["add_java_home_${name}"]
  }

the reload is not good for the step where the exec of the wso2 is done, so no way to send the new env var to the final exec.

The Puppet agent does not normally run from a login shell, and it anyway takes care to pass a very sparse environment to commands it spawns.  Moreover, no spawned command can change its parent's environment, nor, therefore, the environment of any sibling command. Thus, manipulating the agent's environment is not the answer; instead you must declare the Exec resource properly.

The best solution is probably Nicolas's (using the 'environment' property of your Exec resource), but there are other possibilities.  For instance, perhaps the Exec's command could be a wrapper script that sets the needed environment variables.  Better, you could use the 'env' command to launch the real command with specified extra environment settings.  There might be other options as well.


John

[dimitris.s...@gmail.com]

I've been struggling with this for a while as well.

My problem is that I want a specific environment variable set for resources not managed through Exec. Specifically I need an installation path for a custom type/provider

I've tried setting variables in /etc/environment but as John points out they will not be available in the same puppet run.
Another option would be to write the path in a temp file and read it out later on, but I see this as a hack, not a clean solution.

So do we need an environment attribute for all resources? Any other ideas?

thanks in advance!

Op woensdag 16 januari 2013 17:11:52 UTC+1 schreef jcbollinger:

[Felix Frank]

A custom provider you say? You can change the provider code at will? Are
you not in control of the environment for all forked processes from this
specific provider then?

[dimitris.s...@gmail.com]

I'm not sure I understand you properly, so please clarify if that's the case.

I am in control of the environment, i.e. I can set a static path. But I'd like it to be able to set it as a parameter, in case the installation path changes.
To make a more specific case, I want my provider to know where Tomcat has been installed, but that should be specified at run time.

But I think variables such as JAVA_HOME are also required by other modules, so a more general solution to this problem should help greatly!

Op donderdag 6 februari 2014 15:35:34 UTC+1 schreef Felix.Frank:

[Felix Frank]

I see, well - this kind of problem is best tackled using custom facts I
think.

HTH,
Felix

[jcbollinger]

On Thursday, February 6, 2014 9:14:12 AM UTC-6, Felix.Frank wrote:

I see, well - this kind of problem is best tackled using custom facts I
think.

... coupled with feeding the data to your resource via a parameter or property, as appropriate.


John

[dimitris.s...@gmail.com]

I think custom facts would be fine for the case of JAVA_HOME of the OP. However, feeding data to the resource will not work for the self.instances method unfortunately.
Custom facts won't work either, as facts are only determined prior to the catalog compilation. At that point, the installation path is not yet available (I'm installing Tomcat through a package manager so I don't have control over the installation paths).

I ended up getting the desired path within the custom provider as follows:

ps_line = `ps -eaf | grep tomcat7`        
installation_path = /catalina.base=([\S]+)/.match(ps_line)[1]

This works just fine!

Anyway, thanks a lot for the quick responses, cheers

Op donderdag 6 februari 2014 23:53:18 UTC+1 schreef jcbollinger: