On this page

Show all

Help Center/ MapReduce Service/ User Guide (Ankara Region)/ Alarm Reference/ ALM-12066 Trust Relationships Between Nodes Become Invalid

ALM-12066 Trust Relationships Between Nodes Become Invalid

Updated on 2024-11-29 GMT+08:00

View PDF

Alarm Description

The system checks whether the trust relationship between the active OMS node and other Agent nodes is normal every hour. The alarm is generated if the mutual trust fails. This alarm is automatically cleared after the fault is rectified.

Alarm Attributes

Alarm ID	Alarm Severity	Alarm Type	Service Type	Auto Cleared
12066	Major	Communications	FusionInsight Manager	Yes

Alarm Parameters

Type	Parameter	Description
Location Information	Source	Specifies the cluster or system for which the alarm was generated.
	ServiceName	Specifies the service for which the alarm was generated.
	RoleName	Specifies the role for which the alarm was generated.
	HostName	Specifies the host for which the alarm was generated.
Additional Information	Failed hosts	Specifies hosts that fail to be trusted.

Impact on the System

Some operations (such as restart, configuration synchronization, and instance status query) that need to connect to the node may fail. If the trust relationships between nodes are invalid, services may be affected.

Possible Causes

The /etc/ssh/sshd_config configuration file is damaged.
The password of user omm has expired.

Handling Procedure

Check the status of the /etc/ssh/sshd_config configuration file.

In the alarm list on FusionInsight Manager, locate the row that contains the alarm and click to view the host list in the alarm details.
Log in to the active OMS node as user omm.
Run the ssh command, for example, ssh host2, on each node in the alarm details to check whether the connection fails. (host2 is a node other than the OMS node in the alarm details.)
- If yes, go to 4.
- If no, go to 6.
Open the /etc/ssh/sshd_config configuration file on host2 and check whether AllowUsers or DenyUsers is configured for other nodes.
- If yes, go to 5.
- If no, contact OS experts.
Modify the whitelist or blacklist to ensure that user omm is in the whitelist or not in the blacklist. Check whether the alarm is cleared.
- If yes, no further action is required.
- If no, go to 6.

Check the status of the password of user omm.

Check the interaction information of the ssh command.
- If the password of user omm is required, go to 7.
- If message "Enter passphrase for key '/home/omm/.ssh/id_rsa':" is displayed, go to 9.
Check the trust list (/home/omm/.ssh/authorized_keys) of user omm on the OMS node and host2 node. Check whether the trust list contains the public key file (/home/omm/.ssh/id_rsa.pub) of user omm on the peer host.
- If yes, contact OS experts.
- If no, add the public key of user omm of the peer host to the trust list of the local host.
Add the public key of user omm of the peer host to the trust list of the local host. Run the ssh command, for example, ssh host2, on each node in the alarm details to check whether the connection fails. (host2 is a node other than the OMS node in the alarm details.)
- If yes, go to 9.
- If no, check whether the alarm is cleared. If the alarm is cleared, no further action is required; otherwise, go to 9.

Collect the fault information.

On FusionInsight Manager, choose O&M. In the navigation pane on the left, choose Log > Download.
Select Controller for Service and click OK.
Click in the upper right corner to set the log collection time range. Generally, the time range is 10 minutes before and after the alarm generation time. Click Download.
Contact O&M engineers and provide the collected logs.

Alarm Clearance

This alarm is automatically cleared after the fault is rectified.

Related Information

Perform the following steps to handle abnormal trust relationships between nodes:

NOTICE:

Perform this operation as user omm.
If the network between nodes is disconnected, rectify the network fault first. Check whether the two nodes are connected to the same security group and whether hosts.deny and hosts.allow are set.

Run the ssh-add -l command on both nodes to check whether any identities exist.
- If yes, go to 4.
- If no, go to 2.
If no identities are displayed, run the ps -ef|grep ssh-agent command to find the ssh-agent process, stop the process, and wait for the process to automatically restart.
Run the ssh-add -l command to check whether the identities have been added. If yes, manually run the ssh command to check whether the trust relationship is normal.
If identities exist, check whether the /home/omm/.ssh/authorized_keys file contains the information in the /home/omm/.ssh/id_rsa.pub file of the peer node. If it does not, manually add the information.
Check whether the permissions on the files in the /home/omm/.ssh directory are modified.
Check the /var/log/Bigdata/nodeagent/scriptlog/ssh-agent-monitor.log file.
If the /home directory of user omm is deleted, contact MRS support personnel for assistance.

Parent topic: Alarm Reference

Previous topic: ALM-12064 Host Random Port Range Conflicts with Cluster Used Port

Next topic: ALM-12067 Abnormal Tomcat Resources of Manager

Feedback

Was this page helpful?

Helpful Not helpful

Provide feedback

Thank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.

The system is busy. Please try again later.

Which of the following issues have you encountered?

Content is inconsistent with the product UI

Unclear descriptions

Lack of examples or code

Incorrect steps

Can't find what I need

Lack of best practices

Feedback (optional)

0/500

Select at least one type of issue, and enter your comments or suggestions.

Enter a maximum of 500 characters.

Submit Cancel

For any further questions, feel free to contact us through the chatbot.

Chatbot