Using X11 remotely
==================

SecureShell (SSH) will securely transport an X-windows graphical user interface
across the network.  The command to use this feature is

ssh -Y user@remoteserver

if SSH is configured to support it (see below). The "-Y" flag is used for 
trusted host connections.  A similar "-X" flag is available.  Use "man ssh" for
more information.

This technique works well only on a gigabit network with low latency.  Over long
distances, regardless of the network capacity, the lag between command and
response (latency) due to transit time becomes unacceptable. Therefore unless
this software is being used on a high speed local area network, we recommend
running indiserver on a computer at the telescope, and  clients on the
observer's computer.  The server and the clients communicate with XML, are
tolerant of latency, and do not require a high speed connection.

If you are controlling the server from a remote location for this purpose it is
recommended that you do NOT transport X over the connection used to run the
server.  You will connect to the server (telescope) computer with a command such
as the one described below:

ssh -L 7624:localhost:7624 user@remoteserver

On a high speed local area network if you also want to transport X you may
connect with

ssh -Y -L 7624:localhost:7624 user@remoteserver


Configure SSH without passwords
===============================

On the computer you are connecting from

ssh-keygen -t dsa

generated two files in $HOME/.ssh

-rw------- id_dsa
-rw-r--r-- id_dsa.pub

id_dsa is the private key and id_dsa.pub is the public key. Note the differences 
in the default permissions.

Copy and append id_dsa.pub to 

$HOME/.ssh/authorized_keys

on the system you are connecting to.  This may be accomplished by the command
line

ssh-copy-id ./ssh/id_dsa.pub user@host

Note that id_dsa is the private key and id_dsa.pub is the public key.  You
should copy only the public key to the remote system.


For reciprocal passwordless login, do this on both machines.


It may be necessary as root user or sudo to configure the file
/etc/ssh/ssh_config to have the entry

ForwardAgent yes

By default in Suse /etc/ssh/sshd_config will have

PubkeyAuthentication yes

so you won't have to change that, nor restart sshd. 

If you are connecting from an observer's computer to a telescope computer that
is not on a local area network, you may also need to change the firewall
settings to enable SSH.  For OpenSuse there is a YAST utility to manage the
firewall that will do this for you.  Other distributions may use
/etc/hosts.allow and /etc/hosts.deny for access control.  

Secure shell is very secure!  However, once you open your computer to SSH
access, it is likely that someone will try to take advantage of the open
port and attempt to log in remotely.  The simple technique of using a secure
password is usually all that is needed to protect your system.  It is of course
much safer to include lines in the system /etc/hosts files to enable
access only from known IP addresses.  Here's an example of how that would look.


             hosts.deny          hosts.allow
             ----------          -----------
             ALL : ALL           ssh: 192.168.1.1
 
The telescope computer's hosts.allow file would include the IP addresses for all
allowed remote users.  Each remote user would include in their hosts.allow file
the IP address of the telescope computer.  By using ALL in the hosts.deny file
you insure that only systems in hosts.allow are permitted to connect to this
computer.

These controls apply to incoming communications, not to outgoing communications.
The telescope and camera software require bidirectional transfer and therefore
systems at both ends of the connection must be properly configured. 

Test the connection by "ssh user@remotehost" and it should not prompt for a 
password when the contents of the user's .ssh and the system etc/ssh/ files
are correctly set.  If a connection fails completely for ssh, it is likely the
problem is in the firewall or hosts files. 


Server Port
===========

The XmCCD camera controller runs as an INDI device.
It will accept remote commands on port 7624.  
To tunnel this port through  SSH,  initiate a passwordless session 
from the client to the server with this command line: 

ssh -L 7624:localhost:7624 user@remoteserver

Other ports may be opened  at the same time, for example:

ssh -L 7624:localhost:7624 -L 6791:localhost:6791 user@remoteserver


Start the server
================

