ALM-12066 Trust Relationships Between Nodes Become Invalid
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.)
- 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.
- 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.)
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:
- 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 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.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot