Bug 1347466

Summary: Consider overriding '/usr/sbin/alternatives' for PKI java
Product: Red Hat Enterprise Linux 7 Reporter: Matthew Harmsen <mharmsen>
Component: pki-coreAssignee: Endi Sukma Dewata <edewata>
Status: CLOSED ERRATA QA Contact: Asha Akkiangady <aakkiang>
Severity: unspecified Docs Contact: Tomas Capek <tcapek>
Priority: high    
Version: 7.3CC: alee, cfu, cheimes, edewata, ftweedal, jcholast, jmagne, mharmsen, mkosek, nkinder, pvoborni, ssidhaye, tcapek
Target Milestone: rc   
Target Release: 7.3   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: pki-core-10.3.3-1.el7 Doc Type: Release Note
Doc Text:
Explicit dependency on OpenJDK 1.8.0 The current PKI code has only been verified to work with OpenJDK 1.8.0. Previously, PKI depended on a generic "java" link provided by alternatives and assumed that the link would point to OpenJDK 1.8.0. Since the alternatives settings could change for various reasons, it could cause some problems to PKI. To ensure that PKI always works properly, PKI has been changed to depend more specifically on "jre_1.8.0_openjdk" link which will always point to the latest update of OpenJDK 1.8.0 regardless of other Java installation.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-04 05:24:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Matthew Harmsen 2016-06-17 00:36:51 UTC 
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/pki/ticket/2363

Case I:
{{{
A user is running an older Dogtag pki-ca with Java 1.7 selected, and upgrades
to the latest Dogtag which requires Java 1.8.  When "yum update pki-ca" is typed,
will PKI switch the Java or simply crash during upgrade and thus leave PKI services
with a broken upgrade?
}}}

Case II:
{{{
A user is new to Dogtag, and has Fedora installed with Java 1.7 selected.
When "yum install pki-ca" is entered, will the Dogtag installer switch
automatically, report a clean and nice error, or will it crash?
}}}

These two cases need to be tested out.  If 'alternatives' does not update to the latest java "automatically", and perhaps even if it does, this ticket proposes considering circumventing its use by hard-wiring PKI paths to Java 1.8 rather than using the current "selectable" path mechanisms.  Tests will show if this change is necessary, and depending upon the outcome, help determine how soon this alternative approach would need to be implemented.

One reason to consider making this change regardless would be to prevent accidental administrator switching from Java 1.8 back to Java 1.7 via '/usr/sbin/alternatives'.
Comment 1 Matthew Harmsen 2016-06-17 00:38:32 UTC 
Performed the following simple test:
{{{
# yum install java-1.7.0-openjdk-1.7.0.101-2.6.6.1.el7_2 java-1.7.0-openjdk-headless-1.7.0.101-2.6.6.1.el7_2

# /usr/sbin/alternatives --config java

There is 1 program that provides 'java'.

  Selection    Command
-----------------------------------------------
*+ 1           /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.101-2.6.6.1.el7_2.x86_64/jre/bin/java

Enter to keep the current selection[+], or type selection number:

# yum install java-1.8.0-openjdk-1.8.0.91-0.b14.el7_2.x86_64  java-1.8.0-openjdk-headless-1.8.0.91-0.b14.el7_2.x86_64

# /usr/sbin/alternatives --config java

# /usr/sbin/alternatives --config java

There are 2 programs which provide 'java'.

  Selection    Command
-----------------------------------------------
 + 1           /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.101-2.6.6.1.el7_2.x86_64/jre/bin/java
*   2           /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.91-0.b14.el7_2.x86_64/jre/bin/java

Enter to keep the current selection[+], or type selection number:

# java -version
java version "1.7.0_101"
OpenJDK Runtime Environment (rhel-2.6.6.1.el7_2-x86_64 u101-b00)
OpenJDK 64-Bit Server VM (build 24.95-b01, mixed mode)
}}}

Which shows that merely installing another version of Java does not automatically update it
to running the latest version installed -- even when it is a later version.

Continuing simple tests:
{{{
# yum remove java-1.8.0-openjdk-1.8.0.91-0.b14.el7_2.x86_64  java-1.8.0-openjdk-headless-1.8.0.91-0.b14.el7_2.x86_64

# yum update java-1.8.0-openjdk-1.8.0.91-0.b14.el7_2.x86_64  java-1.8.0-openjdk-headless-1.8.0.91-0.b14.el7_2.x86_64
Loaded plugins: product-id, search-disabled-repos, subscription-manager
Package(s) java-1.8.0-openjdk-1.8.0.91-0.b14.el7_2.x86_64 available, but not installed.
Package(s) java-1.8.0-openjdk-headless-1.8.0.91-0.b14.el7_2.x86_64 available, but not installed.
No packages marked for update
}}}

