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.

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

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 Level 0: Basic TLS/SSL Configuration, 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

  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 Level 0: Basic TLS/SSL Configuration, 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

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