On Thursday, 8 March 2012 15:38:57 UTC+1, jcbollinger wrote: > > > > On Mar 7, 10:24 am, Bob Rontomskin <rontoms...@gmail.com> wrote: > > 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. > > > 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. >
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. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/UViAFhG-0_wJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
