Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

restricting port range for spawned jupyterhub singleuser servers #102

Open
pontiggi opened this issue Jul 26, 2018 · 4 comments · May be fixed by #114
Open

restricting port range for spawned jupyterhub singleuser servers #102

pontiggi opened this issue Jul 26, 2018 · 4 comments · May be fixed by #114

Comments

@pontiggi
Copy link

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
Copy link
Contributor

rkdarst commented Jul 27, 2018

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
Copy link
Member

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
Copy link
Contributor

rkdarst commented Jul 31, 2018

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

rkdarst added a commit to rkdarst/batchspawner that referenced this issue Aug 7, 2018
- Allows selection of random ports within a certain range only as a
  first use case.
- Closes: jupyterhub#102 via a different strategy.
- Currently uses the traitlet Any, but should be Callable - but this
  is not in upstream traitlets, it is special to kubespawner.  So
  leave Any for now and change later.
@rkdarst rkdarst linked a pull request Aug 7, 2018 that will close this issue
@rkdarst
Copy link
Contributor

rkdarst commented Aug 7, 2018

In #114 I implemented @mbmilligan's suggestion.

rkdarst added a commit to rkdarst/batchspawner that referenced this issue Sep 5, 2018
- Allows selection of random ports within a certain range only as a
  first use case.
- Closes: jupyterhub#102 via a different strategy.
- Currently uses the traitlet Any, but should be Callable - but this
  is not in upstream traitlets, it is special to kubespawner.  So
  leave Any for now and change later.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants