[chef] Re: Re: JDK RPM Install Error

[Bryan Berry < >]

I revised the java cookbook to handle all of Oracle's naming nonsense. You may find it useful

https://github.com/bryanwb/cookbooks/tree/master/java 

recipe[java::oracle]   will install from the binaries (not the rpm) to /usr/lib/jvm/  and update the /usr/bin/java to point to the java binary command in the jdk

it installs update 30 by default and also supports oracle's jdk 7, openjdk6, and openjdk7

On Thu, Jan 26, 2012 at 12:08 AM, mandi walls < "> > wrote:

Howdy

I have seen that same problem, with that same version of the java rpms. In our case it ended up being that the metadata didn't match the filename:

The RPM's internal "Name" tag is different from the filename, so the rpmdb knows it as "jdk-1.6.0_23-fcs.x86_64", which is not the filename. The chef yum provider, iirc, is looking in the RPM database for the package using a parse of the filename, so it looks like "jdk-6u23-linux-x64" isn't installed.  They're not even similar enough to assume that "jdk-1.6.0_23-fcs" and "jdk-6u23" are the same; the "fcs" can't be assumed to be insignificant.

So Chef tries to install it, and when RPM gets a look at the file, it reads the internal "Name" from the metadata and errors out with the "already installed" message.

On the machines that are throwing that error, you should see the jdk package already installed if you query the rpmdb. If you use "yum install /path/to/filename" rather than the "localinstall" subcommand to yum, you should get a line that starts with "Examining /path/to/filename: package.x86_64" that will tell you what the package actually contains. I don't know why "localinstall" suppresses that information.

I fixed this on our systems at the time by changing the name of the rpm in our yum repos to match what the rpm had in its metadata as the package name, "jdk-1.6.0_23-fcs.x86_64.rpm".  If you're downloading to local cache on your systems, that might be a quick fix for you, too. I didn't do any lengthy research into wtf had happened there, so I don't know if there was some reason upstream or it was just sloppiness.

HTH,
--mandi

On Wed, Jan 25, 2012 at 5:07 PM, < " target="_blank"> > wrote:

I have written a simple cookbook to install Sun's JDK via RPM. Once in a while
I get support questions about it failing during the install process of the
package.

The error is,

{
FATAL: Chef::Exceptions::Exec: package[jdk-6u23-linux-x64.rpm]
(sun_java::default line 23) had an error: yum -d0 -e0 -y --nogpgcheck
localinstall /var/cache/chef/jdk-6u23-linux-x64.rpm returned 1, expected 0
}

When they run the command they see,

{
yum -d0 -e0 -y --nogpgcheck localinstall /var/cache/chef/jdk-6u23-linux-x64.rpm
This system is not registered with RHN.
RHN support will be disabled.

Transaction Check Error:
 package jdk-1.6.0_23-fcs.x86_64 is already installed
}

Which is actually the same exact package they are trying to install. I am
guessing this is an issue with the build/packaging of the rpms being different.

Has anyone seen this or have any ideas how to fix/avoid this? The easiest
option I could think of is to add a 'not_if' option to the package and to grep
the output of 'java -version' for the correct version, but I don't like that
idea since the package resource should handle it.

Here is the resource in question,

{
package javaRPM do
 action :install
 source "#{Chef::Config[:file_cache_path]}/#{javaRPM}"
 options "--nogpgcheck" # sun/oracle doesn't sign their RPMs o_O
 notifies :run, "bash[update-alternatives java]", :immediately
end
}