This is the documentation for Cloudera Enterprise 5.8.x. Documentation for other versions is available at Cloudera Documentation.

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 Cloudera Manager Supported JDK Versions and CDH 5 Supported JDK Versions. In some cases, using JDK 1.8 can cause minor performance degradation compared to JDK 1.7.

Warning:

Cloudera does not support upgrading to JDK 1.8 while upgrading to Cloudera Manager 5.3 or higher. The Cloudera Manager Server must 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, Cloudera Manager offers you an option to automatically install the policy files; for unmanaged deployments, install them manually.) See If you are Using AES-256 Encryption, install the JCE Policy File.
For both managed and unmanaged deployments, you must also ensure that the Java Truststores are retained during the upgrade. (See Creating Truststores.)

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
Upgrading to Oracle JDK 1.8 in an Unmanaged Deployment
If you are Using AES-256 Encryption, install the JCE Policy File

Upgrading to Oracle JDK 1.8 in a Cloudera Manager Deployment

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

Upgrade to Cloudera Manager 5.3 or higher if you have not done so.
Upgrade to CDH 5.3 or higher if you have not done so.
Stop the Cloudera Management Service.
Stop all clusters.
Stop all Cloudera Manager Agents.
Stop the Cloudera Manager Server.
Clean up existing Java versions.
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.
On the Cloudera Manager Server host, configure the location of the JDK in /etc/default/cloudera-scm-server.
Start the Cloudera Manager Server.
Start all Cloudera Manager Agents.
Configure the location of the JDK on cluster hosts as described in Configuring a Custom Java Home Location.
Start all clusters.
Start the Cloudera Management Service.

Upgrading to Oracle JDK 1.8 in an Unmanaged Deployment

Important:

If you use Cloudera Manager, do not use these command-line instructions.
This information applies specifically to CDH 5.8.x. If you use a lower version of CDH, see the documentation for that version located at Cloudera Documentation.

Upgrade to CDH 5.3 or higher if you have not already done so.
Shut down the cluster.
Clean up existing Java versions.
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, as instructed.
Start the cluster.

If you are Using AES-256 Encryption, install the JCE Policy File

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:

On the local KDC host, type this command to create a test principal:
```
$ kadmin -q "addprinc test" 
```
On a cluster host, type this command to start a Kerberos session as test:
```
$ kinit test 
```

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 July 8, 2016.