Which shows that java-1.8.0 does not "update" java-1.7.0.
Comment 2 Matthew Harmsen 2016-06-17 00:39:22 UTC 
Successfully installed and tested IPA using the following packages:

    * java-1.7.0-openjdk-1.7.0.95-2.6.4.0.el7_2.x86_64
    * java-1.7.0-openjdk-headless-1.7.0.95-2.6.4.0.el7_2.x86_64
    * jss-4.2.6-37.el7.x86_64
    * nuxwdog-1.0.3-4.el7_2.x86_64
    * nuxwdog-client-java-1.0.3-4.el7_2.x86_64
    * pki-base-10.2.5-8.el7_2.noarch
    * pki-ca-10.2.5-8.el7_2.noarch
    * pki-kra-10.2.5-8.el7_2.noarch
    * pki-server-10.2.5-8.el7_2.noarch
    * pki-tools-10.2.5-8.el7_2.x86_64
    * tomcat-7.0.54-2.el7_1.noarch
    * tomcat-el-2.2-api-7.0.54-2.el7_1.noarch
    * tomcat-jsp-2.2-api-7.0.54-2.el7_1.noarch
    * tomcatjss-7.1.2-1.el7.noarch
    * tomcat-lib-7.0.54-2.el7_1.noarch
    * tomcat-servlet-3.0-api-7.0.54-2.el7_1.noarch

Installed (but did not select) Java 1.8:

    # yum install java-1.8.0-openjdk-1.8.0.91-0.b14.el7_2.x86_64.rpm java-1.8.0-openjdk-headless-1.8.0.91-0.b14.el7_2.x86_64.rpm

    # /usr/sbin/alternatives --config java

    There are 2 programs which provide 'java'.

      Selection    Command
    -----------------------------------------------
     + 1           /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.95-2.6.4.0.el7_2.x86_64/jre/bin/java
    *  2           /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.91-0.b14.el7_2.x86_64/jre/bin/java

    Enter to keep the current selection[+], or type selection number:

Attempted to update 'pki-ca' (and 'pki-kra') on running IPA instance:

    # yum update pki-ca-10.3.2-5.el7.noarch.rpm pki-kra-10.3.2-5.el7.noarch.rpm

    Dependencies Resolved

    ================================================================================
     Package            Arch   Version           Repository                    Size
    ================================================================================
    Updating:
     pki-ca             noarch 10.3.2-5.el7      /pki-ca-10.3.2-5.el7.noarch  2.3 M
     pki-kra            noarch 10.3.2-5.el7      /pki-kra-10.3.2-5.el7.noarch 537 k
    Installing for dependencies:
     pki-base-java      noarch 10.3.2-5.el7      RHEL-7.2-x86_64-main         1.1 M
    Updating for dependencies:
     jss                x86_64 4.2.6-40.el7      RHEL-7.2-x86_64-main         704 k
     nspr               x86_64 4.11.0-1.el7_2    RHEL-7.2-x86_64-main         126 k
     nspr-devel         x86_64 4.11.0-1.el7_2    RHEL-7.2-x86_64-main         114 k
     nss                x86_64 3.21.0-13.el7     RHEL-7.2-x86_64-main         849 k
     nss-devel          x86_64 3.21.0-13.el7     RHEL-7.2-x86_64-main         211 k
     nss-softokn        x86_64 3.16.2.3-14.3.el7 RHEL-7.2-x86_64-main         304 k
     nss-softokn-devel  x86_64 3.16.2.3-14.3.el7 RHEL-7.2-x86_64-main          25 k
     nss-softokn-freebl x86_64 3.16.2.3-14.3.el7 RHEL-7.2-x86_64-main         203 k
     nss-softokn-freebl-devel
                        x86_64 3.16.2.3-14.3.el7 RHEL-7.2-x86_64-main          45 k
     nss-sysinit        x86_64 3.21.0-13.el7     RHEL-7.2-x86_64-main          54 k
     nss-tools          x86_64 3.21.0-13.el7     RHEL-7.2-x86_64-main         486 k
     nss-util           x86_64 3.21.0-2.2.el7_2  RHEL-7.2-x86_64-main          72 k
     nss-util-devel     x86_64 3.21.0-2.2.el7_2  RHEL-7.2-x86_64-main          71 k
     pki-base           noarch 10.3.2-5.el7      RHEL-7.2-x86_64-main         485 k
     pki-server         noarch 10.3.2-5.el7      RHEL-7.2-x86_64-main         3.0 M
     pki-tools          x86_64 10.3.2-5.el7      RHEL-7.2-x86_64-main         605 k
     tomcat             noarch 7.0.69-2.el7      RHEL-7.2-x86_64-main          86 k
     tomcat-el-2.2-api  noarch 7.0.69-2.el7      RHEL-7.2-x86_64-main          76 k
     tomcat-jsp-2.2-api noarch 7.0.69-2.el7      RHEL-7.2-x86_64-main          90 k
     tomcat-lib         noarch 7.0.69-2.el7      RHEL-7.2-x86_64-main         3.8 M
     tomcat-servlet-3.0-api
                        noarch 7.0.69-2.el7      RHEL-7.2-x86_64-main         208 k
     tomcatjss          noarch 7.1.2-2.el7       RHEL-7.2-x86_64-main          34 k

    Transaction Summary
    ================================================================================
    Install             (  1 Dependent package)
    Upgrade  2 Packages (+22 Dependent packages)

    Total size: 15 M
    Total download size: 13 M
    Is this ok [y/d/N]:

    # /usr/sbin/alternatives --config java

    There are 2 programs which provide 'java'.

      Selection    Command
    -----------------------------------------------
     + 1           /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.95-2.6.4.0.el7_2.x86_64/jre/bin/java
    *  2           /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.91-0.b14.el7_2.x86_64/jre/bin/java

    Enter to keep the current selection[+], or type selection number:

    # ipa cert-show
    Serial number: 1
    ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Internal Server Error)

    # pki cert-find
    Exception in thread "main" java.lang.UnsupportedClassVersionError: com/netscape/cmstools/cli/MainCLI : Unsupported major.minor version 52.0
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
	at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)

