Linux JAVA_HOME zieht nicht

[PHuV]

Ich habe hier gerade ein großes Verständnisproblem:

Ich installiere eine Java
https://linuxize.com/post/install-java-on-centos-8/

dnf -y install java-11-openjdk.x86_64
Mache ein

export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-11.0.7.10-1.el8_1.x86_64

Und ich kann ein gewisses rpm-Paket von einem Hersteller (nicht öffentlich) installieren.

JAVA_HOME fehlt komischerweise, und wenn ich das JAVA per RPM installiere, ist es natürlich sofort verfügbar, weil es unter /usr/bin installiert wird.

Jetzt möchte ich das so nicht haben, sondern ein bestimmtes Java (weil vom Hersteller explizit supported und recommend) unter

/opt/java

auspacken und per /etc/bashrc setzen.

JAVA_HOME=/opt/java
PATH=$JAVA_HOME/bin:.:$PATH

export JAVA_HOME PATH

Mach ich seit Jahren so, funktionierte ohne RPM bisher immer. Siehe auch
https://stackoverflow.com/questions/14637979/how-to-permanently-set-path-on-linux-unix
Es soll aus diversen Gründen kein Java unter /usr/bin und diversen verteilten Verzeichnissen zu finden sein, sondern nur unter /opt/java.

[root@server user]# echo $JAVA_HOME $PATH
/opt/java /opt/java/bin:/sbin:/bin:/usr/sbin:/usr/bin
[root@server user]# java -version
openjdk version "11.0.7" 2020-04-14 LTS
OpenJDK Runtime Environment Zulu11.39+15-CA (build 11.0.7+10-LTS)
OpenJDK 64-Bit Server VM Zulu11.39+15-CA (build 11.0.7+10-LTS, mixed mode)
[root@server user]# which java
/opt/java/bin/java

Über die /etc/bashrc wird das Java schön für alle global gesetzt, wie es sein sollte. Prüfung zeigt ja, das Java (als User) immer verfübar, egal ob unter Root oder sonstige User auf diesem Server.

Aber ich kann es nicht installieren, weil folgende Fehlermeldung kommt.

  Running scriptlet: programm-v.3.1-2020032211130.x86_64                                                                                                                   1/1
No java in PATH, exiting ...
Please install Java 1.8 and add java executable to PATH variable.
error: %prein(programm-v.3.1-2020032211130.x86_64) scriptlet failed, exit status 1

Error in PREIN scriptlet in rpm package talend-jobserver
  Verifying        : programm-v.3.1-2020032211130.x86_64                                                                                                                   1/1
Installed products updated.

Im Scriptlet vom rpm-Paket finde ich in %pre folgenden Code:

if [ "$1" = "1" ]; then
  ## We are handling new Installation (pre-install script)
  ## Limitation: files are still not copied, we cannot call external scripts

  # Our preconditions to install:
  # - java should be available in PATH
  # - JAVA_HOME should point on the same version like java executed directly from cmdline

  if [ -z "`which java 2>/dev/null`" ]; then
    echo "No java in PATH, exiting ..."
    echo "Please install Java 1.8 and add java executable to PATH variable."
    exit 1
  fi

  if [ -z "$JAVA_HOME" -o ! -f $JAVA_HOME/bin/java ]; then
    echo "JAVA_HOME variable is not set up or it points on a wrong location !"
    echo "Please set up JAVA_HOME variable properly and re-run the installation."
    exit 1
  fi

  java_home_ver=`$JAVA_HOME/bin/java -version 2>&1 | grep version | sed s/.*version\ //`
  java_cmdline_ver=`java -version 2>&1 | grep version | sed s/.*version\ //`
  if [ "$java_home_ver" != "$java_cmdline_ver" ]; then
    echo "Error: Java version from command line mismatches with Java version from JAVA_HOME !"
    echo "JAVA_HOME point on java version : $java_home_ver"
    echo "java version from command line  : $java_cmdline_ver"
    echo "Please make them equivalent and then re-run the installation."
    exit 1
  fi

Packe ich das in ein Script und starte es, alles in Ordnung. Alternatives Setzen über /root/.bashrc oder /root/.bash_profile brachte übrigens kein Erfolg, ebenso ein Reboot nicht.

Wo liegt nun mein Denkfehler? Vermutung: yum bzw. dnf laufen mit eigenem Service (wie systemd) und findet die JAVA_HOME nicht. Aber warum geht das, wenn ich das Java direkt über den Repomanager installiere?

 

