asked on
Java & patching on Linux Redhat
I'm trying to work on a stable patching solution for RHEL, all version. One of the things I'm running into is jre patching. Generally, jre when installed is linked to /usr/bin/java. But developer sometimes install their own java version and in their or directory path, where ever that is, and call it via full path from their app. Sure enough, i want to make sure that I one, don't break an app, and 2 don't resolve a security or vulnerability issue because I didn't address all the java versions. Do you have a good way, script, something, that can help me figure out where Java is installed all over my systems, identify the version, and maybe even help upgrade said found version? I know how stupid this question might sound, but it was asked of me and I really can't come up with a clear cut solution. Please help.
LinuxUnix OSOS Security
Last Comment
gheist
ASKER
I screwed up. I was not trying to put this as a 500 point question. I'm not even sure how hard this question is. It may actually be very simple, and I would have increased the points as it got more complicated. Moderator, please reduce the point to 100 until further notice please..
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
Well, there is always the possibility of doing a locate-like thing, but this is fraught with problems... Finding the jre/java executables should be fairly trivial, and parsing the version info from a "/path/to/jre --version", but are you then to patch as that user? Or root? How are you to ascertain that the app "survives" the patch? In real life, you can't. Also, if they are devs... They likely installed the sdk (including the jre), so you'd have to differentiate that and act accordingly...
One of the reasons to absolutely hate java:-)
Cheers
--
-- Glenn
One of the reasons to absolutely hate java:-)
Cheers
--
-- Glenn
What developers install is not your problem. You cannot help
To help them you can create supported JVMs to keep catalogue patched (aka vendor-supporetd) in /usr/lib/jvm/ subdirectories (as RHEL installs them there)
To help them you can create supported JVMs to keep catalogue patched (aka vendor-supporetd) in /usr/lib/jvm/ subdirectories (as RHEL installs them there)
ASKER
It becomes my problem if I upgrade packages and it screws up an app. That's why I'm being tasked with finding a solution for something I'm not sure has a solution. Some developers have their own version of Java and set their own version location inside the app. I don't know what else to thing to do beside ask because I've never had to worry about that before.
It is merely their problem that they plant some libraries into JVM directories instead of where it is due - applications' library directory.
Given recent java security hole - you apply critical update and broken crap breaks, and you are not one to help.
Given recent java security hole - you apply critical update and broken crap breaks, and you are not one to help.
ASKER
Yeah, but I can't take that kind of approach saying it is merely their problem. I get what you are saying. I'm trying to see if there is way to do this. I don't know that there is.
they should stick with supported JVMs - 1.6 will be EOL in a month.
you are not in position to support products past their EOL... (Lawrence Elison is, but that is a different story)
why don't they require SINIX system running OpenJDK? It is from same stone age....
they should recompile their applications with 1.7, fix compilation warnings and live happy for couple of years to come.
you are not in position to support products past their EOL... (Lawrence Elison is, but that is a different story)
why don't they require SINIX system running OpenJDK? It is from same stone age....
they should recompile their applications with 1.7, fix compilation warnings and live happy for couple of years to come.
ASKER
Here is the thing. In advance, I won't know what they use in each department. All I do know is that in several departments, they had issues with Java after patching. Additionally, in my personal experience with other firms, I have seen multiple installs of Java in different locations. Especially when multiple apps run on the same server and one dev group uses an app that does not support a specific version of Java. For that reason, I'm trying to find a way to find all the different versions as java has been identified as a know issue with patching by this companies past experience.
You have following options (RHEL adds IMB JDK, SUN JDK and JROCKIT 1.6, but not centos or OEL):
java-1.7.0-openjdk
java-1.6.0-openjdk
java-1.4.2-gcj
all of them install under /usr/lib/jvm/*/
where people in need can pick them up.
you can install IBM and jrockit under that path too.
once you have your catelogue of java make a statement that openjdk 1.7 as universally available should be preferred, but any other can still be used...
java-1.7.0-openjdk
java-1.6.0-openjdk
java-1.4.2-gcj
all of them install under /usr/lib/jvm/*/
where people in need can pick them up.
you can install IBM and jrockit under that path too.
once you have your catelogue of java make a statement that openjdk 1.7 as universally available should be preferred, but any other can still be used...
ASKER
I can try that, but I'm thinking about cases I've seen in the past at other firms where multiple developers have apps installed on the same system with each app requiring a different version of Java. Because of that, they installed it in different places and placed full path for their java location in their app. I don't know that this isn't happening in the place, but it could be and I need to account for it. Especially now with all the Java vulnerabilities that have come to lite. We've just been told to run updates for java on a group of system and we are trying to find app owners to make sure this isn't the case. But as you know, alot of companies are cutting back, laying people off, and some apps are somewhat abadoned in some spaces. Hence why I posted the question.
java before latest 1.7 is FATALLY INSECURE
vendor does not support running it.
if they back old version with insurance - no problem, otherwise you or your employer are to cover losses.
vendor does not support running it.
if they back old version with insurance - no problem, otherwise you or your employer are to cover losses.