We have been using Apache and Shibboleth with ProxyPass to CryoSPARC’s port 39000. This no longer works with version 4.0.0. Any suggestions on how to proxy to version 4 since there is no built in https support?
Please can you
- post a screenshot of your browser window that illustrates the failed connection
- post a screenshot of output to the browser console during a reload attempt of that web page (More tools|Developer tools on Chrome).
at the browser console prompt
- email us the output of
Here’s a screenshot. I’ve done the localStorage.setItem(‘cryosparc_debug’, ‘on’) and reload as requested.
Our Apache conf has:
Thanks for sending this over. Can you also send us the output of
Can you also open up the “Network” tab in the Developer Tools, refresh the page, then send us the screenshot of that?
cryosparc5@dcc-cryosparc-05 ~ $ cryosparcm status
CryoSPARC System master node installed at
Current cryoSPARC version: v4.0.0
CryoSPARC process status:
app RUNNING pid 558724, uptime 18:50:53
app_api RUNNING pid 558790, uptime 18:50:52
app_api_dev STOPPED Not started
app_legacy STOPPED Not started
app_legacy_dev STOPPED Not started
command_core RUNNING pid 558574, uptime 18:51:24
command_rtp RUNNING pid 558606, uptime 18:51:14
command_vis RUNNING pid 558600, uptime 18:51:16
database RUNNING pid 558460, uptime 18:51:31
License is valid
global config variables:
Can you set this variable to
localhost and comment out (add a
# in front of the line)
export CRYOSPARC_HOSTNAME_CHECK=“dcc-cryosparc-05.rc.duke.edu”. Once that’s done, restart CryoSPARC (
cryosparcm restart) and try again
I can, but we had to set that value because this server has 2 NICs. One network interface is where the CryoSPARC web server is connected to and the other NIC is plumbed into the subnet our Slurm cluster and where the GPU compute nodes that CryoSPARC uses for jobs is located. The CryoSPARC worker was unable to contact the master until we added that variable setting.
@jmnewton based on the logs, it seems two services (
app at port 39000 and
app_api at port 39006) are having trouble talking to each other.
Note that port 39006 used to host the CryoSPARC Live web application which has now been integrated into the main CryoSPARC application at 39000. The 39006 service now provides real-time subscriptions for the main web application’s server process and no longer needs to be accessible from a browser.
Do you have any authentication enabled in your Apache or proxy config for
dcc-cryosparc-05.rc.duke.edu:39006 to allow browser access? Or perhaps forcing HTTPS on it? If so removing that config and restarting CryoSPARC should fix the issue.
If you’ve checked this and CryoSPARC still doesn’t load, could you send me the output of the following command from the master host?
Edit: Fixed curl URL
OK, here’s the output:
curl "http://dcc-cryosparc-05.rc.duke.edu:39006" cryoSPARC Application API
Oops sorry, gave you the wrong URL, it’s
By the way setting CRYOSPARC_MASTER_HOSTNAME=“localhost” and restarting throws an error:
ERROR: Re-run this command on the master node: localhost.
Alternatively, set CRYOSPARC_FORCE_HOSTNAME=true in cryosparc_master/config.sh to suppress this error.
If this error message is incorrect, set CRYOSPARC_HOSTNAME_CHECK to the correct hostname in cryosparc_master/config.sh.
Re: The localhost hostname error, try adding that line to you cryosparc_master/config.sh
Once you have that, try logging into the web interface again, wait for the web page loading to stall. Then can you send me the output of the following commands?
cryosparcm log app | tail -n 1000 cryosparcm log app_api | tail -n 1000 cryosparcm log command_core | tail -n 1000
Output sent to email@example.com in attached files due to length.
Hi @jmnewton ,
Could you refresh the page while the ‘Network’ browser dev tools tab is open, select the
/websocket line and paste a screenshot? Please make sure to wait a bit (shouldn’t report ‘pending…’). Example:
The first websocket capture uses the original cryosparc_master/config.sh and the second with the ‘export CRYOSPARC_MASTER_HOSTNAME=“localhost”’ change.
Hi @jmnewton ,
Thanks for these. The screenshots show the request is still in progress - we’d like to see the result of the request after it has returned. Please give it a minute or so.
The first screenshot indicates quite a few console errors - could you also send a screenshot of that over?
Hi @jmnewton ,
This is quite odd indeed. We haven’t been able to reproduce this issue. Could you either downgrade to v3.4 or stay on v4.0 and use the legacy application? You can start the process by running
cryosparcm start app_legacy .
Is there any other information you can provide about your setup? Perhaps you can email us another set of recent logs.