Operational Changes (Release 7.0.0)

Lists the functional changes made to existing commands in HPE Ezmeral Data Fabric release 7.0.0.

Release 7.0.0 Is Not Supported on CentOS

Release 7.0.0 removes support for CentOS. CentOS Linux 8 has reached End of Life (EOL) status. For more information, see this page. See also the HPE Ezmeral Data Fabric Advisory in response to CentOS 8 Discontinuance.

For a complete list of supported operating systems, see Operating System Support Matrix.

32-GB Minimum Memory Requirement for Production Nodes

Minimum memory requirements for production nodes have changed. Production nodes require at least 32 GB of memory per node. For more information, see Memory and Disk Space.

Nonsecure Configurations

Release 7.0.0 installations are secure by default. Nonsecure installations have not been validated for use with release 7.0.0.

S3 Gateway Supported only for Migration Purposes

The S3 Gateway is not supported for use with release 7.0.0 and later. S3 Gateway software is present in release 7.0.0 to facilitate migration to the object store. HPE Ezmeral Data Fabric 7.0.0 introduces a native object storage solution. For more information, see HPE Ezmeral Data Fabric Object Store.

Key Store and Trust Store Changes in Release 7.0.0

Release 7.0.0 supports FIPS installations, adding new security files and subdirectories. For Java applications, release 7.0.0 added the Bouncy Castle BCFKS key and trust stores. For non-Java applications, the existing PKCS#12 key and trust stores, as well as PEM files are used. Because of the security changes, the list of files that you must copy to enable security on all nodes is longer. For more information, see these topics:

FileMigrate Is Not Supported

The FileMigrate utility is not supported in release 7.0.0, and the documentation for the utility has been removed. The File Migration service was provided to copy files from the HPE Ezmeral Data Fabric file store to the S3 object store to make the files accessible by any S3 client. The HPE Ezmeral Data Fabric Object Store provided in release 7.0.0 gives S3 clients direct access to files (as objects), reducing the need for file migration.

Changes to Cross-Cluster Configuration

Note these operational changes:
  • Running configure-crosscluster.sh in release 7.0.0 requires you to specify two additional parameters:
    • localtruststorepassword
    • remotetruststorepassword
  • The configure-crosscluster.sh script now returns an error if it is run by a user other than the cluster owner. For example, you cannot run the script as the root user.
  • In release 7.0.0 and later, cross-cluster configuration using the basic configure-cross.cluster.sh script options is supported if nodes in the local and remote clusters are either all non-FIPS nodes or all FIPS nodes. See Configuring Cross-Cluster Security for a Mixed (FIPS and Non-FIPS) Configuration for the manual steps to configure mixed clusters consisting of FIPS and non-FIPS nodes using the -localhosts and -remotehosts options.

For more information, see configure-crosscluster.sh.

About ssl-server.xml and ssl-client.xml in Release 7.0.0

The Hadoop configuration files (ssl-server.xml and ssl-client.xml) contain SSL configuration information for the client and server in XML format. This section describes some changes in the use of these files in Release 7.0.0

Clear-Text Passwords Are Removed from ssl-server.xml and ssl-client.xml

In release 6.2.0 and earlier releases of the HPE Ezmeral Data Fabric, key and trust store passwords are stored in clear text in the ssl-server.xml and ssl-client.xml configuration files, and the passwords are the same for both key and trust stores.

Beginning with release 7.0.0, clear-text passwords are removed from the Hadoop ssl-server.xml and ssl-client.xml configuration files. And distinct passwords are generated – one for the key store and one for the trust store. See Key and Trust Store Password Protection.

For Java applications, key and trust store passwords are now protected in credential stores accessible through the Hadoop Credential Provider API. For non-Java applications key store passwords are stored in maprkeycreds.conf, and trust store passwords are stored in maprtrustcreds.conf. See Application Development with Encrypted Key and Trust Stores.

For information about what happens to the clear-text passwords during an upgrade, see the Upgrade Notes (Release 7.0.0) and Removing Clear-Text Passwords After Upgrade.

Do Not Copy These Files When FIPS-Enabled Nodes Are Present

In a cluster with FIPS-enabled nodes, the following files must not be copied to other nodes during security configuration:
  • ssl-client.xml
  • ssl-server.xml
  • ssl_keystore (symlink)
  • ssl_truststore (symlink)
  • ssl_userkeystore (symlink)
  • ssl_usertruststore (symlink)

In release 7.0.0, it is a best practice to avoid copying the ssl-client.xml and ssl-server.xml files regardless of the FIPS configuration. In particular, when adding a non-FIPS node to a FIPS cluster, you must not copy the Hadoop ssl*.xml files to the other nodes in the cluster. To determine whether a node is FIPS enabled, manageSSLKeys.sh reads the trust store type from ssl-client.xml when running in standalone mode instead of indirectly through configure.sh. Copying the Hadoop ssl*.xml files that are set to the BCFKS store type from a FIPS to a non-FIPS node then causes commands such as manageSSLKeys.sh convert to fail.

In a FIPS-enabled node, symlink files are provided for the .bcfks versions of the key store, user keystore, truststore, and user trust store. These files must not be copied. Copying the files can result in errors later when you run configure.sh.

For more information about the files to copy when you enable security, see Enabling Security.