To "manually" correct this problem:

    # /usr/sbin/alternatives --config java

    There are 2 programs which provide 'java'.

      Selection    Command
    -----------------------------------------------
       1           /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.95-2.6.4.0.el7_2.x86_64/jre/bin/java
    *+ 2           /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.91-0.b14.el7_2.x86_64/jre/bin/java

    Enter to keep the current selection[+], or type selection number:

    # systemctl restart pki-tomcatd
Comment 3 Martin Kosek 2016-06-17 06:56:44 UTC 
Thank you! This is important for ipa-server package, upgrade from 7.2 to 7.3 needs to be seamless.
Comment 4 Endi Sukma Dewata 2016-06-17 20:08:05 UTC 
Fixed in master:
* 502e9ee5eb52bda8cb5bdf4ac4ef1d32dbded98f
* fc96c05922d1a42d0fbaaa02a67a31e69c667f84
* c5e4920126f8b7c689ad0aa000f17089cd54426d

The RPM spec has been modified to use exact build and runtime dependency on OpenJDK 1.8.0 and the code has been modified to use the JVM in /usr/lib/jvm/jre-1.8.0-openjdk. This path is actually still controlled by alternatives, but it should be less affected by Java upgrades.

$ alternatives --config jre_1.8.0_openjdk

There is 1 program that provides 'jre_1.8.0_openjdk'.

  Selection    Command
-----------------------------------------------
*+ 1           /usr/lib/jvm/jre-1.8.0-openjdk-1.8.0.91-3.b14.fc22.x86_64

Enter to keep the current selection[+], or type selection number:

If someone installs a newer OpenJDK 1.8.0 the alternatives might change the link target, but the new target will still be an OpenJDK 1.8.0. If someone installs OpenJDK 1.7 or 1.9, or JVM from a different vendor, the above path should not change.

An upgrade script has been added to update the Tomcat configuration file in existing PKI instances to use the OpenJDK 1.8.0 path.
Comment 6 Sumedh Sidhaye 2016-08-11 01:02:14 UTC 
Tested the following scenarios:

    Before installing latest pki build I see the following for alternatives java config
     
    [root@pki1 cloud-user]# java -version
    java version "1.7.0_101"
    OpenJDK Runtime Environment (rhel-2.6.6.6.el7-x86_64 u101-b00)
    OpenJDK 64-Bit Server VM (build 24.95-b01, mixed mode)
    [root@pki1 cloud-user]# alternatives --config java
     
    There is 1 program that provides 'java'.
     
      Selection    Command
    -----------------------------------------------
    *+ 1           java-1.7.0-openjdk.x86_64 (/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.101-2.6.6.6.el7.x86_64/jre/bin/java)
     
     
    =================================
     
     
    After installing latest pki I see the following
     
    [root@pki1 cloud-user]# alternatives --config java
     
    There are 2 programs which provide 'java'.
     
      Selection    Command
    -----------------------------------------------
     + 1           java-1.7.0-openjdk.x86_64 (/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.101-2.6.6.6.el7.x86_64/jre/bin/java)
    *  2           java-1.8.0-openjdk.x86_64 (/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.102-0.b14.el7.x86_64/jre/bin/java)
     
    Enter to keep the current selection[+], or type selection number:
    [root@pki1 cloud-user]#

Just installing a newer version of pki does not automatically update it.
Updating to a latest version of pki installs java-1.8.0 but does not alter which system java is being used. But java-1.8.0 is available as an alternative.

Tested the above using build # 10.3.0.b1-2.el7_2 and 10.3.3-5.el7.

Also tested scenarios mentioned in earlier comments.
Comment 9 errata-xmlrpc 2016-11-04 05:24:51 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2396.html