Apply power to the camera and telescope. For the SBIG camera when its fan has 
started, the camera has loaded its firmware.  You may check this with lsusb 
from the command line to see the status of the usb interface. Once the camera 
is powered on, start the indiserver with the camera driver using the 
commandline:

indiserver ccd &

If you are using xmtel as well, start both camera and telescope drivers at 
the same time:

indiserver tel ccd &

If you are running other indi devices, the command line would be, for example,

indiserver tel ccd dome guider &



Start the clients xmccd, xmtel, xmdome, xmguider and xephem
==========================================================

As a separate process on the local computer start xmccd with

xmccd &

The xmccd control panel will appear and the image display program ds9 
will start automatically. Enable remote operation on the control panel. 

For controlling your telescope xmtel and xephem are compatible with xmccd and
use the INDI protocol.  The control panel available in xephem will also allow
you to control all aspects of the camera operation. Each may be started in a 
separate request:

xmtel &
xephem &


Configure xephem
================

To use XEphem with INDI add the following to your configuration, either in
/etc/XEphem or in your home directory's .xephem/XEphem file:

XEphem*INDIConfig*GotoDecValue.value:        tel.target_2000.dec
XEphem*INDIConfig*GotoRAValue.value:         tel.target_2000.ra
XEphem*INDIConfig*SkyDecValue.value:         tel.telescope_2000.dec
XEphem*INDIConfig*SkyRAValue.value:          tel.telescope_2000.ra

These values may also be set in XEphem's telescope configuration menu in 
under skyview.  If you do it that when, when you close XEphem you will have
an option of saving the new configuration to your .xephem/XEphem file.  If
you make the change by editing the /etc/XEphem file, it will be available to
all users by default.


Using TightVNC
==============

XmCCD and XmTel operate well with VNC, and they have been tested with "TightVNC"
and the Java client.  Using VNC removes, for the most part, the problem of
latency that still persists with X11 and SSH, especially when there is a long
travel time for packets (as in transpacific operation, for example).  

Use SSH to connect to the remote telescope system with a command such as

ssh  -L 5901:localhost:5901 user@remote.telescope.edu

subsituting of course your username and telescope system address.

Here port 5901 is the one used by the tightvnc server on display :1, and
"localhost" refers to your console computer.  The ssh command forward the port
5901 on your local computer to the same port on the telescope computer.

After connecting, start the server on the remote computer with:

vncserver 

or

vncserver :1

to specify the display.

You may kill the server with

vncserver -kill :1


If you have used vncserver before this is all you need to do on the remote
system.  However, keep this window open to maintain the port forwarding.  If
you have not used vnserver before, you will be prompted for a password which
will be saved in $HOME/.vnc/, along with an "xstartup" script.

The script "xstartup" will determine how your display is started.  For example,
for gnome it may be

#!/bin/sh
/usr/bin/gnome &

and for xfce4 it would be

#!/bin/sh
/usr/bin/xfce4-session &


Edit xstartup to set the type of session you want to run.  By default it will be
a plain x11 session, but you can make it the same as the desktop you are used to
with editing.


Once you are happy with xstartup, make sure no sessions are running (check ps
-e) and kill them with "vncserver -kill :1", for example, as needed.

Start the server with "vncserver :1".

If you want to specify the screen size, start with 

vncserver -geometry 800x600 :1

as an example, for an 800x600 display.


Now in a command line window on your local computer run the tightvnc Java
viewer.

The command line, which may be scripted, is

java  -jar /usr/local/tightvnc/tightvnc-jviewer.jar

You will be prompted for the client and the port: localhost, 5901.  Note you run
locally, not on the remote server.

You should quickly see the remote telescope display as a large window on your
local machine.  You may do anything within that window that you would do with
the desktop if you were present at the remote machine.


In this type of operation all the image files, display, and processing 
are on the remote machine.  This may be necessary since file transfer is 
often slower than data acquisition.  You may run mirroring of the data directory
on the remote machine to your local machine so that you can work with files as
they become available, without backlogging acquisition to await transfer of
previous images.












