[mdlug] OT: KISS! Was: Run script on file arrival

[Aaron Kulkis]

Stan Green wrote:
> On Tuesday 01 March 2011 01:55:51 pm Aaron Kulkis wrote:
>>> OK, so this is a side topic.
>>>
>>> I would not what the user to have to interact with the script. They have
>>> a hard enough time with the concept of logging off! (They are always
>>> trying to shutdown!)
>> You might want to write a wrapper program in C which does
>> sudo to the desired username and runs the desired shellscript.
>> [This, of course, would be installed on the remote system,
>> not on the user's computer, and also edit /etc/sudoers on
>> the remote computer appropriately.]
> This is not a bad idea. I've never done so, but it might be worth looking into. 
> The one down side is the concept of isolation. I'm not sure I what the client 
> to have to know what script to run on the server. This make it harder to 
> maintain the client if I what to run a different script someday. 
>>
>> Q:  Why is the user in question misbehaving by trying to shut down?
>> What's going on with management/supervision that they are not
>> taking any corrective action?
>>
> I am the team lead! They are only confused as they are used to shutting down 
> Windows when they are done. I have it set up so the system shutdown when the 
> background task are done. It is just a leaning curve and I try to keep it as 
> flat as I can. 
>>> With ssh, to keep the user from interacting with the script,  wouldn't I
>>> need to put the user's password in the script?
>> No.  Big security hole.
>>
>>> I've seen many different ways to handle
>>> this, but I have never been 100% happy with any of them. Is there a "best
>>> practice" for putting passwords in scripts.
>> Either use sudo, or the user will have to BEHAVE LIKE
>> A RESPONSIBLE ADULT WHO EARNS THEIR PAY, and type in
>> their own password.
> You assume my team is paid, which is an invalid assumption. They are 100% 
> volunteers.  I simply don't want them to interact with scripts. They enter 
> their password when they login to the system. They have a job to do and they do 
> it well.  I do my best to not complicate it. I have made it 50% simpler by 
> going to Linux, because we have the power of scripts. I'm not gong back to a 
> complicated process. Then I might as well go back to Windows.
>> If they can't handle this, then seriously, what other
>> basic work tasks are they also screwing up?
> None. They are all talented people who do a wonderful job. They are just not 
> deep technical people. Which is 100% fine with me as I want people do focus on 
> what they are good at and not what they are not good at. This is why I do 90% 
> of the deep technical stuff for the team.


No problem
On the remote side, you make a wrapper script that is THIS:


#!/bin/bash
shift		# shift elements of $* 1 place to the left
$*		# execute the redirected script

Suppose we save this script as /local/bin/executor

$ ssh remotehosts /local/bin/executor somescript arg1 arg2 arg3 arg4

argument assignments at the beginning of execution:
$0 = executor	# This is how a program with multiple hard links
	# or symbolic links to it can change behavior
	# depending upon what name it is called by,
	# ... they examine the "0th" element of the argument
	# vector, decide how to proceed accordingly]
	# (for example, ex, vi (or vim), and view are the
	# same program. try  ls -al /usr/bin/{ex,vi,vim,view}
	#
$1 = somescript
$2 = arg1
$3 = arg2
$4 = arg3
$5 = arg4

so:

executor somescript arg1 arg2 arg3 arg4
    $0       $1      $2   $3   $4   $5
After executing the shift instruction, $0 is dropped, producing

somescript arg1 arg2 arg3 arg4
   $0       $1   $2   $3   $4

the $* stands for all arguments, so it is basically executes
the first argument (as submitted to the script) with all of the
remaining arguments tacked on as arguments.