Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.astro.louisville.edu/software/sbig/xmccd-5.1/REMOTE Дата изменения: Thu Jun 18 18:53:10 2015 Дата индексирования: Sun Apr 10 02:10:34 2016 Кодировка: Поисковые слова: m 63

Using XPA remotely
==================

XPA starts by default using network communication with access control. While
this allows connections between machines (see the XPA documentation on access
control) the method may be complicated by firewalls and blocked ports. An
alternative is to tunnel XPA requests through SSH. A typical command would be
one like

ssh user@remote.machine xpaget ds9 region

This will return the terminal stdout from "xpaget ds9 region" on the remote
machine. SSH may be configured for secure passwordless login as described
below.


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. Although VNC is
less secure, it is a better solution that forwarding X11 when the network is
slow or there is significant latency.


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 XPA controller runs on the local network and is not accessible
to the outside if the environment variable

export XPA_METHOD=local

is set. Alternatively, if it is set to the default "inet" the port 14285 is
used for the xpans server, and random ports are used for various clients.



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

Apply power to the camera and telescope and cameras. Start the servers with

xpaccd &
xpatel &

and any others you may need. The first one will create an instance of xpans,
and additional xpa servers will use xpans to provide a central point for
communications. To query the status of one of the devices, use

xpaget tel

for example.




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.

xmccd &
xmtel &
xephem &


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

With this version of xmccd we do not use INDI for communicating with
other processes. It is not necessary to open the xephem control panel in
use. You will need to "make" the fifo communication files in the "fifo"
directory of /usr/local/xephem/fifos when you install XEphem before using it
with xmtel.


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.