OSBN/Ubuntuusers Planet RHEL / CentOS XING / LinkedIn / Amazon

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:

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

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

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

ESC ZZ

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

Kanal Beschreibung
rhel-x86_64-server-6 RHEL 6 x86_64 Basiskanal
centos6-base-x86_64 CentOS 6 x86_64 Basiskanal
centos6-updates-x86_64 CentOS 6 x86_64 Update-Kanal

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

# yum whatprovides jre|grep -i Repo|sort -u
Repo        : centos6-base-x86_64
Repo        : 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:

# ldd $(which java)
        linux-vdso.so.1 =>  (0x00007fff677ff000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003e68800000)
        libjli.so => not found
        libdl.so.2 => /lib64/libdl.so.2 (0x0000003e68c00000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003e68400000)
        /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.

# echo "/usr/java/jre1.7.0_51/lib/amd64/jli" > /etc/ld.so.conf.d/oracle-jre.conf
# ldconfig -p|head -n1
438 libs found in cache `/etc/ld.so.cache'
# ldconfig ; ldconfig -p|head -n1
439 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:

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

🙂

Sharing is caring

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.