A recent project is to use RABBITMQ, keepalived, and supervisor together. One scenario is that a keepalived instance is promoted to master and the client process needs to be killed on the remote host where the RABBITMQ client is deployed.
The general idea is to configure a password-free SSH login between the host where the keepalived resides and the client deployed, and then execute the remote command via SSH, first obtaining the process number of each client process, and then killing each of those processes individually.
The general idea is simple, but the process has encountered a lot of problems. The steps to configure a password-free SSH to a remote host are simple. Not much to say here. Once configured, you can use it directly in the script:
Ssh-p PORT IP "command"
Or
Ssh-p PORT IP ' command '
To execute the command on the remote host.
Let's talk about the general design problem.
At first it was straight-line thinking: Get the client process number remotely via SSH, SSH to the remote for each process number, respectively. Because there are multiple keepalived instances running on different hosts, it is necessary to maintain a list of clients that need to be processed on each host, and to perform a naming of the process number and the kill process multiple times via SSH to the remote deployment client host. This is disgusting in terms of maintenance and performance.
In a different way of thinking, since both the process and the kill process are performed on the remote host. Why not just maintain a list of clients that need to be processed on the remote host and encapsulate these operations that get the process number and kill process into a single script placed on the remote host? This allows the host of the remaining keepalived instances to invoke the remote host's script only once in the SSH naming. Eliminates a lot of unnecessary steps.
Above is the application design problem, it can be seen in the implementation of a project before considering the best solution to reduce the amount of trouble for subsequent implementations. There are a number of aspects that must be considered when encountering a problem. and try to use the simplest way possible rather than the most complex way of the highest size.
Again, some of the details of the problem.
Ssh-p PORT IP "command"
Or
Ssh-p PORT IP ' command '
If a variable is included in the command, the variable must be quoted in the corresponding quotation marks in order to parse correctly (actually the string concatenation in the shell).
Such as:
consumer=worker_for_summary.py
The
Ssh-p PORT IP "Ps-ef | grep "$consumer" |grep-v grep "
Or
Ssh-p PORT IP ' Ps-ef | grep ' $consumer ' |grep-v grep '
Not when you use the following command
Ssh-p PORT IP ' Ps-ef | grep $consumer |grep-v grep '
In addition to using awk in SSH, it is important to note that because the awk command uses single quotation marks to indicate the action to be performed, the quotation marks surrounding the command in the corresponding SSH are changed to double quotation marks and the "$" value in awk is the parameter to be added to the transfer character
Such as:
consumer=worker_for_summary.py
The
Ssh-p PORT IP "Ps-ef | grep "$consumer" |grep-v grep | awk ' {print \$2} ' "
It is not possible to use any other means.
Finally, note the use of SSH in shell scripts
In general, the ssh-p PORT IP "command" is executed by default using the current user to the remote host.
If the ssh-p PORT IP "command" is encapsulated in the script, the user logged in with the execution of the script will log on to the remote host to execute the command.
Our application encapsulates the ssh-p PORT IP "command" into a script that is called by keepalived after the keepalived instance enters the master state. The keepalived is initiated by the root user, so the command is actually executed with the root user to the remote host. And we configured the non-password SSH to the remote host with the non-root user work (typically the current user's public key), so the remote command does not execute successfully, prompting the need for a password, even if the ssh-p port IP "command" to add the user information into Ssh-p port [ Email protected] "command" also not. Therefore, the problem is circumvented by generating the root user's public key and configuring a password-free SSH to the remote host.
When trying the password, the wrong password causes the account to be locked and unable to log in, and the Faillog command can be used to view the failure record and set the login failure limit.
Such as:
Viewing user logon Failures
sudo faillog-u OP1
Reset User
sudo faillog-u op1-r
SSH No password login remote host to perform specific command considerations
