Reprinted from: http://www.taskctl.com/forum/detail_129.html

The last time I wrote a post TASKCTL, I did not use proxy to execute remote script configuration (SSH plug-in extension) through SSH secret-free connection. http://www.taskctl.com/forum/detail_122.html  . After writing, it is found that it is possible to modify the original sh job type and extend it to the job type that used to be executed by command, which can be extended appropriately. Command Line Class Plug-in Upgrade 20171110.rar Namely Sh, exe, python plug-ins and new scp job types that copy some small files. The main usage of the plug-in is ssh privacy-free and its related parameters and several modes of bash. This is only a basic version. If you have special requirements, you can modify the plug-in based on the above. The following is an extension of a sh script written on the original web page. The others are similar.

When using TASKCTL to dispatch services, if it is necessary to dispatch services across users or servers, it can be achieved by installing agents of taskctl, but sometimes there are only a few scripts or one or two executable programs on the servers that need to execute jobs. At this time, it seems a little worthwhile to deploy agents. We know that TASKCTL supports any type of job extension, so can we consider extending these plug-ins through SSH remote connections to enable them to execute these remote small scripts?

The next step is to support the scheduling of remote jobs by extending TASKCTL with ssh connection. On the one hand, it can solve some friends'urgent scheduling needs, on the other hand, it can attract more job plug-ins to meet their needs in TASKCTL.

References to the process described below http://www.taskctl.com/forum/detail_33.html .

1. First, add cprunsh.sh job plug-in in the $TASKCTLDIR/src/plugin/sh/shell/directory of the server, which is actually a shell program. The code is as follows:

#!/bin/sh
#------------------------------------------------------------------------------
#	Functions: [ssh mode] execute [remote] Shell script-driven plug-ins
#
#	Update logs: 20171030 was converted from the initial integration to plug-ins, and enhanced extensions could only execute shell scripts that are currently readable by users.
#		Through ssh protocol, different local users and other non-local users can be executed without confidentiality.
#
#	Parameters: 
#		1. The full path name of the progname script
#		2. para script entry parameters in para1 para2..
#		3. exppara corresponds to the exppara attribute of the corresponding script, which is the user of the script file. When the parameter is empty, it defaults to the current user. If it is not the current user, it is the remote connection IP address and user name.
#			SIP = 172.22.1.1 SSH Remote IP address
#			Sport = 9527 SSH Remote connection port
#			Suser = taskctl SSH Remote User
#	Return value: Actual return value after script execution
#	
#	Examples of process pattern code task definition:
#	1. Install the sh script on the server that the user can execute with the default two input parameters (if the parameters are multiple, and so on)
#	<sh>
#		<name>job1</name>
#		<progname>/home/taskctl/test.sh</progname> 
#		<para>para1 para2</para>
#	</sh>
#	2. Other users on the same server can execute, the current node installs user can not execute sh script, the current user and target user do ssh secret (if there are many parameters, and so on)
#	<sh>
#		<name>job1</name>
#		<progname>/home/username/test.sh</progname> 
#		<para>para1 para2</para>
#		<exppara>[sport=22,]suser=taskctl</exppara>
#	</sh>
#	3. On different servers, but all of them are shell jobs. Current users of node installation have done ssh secret-free (if there are many parameters, and so on).
#	<sh>
#		<name>job1</name>
#		<progname>/home/username/test.sh</progname> 
#		<para>para1 para2</para>
#		<exppara>sip=172.22.1.1,[sport=22,]suser=taskctl</exppara>
#	</sh>
#
#------------------------------------------------------------------------------

if [ $# -ne 3 ]
then
    echo "Param error !"
    echo "Usage: $0 progname para expara"
    exit 126
fi

#------------------------------------------------------------------------------
#      Step 1: Receiving parameters
#------------------------------------------------------------------------------ 
ProgName=$1
Para=$2
ExpPara=$3

#------------------------------------------------------------------------------
#      Step 2: Parse exppara
#------------------------------------------------------------------------------ 
function getValue(){
	if [ $# -ne 2 ] 
	then
		echo "......."
		exit 1
	fi
	
	str=`echo $2|awk -v record=$1 'BEGIN {
		split(record,myarray,",");
		
	}
	END{
		for (i in myarray){
			if (myarray[i]~$1){
				if ( index(myarray[i],$1) == 1){
					print myarray[i];
					break;
				}
			}
			}
	}
	'`
	echo $str|awk -F"=" '{print $2}'
}

ExpPara=`echo $ExpPara`    #Here, in order to get rid of the front and back spaces, in order to determine whether the entry parameters really exist.
#By judging whether exppara is empty, decide whether to execute sh directly or take ssh channel
#Direct execution
if [ ! -n "$ExpPara" ] 
then
	sh $ProgName $Para
	ret=$?
	exit $ret
fi
#Take the ssh channel
sip=`getValue $ExpPara sip`
#By deciding whether sip is empty, decide whether to execute sh scripts directly on other local users or remote servers
if [ ! -n "$sip" ] 
then
	sip=localhost
fi
#sport=`getValue $ExpPara sport` #By default, there is no pre-pass shielding when port parameters are not modified.
sport=22
suser=`getValue $ExpPara suser`

#------------------------------------------------------------------------------
#      Step 3: Check if ssh Secret-Free Connections are configured
#------------------------------------------------------------------------------
ssh -o ConnectTimeout=5 -o NumberOfPasswordPrompts=0 -o StrictHostKeyChecking=no -p $sport $suser@$sip 'pwd' &>/dev/null
if [ $? != 0 ];then
	echo -e "\nSSH Connection failed $sip"
	echo -e "\nssh-keygen -t rsa -P ''"
	echo -e "\nssh-copy-id -p $sport $suser@$sip"
	exit 1
else
	echo -e "\nSSH connection succeeded $sip"
fi

#------------------------------------------------------------------------------
#      Step 4: Run JOB and return the result
#------------------------------------------------------------------------------ 
#echo "ssh -o NumberOfPasswordPrompts=0 -o StrictHostKeyChecking=no -p $sport $suser@$sip bash --login $ProgName $Para"    #Here, execute the command line for printing, so that debugging can determine whether entry parameters really exist.
ssh -o NumberOfPasswordPrompts=0 -o StrictHostKeyChecking=no -p $sport $suser@$sip "bash --login $ProgName $Para"
ret=$?
exit $ret

2. Enter the "Task Type" function in the desktop software admin and set the ssh job type as shown in the following figure:

3. Designing sh job in Desktop Software designer as follows:

<!-- Process settings written according to plug-in rules -->
  <sh>
    <name>MainModul_JobNode0</name>
    <progname>/home/cdchen/successjob.sh</progname>
    <para>para1 para2</para>
    <exppara>sip=192.168.0.192,suser=cdchen</exppara>
    <jobdesc>Test remote sh task</jobdesc>
  </sh>

4. Whether the debugging and testing work meets expectations