Installer Known Issues

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.

IN-2705

If you used the Installer to install Sentry on an insecure cluster, you must manually add Sentry to the list of services that Warden monitors. To add Sentry to the list of services that Warden monitors, copy /opt/mapr/sentry/sentry-<version>/conf.d/warden.sentry.conf to /opt/mapr/conf/conf.d.

Neither Hive nor Impala is configured to use Sentry by default; however, you can configure Hive and Impala to use Sentry, as described in Configure Hive to use Sentry Authorization and Configure Impala to Use Sentry Authorization

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 MEP 6.x to MEP 7.0.0 or MEP 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 MEP 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:

Use the jps command to find the process for the old Elasticsearch.
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

Rename /opt/mapr/lib/libibverbs.so. For example:

mv /opt/mapr/lib/libibverbs.so /opt/mapr/libibverbs.so.sv

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 Object Store) 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 SUSE 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 SUSE 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:

Remove or rename the .keystore_password file. For example:

rm /opt/mapr/elasticsearch/elasticsearch-x.x.x/etc/elasticsearch/.keystore_password

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:

Install a 6.x cluster manually with security enabled.
Run the Installer Stanza probe command on the cluster or on a node to be added to the cluster.
Use the import command to import the probe .yaml file into the Installer.
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 MEP 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 MEP 3.0) to Drill 1.15.0.0 in MEP 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:

Shut down the mapr-drill-1.10 Drillbits.

maprcli node services -name drill-bits -action stop -nodes <node hostnames separated by a space>

Create ${MAPR_HOME}/drill/OLD_DRILL_VERSIONS/drill-1.10.
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.
Proceed with the upgrade.
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:

Click Support > Reset Installer. A warning screen appears.
Click OK.
Click Support > Import State.
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:

Restart the NFS service:

maprcli node services -nodes <node names> -nfs4 start

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:

Format the disks on the CLDB nodes.
Start ZooKeeper on the ZooKeeper nodes.
Start Warden on the CLDB nodes.
Format the remaining node disks using disksetup.
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 MEP 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 MEP 5.0.0, and then upgrade to 6.1.0 and MEP 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 MEP 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:

Click Support > Reset Installer. A warning screen appears.
Click OK.
Click Support > Import State.
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
SUSE: 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 SUSE 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 MEP 3.0.0.

Workaround: None.

IN-870

If your cluster uses 2-digit MEPs, 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 MEP version to the equivalent 3-digit MEP 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:

Change to the root user (or use sudo for the following commands).
Stop Warden.
```
sudo service mapr-warden stop
```
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 SUSE, 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 MEP 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.