I’m in the unfortunate position of trying to keep a very old CE edition of Kaltura running. I think it is version 5 (Falcon)… well before the rpm days and something that is apparently un-upgradeable and very difficult if not impossible to migrate into a current release. For now, I have to try and keep it running. Mostly it’s fine. Recently though, a scan by a vulnerability scanner we started to use is reporting issues with the Java version. The scanner reports
Path : /usr/java/jre1.7.0_25/
Installed version : 1.7.0_25
Fixed version : 1.5.0_65 / 1.6.0_75 / 1.7.0_55 / 1.8.0_5
The server itself says
java -version
java version “1.6.0_41”
OpenJDK Runtime Environment (IcedTea6 1.13.13) (rhel-1.13.13.1.el6_8-x86_64)
OpenJDK 64-Bit Server VM (build 23.41-b41, mixed mode)
which java
/usr/bin/java
…and tracing past the symbolic links reveals this actual path
/usr/bin/java -> /etc/alternatives/java
/etc/alternatives/java -> /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java
According to what I am reading, OpenJava 1.6 may in fact be the same as OracleJava 1.7. I’m also reading that upgrades for Java <= 1.8 can only be had from Oracle via an extended service contract.
So, any suggestion for how I might update Java on this CentOS 6.x server? Would it actually stop Kaltura from working if I just removed Java altogether? Is it actually used by Kaltura, or is it just there as a means to possible API’s for custom work?
Java is used for the analytics mechanism so, unless you’re OK with not having this data, it is necessary.
CE 5 [that’s Eagle, actually, Falcon was version 6] is very very old indeed. The analytics code included in your version may run correctly with Java 1.7 but I can’t guarantee it. I’m quite positive it will fail with 1.8. You can switch the versions [using the alternatives mechanism], wait 24 hours to allow all the DWH scripts to run and verify there are no errors in /opt/kaltura/dwh/logs.
If there are issues, you can again use the alternatives mechanism to switch back [it basically changes where the /etc/alternatives/java symlink points to].
That said, running such an old version, I imagine Java is not the only vulnerable component. The Kaltura Server relies on many third party components [PHP, Apache, OpenSSL, etc, etc] and if you haven’t upgraded these from the official repos then your machine is potentially subjected to other exploits. Of course, we also made several security enhancements in our own code base since CE 5 was released [over 6 years ago].
While the migration path from the pre-RPM version is not as straightforward and smooth as with the RPMs, I highly recommend you clone your production machine[s], perform the needed steps, test and, once everything is OK, replace your current production instance[s].
For instructions on how to migrate pre-RPM versions, see my reply here:
Thank you very much for this thoughtful and thorough reply. Most of the rest of the server is patched to a reasonable level, though I should get php up to 5.6. At this point, I just want to nurse it along until we determine a long-term direction. I’ve tried and failed the migration in that referenced thread enough times that we’ve decide to export and re-ingest and take the opportunity to move to some form of hosted service.
You’re welcome, of course.
Please do not attempt to upgrade to PHP 5.6 while running CE 5 as it is certain to fail.
Should you have specific questions about the upgrade procedure, feel free to post them:)