Automating Commands and Responses on a Remote Server within a script

[Andrew Kaplan]

Hi there --

I am in the process of writing a script where a telnet connection is made to a remote server. What I need to do is to be able to have commands and responses be automated on the remote server.

The workstation that is running the script is a Fedora Core 2 system, while the remote server is running the HP-UX 11.00 OS. Listed below is the text of the script:

#!/bin/bash

# This script will provide access to the gmc application which
# is located on the mcrs1 server.

# First disable access control so that clients can connect from any host.
xhost +

# Establish a telnet session with mcrs1.
telnet

# The mcrs1 server will prompt the user for the terminal type to be used for
# the current session.
/usr/dt/bin/dtterm

# Configure the display environmental variable on mcrs1 so that X applications
# can run on the workstation that has made the connection to mcrs1
setenv DISPLAY :0.0

/opt/gnome/bin/gmc

What I need to do is have the dtterm and setenv DISPLAY commands run on the remote server in order to have the X application be able to run on the local workstation. Once those are done, I want to have the gmc application that resides on the remote server, to be remotely run on the workstation.

What command syntax do I need to for the dtterm, setenv, and gmc commands in the script?

[Steven E. Protter]

Shalom,

You may not need to get so complex.

ssh -X hostname

This will permit you to run X windows apps remotely, if secure shell/openssh is configured on the remote workstation, which is the default for Fedora 2.

To run local via script, you can source the .dtprofile file to get your environment.

SEP

[Steven Schweda]

> # First disable access control so that clients can connect from any host.
> xhost +

> # Establish a telnet session with mcrs1.
> telnet

If you know to where you're about to Telnet,
why open the X server to all hosts instead of
just that one?


You might want to put a script on the remote
host, and run that with a simpler "rsh" or
"ssh".

[Mike Stroyan]

As an aside, you may need to change the way that the X server on fedora is started to make it listen to X clients on the HP-UX system. In addition to "xhost +mcrs1" you need to make the X server listen to tcp connections and configure any active firewall to allow the connection. That is discussed in this fedora forum thread.
http://www.fedoraforum.org/forum/showthread.php?t=104171&highlight=export+display

Once you get X applications working interactively you can go on to the automation.
The expect command is very good at automating interactive terminal sessions. It can start a command like telnet or "ssh -X" and then provide scripted responses in reaction to what it reads from the command.

You would make your script launch expect as-
expect start_gmc.expect

where start_gmc.expect is a file containing-
spawn telnet mcrs1
expect {
login: {
send "username\n"
}
}
expect {
Password: {
send "mypassword\n"
}
}
expect {
"$ " {
send "setenv DISPLAY :0.0\n"
}
}
expect {
"$ " {
send "exec /opt/gnome/bin/gmc\n"
}
}

It is not at all clear what your use of /usr/dt/bin/dtterm is supposed to be. It sounds like you may have a telnet account that always prompts for some command to run. And you want to provide dtterm as that one command to run. Where does that dtterm get its DISPLAY setting? And did you intend to send the rest of the commands to the telnet connection or to the shell started by dtterm? It would be very difficult to interact with the dtterm shell from your shell script. dtterm will be starting an entirely separate connection that has nothing to do with your telnet tty. You can have dtterm run a script instead of an interactive shell. Using "dtterm -e myscript" will execute myscript with a possibility for the user to interact with the commands run by myscript. In that case myscript could start a shell. But when myscript itself finishes dtterm will exit rather than going to a shell prompt.