Operational Changes (Release 7.0.0)
Lists the functional changes made to existing commands in HPE Ezmeral Data Fabric release 7.0.0.
Repository Changes
Recent changes to the download repository for HPE Ezmeral Data Fabric core and ecosystem packages might affect your ability to install or upgrade software. For more inforrmation, see What's New in 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 (Article Number: 000068015).
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
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
- 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 theroot
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
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.