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.
teckwiz01Asked:
Who is Participating?
 
jlevieConnect With a Mentor Commented:
If you don't have control over where Jave/Jre is installed, you have no hope of implementing any patch strategy.

Note that this is an administrative problem, not a technical problem.
0
 
teckwiz01Author Commented:
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..
0
 
GnsCommented:
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
0
Improved Protection from Phishing Attacks

WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!

 
gheistCommented:
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)
0
 
teckwiz01Author Commented:
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.
0
 
gheistCommented:
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.
0
 
teckwiz01Author Commented:
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.
0
 
gheistCommented:
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.
0
 
teckwiz01Author Commented:
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.
0
 
gheistCommented:
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...
0
 
teckwiz01Author Commented:
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.
0
 
gheistCommented:
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.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.