[benneq]

Hier stand Unsinn.

EDIT: Hast du JAVA_HOME auch für root gesetzt bzw. den Benutzer mit dem du das Paket nicht installieren kannst?

 

[DoubleJ2k]

Zum Verwalten mehrerer Java-Versionen bietet sich https://sdkman.io/ an

 

[lokon]

/etc/bashrc

Vielleicht eher in /etc/profile.d/

 

[ScOuRgE_]

Ich mache das immer über Lmod (https://lmod.readthedocs.io/en/latest/) und ein entsprechendes Modulfile in Lua:

help([==[

Description
===========
Java Platform, Standard Edition (Java SE) lets you develop and deploy
 Java applications on desktops and servers.


More information
================
 - Homepage: http://openjdk.java.net
]==])

whatis([==[Description: Java Platform, Standard Edition (Java SE) lets you develop and deploy
 Java applications on desktops and servers.]==])
whatis([==[Homepage: http://openjdk.java.net]==])
whatis([==[URL: http://openjdk.java.net]==])

local root = "/etc/alternatives/jre_11_openjdk/"

conflict("Java")

prepend_path("CPATH", pathJoin(root, "include"))
prepend_path("LD_LIBRARY_PATH", pathJoin(root, "lib"))
prepend_path("LIBRARY_PATH", pathJoin(root, "lib"))
prepend_path("PATH", pathJoin(root, "bin"))

prepend_path("PATH", root)
setenv("JAVA_HOME", root)

Mit der Abänderung von "local root" lassen sich entsprechend auch Java 8 etc. Modulefiles realisieren. Man kann dann ziemlich einfach die Java-Versionen laufend austauschen und Standardmodul-Configs speichern (siehe Lua-Webseite).

 

[PHuV]

Danke für Eure Hilfe.

EDIT: Hast du JAVA_HOME auch für root gesetzt bzw. den Benutzer mit dem du das Paket nicht installieren kannst?

Ja.

Vielleicht eher in /etc/profile.d/

Schon getestet, geht auch nicht.

Zum Verwalten mehrerer Java-Versionen bietet sich https://sdkman.io/ an

Ich möchte aber nicht mehrere Java-Versionen verwalten, ich will nur eine verwenden und installieren.

@ScOuRgE_

Das ist im Prinzip eine gute Idee, ich möchte aber ohne zusätzliche Tools auskommen, es soll hier nur das Notwendigste installiert werden. Eigentlich sollte doch das korrekte Setzen der Umgebung laut Doku in /etc/bashrc oder user/.bash_profile etc. ausreichen, wenn Userprozesse im Spiel sind?

 

[ScOuRgE_]

Das kannst du auch machen, legst dich damit aber auf eine Version fest. Beachte oben, dass dir eine ganze Reihe von Umgebungsvariablen fehlen. Nehme an, dass deshalb die Fehlermeldung kommt.

 

[lokon]

Liegt es am Unterschied "login" und nicht-login shell ?
bash doku , superuser
/etc/bashrc ist nicht dokumentiert - kann natürlich sein dass CentOS das irgendwie verwendet

Edit: genau: Der rpm installer nutzt die bash eben ohne deine Änderungen - das solltest du testen, wenn du die bash eben anders aufrufst

 

[DoubleJ2k]

Ich möchte aber nicht mehrere Java-Versionen verwalten, ich will nur eine verwenden und installieren.

"Eine (konkrete) Version installieren" ist Teilmenge von "mehrere Versionen installieren" - geht also auch. Und setzt alle nötigen Umgebungsvariablen automatisch.

 

[PHuV]

Anders gefrag

Liegt es am Unterschied "login" und nicht-login shell ?
bash doku , superuser
/etc/bashrc ist nicht dokumentiert - kann natürlich sein dass CentOS das irgendwie verwendet

Das habe ich ja mit allen Varianten ja durch mit /etc/profile, lokales profile usw.

Anders gefragt, was macht denn dnf anders, wenn es das Java installiert? Das muß doch auch irgendwo das Java eintragen.

Update, ich hab eine Lösung:
https://github.com/elastic/logstash/issues/6902

Anscheinend will ein RPM Scriptlet unbedingt das Java in /usr/bin. Linkt man dort hin

ln -fs /opt/java/bin/java /usr/bin/java

geht die Installation nun durch.