Cloudera Enterprise 5.15.x | Other versions

Upgrading to Oracle JDK 1.8

Cloudera Manager 5.3 and higher and CDH 5.3 and higher support Oracle JDK 1.8. For other supported versions, see CDH and Cloudera Manager Supported JDK Versions.

  Warning:
  • Cloudera does not support upgrading to JDK 1.8 while upgrading to Cloudera Manager 5.3 or higher. The Cloudera Manager Server must be upgraded to 5.3 or higher before you start.
  • Cloudera does not support upgrading to JDK 1.8 while upgrading a cluster to CDH 5.3 or higher. The cluster must be running CDH 5.3 or higher before you start.
  • Cloudera does not support a rolling upgrade to JDK 1.8. You must shut down the entire cluster.
  • If you are upgrading from a lower major version of the JDK to JDK 1.8 or from JDK 1.6 to JDK 1.7, and you are using AES-256 bit encryption, you must install new encryption policy files. (In a Cloudera Manager deployment, you automatically install the policy files; for unmanaged deployments, install them manually.) See Using AES-256 Encryption.

    For both managed and unmanaged deployments, you must also ensure that the Java Truststores are retained during the upgrade. (See Recommended Keystore and Truststore Configuration.)

The process for upgrading to Oracle JDK 1.8 varies depending on whether you have a Cloudera Manager Deployment or an Unmanaged Deployment.

Continue reading:

Upgrading to Oracle JDK 1.8 in a Cloudera Manager Deployment

Minimum Required Role: Cluster Administrator (also provided by Full Administrator)

  1. Upgrade to Cloudera Manager 5.3 or higher if you have not done so.
  2. Upgrade to CDH 5.3 or higher if you have not done so.
  3. Stop the Cloudera Management Service.
  4. Stop all clusters.
  5. Stop all Cloudera Manager Agents.
  6. Stop the Cloudera Manager Server.
  7. On the Cloudera Manager Server host and each cluster host:
    1. Install the same supported version of JDK 1.8. See Java Development Kit Installation for instructions.
  8. On the Cloudera Manager Server host, configure the location of the JDK in /etc/default/cloudera-scm-server.
  9. Start the Cloudera Manager Server.
  10. Start all Cloudera Manager Agents.
  11. Configure the location of the JDK on cluster hosts as described in Configuring a Custom Java Home Location.
  12. If you have configured TLS for Cloudera Manager, as described in Configuring TLS Encryption for Cloudera Manager, copy the jssecacerts file from the previous JDK installation to the new JDK installation. For example: 
    cp previous_java_home/jre/lib/security/jssecacerts new_java_home/jre/lib/security
    (Substitute previous_java_home and new_java_home with the paths to the JDK installations.)
  13. Start all clusters.
  14. Start the Cloudera Management Service.
  15. Delete your previous Java version files.

Upgrading to Oracle JDK 1.8 in an Unmanaged Deployment

  Important:
  • Follow these command-line instructions on systems that do not use Cloudera Manager.
  • This information applies specifically to CDH 5.15.0. See Cloudera Documentation for information specific to other releases.
  1. Upgrade to CDH 5.3 or higher if you have not already done so.
  2. Shut down the cluster.
  3. On each cluster host:
    1. Install the same supported version of JDK 1.8. See Java Development Kit Installation for instructions.
    2. Verify that you have set JAVA_HOME on each host to the directory where you installed JDK 1.8 and created a symbolic link to it.
    3. If you have configured TLS for Cloudera Manager, as described in Configuring TLS Encryption for Cloudera Manager, copy the jssecacerts file from the previous JDK installation to the new JDK installation. For example: 
      cp previous_java_home/jre/lib/security/jssecacerts new_java_home/jre/lib/security
      (Substitute previous_java_home and new_java_home with the paths to the JDK installations.)
  4. Start the cluster.
  5. Delete your previous Java version files.

Using AES-256 Encryption

  Note: This step is not required when using JDK 1.8.0_161 or greater. JDK 1.8.0_161 enables unlimited strength encryption by default.

If you are using CentOS/Red Hat Enterprise Linux 5.6 or higher, or Ubuntu, which use AES-256 encryption by default for tickets, you must install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy File on all cluster and Hadoop user machines. For JCE Policy File installation instructions, see the README.txt file included in the jce_policy-x.zip file.

Alternatively, you can configure Kerberos to not use AES-256 by removing aes256-cts:normal from the supported_enctypes field of the kdc.conf or krb5.conf file. After changing the kdc.conf file, you must restart both the KDC and the kadmin server for those changes to take affect. You may also need to re-create or change the password of the relevant principals, including potentially the Ticket Granting Ticket principal (krbtgt/REALM@REALM). If AES-256 is still used after completing steps, the aes256-cts:normal setting existed when the Kerberos database was created. To fix this, create a new Kerberos database and then restart both the KDC and the kadmin server.

To verify the type of encryption used in your cluster:

  1. On the local KDC host, type this command to create a test principal: 
    $ kadmin -q "addprinc test"
  2. On a cluster host, type this command to start a Kerberos session as test: 
    $ kinit test
  3. On a cluster host, type this command to view the encryption type in use: 
    $ klist -e

    If AES is being used, output like the following is displayed after you type the klist command; note that AES-256 is included in the output:

    Ticket cache: FILE:/tmp/krb5cc_0
Default principal: test@SCM
Valid starting     Expires            Service principal
05/19/11 13:25:04  05/20/11 13:25:04  krbtgt/SCM@SCM
    Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CTS mode with 96-bit SHA-1 HMAC
Page generated May 18, 2018.