Be aware that NX™ access to each beamline is restricted to a
pre-requested username and IP domain only.
Frequently Asked Questions: |
Q: | How can I gain the remote access to GM/CA @ APS computers? |
A: | The remote access needs to be requested when applying for beamtime.
There is a checkmark in the user account setup utility that enables remote access after
the beamtime is granted. You will also need to specify the IP domain(s) from which you
are planning to login. Keep in mind that many institutional networks are behind the
firewalls. Please use the "Show my IP" tool to verify
how your IP is exposed to us. As a security protection, we only open our computers to
requested IP domains, but you may specify multiple domains. |
Q: | What network speed should I have in order to be able to
collect data remotely? |
A: | Please read the Speed
Benchmarking page. |
Q: | Can I improve my connection speed? |
A: | It may be possible to improve the speed by tuning the TCP
parameters on your computer, although the administrative access to your computer
and some computer administrating skills may be required. Please read the
fasterdata.es.net
guide. |
Q: | How long can I use the remote access capability? |
A: | The NOMACHINE™ remote access is provided to two beamline computers
('acquisition' and 'processing') during allocated beamtime and solely for collecting
and analyzing data in parallel. These computers can also be accessed by SSH/SFTP, but it is
not recommended since may affect your data acquisition and processing speeds. Additionally,
SSH access is provided to our second-day-area computer for two more days solely for backing up data.
The remote access resources are mapped in the following table:
Computer |
Primary Purpose |
Primary Access |
Other Access |
Availability |
blXws2 |
Acquisition |
NOMACHINE™ |
SFTP/SCP |
Day 1 |
blXws3 |
Acquisition (alternative) |
Teamviewer™ |
- |
Day 1 |
blXws6 |
Processing |
NOMACHINE™ |
SFTP/SCP, Teamviewer™ |
Day 1 |
blXws5 |
Backup |
SFTP/SCP, Globus GridFTP |
NOMACHINE™ |
Days 1-3 |
Here X=1 for 23ID-D and X=2 for 23ID-B. The full URLs are blXwsN.gmca.aps.anl.gov.
Please request additional SCP/SFTP connection details from your host or see the
SCP/SFTP information below. |
Q: | Can I have an extended or permanent remote access? |
A: | Long-term remote access to GM/CA @ APS systems is not provided.
The major consideration behind such policy is to prevent overloading our systems, which may slow
down data collection or processing for the groups doing experiments during their allocated
beamtime. |
Q: | Why do I have to login on different systems for 23ID-D and 23ID-B? |
A: | The two beamlines have independent computing systems with different NX™
servers, different account management, different central storage and different
subnets. |
Q: | What types of operating systems can I use for remote access? |
A: | Supported platforms are Mac OS X, Windows, Linux and Solaris.
Check NOMACHINE™ web site for
additional details. |
Q: | What are the requirements to hardware?
|
A: | Network connectivity must be ADSL or faster.
Minimum video resolution is 1280x1024, but 1600x1200
or higher is strongly recommended. |
Q: | Are dual monitors supported? |
A: | Yes, but with some restrictions. On Windows platforms you should have
NX™ client version 3.4.0 or later. If you install the client through our web page, this
condition is satisfied. On any OS both monitors should be set to the same color depth. See the
NOMACHINE™
article for additional details. |
Q: | I have Java installed on Linux, but it does not work in firefox |
A: | On Linux (at least on Redhat Linux) Java installation does not configure
Firefox web browser to use. One has to create a symbolic link to from Java installation directory
to Firefox plugins directory.
For 32-bit systems it will look like this:
ln -s /usr/java/latest/lib/i386/libnpjp2.so /usr/lib/mozilla/plugins/
..and for 64-bit systems and 64-bit Java installed it will look like this:
ln -s /usr/java/latest/lib/amd64/libnpjp2.so /usr/lib64/mozilla/plugins/
For other Linux distributions, the directories may have different locations, but the basic principle
that libnpjp2.so should be linked to the Firefox plugins directory remains the same. On the 64-bit
distributions it is important to verify whether 32-bit or 64-bit Firefox is used and install/link
matching 32-bit or 64-bit Java.
Do not forget to fully close and restart your Firefox after making the link. |
Q: | I am having problem to start NX™ client. |
A: | This may happen sometimes because of NX™ client cache left after
your previous beamtime. The client software is automatically updated when new releases become
available and the cache corresponding to an older version may become incompatible. The recipe
is to wipe the cache by deleting the .nx directory. If your computer is Unix/Linux or
Mac, the .nx directory is located in your home directory. On Windows it is in
"C:\Documents and Settings\<username>".
If you start NX™ client through our web page, the later uses Java in your web browser
to install NX™ on your computer and then there might also be a problem with Java cache.
If your computer is Linux, try to wipe .java subdirectory in your home directory. On
Mac it is going to be "/Users/<username>/Library/Caches/Java" and on
Windows "C:\Documents and Settings\<username>\Local Settings\Application
Data\Sun\Java". |
Q: | When I am trying to login, the NX™ client
keeps telling me "Authentication failed". |
A: | Perhaps there was a miscommunication with your host about remote
access or you are trying to login from a computer, which IP does not match the IP range you
provided to us (see the "Show my IP" tool), or you are
trying to login too early (your beamtime has not started) or too late (your beamtime is over),
or you are trying to login to incorrect beamline (e.g. 23ID-B instead of 23ID-D or vice versa).
In any case please STOP and contact your host. If your
login attempts fail too many times, the ANL automatic protection system may treat you as
a hacker and automatically ban your IP, which will make the issue much harder to resolve.
The same applies to unsuccessful SSH and SFTP logins: do not try more than three times;
instead contact your host. |
Q: | When I am trying to login, the session is
terminated before I get any connection. |
A: | This is most likely an obsolete cache problem on either client or
server side. See instructions above on cleaning cache at your side.
To clean cache at the server side, either ask your host or ssh to respective GM/CA @ APS
computer and type: rm -Rf .nx. Try again after the cache is deleted. |
Q: | I login using Gnome and some Gnome panels are missing.
What happened? |
A: | This is known to happen with NX™ clients on certain versions
of Mac OS X or when users login locally and remotely on the same computer at the same time.
It is believed to be due to differences in the versions of X-server on the GM/CA @ APS computer and the
remote computer used by the NX™ client. Since either server writes its auxiliary files into
the .gconf, .gconfd, .gnome, and .gnome2 subdirectories under
users home, they may overwrite each other's records causing the conflict. There are two workarounds:
(i) logout from the affected computer both locally and remotely; then login
in text mode (e.g using ssh if remotely or Ctrl+Alt+F1 if locally) and erase
the above directories and all their content; then login back via NX™, but do not
use local Gnome login. (ii) Use KDE for remote logins via NX™. |
Q: | Why the Image Window in ADXV does not refresh
correctly under NX™? |
A: | This a known long standing bug in NX™ when the lazy encoding is enabled.
See this
NOMACHINE™ article for possible workaround. This workaround can be applied
using the NX™ session wizard. Open the wizard and select
ADXV among other options. The selection changes the link type to "LAN" and disables
deferred screen updates. Please be aware that it may substantially reduce the speed of remote
operation. With this consideration, the preconfigured NX™ the sessions provided in the
tables at the beginning of this web page do not include the ADXV workaround since we do not
want to slow down the connection for all users. The ADXV addicts are suggested to configure
their session with the NX™ session wizard or try
TeamViewer, which does not suffer from the ADXV problem.
|
Q: | How to end the NX™ session properly? |
A: | - To close all of your programs properly, you
should use session logout as shown in the illustration below.
A common mistake is to click on the cross at the top of NX™ window. That gives two options:
"Disconnect" and "Terminate".
Terminating is OK since it has the same effect as logout. Disconnecting leaves the session
and all programs inside it running at the GM/CA @ APS computer. We shall have to kill them
after your beamtime is over and it may result in corrupting files opened by the
applications. |
Q: | Are there any other known problems? |
A: | - If Windows computer has Cygwin installed
and the cygwin.dll is in the system path, that may cause a conflict with NX™ client
installation. Upgrading cygwin and NX™ to their latest versions usually fixes the
problem. Alternatively, remove the cygwin directories from the system path.
- Simultaneous remote and local access to the same account on
the computer running NX™ server may cause conflicts in GNOME settings. Therefore, users
present at the GM/CA @ APS locally should not login on the blXws2, blXws5 and blXws6 workstations
if the remote access session is in progress. In case this happened by mistake see
possible workarounds in the above question about disappearing panels in Gnome. |
Q: | Are there any alternatives to NX™? |
A: | - You may try to use
TeamViewer™.
Read our TeamViewer™ guide. |
Q: | How can I start/use MARCCD software when I am remote? |
A: | - Indeed, MARCCD software runs on a separate computer
named marX (X=1 for 23ID-D and X=2 for 23ID-B). When you at the beamline (i.e. operate locally),
you see a separate monitor of MAR computer next to the monitor of your beamline control workstation.
So, in the local mode you simply login on MAR computer with your account and start MARCCD software by
typing "marccdepics" or clicking the "marccdepics" icon on the desktop panel at
the bottom of the screen:
When you are remote, you will need to bring the MARCCD interface to the desktop of computer you
are connected to. You start same way as in the local mode by typing "marccdepics" or
clicking the "marccdepics" icon (if instead of full remote desktop you chose the
"JBluIce only" remote session, "marccdepics" can be called via the JBluIce
Tools). However, this time "marccdepics" will popup the following GUI:
The GUI presents two options depending on whether someone is logged or not on the MAR computer screen
with your account. Please read the explanations on the GUI and proceed according to your situation.
Option-1 has an advantage that it allows to scale down the MARCCD interface which is fairly large and
may not fit your remote computer display. Also, with this option, it is easier to arrange your host
and local collaborators to watch data collection. On the other hand, option-2 may generate less
traffic since it only displays MARCCD program instead of showing full MAR computer desktop.
|
Q: | Remote MARCCD start fails. What is wrong? |
A: | - We have seen a few cases when remote MARCCD
start was failing because of missing fonts on remote (user's) computer. To diagnose if this is
your case, open a terminal window and type (substitute "X" by "1" for 23ID-D and by "2" for 23ID-B):
ssh marX
marccd
When there is a missing fonts issue, MARCCD may output the following errors:
Warning: Missing charsets in String to FontSet conversion
Warning: Cannot convert string "-adobe-helvetica-medium-r-normal-*-12-*" to type FontSet
Warning: Missing charsets in String to FontSet conversion
Warning: Unable to load any usable fontset
Segmentation fault
The recipe from the MAR vendor Rayonix is: "Usually when I see such errors I install the
xorg-x11-fonts-* packages and they go away." Note that it should include both 75dpi
and 100dpi fonts.
In addition to the Rayonix response, our own investigation shows that the problem might be
related to the UTF8 locale on user's computers. In this case the X11 server at the user side
needs xorg-x11-fonts for all locales including Chinese, Japanese, Arabic, and etc.,
although the MARCCD program would only use Western fonts. Please have your system
administrator to either change the locale to "C" (which corresponds to the US locale) or
install the xorg-x11-fonts from all available locales, both 75dpi and 100dpi.
Another resolution is to run MARCCD program via a VNC connection to shared MAR computer
desktop. This option has not been noticed to give the missing fonts problem.
|
Q: | Coot or Pymol fail to start in NX session. What is wrong? |
A: | - Coot and Pymol use OpenGL capability of X11 provided by the
graphics driver. Depending on the computer where the NX™ client is running, this capability may or
may not be supported. If this happens, try to set the LIBGL_ALWAYS_INDIRECT environment:
export LIBGL_ALWAYS_INDIRECT=1
Then try to start Coot or Pymol again from the same terminal window. |
Q: | How can I offload my data? |
A: | - You need to use either
Globus Online or SCP/SFTP. Globus Online is basically a
gridFTP service
with a convenient web browser interface developed by several US research institutions
including Argonne. It is between 2x and 3x faster than SCP, which is a considerable advantage
for transferring large amounts of data in spite of one-time effort to setup and limited sync
capability (support for continuous sync in progress). If you are interested in this free
service, please check the details in our
Globus Online User Guide.
For SCP/SFTP, a dedicated workstation is blXws5 (X=1 for 23ID-D and X=2 for 23ID-B).
It is accessible from declared IP domains during your beamtime and for two extra days after
the beamtime is over. In principle, blXws6 may also be used, but the primary task of that
workstation is data processing and then it is only available during beamtime. You may use
any SCP/SFTP client available for your platform and supporting SSH2, but it is preferred
to deploy those clients that preserve files time stamps. Among command line clients,
rsync and
openssh are perhaps the most commonly
used. Both are included with Linux and Mac OS X while on Windows OS they are available with
Cygwin. The command lines for transferring
data with rsync and openssh will look like this (these should be executed on a computer in
your lab):
rsync -avz -e ssh username@blXws5:/remote/dir /my/local/dir/
scp -rp username@blXws5:/remote/dir /my/local/dir/
Among SCP/SFTP clients with friendly graphical user interface you may try (listing
these clients here does not mean our endorsement):
Keep in mind that SCP works faster than SFTP, but in general SFTP/SCP are not very fast data
transfer protocols. In some
cases shipping an external hard drive along with your samples might be a better option. |
Q: | How can I learn more about GM/CA @ APS remote access? |
A: | Study our Remote
Operations Manual for Users. Also, check our remote
access video demo (please turn on the sound!). |