restricting port range for spawned jupyterhub singleuser servers

[pontiggi]

Hello,
I needed to setup jupyterhub on a cluster which - due to data security requirements and policy - the incoming connections to the compute resources in the private IP space from the submission host have to be restricted to a limited number of predefined ports on which the compute nodes can be reached.

I did not seem to be able to control that feature within the existing code for the batchspawner.
I solved the problem with the following change in a fork of the repo
pontiggi@50428e8
in which I added an additional option, configurable in jupyterhub_config.py , to set the port range for the spawned singleuser servers. something like for example
c.BatchSpawnerBase.ports = '40000-41000'

I was wondering if there was any other way already existing in the orignal code base to achieve the same goal, with some option I might have missed.
Or, if there is not such option, if you are interested in incorporating this in the upstream code. In which case I'll be happy to cleanup the code as needed according to your guidelines and open a pull request.

Thanks for any advise or feedback
Best
Francesco

[rkdarst]

Hi,

This seems like a good idea overall. I'll leave some comments in the diff, but note that I'm not actually a batchspawner developer but have done a lot of work in it. (There isn't any current way to do this, unless OS can control the default bind ports and thus affect the behavior of jupyterhub.utils.random_port).

My first thought was "this would be good to add to jupyterhub", but randomly checking two spawners show there isn't necessarily a lot of overlap. Plus it would require many jupyterhub releases before it could be relied on here anyway. Plus there's no default way for random_port to get info from the spawner options...

Have you seen #58? It is somewhat related in that it is about more clever port selection, but not limiting that selection. If we ever made progress on that, we should put these two together.

I'll highlight @minrk since it possibly relates to jupyterhub itself. (btw, abstractly I still want to integrate #58 with JH but it's been slow going)

[mbmilligan]

I think the most general way to handle this would be for us to pull out the call to jupyterhub.utils.random_port() into a trait or class method that could be overridden during the configuration process. Off the top of my head, I'm thinking we could use a trait that accepts a callable (specified to return a port number), and we could have pre-made callables for common scenarios like "a range of ports" or, once #58 goes through, "use the port selection API."

[rkdarst]

I think @mbmilligan's solution is quite clearly the right one for now...

[rkdarst]

In #114 I implemented @mbmilligan's suggestion.