Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR includes changes I made in my fork to get SSHSpawner to work with JupyterHub 2.3.1 in my personal Docker-based testing environment. There are not many source-code changes, so I will describe them all:
Simplify since ip and port always required now: This is a simplification of the
get_port.py
script. Since the latest versions of JupyterHub seem to require bothip
andport
be specified (and in that order), I just simplified the script to always return the(ip, port)
tuple. However, maybe we want backwards compatibility, in which case this should probably be reverted/modified.Change default IP for all SSHSpawners: By default, JupyterHub Spawners have a default
ip
of127.0.0.1
, which will not work for any remote singleuser instance. According to the JupyterHub documentation, remote Spawners should use anip
value of0.0.0.0
. I cannot think of an instance where an SSHSpawner would not be remote (otherwise why not just use LocalProcessSpawner?), so I've changed the defaultip
value to0.0.0.0
.Always set the port: SSHSpawner relies on the separate
get_port.py
script to determine the port on the remote system to listen on, which means the remote port number needs to be passed to the singleuser instance. So, I figure you probably always want the--port
option set.Wrap all env vars in quotes to ensure JSON encoding & Need single quote to wrap JSON: There are
JUPYTERHUB_*
environment variables sent to the spawned process that contain JSON data, and the previous setting/exporting of those environment variables in SSHSpawner's bash run script did not encase this JSON in quotes, just leading to improperly set environment variables. For safety's sake, I have wrapped all of the environment variables used in the SSHSpawner run script with single quotes. Something more sophisticated may be needed if this is not always sufficient.In additiion to these source-code changes, I had to make one additions to the
jupyterhub_config.py
file to allow SSHSpawner to work. This change was:I am not sure if this suggests a modification needs to be made to SSHSpawner that I have not made. It seems to me that there should be an automated was of constructing the SSHSpawner's
hub_api_url
from information already known. I just haven't investigated this, yet.I completely understand if these changes are not what you want implemented in SSHSpawner. I just wanted to share them with you to demonstrate what I needed to do to get it to work with JupyterHub 2.3.1 (latest version).