Thanks for the quick response/
Any suggestions on how the host_regex should be?
our hosts are set with compute-x-x and gpu-x-x convention
we can add the <my_center.edu> part to the hostname if needed.
Right now it looks like this:
Ok I was able to get that part fixed with adding the mycenter extension to the hostnames.
What’s remaining is the password prompt which says “invalid”
First it goes to login authentication page again and then “invalid” password for jupyter.
Bummer, that would have been a quick fix. In any case, that topic has a lot of debugging steps that I would just replicate here. If you do look through it and still can’t find what you’re looking for update this topic with information and we’ll look into it more.
Things we’d want to know are
what your view.html.erb looks like (if it’s different from ours).
if you’re creating a valid connection.yml file (the directory for a given session is described in the other topic).
what you’re passing when you submit the form (what’s included in all those Firefox/Chrome dev tool images in the other topic)
Looking at that topic, one obvious difference in our case is that,
when we click the “connect to Jupyter” in the Sandbox environment, it prompts to the ondemand web authentications which users have already done when they logged into the website.
Then we pass that authentication, and then “jupyter password” webpage appears with a message “invalid authentication”
For the sake of testing, I tried to copy the password that is generated in
“connection.yml” file under <user_path>/jupyter-notebook/output/<jupyter_instance>
and when enter that, a blank page appears. It seems the same with entering any other password.
OK yea something’s very wrong with that. You should not have to authenticate twice. You’re going to need to use Chrome’s web dev tools to ‘open on new tab’ and see how you’re being redirected once you click ‘connect to jupyter’.
I’m not sure why/how you’re being redirected like that. What authentication method do you use. And are you being redirected to a different host? like sandbox.myorg -> production.myorg?
Here is what I see when clicking the “connect to Jupyter”:
This is the authentication pop-up that appears and I try to cancel –
The override.css looks like
Is that the CAS that you were referring to??
My response headers look like this. The big difference here is the ‘Location’. It should be relative (there’s no hostname in the location, it’s only the path) and from Jupyter itself (the ‘server’ is TornadoServer, that’s Jupyter).
How you’re being redirected seems very off to me, especially if you need to re-login.
Thanks for bearing with us as we investigate the issue. We use LDAP for authentication not CAS.
I will revisit those steps and provide the web screenshot you requested. In the meantime, can you remind me what path should we expect as the output of each jupyter launch?
For some partitions, I get
which seems to be wrong?
Any hints on what to check to get that part fixed are appreciated
That’s the right path, but the wrong host. https://<OOD HOST>/node/compute-x-x.<mycenter.edu>/16863/ should be the host/path.
If you look at our view.html.erb (the box that has the ‘connect to jupyter’ button) the action is relative meaning you should still land on the open ondemand host and not be redirected directly to the compute node, we (OOD) should be proxying to the compute node for you.
Under the General tag in Headers or Response Headers or Request Headers, the “Location” doesn’t appear.
As mentioned, one difference with the other thread is that it routes to authentication again before getting to jupyter, i.e., after “connect to Jupyter” the authentication prompt window appears again. If I authenticate that, then I am prompted to the jupyter notebook with an “invalid credentials” message. Then, attached is the screenshot you asked for.
As a side note,
I just see something in the jupyter output file from one of the launches:
/home/user/ondemand/data/sys/dashboard/batch_connect/dev/jupyter_notebook/output/jupyter-id/before.sh: line 38: openssl: command not found which means traffic won’t be encrypted. I don’t think that’s related but just wanted to bring that.
Just for sanity checks: here is the websockify installation
I have verified that websockify is installed and working on the COMPUTE node:
As a sanity check, be sure you’re passing the password in the form data. You’ll see it in under the ‘request headers’ portion of your chrome dev tools. I don’t think it’s a problem, but just to be sure.