Execting a command on remote server

[Paul Thomson_2]

Does anyone know how to execute a command on a local system so it will take effect on a remote system.

I have written a script to check some files and output the command to a file. I could ftp the file onto 200+ servers, but wondered if it is possible to execute the command on a local system to work on the remote system.

Similar to perhaps
remsh hostname -n sysdef | grep nflocks >> output_file

where the sysdef option would be the local command, outputting to a file back on the local server, but actually running the script on the remote system.

Any ideas ?

[Rodney Hills]

sysdef would have to be available within the filesystems available to the remote systems.

option 1) Copy sysdef to all systems.

option 2) Create a directory to hold common commands that all systems can run, and export it via NFS. Then each remote system would mount this filesystem and then they would have access to the common commands.

Hope this helps...

-- Rod Hills

[George Petrides_1]

Why not 'rcp' the script instead of all the NFS traffic? Just make sure the original script has execute permissions and do rcp -p sysdef SYSTEM:/..../sysdef
George

[Bill Hassell]

When doing a remsh command, it's important to know what the local shell will do versus the remote shell. For instance:

remsh $HOST pwd > /var/tmp/$HOST.pwd

and

remsh $HOST pwd \> /var/tmp/$HOST.pwd
or
remsh $HOST "pwd > /var/tmp/$HOST.pwd"

The first will write the pwd results into /var/tmp/$HOST.pwd on the local machine while the 2nd and 3rd examples will write the results on the remote machine. Note that "..." and '...' will behave differently. Double quotes "..." will expand env variables like $HOST before sending the resultant string to the remote computer. However, '...' will send the string exactly as typed, and the env varible $HOST would have to be defined at the remote system, which is unlikely.

I would not assume anything about the remote environment, such as $PATH. You can probably assume that pwd for remsh will be the user's home directory, but that's about all. Use bull pathnames to make sure the specific command will be found:

remsh $HOST /usr/bin/pwd > /var/tmp/$HOST.pwd

I've attached a script called remshall.sh which accomplishes something like what you're looking for. I use it to look at dozens of machines and get a status, for instance, get the current time/date for all the machines to make sure NTP is setup, or check the size of syslog, etc.

[Paul Thomson_2]

Thanks for replies.

I do use remsh to perform tasks on a remote server similar to how you have described.

What I really want to do is somehow perform the following

On a local server (serverA) a file called localfile

I would like to execute this on a remote server (serverB)

I perhaps confused the issue by mentioning remsh.

So I would like to execute a file, say called localfile, located on serverA to take effect on serverB and output the information back to a file on serverA

I know with remsh you can specify the output to be on the local server or the remote server.
But the command you execute needs to be on the remote server. Is there anyway to access a remote server, then execute a command that is located on the local server.

Am I making sense !?!?

Cheers
Paul

[Wodisch_1]

Hello Paul,

if all those other systems are NFS-clients, and *your* system is an NFS-server, then the NFS-command "on" might be right what you want.
Read the man pages for "on" and enable that service for *your* computer in your "/etc/inetd.conf".
Then start the "on" command on your computer like this:
on serverB "sysdef | grep nflocks >> output"

HTH,
Wodisch

[Bill Hassell]

This sounds like a system inventory script that I wrote to collect data from over 300 HP-UX machines. The way I set it up was to place a cron job on every machine. This job would use ftp commands within the script to pull down the latest copy of the inventory script. Then the script runs the local copy of the inventory script, save a copy of the results on the machine and ftp a copy back to the inventory collector machine.

In that way, I could update the inventory script (daily if needed) and all the machines would run the latest version that evening and all the new results returned to the collector the next day.

NOTE: from personal experience with this script: always use set -u in your scripts. A simple spelling error that would have been caught with set -u removed the /usr/local/bin directories on 300+ machines. Test your scripts carefully before dropping them into the central directory.

[Carlo Henrico_1]

Your serverA's "localfile" that you want to execute on serverB, as initiated from ServerA (do I understand it correctly?) - is it some form of script generated from something else (i.e. it may change from run to run)?

If so, I would have a generic script on serverB which does a rcp of "localfile" and then executes it. The generic script could be called from a remsh from serverA...

Cheers

Carlo