Installer Known Issues

This topic describes some Installer known issues that you should be aware of while troubleshooting.

If you are viewing this page from within the Installer application, click here to display the information in a browser.

IN-2956
The mapr-installer-cli probe, export, and import commands fail when the specified password includes the @ character. For example, the following command fails:
/opt/mapr/installer/bin/mapr-installer-cli  probe -n -o config.ssh_id=mapr config.ssh_password=pword\@123 config.hosts='["<node-1>","<node-2>","<node-3>"]' -u mapr:pword\@123@$HOSTNAME:9443
Removing the @ character enables the same command to succeed:
/opt/mapr/installer/bin/mapr-installer-cli  probe -n -o config.ssh_id=mapr config.ssh_password=pword config.hosts='["<node-1>","<node-2>","<node-3>"]' -u mapr:pword@$HOSTNAME:9443
Workaround: Avoid using an @ character in a password you specify within an mapr-installer-cli command.
IN-3362
EEP 9.1.1 is supported for use with core 7.2.0 or core 7.3.0. But the Installer cannot install EEP 9.1.1 on core 7.2.0 because EEP 9.1.1 includes Data Access Gateway 6.0.0, which is not supported on core 7.2.0.
Workaround: To use EEP 9.1.1 with core 7.2.0, you must install Data Access Gateway 5.1.0 (and not Data Access Gateway 6.0.0), and you must perform the installation or upgrade using manual steps.
IN-3240
The probe command can fail in releases 7.1.0 and 7.2.0. For example:
$ /opt/mapr/installer/bin/mapr-installer-cli probe -nv -o config.hosts='["node1.cluster.com"]' config.ssh_id=root config.ssh_password=**** > /home/mapr/probe.yaml
MapR Installer SDK
Logging in to localhost
/opt/mapr/installer/build/installer/lib/python2.7/site-packages/ansible/parsing/vault/init.py:44: CryptographyDeprecationWarning: Python 2 is no longer supported by the Python core team. Support for it is now deprecated in cryptography, and will be removed in the next release.
  from cryptography.exceptions import InvalidSignature
 69504 1675179955.19489: become_pass = None
 69504 1675179955.19497: remote_pass = mapr
 69504 1675179955.19500: become = None
 69504 1675179955.19503: become_method = None
 69504 1675179955.19504: sudo_user = root
properties.json does not contain vault_password, assuming vault does not exist
ERROR: probe command failed
'Options' object has no attribute 'manifest'
Log files mapr-installer.log and installer-cli.log can be found at /opt/mapr/installer/logs
Workaround: None.
IN-3223
Because of an overwrite condition made possible by the presence of the new mapr-ranger-usersync package in EEP 9.1.0, the Installer fails to install or upgrade Ranger in the following use cases:
  • A new installation of EEP 9.1.0 with the Ranger service selected.
  • An incremental installation of EEP 9.1.0 to add the Ranger service.
  • An upgrade to release 7.2.0 and EEP 9.1.0 from a cluster where the Ranger service was installed.
The issue affects only Ubuntu installations and is caused by RAN-260.
Workaround: Install the Ranger service manually by using dpkg and the --force-overwrite flag. See the RAN-260 known issue in Ranger 2.3.0.100 - 2301 (EEP 9.1.0) Release Notes.
IN-3183
Using the Installer to install release 7.0.0 and EEP 8.1.0 with mapr-patch-7.0.0.6 on Rocky Linux 8.5 fails during security configuration. Logs indicate that the private.key and public.crt files are missing.
Workaround: To enable the installation to succeed:
  1. Install the release 7.0.0 cluster without the patch.
  2. Perform a maintenance update to apply the patch. For more information, see Performing a Maintenance Update.
IN-2934
You may receive the following error message while running Installer on Ubuntu v1.16.0.1 or earlier versions:
Installing installer packages... 

Executing: /tmp/tmp.ROkwOhfN5p/gpg.1.sh -q
--keyserver-options
http-proxy=http://web-proxy.corp.hpecorp.net:8080
--fetch-keys
https://package.ezmeral.hpe.com/releases/pub/maprgpg.key
gpgkeys: protocol `https' not supported
gpg: no handler for keyserver scheme `https'
gpg: WARNING: unable to fetch URI https://package.ezmeral.hpe.com/releases/pub/maprgpg.key: keyserver error

ERROR: Could not import repo key https://package.ezmeral.hpe.com/releases/pub/maprgpg.key

This error occurs because HTTPS protocols are not supported. This known issue affects Ubuntu v1.16.0.1 and earlier versons, in addition to version 1.17.0.0.

Workaround: To work around this issue, you must install the gnupg-curl package before installing the Installer, as this package is a dependency to successfully installing the Installer under this scenario. To do so, do one of the following:

  • Install the the gnupg-curl package using mapr-setup.sh:
    mapr-setup.sh -r http://package.ezmeral.hpe.com/releases/
  • Update and then install the gnupg-curl package on Ubuntu 16.x:
    sudo apt-get update
    sudo apt-get install gnupg-curl
