How can we update Java, but leave a specific older version also installed?
Not really a Kace specific question, but Kace is our method of deployment so I'm hoping others may have addressed a similar issue.
We have a number of internal apps in our large teired organization. A couple apps require a specific version of Java. Though it's a different version for each app. To meet security requirements, we need to update Java, but for the apps to work, we need to keep the older versions installed.
At the moment, we have 2 apps requiring different specific Java versions.
Even if we can name the required versions that should remain installed, how can we deploy the Java updates so it doesn't overwrite the existing Java install?
Answers (3)
While I would agree with the security issues mentioned above, this can be done by using the
STATIC=1
flag on your installs. It installs java in static mode, which means that future versions of the software will not upgrade, but instead install next to the static version. More information about static installations can be found here:
http://docs.oracle.com/javase/7/docs/webnotes/install/windows/jre-installer-options.html
Comments:
-
Wow, I did not know that trick. - darkhawktman 11 years ago
-
Thanks. Yea. I was reading a lot about static mode yesterday. I'm creating a couple installs to test right now actually. My concern is some references to recompiling the applications that are Java version dependent to point to the correct directory for their specific Java version. I defer to those who have far more Java knowledge than me, but I need to know if this is necessary.
If we use static=1 and a new version of Java is installed in a different directory than the default install directory, do our developers need to edit the applications to look at the different Java directory? Basically, will apps be able to handle finding the necessary Java version on their own? I get it... You (techies at large), can't know how our dev staff build things, but in general, do apps need to be specifically directed or will they recurs through the Program Files\Java\** directories?
Since we're only one slice of a 25 piece pie in a 50,000 people organization, our developers won't change or recompile the apps. We have about 1,300 people in our slice of the pie, but the developers for these particular apps write them for the entire organization.
EDIT: 1/31/13 - Fixed typo - murbot 11 years ago -
Great question and not one that I can answer unfortunately, but I would be very interested in finding out. I would think that if the app is calling for a specific Java, as long as it is resident, then it should be found, but I guess that would be more dependent on your coding. - andrew_lubchansky 11 years ago
Do not know if you can afford this or not we started using Citrix to deliver a v-desktop for a couple of legacy apps like this.
http://www.citrix.com/products/xendesktop/overview.html
Comments:
-
It's not a bad way to go. We actually did that with Citrix for other apps a few years ago. We decommissioned Citrix and went with View last year to meet some odd growth needs internally. The problem in this case is the staff who use some of these apps tend to turn over frequently and that means more overhead\mgt for their virtual devices than we have the manpower to handle. It's more a policy issue than a technical overhead issue. Security is rather strict here. - murbot 11 years ago
One of the issues with having multiple versions of java installed is that it is still a security exploit. A Java script can still ask for a specific exploited version of java and still hose you even if the have the newer non-exploited version installed. Have you tried running the newer version of java with your apps? Sometimes that works even if a vendor says it won't.
Comments:
-
You are preaching to the choir. We're one of 25 smaller pieces to the larger organization. They have developers that built the unsecure apps requiring one specific Java version. We squawked for a long time about the requirement to leave an older version of Java installed and not update at all. Hence a recent new requirement to improve Java security by leaving the old version installed and now also updating with a new version. Internally, I've had no luck thus far with finding out how anyone else addresses this new requirement. Your point of exploited versions may not have been properly brought up previously thought. I'll be mentioning it at our next meeting. - murbot 11 years ago
