Remote Observing Manual
COMPUTER ACCESS POLICY:
Any and all users of ARO computing facility will be required to submitted the IP address of the computer from which they plan to access the ARO telescopes. This IP must be communicated to the ARO staff prior to your observing dates to allow time to include the IP in our system.
If you do not know your IP address then you can determine it by going to this web site: https://ipinfodb.com/.
Please email your IP, along with your name and affiliation to firstname.lastname@example.org.
12 Meter Operator: Info on the scheduling of remote test runs and account passwords.
10 Meter Operator: Info on the scheduling of remote test runs and account passwords.
Phone: 520-621-4328 x210
Software Engineer: Info on the Xremote software package and account passwords
Observers can connect to the 12-m or SMT telescope computers and establish a remote data reduction session, see the on‑line "Status" screen, have a computer "Talk" session with the telescope operator, have a real‑time automatic display of incoming data, browse previously recorded data, see weather information, view receiver switched power and total power "chart recorder" output.
The choice as to whether to observe remotely or on-site is largely the observers', although management may insist on local observing if the observations are deemed particularly complicated or if the observers are unfamiliar with the telescope. Most importantly, observers should understand that remote observing is intended for experienced users who are very familiar with the facility, the observing modes, and the telescope personnel. The principal assets of remote observing are convenience, access and making small blocks of telescope time accessible to observers who otherwise might be unable to travel. We think it is most appropriate for short observing runs or for use by a collaborator who is not at the telescope but who wishes to participate in the observing. Most programs benefit from the on-site presence of the observers: communication with the operator and other staff members is more fluid, access to staff advice and other observatory resources is easier, and the confluence of collaborators at the telescope may prove stimulating and beneficial to the scientific program. The possibilities of remote observing are being tapped and a number of the traditional objections to it have been eliminated by technological advances. Nonetheless, we are continuously enhancing remote observing capabilities to extend it to a wider audience and broaden its power and flexibility. We welcome comments and suggestions from users.
Remote observing is designed for independent observer runs or in collaborative observing runs involving the same observing program. Multiple collaborative observers may use the package at the same time. But, be mindful that the package requires both computer cycles and network bandwidth and you should not be competing with other observers for these resources. In addition, many observers may be (understandably) uncomfortable with their data being monitored by someone who is not part of their group. When you start the remote package the telescope operator receives a message on his monitor screen that a remote login has occurred.
Observers should do trial logins before a remote observing run. Notify the operator when you are attempting a trial run. Once you have performed the login and checked that all the tasks are working, you should exit as quickly as possible. Simple courtesy and common sense will avoid any conflicts.
All observations to the ARO telescopes are performed using ssh. Using ssh provides the most secure type of communications to and from the telescopes. Ssh also makes setting X display variables easier because it does all the work for us.
If your computer is behind a firewall or you use DHCP for obtaining IP addresses, then ssh will most likely be the only way remote observing will work for you.
Just make sure your instance of ssh is doing the X11 tunneling for you.
Observers are required to obtain and use ssh.
A free implementation of ssh for Windows is called putty and may be obtained at:
The latest version of Xming can be obtained at:
The latest version of openssh can be obtained at:
Most Linux distributions already supply ssh or openssh by default.
It is the policy of ARO not to give out passwords via email. All passwords must be obtained by calling the Telescope Operator or the Operations Manager (see Contact Info at the top of this page).
The following are required for successful remote observing:
- Fully Compatible X Window system.
- The ssh package.
- The rshd daemon running on your home computer. ( For remote Printing )
- A reasonably fast network connection.
The following systems are known to work with our Remote Observing Package:
- Sun's OpenWindows.
- Unix DECStations.
- Silicon Graphics workstations.
- Most X-Terminals.
- All Linux systems.
- Microsoft Windows using Xwin32, Xming or Hummingbird Xserver emulation software.
NOTE: When setting up your Xserver it is helpful if you enable backing-store. This will reduce the amount of network traffic, from our computers to yours, by not requiring frequent repaints of screen displays.
N.B. We recommend that you make a trial run well in advance of your observing time to ensure that you can successfully log in, start the various remote sessions, and produce graphics displays from the data reduction programs. A trial session is particularly essential if you want to use an X Window environment other than Linux. Sometimes problems arise with font libraries and the like, but solutions to these problems can usually be found given advance notice. Contact the staff to arrange a time for your trial run.
It is imperative that you email the operator, at least 24 hours in advance, with a description of your planned observing run. This email should contain source names, receiver configuration along with frequencies, backend selections and the type of observing you expect to do. This information will be used by the operator to configure your observing ahead of time when possible.
Using the information on Contacts Page, telephone or email the Telescope Operator and have them create a data reduction subdirectory with your initials. The operator will need the name of the principal observer, three initials from his name, and the project id of the program.
Observer = Thomas Folkers
Initials = twf
Project Id = f117
If you have your own catalog of sources you need to copy them to the telescope computers.
The only 'ftp' daemon we use is the "Secure File Transfer Protocol", sftp. This program is part of the ssh suite and is the only type we support.
Once a directory is established, you may sftp your source catalog to our computers by typing, (at your own system prompt):
For Kitt Peak 12 Meter:
For Mt. Graham 10 Meter:
Password: (See section 4 for our password policy)
Next, you must change to your observing directory:
sftp> cd "ini"
( Example: cd twf )
where "ini" are your three observing initials.
To place your catalog in your directory, type:
sftp> put your_catalog_name.cat
( Example: sftp> put agn_sources.cat )
NOTE: Your catalog name must have the extension ".cat" when finished to be recognized by our system as a source catalog.
To end the sftp session, type
Note that all source catalogs must be in the standard ARO format, for example
Other coordinate and velocity frames are supported - Please see contact list above for more info about catalog options.
Examples of ARO catalog format can be found here.
Open a shell / xterm type window then type: (NOTE: the -X allows the required X11 Forwarding)
For Kitt Peak 12 Meter:
% ssh -X -l obs modelo.as.arizona.edu
For Mt. Graham 10 Meter:
% ssh -X -l obs smtoast.as.arizona.edu
% Password: (See Section 4 for our password policy)
[ lots of messages ]
% observer initials: (your initials, as established with the operator)
At the prompt you may start the remote observing package by typing:
% Xremote <cr>
The system will first check that your home machine has allowed our computers the permission to write to your display, and, if so, will print:
% OK %
If you get an error about fonts that prevents you from starting Xremote, there may be problems on your end with your fonts. The solution depends on what platform you are using.
For Fedora Linux: As root type the following: yum install xorg-x11-fonts-*
For Ubuntu Linux: As root type the following: apt-get install xfonts-*
For Windows users using Xming: You can find the source and fonts files here
A control menu like the one shown below should, depending on the site, appear on your screen. The items that are "missing", from the Xremote control panel, are engineering processes that are available only from engineering login accounts. These technical items are not of general interest to observers.
|12 Meter XRemote||SMT Xremote|
Select All button. Pressing it will select all the standard processes.
Clear button. Pressing it will clear all the check boxes.
Start button. Pressing this will start all of the selected processes.
Stop button. Pressing this will stop all the selected processes.
Exit button. Pressing this will end your remote session. Any processes still running will also be terminated.
Page Operator button. Pressing this button will play a prerecorded message in the control room to alert the operator.
If you press the button, check marks will appear in all the default boxes except a few auxiliary processes which must be started explicitly.
Conversely, pressing the button removes all the check marks. It is worth starting all the remote processes at least once to familiarize you with what is available. You may find that you do not need all of the processes, in which case they can be shut down individually. If the network throughput into your site is sluggish, you may also choose to shut down all but the most essential screens.
To start the processes identified by check marks in the boxes above, press the button.
If you want to stop some of the processes, first press the button to remove any remaining checks, then check the specific processes you want to stop, and press the button.
To stop the entire Xremote session, push the button, then log out of your original window by typing "<control-d>" or "logout." Please remember to stop your remote session as soon as you are finished observing.
Depending on your choices, up to 17 windows will begin to appear on your screen. Some of these screens may appear different because of different features at each site.
If your network connection is very slow, than the very least you should run are the following programs:
- Monitor: Show any error messages.
- Status: Shows the status of your observations.
- Xhchat: Allows communications to the operator.
- Analysis: Allows you to reduce your data online.
After you have finished your remote observing session, please stop all the remote processes.
You have two options here. You can press the button on the Xremote screen which will stop all processes and remove the control menu.
Alternatively, press the button, then press the button. This will stop all the default remote windows, but leave the menu screen operative. Please note that killing the Xremote window by itself using the window manager will not kill the other windows; they run as independent processes. To conclude your remote observing session, type "exit" in the original window.
There are two options for routing UniPOPS hardcopies to your local site. Approach 1 is easy but tedious if you are making a lot of hardcopies. Approach 2 is automatic but requires some UNIX savvy, may open a security hole on your remote host, and it can tie up the unipops program while the graphics file is being printed.
Warning: This is for Postscript output only.
Before starting up line or condar set your popsprinter environment to be "capture".
% setenv popsprinter capture
After starting up line or condar, whenever you request a hardcopy (i.e. via GCOPY or TCOPY or LASER or OUTPUT) the postscript output that would otherwise get sent directly to a printer will be deposited in a file with each hardcopy request going into a new file (i.e. each time you type GCOPY, a new file is generated).
The name of the individual files will be capture.file.$$ where $$ will be expanded to a unique number for each file. The name of each file will be echoed to your screen.
ftp or sftp each file from our machine to your remote host and print it out as you would any postscript file (this is the tedious part).
Delete the files on our machine once you've transferred them to your remote host. You may wish to delete them on your remote host as well once they've been printed. Postscript files can be large so you don't want to get in the habit of letting them pile up.
N.B. This method:
- Requires some UNIX savvy.
- It's a security issue for your remote host.
- Can tie up the program while the graphics file is being printed.
- May not work if you are behind a firewall.
At the telescope computer prompt, type:
setenv popsprinter remote
cp ~unipops/remote.print remote.print
Using your favorite editor, edit the copy of remote.print in your own obs/ini subdirectory. Here's what the unedited remote.print looks like:
cat ‑ > remote.ps.$$
rcp remote.ps.$$ username@hostname:remote.ps.$$
rsh ‑l username hostname lpr ‑Pprinter_name ‑r ‑s remote.ps.$$
/bin/rm ‑f remote.ps.$$
- The first line merely indicates that the c‑shell is to be used.
- The second line deposits the standard input into a file (this is what the popsprinter=capture does, using a different file name). The standard input is already in postscript so no conversion to postscript is necessary.
- The next line copies that file to the top level directory of username on hostname.
- The fourth line remotely prints out the file that was just copied using the printer named "printer_name" and the unix lpr command. The ‑r flag to lpr removes the file when printing is completed.
- The final line removes the temporary file on our machine.
Modifications to the script you should make:
- You need to change "username" to be your login name on the remote host (username appears twice in remote.print).
- You need to change "hostname" to the full Internet host name for your remote host (e.g. hamms.as.arizona.edu would be an example of a hostname; hostname appears twice in remote.print).
- You need to change "printer_name" to the name of the desired postscript printer on hostname (printer name appears once).
- It is slightly possible you may need to change the syntax of the lpr command and flags on the fourth line although the above should work on most lpr capably machines.
- On "hostname" (your remote host) you need to create (or modify if you already have one) a .rhosts file (notice the leading "dot" in the name). See the man page for rhosts as well as rsh for complete information. You must also have the rsh daemon running on your machine for this to work.
- Entries in an .rhosts file signal the computer that logins from certain users on certain machines are "trusted" and no password is necessary. This is what allows the rcp and rsh commands to work. Without an appropriate .rhosts file, none of this will work.
- Your .rhosts file should be in your default login directory on "hostname". It should be readable/writable by you (the owner) and read‑only for everyone else. Since you want to signal that the "obs" username on modelo or smtoast is "trusted", you want the following line in your .rhosts file:
That should do it. If everything works as planned you should get a hardcopy out of your remote postscript printer every time you issue a hardcopy request on UniPOPS.
Since EVERY observer uses the obs account on our machines, it should be obvious what a security risk this is. Therefore, it is important that you remove the line you just entered in your .rhosts file whenever you don't need it (i.e. after each observing run). Otherwise, anyone with access to the obs account on our machines will be able to log into your account (username) on your host (hostname).
Time: The UniPOPS prompt will not come back until remote.print has finished. If the graphics file is large (and postscript files tend to be large to start with) and the data rate between our machines and your host is slow, this may be an unacceptably long time to wait for the UniPOPS prompt to come back. You may opt for Approach 1 above since you can do the ftp'ing asynchronously (UniPOPS merely has to wait for the file to be copied to the capture file). There is currently NO way to switch printers once the program has started.