IN-3120
A previously installed cluster disappears from the Installer graphical user interface, and the following error appears when you try to update the mapr-setup.sh Installer script:
ERROR : import command failed
This issue affects Installer 1.17.0.3.
Workaround: This issue is fixed in Installer 1.18.0.0 and later.To work around this issue, you can upgrade to Installer 1.18.0.0 or use either of the following workarounds:
IN-3053
On HPE Ezmeral Data Fabric 7.0.0, update_services.yml fails with the following error message:
Unable to retrieve file contents
Could not find or access '/opt/mapr/installer/mapr_ansible/playbooks/configure_master.yml' on the Ansible Controller.
Workaround: Run the following command to update the update_services.yml file:
sed -i 's/configure_master.yml/configure_security_controller.yml/g' 
/opt/mapr/installer/mapr_ansible/playbooks/update_services.yml
IN-2985
When you install Data Fabric on Ubuntu 20.04 with Python 2 specified as the default Python package, and you choose the option to install the mysql server, the installation can fail with the following message:
No package matching 'python-mysqldb' is available
The installation fails because Ansible is missing a dependency for communicating with MySQL.
Workaround: On the Installer node, set an option in the ansible.cfg file to force Ansible to use Python 3. For example, set the following option:
interpreter_python = /usr/bin/python3
Then rerun the installation.
IN-3016
On Installer 1.16 and earlier, clicking Abort during the Extend Cluster operation returns you to the verification page and does not reset the Installer database back to its initial state.
(Note that on Installer 1.17 and later, clicking Abort resets the Installer database automatically so that you can retry the operation.)
Workaround: On Installer 1.16 and earlier, use these steps to reset the Installer database manually and retry the Extend Cluster operation:
  1. Click Support > Reset Installer. This command uninstalls the metadata from the Installer database. For more information, see Resetting the Installer Database.
  2. Click Support > Import State. The Cluster State dialog box appears, enabling you to reset the cluster to the last known state. For more information, see Importing or Exporting the Cluster State.
  3. Click Reset to recover the Installer to the last known state and return to the Installer home page.
  4. If necessary, retry the Extend Cluster operation.
IN-3007
During a multinode installation of core 6.2 on SLES 15 SP2, the Installer returns the following error:
 "msg": "user {{ ssh_id }} does not have the ability to elevate privileges - check for correct sudoers config for example"
This issue can occur when Python is not installed on all cluster nodes.
Workaround: Check to ensure that Python is installed on all cluster nodes. Install Python, if it is not already installed.
IN-2924
Upon restart, cluster nodes running Loopback NFS do not remount /mapr. This issue can occur when using Installer 1.16.0.0 to perform a new or incremental installation. The issue is caused by a missing symlink.
Workaround: Manually create a symlink from /usr/local/mapr-loopbacknfs/conf/mapr_fstab to /opt/mapr/conf/mapr_fstab, and use the following commands to restart NFS and mount /mapr:
  1. Restart the Loopback NFS service:
    maprcli node services -nodes <node names> -nfs restart
  2. Run the mount_local_fs.pl script to mount /mapr:
    /opt/mapr/bin/mount_local_fs.pl
IN-2397
The Verify phase of the Installer can fail if the authorized_keys file contains a command such as the following:
no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="echo 'Please login as the user \"admin\" rather than the user \"root\".';echo;sleep 10" ssh-rsa ...
Any command in the authorized_keys file prevents the Installer from authenticating with remote nodes.
Workaround: Verify that the authorized_keys file does not contain commands that prevent the Installer from authenticating with remote nodes. In addition, if you are using keys for remote authentication, you must ensure that you can ssh into all nodes in the cluster using the user and password that you specified when you configured remote authentication.
IN-2500
After a new installation, the Installer home page displays two YARN ResourceManager links, but one of the links does not work.
Workaround: This is normal. Click the YARN ResourceManager links until you find the link that works. Even if the ResourceManager is installed on multiple nodes, the YARN ResourceManager only has one server running at a time, . If the running ResourceManager fails, a new ResourceManager is started on one of the other nodes.
SPYG-1136
During a manual installation or upgrade, Collectd provided in core 6.1.0 won't start on RHEL / CentOS 8.2 because it expects the Python 2 libraries to be installed, and RHEL / CentOS 8.2 provides the Python 3 libraries instead. This issue does not affect installations or upgrades performed using the Installer.
Workaround: Before installing the monitoring components, check to see if Python 2 is installed. If the following error is generated, try installing Python 2 on RHEL / CentOS 8.2:
failed: libpython2.7.so.1.0: cannot open shared object file
IN-2637
After a manual installation, Oozie and Hive services can fail to connect to a MySQL or MariaDB database because the server time-zone value is unrecognized or represents more than one time zone. The issue affects your installation if you applied the mapr-patch released on or after February 21, 2021 (including the latest mapr-patch). This issue affects manual installations but is fixed in Installer 1.14.0.0.
Workaround: For manual installations, you must configure either the server or JDBC driver (using the serverTimezone configuration property) to use a more specific time-zone value if you want to utilize time-zone support. After running configure.sh but before starting the Oozie or Hive services, update the serverTimezone parameter in the hive-site.xml or oozie-site.xml. For more information, see MySQL Bug #95036.
IN-2935
On RHEL or CentOS 8.3, new installations using the Installer can fail with the following error message:
mount.nfs: access denied by server while mounting localhost:/mapr
This happens when the Installer cannot start the mapr-loopbacknfs service because the RHEL or CentOS NFS/NFS4 service is running.
Workaround: Edit the /etc/systemd/system/mapr-loopbacknfs.service file to add the following Conflicts directive to the nfs-mountd.service:
[Unit]
Description=MapR Technologies, Inc. loopbacknfs service
After=rc-local.service
After=network.target syslog.target
Conflicts=nfs-mountd.service
The Conflicts command stops nfs-mountd before installation so it cannot interfere with starting mapr-loopbacknfs. After editing the loopbacknfs.service file, perform a daemon reload using the following command, and then retry the installation:
systemctl daemon-reload
IN-2947
For Installer 1.16.0 on Ubuntu 18.04, the Extend Cluster operation fails for clusters larger than three nodes. The operation fails on nodes where ZooKeeper is not installed. The failure occurs because the Installer attempts to update the ZooKeeper service file on a node that has no roles file for ZooKeeper.
Workaround: Make sure ZooKeeper is running on every node in the cluster, and retry the Extend Cluster operation.
ES-77, FLUD-55
During an upgrade from EEP 6.x to EEP 7.0.0 or EEP 7.0.1, some monitoring components do not get updated because of an error in the fourth digit of the package version. This issue can occur during manual upgrades or upgrades performed using the Installer. The affected components can include any or all of the following:
  • Elasticsearch
  • Fluentd
  • Grafana
  • Kibana
