Do I need a fact for this?

[Bob Rontomskin]

Hello group,

I have a Tomcat class which takes a java package name as a parameter.
The parameter looks like openjdk-1.2.3 or sunjava-2.3.4. The purpose of the parameter is that it sets a configuration option in the Tomcat configuration to tell it which java binary to use.
I need to determine which java binary to use by running the following command:
 rpm -ql PKGNAME | grep 'bin/java$'
This seems inefficient, and I don't want to run this every time, only when the java package name changes.

Is this even possible? Many thanks.

Caveats: if the java package is already installed (i.e. not by puppet) the Tomcat config must still be correct (i.e. I don't think a subscribe would work). If the java package changes, the Tomcat config must be updated.

[jcbollinger]

If Puppet is not managing the Java package, then how is it supposed to
know when the package name or version changes except by inquiring of
the system? With all the constraints you have set, I don't see any
alternative to running a command such as the one you specified during
every Puppet run. If you indeed pursue that general direction then I
would recommend wrapping the command into a custom fact.

HOWEVER, be it known that you are engaging in a Puppet antipattern.
It is better for Puppet to know how a node *should* be configured and
to make it so, than to adapt to node configuration details managed by
some other entity. In particular, it seems horribly backwards to say
that Puppet needs to know the name of some installed package while
denying it the ability to manage that package.

Additionally, your particular solution to identifying the Java binary
seems strange. Linux systems with which I work all employ the
"alternatives" facility to make such issues transparent to ordinary
users and services. That allows, for example, one of possibly many
installed Java runtimes to be elected as the default, to be run as /
usr/bin/java. That is normally handled for you automatically via
package scripts, but you can use 'alternatives' manually, too. Are
you sure you aren't making needless work for yourself?


John

[Bob Rontomskin]

Excellent points, thanks.

Additionally, your particular solution to identifying the Java binary
seems strange.  Linux systems with which I work all employ the
"alternatives" facility to make such issues transparent to ordinary
users and services.  That allows, for example, one of possibly many
installed Java runtimes to be elected as the default, to be run as /
usr/bin/java.  That is normally handled for you automatically via
package scripts, but you can use 'alternatives' manually, too.  Are
you sure you aren't making needless work for yourself?

We musnt't change the system java version, just the version for Tomcat. We could set up a java-tomcat alternatives and use that. I'll see whether it works in our setup with changes as a result of your suggestion above.
 

John

 
Thanks.