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. -- 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/-/D_Y4TUGgsmQJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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. 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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.