Workaround: See Reinstalling Monitoring Components After an Upgrade in the data-fabric documentation.
IN-1976
During a version upgrade from core 6.0.1 and EEP 5.0.x to a later version of core, the upgrade succeeds, but the following error message is generated:

This version of Kibana requires Elasticsearch v6.2.3 on all nodes. I found the following incompatible nodes in your cluster: v5.4.1 @ 10.10.103.231:9200 (10.10.103.231), v5.4.1 @ 10.10.102.21:9200 (10.10.102.21), v5.4.1 @ 10.10.103.230:9200 (10.10.103.230)

This happens because the Elasticsearch package script does not remove Elasticsearch completely and does not shut it down. Even though a new version of Elasticsearch is installed, the old version is still running and using the port needed by the new version.
Workaround:
  1. Use the jps command to find the process for the old Elasticsearch.
  2. Use kill -9 to shut down the old Elasticsearch process. Warden will restart the newly installed Elasticsearch.
IN-2742
A configure.sh operation can hang because of a system control hang if you try to install on top of a "minimal" operating system installation and the RDMA RPM or service is not present. This issue can occur during manual installations or during installations using the Installer.
Workaround: Before running configure.sh, use one of the following workarounds:
Workaround #1 - Install the missing RDMA Dependencies
  • RHEL / CentOS
    1. Install libibverbs:
      yum install libibverbs
    2. Enable and start the RDMA service: 
      systemctl enable rdma && systemctl start rdma
    3. Retry the HPE Ezmeral Data Fabric installation.
  • Ubuntu 18
    1. Install the rdma-core package: 
      apt-get install rdma-core
    2. Install libibverbs1: 
      apt-get install libibverbs1
    3. Enable and start the RDMA service: 
      systemctl enable iwpmd && systemctl start iwpmd
    4. Retry the installation.
  • Ubuntu 16

    Release 6.2 does not provide RDMA support for Ubuntu 16 because Ubuntu 16 does not have the rdma-core package.

Workaround #2 - Disable RDMA Support
  1. Rename /opt/mapr/lib/libibverbs.so. For example: 
    mv /opt/mapr/lib/libibverbs.so /opt/mapr/libibverbs.so.sv
  2. Restart the ZooKeeper and Warden nodes.
Workaround #3 - Install the Latest Core Patch
The latest patch contains the export MAPR_RDMA_SUPPORT=false environment variable, which removes RDMA support. For patch information, see "Downloading a Patch" in the data-fabric documentation.
IN-2784 & MFS-11853
Stopping a cluster by stopping ZooKeeper and Warden can cause clients that are accessing the file system through POSIX (for example, the S3 gateway) to hang if Loopback NFS is installed on a cluster node and is not stopped first. Note that beginning with Installer 1.15, the Installer installs Loopback NFS on all cluster nodes unless NFS is enabled.
Workaround: If Loopback NFS is running and you need to stop the cluster, you must first unmount /mapr and stop Loopback NFS on all nodes. Then, you can stop ZooKeeper and Warden. For more information, see "Managing the mapr-loopbacknfs Service" in the data-fabric documentation.
IN-1343
In a new installation of six nodes or more using the Installer, if only data nodes fail to install, retrying the installation can fail.
Workaround: Use the Installer uninstall feature, and retry the installation from scratch. See "Uninstalling Software Using the Installer Uninstall Button" in the data-fabric documentation.
IN-2132
On a SLES cluster, using Installer version 1.10 or earlier of the mapr-setup.sh script can complete successfully even if sshpass is not installed.
Workaround: Upgrade to the latest Installer. You must use version 1.11 or later of the mapr-setup.sh script. If you cannot use Installer version 1.11 or later of the mapr-setup.sh script, install sshpass before running the mapr-setup.sh script on a SLES cluster.
IN-2008
When you upgrade from a secure 6.0.0 cluster to 6.0.1 using Installer 1.9, a security certificate for log monitoring is overwritten. As a result, Elasticsearch can fail to start after the upgrade. This issue is not present during a new installation of 6.0.0 or 6.0.1 or during an upgrade to 6.1.0. This issue is fixed in Installer 1.10 and later.
Workaround: To resolve the issue, you must remove the .keystore_password file, re-run the command to generate new Elasticsearch certificates, and then re-distribute the certificates. Use these steps:
  1. Remove or rename the .keystore_password file. For example:
    rm /opt/mapr/elasticsearch/elasticsearch-x.x.x/etc/elasticsearch/.keystore_password
  2. Perform steps 3 through 7 of "Step 9: Install Log Monitoring" in the data-fabric documentation. Completing steps 3 through 7 regenerates the Elasticsearch certificates and copies them to the other nodes.
