| Remote Access 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 find out
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, the NOMACHINE™ and
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 |
| blXws6 |
Processing |
NOMACHINE™ |
SFTP/SCP |
Day 1 |
| blXws5 |
Backup |
Globus GridFTP,
bbcp,
FDT,
SFTP/SCP |
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, and different subnets.
|
| Q: | What types of operating systems can I use for remote access? |
| A: | Supported platforms are MacOS, Windows, and Linux.
Check the NOMACHINE™ (NX) web site for additional details.
NOMACHINE players may also work on Android and IOS devices, but the screen size and resolution may likely be insufficient for controlling experiment with JBluIce.
|
| 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: both monitors should be set to the same color depth.
See the NOMACHINE™ article for additional details.
|
| Q: | What are my connection options? |
| A: | GM/[email protected] uses the NOMACHINE™ NX technology to provide users with full remote desktop
experience almost like being onsite. There are three NX connection options, each having its cons and pros depending on your network connection, client
computer CPU, GPU, RAM, and etc. These options are summarized in the table below and you can choose either one based on your preference. Sometimes
you may need to experiment in order to see which option works for you best.
| Option |
NX player |
NX Webplayer in some versions of Chrome, Opera, or Edge |
NX Webplayer in other browsers (Firefox, Safari..) |
| Installation required? |
Yes, installation and updates. See below. |
No, if you have the browser installed |
No |
| Desktop transfer technology |
X11 Vector graphics |
x264 video stream via WebRTC |
Motion JPEG (MJPEG) video stream |
| Desktop transfer efficiency (speed) |
Efficient (low network Mb/s requirement) |
Efficient, but needs fast client CPU to uncompress x264 |
Slower, whether it is acceptable depends on your network speed |
| Desktop transfer reliability |
Best |
Weak (may pixelate for some users) |
Moderate (may pixelate for few users) |
| Fitting hires desktop on lowres screen |
No |
Yes (see below) |
Yes (see below) |
If you are OK with installing and periodically updating NX Player on your computer, perhaps that will be your best option in terms of
connection speed (lowest lag in the remote desktop response) and reliability (lowest chance of pixelation or dropped connection). Using
NX Webplayer is the easiest and if you run it in Chrome to take advantage of WebRTC, it may be equally fast, but some users report problems
with it. The matter is that the Webplayer technology adds an extra layer of communication on top of NX Player (it uses NX Player internally)
which needs more computer resources and introduces more parameters (e.g. the browser brand and version) to optimize for best experience.
Using NX Webplaer without WebRTC may be more reliable, but slower and then it depends on your network speed if the response is acceptable.
Please always use wired network connection instead of Wifi when running any version of NX software.
|
| Q: | Do I need to install any software in order to connect remotely? |
| A: | The simplest connection option is to use NX WebPlayer. The later runs as a web page in regular
web browsers. No browser plugins/extensions or Java is required. Therefore with the WebPlayer option you do not need to install any software; just
make sure your browser does not use any Javascript blocker like NOSCRIPT or the blocker whitelists
the GMCA website. Start the WebPlayer here.
|
| Q: | Can I install a standalone NxPlayer application instead of WebPlayer?
|
| A: | Installation of NxPlayer is completely feasible, although it requires a few extra
steps compared to using the NOMACHINE™ WebPlayer.
- If you have admin rights to your computer, download and install the NOMACHINE™ Enterprise player for your operating system from the
NOMACHINE website; then start the nplayer.
- If you do not have admin rights to your computer and you are on Windows, you can still download the NOMACHINE™ Enterprise player:
it will install for non-admin users too.
- Once you start the standalone NxPlayer, click on the "Open connection" button.
- Load the preconfigured NX session file saved from Table-2.
|
| Q: | WebPlayer is slower for me than NXplayer. Can it be improved? |
| A: | WebPlayer and regular NXplayer (desktop application) use different ways of transferring
remote desktop graphics to your computer screen and WebPlayer itself also deploys different ways depending on your web browser. NXplayer tries to use
vector graphics whenever possible, which is very efficient as long as you do not have too many images or video on your desktop. In its turn, WebPlayer
defaults to Motion JPEG (MJPEG) which as a stream of JPEG snapshots of remote desktop. However, with some browsers, e.g. Google Chrome it can use very
efficient x264 video compression (or sometimes VP8) via the WebRTC streaming protocol. Then WebPlayer can be fast. WebRTC will not work in Safari or
Firefox. It may work in Google Chrome, or Microsoft Edge, or Opera depending on the browser version. Since web browsers as well as NOMACHINE software
are in permanent development, it is hard to predict compatibility in advance. For example, WebRTC worked with Google Chrome version 88, but stopped
working with version 89. When WebRTC "does not work", remote desktop does not load after you login with WebPlayer. Given this unpredictability, we decided
not offering WebRTC by default. There is a link to WebRTC sessions in Table-1 in case you want to try it on your own risk.
You can see this link for Google Chrome, Microsoft Edge, and Opera browsers only. The difference between Classic (MJPEG) and WebRTC (x264) links looks
as follows.
Classic (MJPEG):
https://xxx.gmca.aps.anl.gov:4443/nxwebplayer?config=gmca_classic.nxs
WebRTC (x264):
https://xxx.gmca.aps.anl.gov:4443/nxwebplayer?config=gmca_webrtc.nxs
If WebRTC connection fails for you either with remote desktop never loading of with an error message like this:
then replace in the URL "webrtc" by "classic" and try connecting again. It may be a bit slower, but should work. Classic connection was the only
one used before April 2019.
|
| Q: | WebPlayer login wheel is spinning forever, what is wrong? |
| A: | In some cases WebPlayer may stuck on login after reporting "Creating desktop". You may see a
spinning wheel and no remote desktop with Argonne Security dialog. It is a reported bug and NOMACHINE is working on it. Try to resize the browser window
1-2 times. In most cases it helps.
|
| Q: | WebPlayer desktop pixelates or mouse cursor is invisible on some windows. What can I do? |
| A: | Unfortunately, WebPlayer is not free of bugs and its behavior depends on type of web browser, client
(user) operating system and even client's computer hardware (CPU, graphic processor, network card), which makes it hard to resolve with the NOMACHINE Support. For example,
even locally at GMCA it may pixelate the desktop for some client computers (see a screenshot below) and work perfectly for others.
Pixelation can be cleared by moving affected window, but if it happens too often and disrupts your work, try switching to NX Classic connection, changing web browser
or installing NX client.
|
| Q: | Can I increase resolution in WebPlayer? |
| A: | Yes, unlike NXplayer, WebPlayer allows you to see remote desktop in a higher "resolution"
than the resolution of your desktop screen. It is possible because remote desktop is transferred as an image and it can zoomed out. Go to View controls
of your web browser and apply "Zoom Out".
|
| Q: | I am having problem to start standalone NxPlayer. |
| A: | This may happen sometimes because of the NxPlayer cache left after your previous beamtime.
The NX™ Enterprise player may be 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 under your home directory. On Windows it is under "C:\Users\<username>".
If you downloaded a 32-bit portable version of NxPlayer for Linux, be aware that some recent versions of Linux (namely Ubuntu of Fedora) may not
have support for 32-bit applications. To check if it is your case, open a terminal, find nxplayer and try to run it as "./nxplayer". When no 32-bit
support is available, you will see the message "no such file or directory", although the file exists. In this case download the 64-bit portable NxPlayer.
|
| Q: | When I am trying to login, the NxPlayer 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 ended),
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. You can also run
Check
Credentials tool which will let you check your password, eligibility of your IP address and the dates when you
are allowed to login.
|
| Q: | My connection was blocked, but I swear that I did not
try to login many times. What did I do wrong? |
| A: | There is a possibility that NxPlayer tried to login on its own.
It may happen if you checked a box for saving passwords. Then, the NxPlayer may repeatedly try to log you in. If you saved
an incorrect password or if you are trying to login beyond your beamtime time slot, the rejected logins may lead to a
firewall block. Please do NOT check the NxPlayer box for saving passwords!
|
| Q: | When I am trying to login, the session is
terminated before I get any connection. |
| A: | This is most likely a corrupted cache or cache from an older
NX version either on a 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 to my desktop and some panels are missing or
applications not working. What happened? |
| A: | This is known to happen when users login
locally and remotely on the same computer at the same time. Since both the applications started by
local and remote users write their auxiliary files into the same places, they may overwrite each
other's records causing the conflict. The recipe is not using the same computers for remote and
local logins with the same username. For example, if the remote part of the group logins on
workstation-2, the local part is advised to use workstation-3.
|
| Q: | NX™ Shadow session does not work: as soon
as I connect, I kick out my party and vice versa. |
| A: | When two users login via NX with the same account and one opens a virtual
desktop session, the default behavior for the second user is to take over. Use this keys combination: "Ctrl + Alt + Double-click" on the active
virtual session to achieve shadowing in NxPlayer (Cmd + Alt + Double-Click if you are using MacOSX). This applies to WebPlayer as well.
|
| Q: | When I shadow in NX™, I do not see my party's cursor and vice versa. |
| A: | This is configurable through NxPlayer and WebPlayer options. Access the player options by clicking
in the right top corner of the player window, then go to Input Setting and check "Show remote cursor pointer". Be aware that with this option checked, you
may see the cursor clone while moving it. More details can be found here.
|
| 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 ended 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.
|
| Q: | Are there any alternatives to NX™? |
| A: | -
You may try VNC tunneled via ssh (does not support shadowing). You will need some SSH client and a VNC client
(e.g. UltraVNC,
TightVNC,
RealVNC, or
TigerVNC).
First, create an SSH tunnel for VNC:
ssh -L 5950:localhost:5950 [email protected]
where the GM/CA workstations names are explained on the remote web page;
then run VNC on your remote computer and login with your account:
vncviewer localhost:5950
NOTE: do not replace "localhost" by anything else.
|
| Q: | How can I start/use Pilatus or Eiger software when I am remote? |
| A: | - Indeed, Pilatus software runs on a separate
computer. Pilatus and Eiger servers have no graphical interface and you do not need to see an output of them.
Simply click on the detector icon in the panel area at the top of the screen:
and make sure a new minimized terminal window has opened.
|
| 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.
Please note that remote performance of OpenGL may be sluggish.
|
| Q: | How can I offload my data? |
| A: | - You need to use either
Globus Online, or SCP/SFTP, or bbcp,
or FDT.
Among these tools, Globus Online, bbcp, and FDT may be 2-3 times faster than SCP/SFTP for bulk transfers,
but they may suffer from firewall blockages as they use multiple TCP ports. If you face such blockage,
you need to either resolve it with network administrator at your institution or revert to more
conservative SCP/SFTP that uses standard port 22.
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 is in progress). If you are interested in this free service, please check the details in our
Globus Online User Guide.
Unlike Globus, bbcp and FDT do not require
creating any additional accounts while being equally fast. However, they do not have rsync capability
and the command line syntax is somewhat cumbersome.
All data transfers use a dedicated workstation 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 ended. In principle, blXws6 may also be used for SCP/SFTP only, 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 MacOS while on Windows 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 [email protected]:/remote/dir /my/local/dir/
scp -rp [email protected]:/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!).
|
