Oracle JRE über Spacewalk, Red Hat Satellite und SUSE Manager verteilen und sauber installieren

Zur Ausführung von Java-Anwendungen stehen prinzipiell mehrere OpenJDK-Versionen unter Enterprise Linux zur Verfügung. Für die meisten Anwendungen ist das auch i.d.R. ausreichend, manchmal muss es aber doch die proprietäre Version von Oracle sein (z. B. aufgrund Support-Matrizen von kommerzieller Drittanbieter-Software).

Auf der JRE-Webseite gibt es neben Tarballs auch RPM-Pakete zum Download.

Wird das RPM-Paket mithilfe von Spacewalk, Red Hat Spacewalk oder SUSE Manager über einen eigenen Software-Kanal verbreitet, ergibt sich hier das Paketduplikat jre. Soll das Paket anschließend installiert werden, werden Pakete aus den RHEL- / Scientific Linux- bzw. CentOS-Kanälen bevorzugt.

Abhilfe schafft hier das folgende Kommando, welches alle YUM-Repositories außer dem eigenen (hier mychannel) deaktiviert und anschließend das Paket installiert:

1# yum --disablerepo="*" --enablerepo="mychannel" install jre

Alternativ kann diese Ausnahmeregel auch fest in der YUM-Konfiguration verankert werden:

1# vi /etc/yum/pluginconf.d/rhnplugin.conf
2...
3[rhel-x86_64-server-6]
4exclude=java-1.?.0-openjdk java-1.?.0-gcj
5
6ESC ZZ

Der Name des Kanals muss natürlich je nach Distribution angepasst werden - anbei einige Beispiele:

Wenn man nicht weiß, in welchen Kanälen sich Pakete befinden, die jre-Pakete zur Verfügung stellen, hilft das folgenden Kommando:

1# yum whatprovides jre|grep -i Repo|sort -u
2Repo        : centos6-base-x86_64
3Repo        : centos6-updates-x86_64

Nach der Installation fällt jedoch auf, dass sich Java-Anwendungen nicht ausführen lassen. Ein Blick auf die Ausgabe des folgenden Kommandos verrät, dass eine Bibliothek fehlt:

1# ldd $(which java)
2        linux-vdso.so.1 =>  (0x00007fff677ff000)
3        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003e68800000)
4        libjli.so => not found
5        libdl.so.2 => /lib64/libdl.so.2 (0x0000003e68c00000)
6        libc.so.6 => /lib64/libc.so.6 (0x0000003e68400000)
7        /lib64/ld-linux-x86-64.so.2 (0x0000003e68000000)

Mithilfe von find hat sich schnell herausgestellt, dass die Bibliothek zwar Bestandteil des RPM-Pakets war, aber nicht in den Standardpfaden (wie z. B. /usr/lib) liegt. Somit muss eine Konfigurationsdatei mit dem Pfad erstellt und der Bibliothekencache erneuert werden, damit die Datei auch gefunden wird.

1# echo "/usr/java/jre1.7.0_51/lib/amd64/jli" > /etc/ld.so.conf.d/oracle-jre.conf
2# ldconfig -p|head -n1
3438 libs found in cache `/etc/ld.so.cache'
4# ldconfig ; ldconfig -p|head -n1
5439 libs found in cache `/etc/ld.so.cache'

Wichtig sind die Ausgaben der beiden letzten Kommandos - wie zweifelsfrei ersichtlich ist, wurde die Bibliothek erkannt und zum Cache hinzugefügt.

Nun sollte dem Ausführen von Java nichts mehr im Wege stehen:

1# java -version
2java version "1.7.0_51"
3Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
4Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

🙂