IN-2443
An internal server error that includes a NullPointerException can be generated if you install a cluster on Ubuntu 16 using a Installer Stanza. The error appears if Hive is installed but no password for Hive is included in the .yaml installation file.
Workaround: Add the Hive password to the .yaml installation file and re-run the Stanza.
IN-18
When using the -v or --verbose options with Installer Stanzas, detailed error information is not provided on the command line. For example, if a mapr user or group is not present on a host during a new installation, the mapr-installer-cli reports "Verification Error" on the command line.
Workaround: To view more detailed error information when using the -v or --verbose options, check the installer-cli.log[.x] file after running the Stanza. For information about the Installer logs, see "Logs for the Installer" in the data-fabric documentation.
IN-2200
Deploying a release 6.0.1 cluster on AWS fails when the following parameters are specified:
  • diskType: io1
  • installerOnitsOwn: false
Workaround: Try using a diskType of gp2 (general-purpose SSD) instead of io1 (provisioned IOPs SSD), or set InstallerOnitsOwn to false instead of true. Then retry the deployment.
IN-2152
During a Installer upgrade from any release to 6.0.1, core files can be generated for ecosystem components, which can cause alarms in the Control System following the upgrade. This happens because the upgrade sequence shuts down the cluster, then upgrades Core packages, and then restarts Core. Restarting Core is necessary to upgrade some ecosystem components. When the old ecosystem components are started, version incompatibilities with the new version of Core can cause core dumps. This is a temporary issue. Upgrading the ecosystem component, which happens later in the upgrade process, resolves the issue. The issue does not exist in 6.1 and later releases, which have the ability to prevent services from restarting during an upgrade.
Workaround: Ignore the Control System alarms, or upgrade to 6.1 or later, which should not generate core alarms.
IN-1940
In Installer versions 1.9 and earlier, the probe command can fail because of a runtime error if you have installed the Operational Applications with HPE Ezmeral Data Fabric Database template. The error is caused by the presence of the mapr-drill-internal package. Any node running the Data Access Gateway requires the mapr-drill-internal package to be installed even though Drill is not installed as a service. The mapr-drill-internal package provides a set of client libraries used by the Data Access Gateway.
Workaround: Before using the probe command, update the Installer. The probe command is fixed in versions 1.10 and later.
IN-1635
In Installer Stanza versions 1.9 and earlier, the probe command was hard coded with a cluster admin user of mapr. If you configured a cluster admin user other than mapr, the probe-generated YAML file could not be imported using the import command.
Workaround: Before using the probe command, update the Installer to version 1.10 or later. Or, if you must use version 1.9 or earlier, edit the probe-generated YAML file to specify the correct cluster admin user.
IN-2123
In a secure cluster, the Extend Cluster operation fails if you try to extend the control group. The new control node cannot join the cluster because it inadvertently receives a new set of keys. This issue affects versions 1.7 through 1.10 of the Installer and is fixed in Installer 1.10.0.201812181130 and later versions.
Workaround: You can resolve the issue by manually copying mapruserticket into the /opt/mapr/conf directory of the node to be added to the cluster.
IN-2141
The following issue applies to Installer versions 1.7 through 1.10, but not all 1.10 versions. The issue is fixed in Installer 1.10.0.201812181130 and later versions.
An extend cluster (add node) operation can fail when you:
  1. Install a 6.x cluster manually with security enabled.
  2. Run the Installer Stanza probe command on the cluster or on a node to be added to the cluster.
  3. Use the import command to import the probe .yaml file into the Installer.
  4. Perform an extend cluster operation immediately after the import operation.

The extend cluster operation fails because keystore, truststore, and server ticket (maprserverticket) files are not present on the installer node.

Workaround:
Before attempting the extend cluster operation, copy the keystore, truststore, and server ticket (maprserverticket) files from any CLDB node to /opt/mapr/installer/data/tmp on the installer node. The files that need to be copied are:
  • cldb.key
  • dare.master.key*
  • maprserverticket
  • ssl_keystore
  • ssl_keystore.p12
  • ssl_keystore.pem
  • ssl_truststore
  • ssl_truststore.p12
  • ssl_truststore.pem
*The DARE primary key is required only if DARE is enabled.

