Hi Norman - You are correct that Jupyterhub will serve without SSL simply by not providing the SSL keys. There used to be an explicit "--no-ssl" flag but that was deprecated with the 0.7 release.
My suspicion is that this is going to be more finicky than you would like. Presumably you want users to be able to connect to the service using either endpoint. The simplest approach would be to run two fully parallel Jupyterhub stacks, but in that case your users would get two independent sessions if they connected through both endpoints. Maybe that is acceptable for your use case. If not, you thus need to ensure that both Hub/Proxy pairs know about sessions and routes modified by the other. You can do this by pointing them at a common database backend, but I don't think this has been extensively tested and there may be corner cases where one Hub fails to query the DB at the right time. Certainly you will want to use a RDBMS server backend, since the default sqlite implementation is not safe for parallel access. Alternately, and possibly more robustly, you could subclass the Proxy interface to make a single Hub drive two copies of the Proxy component. https://jupyterhub.readthedocs.io/en/latest/reference/proxy.html Personally, I would just run a single Jupyterhub stack (without SSL) behind nginx, and also have nginx or the Proxy (see "--redirect-port" at https://github.com/jupyterhub/configurable-http-proxy) serve a redirect from port 8000 to the nginx endpoint. Regards, Michael On Thu, Mar 22, 2018 at 1:04 PM, Norman Gray <norman.x.g...@gmail.com> wrote: > > Roland, hello. > > On 22 Mar 2018, at 8:22, Roland Weber wrote: > > Afaik, listening on two different ports is not possible without changing >> code. >> > > Righto -- thanks for confirming. > > You could also solve your problem by keeping JupyterHub on the deprecated >> SSL port, and encrypting the connection between the SSL-terminating proxy >> and JupyterHub. >> > > Yes -- I'm going to run two servers, an exposed SSL one and a > reverse-proxied non-SSL one. > > Are they likely to fight with one another, do you think? I can't think of > a reason why they would, but I could be lacking imagination here. > > I'm sure that pull requests to improve the documentation will be happily >> accepted :-) >> > > I've added an issue <https://github.com/jupyterhub/jupyterhub/issues/1747> > which includes some suggested text. > > Thanks for your help. Best wishes, > > Norman > > > -- > Norman Gray : https://nxg.me.uk > > -- > You received this message because you are subscribed to the Google Groups > "Project Jupyter" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to jupyter+unsubscr...@googlegroups.com. > To post to this group, send email to jupyter@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ms > gid/jupyter/2F6AB0DA-4FA4-49B9-A202-231700E5090D%40gmail.com. > > For more options, visit https://groups.google.com/d/optout. > -- Michael Milligan, Ph.D. | Supercomputing Institute Assistant Director for | University of Minnesota Application Development | milli...@umn.edu www.msi.umn.edu/staff/milligan | Phone: 612-624-8857 -- You received this message because you are subscribed to the Google Groups "Project Jupyter" group. To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+unsubscr...@googlegroups.com. To post to this group, send email to jupyter@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CAPuy8gpePT3_90VbpWWHj_kZoN%3DDWFAtQ5qxvXgBnLoVP%2BJpGw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
