ALM-12042 Incorrect Configuration of Key Files

Description

The system checks whether critical configurations are correct every 5 minutes. This alarm is generated when the configurations are abnormal.

This alarm is cleared when the configurations become normal.

Attribute

Parameters

Impact on the System

Functions related to the file are abnormal.

• If the configuration of key files okerberos and oldap is abnormal, the authentication fails and the job may fail to run.
• If the permission on the controller and pms key files is abnormal, the process may be faulty, which may affect the elastic scaling performance.
• If the permission on key Tomcat files is abnormal, the login and viewing functions of FusionInsight Manager are affected.

Possible Causes

The file configuration is modified manually or the system is powered off unexpectedly.

Procedure

Check abnormal file configuration.

1. On the FusionInsight Manager portal, choose O&M > Alarm > Alarms.

   For details about how to log in to FusionInsight Manager, see Accessing MRS Manager.

2. Check the value of HostName to obtain the host name involved in this alarm. Check the value of PathName to obtain the path or name of the abnormal file.
3. Log in to the node for which the alarm is generated as user root.

   For details about how to log in to a cluster node, see Logging In to an MRS Cluster Node.

4. View the $BIGDATA_LOG_HOME/nodeagent/scriptlog/checkfileconfig.log file and analyze the cause based on the error log. Locate the check standards of the file in the Related Information and manually check and modify the file based on the standards.

   Run the vi file name command to enter the editing mode, and then press Insert to start editing.

   After the modification is complete, press Esc to exit the editing mode and enter :wq to save the settings and exit.

   For example:

   vi /etc/ssh/sshd_config

5. Wait an hour and check whether the alarm is cleared.
   • If yes, no further action is required.
   • If no, go to Step 6.

Collect fault information.

6. On the FusionInsight Manager portal, choose O&M > Log > Download.
7. Select NodeAgent from the Service and click OK.
8. Click the edit icon in the upper right corner, and set Start Date and End Date for log collection to 10 minutes ahead of and after the alarm generation time, respectively. Then, click Download.
9. Contact the O&M personnel and send the collected log information.

Alarm Clearing

After the fault is rectified, the system automatically clears this alarm.

Related Information

• Checking the /etc/fstab file
  • Check whether the partitions configured in the /etc/fstab file can be found in the /proc/mounts file.
  • Check whether the swap partitions configured in fstab match those in /proc/swaps one by one.
• Checking the /etc/hosts file

  Run the command to check for any of the following situations. If any is found, the configuration file is abnormal.

  cat /etc/hosts

  • The /etc/hosts file does not exist.
  • The host name is not configured in the file.
  • The IP address of the host is duplicate.

    Solution: Delete unnecessary IP address-to-hostname mappings.

  • The IP address corresponding to the hostname is not contained in the command output of the ifconfig command.
  • One IP address maps to multiple host names in the file.

    Solution: Delete unnecessary IP address-to-hostname mappings.

  • The file does not contain the Hadoop local domain name mapping, for example, xxx hadoop.example.com.

    Solution:

    1. On Manager, choose System > Permission > Domain and Mutual Trust, and record the local domain.
    2. Log in to the current node as user root and run the following command to obtain the IP address of the local domain:

       su - omm

       cat "${BIGDATA_TMP}"/controller.properties | grep om.realm.parse.ip | awk -F "=" '{print($2)}'

    3. Log in to the current node as user root and configure the mapping between the IP address and the local domain in the /etc/hosts file, for example, xxx hadoop.example.com.
• Checking the /etc/ssh/sshd_config file

  Run the following command to verify the following configuration items:

  vi /etc/ssh/sshd_config

  • The value of UseDNS must be no.
  • The value of MaxStartups must be greater than or equal to 1000.
  • At least one of the PasswordAuthentication and ChallengeResponseAuthentication configuration items must be left empty or set to yes.
• Checking the built-in client files

  Check whether any of the following conditions exists in the built-in client directory ${BIGDATA_HOME}/client on the active and standby OMS nodes. If yes, the built-in client file of the cluster is incorrectly configured.

  • The client symlink does not exist.

    Solution:

    If the client symlink does not exist, run the following command as the owner of the client directory:

    ln -s $BIGDATA_HOME/client_Cluster version  $BIGDATA_HOME/client

  • The actual client path does not exist.

    Solution: Delete the client and reinstall it.

  • The actual client path is empty.

    Solution: Delete the client and reinstall it.

  • The owner and owner group of the client symlink and actual path are not omm:wheel.

    Solution:

    Run the following command as the owner of the client directory:

    chown omm:wheel $BIGDATA_HOME/client

    chown omm:wheel $BIGDATA_HOME/client_Cluster version

  • The permission on the actual client path is not 700.

    Solution:

    Run the following command as the owner of the client directory:

    chmod 700 $BIGDATA_HOME/client_Cluster version

  • Run the following command to check whether the client contains files that are not owned by user omm:

    (Do not use user root to operate on the built-in client of the cluster, as this may generate root-owned files and cause client configuration update failures.)

    find "Actual client path" ! -user omm -ls

    If yes, run the following command as user root to change the file owner to omm:

    chown omm:wheel File path