If metrics monitoring is configured on the cluster, you must also copy the tickets related to Fluentd, Kibana, and Elasticsearch to the same location.

IN-2217
During an upgrade to EEP 6.1.0 using the Installer, the Installer does not back up the Drill conf, log, and jar directories into ${MAPR_HOME}/drill/OLD_DRILL_VERSIONS. This can happen when you upgrade Drill from an old version (for example, Drill 1.10 in EEP 3.0) to Drill 1.15.0.0 in EEP 6.1.0.

Recent packaging changes in Drill contribute to this issue. Drill 1.10 consists only of mapr-drill-1.10 (role and binaries), whereas Drill 1.15.0.0 consists of mapr-drill-1.15 (roles) and mapr-drill-internal-1.15 (binaries). During the upgrade, the mapr-drill-1.10 binaries are successfully uninstalled, but the OLD_DRILL_VERSIONS directory that is needed to back up Drill 1.10 is not created.

Workaround:
Before upgrading, perform the following steps:
  1. Shut down the mapr-drill-1.10 Drillbits.
    maprcli node services -name drill-bits -action stop -nodes <node hostnames separated by a space>
  2. Create ${MAPR_HOME}/drill/OLD_DRILL_VERSIONS/drill-1.10.
  3. Copy the following directories of mapr-drill-1.10 into the OLD_DRILL_VERSIONS directory:
    1. Copy the conf directory to ${MAPR_HOME}/drill/OLD_DRILL_VERSIONS/drill-1.10.0/conf.
    2. Copy the logs directory to ${MAPR_HOME}/drill/OLD_DRILL_VERSIONS/drill-1.10.0/logs.
    3. Copy the jars/3rdparty directory to ${MAPR_HOME}/drill/OLD_DRILL_VERSIONS/drill-1.10.0/jars.
  4. Proceed with the upgrade.
  5. After successfully upgrading and starting mapr-drill-1.15.0.0, you may remove the ${MAPR_HOME}/drill/drill-1.10.0 directory.
IN-1915
During an upgrade using the Installer, refreshing the browser page can cause the Installer to forget upgrade parameters that were specified before the refresh.
Workaround: Avoid refreshing the browser page during an upgrade operation. If you must refresh the page, go back to the first page of the upgrade operation and start over again to ensure that the Installer has the correct parameters before it begins the Verify phase of the upgrade.
IN-2035
During a version upgrade using the Installer, if you select the Advanced Configuration button and then click Previous (one or more times) followed by Abort, the Installer can indicate that the upgrade completed even though the upgrade was aborted.
Workaround:
If this happens, you must reset the installer and reload the last known state. Follow these steps to reset the cluster state:
  1. Click Support > Reset Installer. A warning screen appears.
  2. Click OK.
  3. Click Support > Import State.
  4. Click Reset to recover the cluster to the last known state. It is safe to retry the upgrade at this point.
For more information about the Reset Installer and Import State commands, see "Resetting the Installer Database" and "Importing or Exporting the Cluster State" in the data-fabric documentation.
IN-2065
/mapr sometimes does not get mounted after you enable NFS (v3 or v4) using the Installer Incremental Install function. The Incremental Install function is an online operation. Enabling NFS using an Incremental Install can create a race condition between when the mapr_fstab file gets created and NFS is started by Warden. If NFS is started by Warden before the mapr_fstab file is created, /mapr does not get mounted.
Workaround:

If /mapr is not mounted, check the time stamp of the /opt/mapr/conf/mapr_fstab file to see if it is older than the time stamp in the warden.log file for starting NFS. For example: 

[root@atsqa4-61 logs]# ls -ld /opt/mapr/conf/fstab
rw-rr- 1 mapr mapr 39 Sep 26 11:31 /opt/mapr/conf/mapr_fstab

[root@atsqa4-61 logs]# fgrep starting warden.log | fgrep nfs
2018-09-26 11:29:33,407 INFO com.mapr.warden.service.baseservice.Service [Thread-34]: -------------Service is starting for: nfs4
If the time stamp of the mapr_fstab file is older than the Warden time stamp:
  1. Restart the NFS service:
    maprcli node services -nodes <node names> -nfs4 start
  2. Run the mount_local_fs.pl script to mount /mapr:
    /opt/mapr/bin/mount_local_fs.pl
INFO-420
The procedure for configuring storage using disksetup does not work for new installations of DARE-enabled 6.1 clusters. With DARE enabled, disksetup fails on any node that is not a CLDB node because there is no local copy of the dare.master.key file. When you use disksetup, non-CLDB nodes try to contact the CLDB, which must be running when the nodes attempt contact.
Workaround:
After running configure.sh, you must:
  1. Format the disks on the CLDB nodes.
  2. Start ZooKeeper on the ZooKeeper nodes.
  3. Start Warden on the CLDB nodes.
  4. Format the remaining node disks using disksetup.
  5. Start Warden on the remaining nodes.
IN-2057
A fresh install of 6.0.0 using the sample_advanced.yaml file for Installer Stanzas (Installer version 1.9) can fail with the following error message:
ERROR: install command failed
Service mapr-data-access-gateway must be a member of a template group. Configured services require it: ['mapr-data-access-gateway']
The error is generated because the .yaml file is missing an entry for the mapr-data-access-gateway in the MASTER services section. The mapr-data-access-gateway service is needed for HPE Ezmeral Data Fabric Database installations.
Workaround:

