Hi Merlin,
Have you used this on the new lsst-dev machine? I followed this (very helpful, thanks) post before the switch over with no problem but now I’m getting an error from jupyter notebook:
socket.error: [Errno 99] Cannot assign requested address
Have you seen this before?
-Bryce
Try:
$ ipython notebook --no-browser --ip=127.0.0.1 --port=YYYY
Seems to work for me.
Credit here: https://github.com/ipython/ipython/issues/6193#issuecomment-50062534
You don’t need to specify a port for this magic to work; as usual jupyter will choose an available port >= 8888. You can say --port YYYY if you like.
This still seems to be necessary, and John’s GitHub link implies that it’s something due to a misconfiguration problem at NCSA. Can someone take a look? I’m pinging @daues, but I’ve no idea if he’s the right person.
The problem is that lsst-dev01 does not recognize localhost as 127.0.0.1, despite it being in /etc/hosts. I’m not sure if this is intentional or a misconfiguration.
I’ll gather the response of our admins to this. Some searching around suggests the order of entries in /etc/hosts may be wrong (?)
https://bugzilla.redhat.com/show_bug.cgi?id=1093037
I may have been wrong about this (unless something changed). ping localhost works fine. I was using a different (probably incorrect) tool.
I think the issue is that localhost is both 127.0.0.1 and ::1. IPython seems to be trying to bind to the latter rather than the former, and that’s what fails.
I gave this a try today and @Merlin was very kind to help over Slack! Ultimately, I wasn’t able to get it working, because no local copy of ds9 I launched was ever willing to grab the port numbers I configured with XPA_PORT. It would instead insist on choosing something like XPA_METHOD: /var/folders/gh/wk3w_d9d5qx_550341rf7gmh0000gn/T//DS9_ds9.45817 (where the last number is apparently randomly assigned).
This turned out to be caused by the line export XPA_METHOD=local in my .bashrc, which I added ages ago to stop ds9 from often telling me “XPA unable to verify hostname, setting XPA_METHOD to LOCAL” in a pop-up when it launched. With the XPA_LOCAL export removed, and the XPA_PORT export in place, ds9 apparently tries to take the XPA_PORT assignment and fails because it doesn’t believe my hostname can be verified. It displays the popup warning yet again and does not set XPA_METHOD as desired.
This problem is apparently indicative of how one’s internet hostname is managed(?), and not something I can easily work around. If you know otherwise, I’d love to hear more!
Thanks @price, that is indeed easier (once I installed xpra on my Mac). The ds9 window has very weird/ugly fonts when it loads over xpra, but it appears reasonably promptly, and that’s essentially what I was after!
I think the fonts issue clears up if you reset the ds9 preferences, or you explicitly set a font size, or something like that.
I am not sure if this is relevant. But I cannot make this work with the current stacks available on lsst-dev (I actually tried w_2017_40, v14_0 and w_2017_44). The failure mode is that ipython and claims to run fine in the terminal. But it does not show up on my local browser (I get the default THIS WEBSITE CANNOT BE REACHED). I went through the checklist in Ds9 communication via XPA through step 6 to no avail. I talk with a Sam Thrush who had previously made it work with lsst_distrib -t w_2017_18. But that is no longer an option on lsst-dev, and she gets the same failure mode as I do now. Is there an available stack that makes this work?
Sorry, this isn’t really debug information, but this isn’t a problem with the stack version as I just tried w_44 on lsst-dev, and have no problems connection to either the ipython kernel, nor forwarding data to ds9.
It sounds like your ssh tunnels aren’t working/configured correctly; if I try to connect to localhost:<random_number> I get that error too, so I suggest that something in the ssh and tunneling setup is the point of failure. Hope that’s of non-zero help.
Merlin helped me offline with this (thanks, dude). The issue was port choice. 6668 was insecure. You may want to check out:
http://www.networksorcery.com/enp/protocol/ip/ports06000.htm
If your jupyter is not working over the network.
Hello, I am coming back to this old post because I do not manage to run ds9 through the lsst-lspdev jupyterLab. Did anyone succeed?
The above instructions won’t work with LSST-hosted Jupyterlab installations (lsst-lspdev, etc.), because you can’t SSH to the jupyter instances.
From private conversations, it sounds like it actually should be/is possible to setup the necessary tunnels by ssh-ing out, but this should be considered unsupported at best!