In the MASTER services section of the sample_advanced.yaml file, add mapr-data-access-gateway to at least one of the host groups, and retry the installation.

IN-1272
During an upgrade to 6.0 or later (Drill 1.11), configure.sh sometimes fails to disable the storage plugin for HBase. The HBase server is not supported in Core 6.0 or later, so the HBase storage plugin should be disabled before a cluster is upgraded to 6.0 or later. Otherwise, Drill queries against HBase will hang.
Workaround:
Before upgrading to Drill 1.11 or later, manually disable the HBase storage plug-in. To manually disable the plug-in, you can use the Drill Web Console or Drill REST API commands. You can disable the HBase storage plugin on the Storage page of the Drill Web Console at http(s)://<drill-hostname>:8047. For more information, see this page:
https://drill.apache.org/docs/rest-api-introduction/#delete-/storage/{name}.json
IN-1747
If you use the Installer 1.10 Uninstall button to uninstall software and a node is unreachable, you will not be able to uninstall the node later when the node is reachable.
Workaround:

Uninstall the software on the node manually. See "Decommissioning a Node and Uninstalling Data Fabric Software from the Command-line" in the data-fabric documentation.

IN-2015
A fresh install of 6.0.0 with EEP 4.1.1 using Installer 1.9 can fail with the following error message:
file not found: /opt/mapr/elasticsearch/elasticsearch-5.4.1/etc/elasticsearch/sg/admin-usr-clientCombo.pem
Workaround: Update the Installer to version 1.10 or later, and retry the operation.
IN-2018
Logging on to Kibana results in an authentication failure. This can happen on a CentOS cluster if you use Installer 1.10 to install 6.0.1 EEP 5.0.0, and then upgrade to 6.1.0 and EEP 6.0.0.
Workaround: Try using Installer 1.9 to install the 6.0.1 cluster and Installer 1.10 to upgrade the cluster. See "Updating the Installer" in the data-fabric documentation.
CORE-150
After using the Incremental Install function of the Installer to apply security to an Azure-based 6.1.0 cluster, the Hue and Spark-thrift server links are not accessible in the Installer interface. This issue can occur on an Azure-provisioned cluster whose internal DNS suffix starts with a number rather than a letter.
Workaround: Re-create the cluster in Azure so that the internal DNS suffix starts with a letter and not a number.
IN-2025
The Extend Cluster operation can fail during the Verify Nodes phase with an error indicating Unscalable host groups found. This error can occur when the MASTER group is missing or a single-instance service (for example, Grafana) has been moved out of the MASTER group. The mapr-installer.log reveals which cluster services are supposed to be in the MASTER group.
Workaround: Move any original MASTER services that caused the error back to the MASTER group. The mapr-installer.log indicates the services that need to be moved along with the Unscalable host groups found error.
IN-2006
On a cluster with mapr-drill installed, the probe command can return the wrong database type value.
Workaround:
After using the probe command, check to see if the resulting YAML file has the correct mapr_db setting. Possible settings are:
  • QS
  • DRILL
  • DRILLQS

If necessary, change the setting in the YAML file to match the value from the probed cluster.

IN-1955
If you install cluster software using the Installer in a browser and then upgrade the installer in the same browser tab and attempt an upgrade without starting a new browser, the stale browser cache can cause upgrade errors.
Workaround: Clear your browser cache or open a new browser tab whenever you need to update the Installer and perform a new installer operation.
IN-1983
After an upgrade from release 5.x to release 6.1 and EEP 6.0.0 using the Installer, the kafka-connect service fails to start. This issue has been noticed on platforms that use systemd.
Workaround: Stop the kafka-connect service manually, and restart the service.
IN-1972
During an upgrade from release 5.x to release 6.1, the Installer prompts you for the MySQL user ID and password. If you enter a password that is different from the password you provided when you originally configured MySQL through the Installer, the upgrade fails with this error: "Unable to connect to database.…"
Workaround: When the Installer prompts you for the MySQL user ID and password, enter the password that you specified when you first installed the cluster. If you did not specify a password for MySQL when you installed release 5.x, leave the password field blank.
IN-1904
If you initiate a system startup by clicking the Startup button on the Installer web interface, the Authentication screen is displayed. If you subsequently click the Previous button, the following buttons are shown as active even though they are not usable during system startup:
  • Extend Cluster
  • Incremental Install
  • Maintenance Update
  • Shutdown
  • Uninstall
Workaround: Do not use the Previous button during startup.
IN-1657
After updating the Installer 1.7 or later, the Installer can lose awareness that a cluster was previously installed. For example, the Installer might indicate the need for a fresh install.
Workaround: If this happens, do NOT proceed with installation or upgrade operations. Follow these steps to reset the cluster state:
  1. Click Support > Reset Installer. A warning screen appears.
  2. Click OK.
  3. Click Support > Import State.
  4. Click Reset to recover the cluster to the last known state. It is safe to use the Installer at this point.
IN-1804
For release 6.0 or later clusters, enabling security by using the Incremental Install function can overwrite custom certificates in the ssl_truststore and ssl_keystore files. When you turn on security, the Installer runs the configure.sh script on the CLDB primary node to generate security keys and then distributes the keys to all the other CLDB nodes. The installer also distributes certificates to all the other nodes. This process can cause custom certificates to be overwritten. However, before enabling security, the Installer makes a backup of the existing ssl_keystore and ssl_truststore files.
Workaround:
After enabling security, locate the backup of the ssl_keystore and ssl_truststore files. The backup uses this format: 
/opt/mapr/conf/ssl_keystore.sv.<timestamp>
Extract any custom certificates from the backup files, and manually merge or add them into the new ssl_keystore and ssl_truststore files.

To merge the files, you can use the /opt/mapr/server/manageSSLKeys.sh utility, as shown in "Configuring Secure Clusters for Running Commands Remotely" in the data-fabric documentation.

IN-997
When using Installer 1.9 with Ubuntu distributions, an upgrade of the Installer definitions requires a restart of the installer service. The restart is needed because the Installer services version is not updated properly when you use either of the following commands:
  • mapr-setup.sh reload
  • apt-get install mapr-installer-definitions
Workaround: After installing or reloading the Installer definitions, issue one of these commands to fix the services version:
  • service mapr-installer restart
  • systemctl restart mapr-installer
IN-1671
For Installer 1.8 and earlier, installation on Ubuntu 16.04 can fail if Python 2 is not available or if the default is set to Python 3. The installer requires python and python-yaml to be installed on all nodes.
Workaround: To install the Python packages manually:
sudo apt-get install python python-yaml -y
IN-1336
The Installer Retry function can be affected if the installer operation fails. Suppose you deselect a service during an Incremental Install operation. If the Incremental Install fails and you need to Retry, it's possible that the service will not be deselected (uninstalled).
Workaround: Manually remove (uninstall) the service by using one of these commands:
  • Red Hat / CentOS: yum remove
  • Ubuntu: apt-get remove
  • SLES: zypper remove
IN-1392
During an Extend Cluster (add node) operation using the Installer, if installation of the added node fails and you abort the operation, the installer can display the added node even though it did not get installed.
Workaround: When the Installer indicates that a node did not get added correctly (typically during the Installation phase), select the node and click Remove Node. Then retry adding the node.
IN-1396
An installation using the Installer fails with the following Ansible module error:
nValueError: need more than 1 value to unpack
Workaround: Check for syntax errors in the /etc/sysctl.conf file, which can cause an Ansible error when the Installer is attempting to set various kernel parameters.
IN-1398
In the Installer Verify Nodes page, if you click a host, the Disks Selected for MapR box in the right pane displays the disks that were specified for the host either manually or automatically. If you deselect a disk in the right pane and click Retry, the deselection is not always implemented.
Workaround: Click Previous to go back to the Node Configuration page, and re-specify the disks that you want. Then continue with the operation.
IN-1386
On a secure cluster, YARN jobs can fail if you specify IP addresses rather than host names when you configure nodes using the Installer.
Workaround:

Do not use an IP address for node configuration with the Installer. If you already used an IP address, change the IP address in the yarn-site.xml file on all nodes. In the following example, the 10.10.10.7 IP address must be changed to a host name, such as bld73.qa.lab:

<property>
<name>yarn.timeline-service.hostname</name>
<value>10.10.10.73</value>
</property>
IN-1333
On Ubuntu clusters, the mapr-setup.sh script fails to reload the Installer definitions during an update of the installer and definitions.
Workaround: After updating, restart the installer to load the definitions:
service mapr-installer restart
IN-907
The Installer service fails if the mapr user or root user already exist and they are configured to use a shell other than bash. For more information about user requirements, see "Installer Prerequisites and Guidelines" in the data-fabric documentation.
Workaround: Configure the users to use bash. For more information about user requirements, see "Installer Prerequisites and Guidelines" in the data-fabric documentation.
IN-1079
Verification fails when the installed language pack is for a language other than English.
Workaround: Remove the non-English language pack and install the English language pack. In the following example, the non-English language pack is shown as German. Also, make sure your system locale is set to en_us, as described in "Infrastructure" in the data-fabric documentation.
sudo apt-get install language-pack-en language-pack-en-base manpages
sudo apt-get remove language-pack-de language-pack-de-base manpages-de
IN-804
Using the Incremental Install operation to add a third node to a CONTROL group generates an error: ERROR: configure_refresh.sh failed. This issue applies to Installer versions 1.6 and earlier.
Workaround: Update the Installer to version 1.7 or later, and retry the operation. See "Updating the Installer" in the data-fabric documentation.
IN-1314
When you use the Installer to install ecosystem components that require a MySQL component such as Hive, Oozie, or Hue, the passwords you provide to install the MySQL database are displayed in the mapr-installer.log and <nodename>.log files. Beginning with Installer 1.7, the permissions for the mapr-installer.log and <nodename>.log files are changed so that these passwords are not world readable. However, the passwords are still present in log files created with earlier versions of the Installer.
Workaround: For increased security, remove the earlier logs or change the user permissions for them.
IN-1042
Installation of the 5.2.x mapr-metrics package on SLES 12 SP2 fails because the libmysqulclient16 package is not present. This can happen when mapr-metrics is installed manually or using the Installer. This issue was detected during installations of release 5.2.x with EEP 3.0.0.
Workaround: None.
IN-870
If your cluster uses 2-digit EEPs, and you use the Installer Extend Cluster button to add a node, the node can be added with a patch version that is different from the patch version of other nodes in the cluster. See "Understanding Two-Digit and Three-Digit MEPs" in the data-fabric documentation.
Workaround: A one-time change can prevent this issue. After updating the Installer from version 1.5 to version 1.6 or later, but before performing any Installer operations, use an Incremental Install function to change your 2-digit EEP version to the equivalent 3-digit EEP version. See "Updating the Installer" in the data-fabric documentation.
ES-27, IN‑1387
On a new installation of a secure cluster using the Installer, Elasticsearch fails to start, and logs indicate that Elasticsearch key generation failed. When this happens, Kibana and Fluentd also do not start. The Installer allows the installation to complete.
Workaround: Check the installer log for a message indicating that Elasticsearch could not be secured. Use the Incremental Install feature of the Installer to retry installation of the Monitoring logging components. Alternatively, you can configure security for the logging components manually. See "Step 9: Install Log Monitoring" in the data-fabric documentation.
IN-1332
On clusters with less than the recommended memory configuration (16 GB per node), services added during an Incremental Install operation might fail to start because Warden allocated available memory to the filesystem. The Installer might not indicate a problem with the newly added services. If this issue occurs, the filesystem cannot relinquish memory without restarting Warden.
NOTE
This issue can also occur on clusters with more than 16 GB of memory per node if the installed services require more memory than is currently installed.
Workaround:

Use the Control System or the maprcli service list -node command to determine if the added services are running. If not, perform a rolling restart of the nodes to which the new services were added. The rolling restart will rebalance memory across the filesystem and services. One node at a time, restart Warden on each node following the group upgrade order prescribed in "Manual Rolling Upgrade Description" in the data-fabric documentation. Use the following steps:

  1. Change to the root user (or use sudo for the following commands).
  2. Stop Warden.
    sudo service mapr-warden stop
  3. Restart Warden.
    service mapr-warden start
IN-1339
Installation fails with the Installer reporting an Unexpected failure during module execution, and the following entry is present in the "Logs for the Installer" described in the data-fabric documentation:
os.write(self.sshpass_pipe[1], to_bytes(self._play_context.password) + b'\n')
OSError: [Errno 9] Bad file descriptor
Workaround: Change the ssh settings as described in known issue IN-405 later on this page, and retry the installation.
IN-553
New installations on Ubuntu 14.04 using Installer 1.6 or 1.7 can fail because of a JDK 1.8 issue.
Workaround:

If you are installing on Ubuntu 14.04, you must install Java JDK 1.8 before running the Installer. For more information, see this website. If you are installing on RHEL/CentOS or SLES, the Installer installs Java JDK 1.8 for you.

IN-405
Installation or cluster import using the probe command fails with the error message: "Failed to resolve remote temporary directory from ansible-tmp- ...."
Workaround:

To proceed using the Installer, disable SSH connection reuse by including this entry underneath the [ssh_connection] property of /opt/mapr/installer/etc/ansible.cfg:

ssh_args=-o ControlMaster=no -o ControlPath=none -o ControlPersist=no

This workaround can lead to longer install times. We recommend that you resolve any network connectivity issues in your environment.

IN-250
An upgrade to a new core version and a new EEP using the Installer can fail if the cluster being upgraded was initially installed with Hive Metastore but not with Hive. The Hive Metastore package has an installation dependency on Hive, but the Hive Metastore definitions do not enforce the dependency, resulting in inconsistencies in the installer database. This issue has been observed on Ubuntu platforms.
Workaround:

Before upgrading, if you have Hive Metastore installed by itself, use the Incremental Install feature of the Installer to install Hive. Then proceed with the upgrade.

Performing an upgrade without doing the Incremental Install of Hive will cause the upgrade to fail. In this scenario, you will have to reinstall or rebuild the database by using Stanza commands. You can use the reset command, followed by probe, and then edit the versions in the resulting YAML file. The last step is to import the edited YAML using the import command. See "Using probe and import to Generate the Installer Database" in the data-fabric documentation.

N/A
The Installer Web Interface can inadvertently deselect services that you have selected, preventing them from being installed. For example, if you select an auto-provisioning template on the Select Services page, and you also select additional services (for example, Streams Tools), and go to the next page, when you return to the Select Services page, Streams Tools will be deselected, and you will need to reselect it to ensure that it is installed.
Workaround: Reselect any services that are deselected.
MAPR-20606
The Configure Service Layout page may assign services to a group with the name "Unprovisioned Services."
Workaround: In the Installer Web Interface, click Restore Default.
N/A
You cannot use the Installer after you upgrade the cluster using the command line.

After you use the command line to upgrade a cluster that you installed with the Installer, the Installer is not aware that the cluster runs the upgraded version. Therefore, Installer does not install nodes and ecosystem components that apply to the upgraded version.

Workaround: Use the Installer Stanzas probe and import commands to update the installer database. See "Using probe and import to Generate the Installer Database" in the data-fabric documentation.