Update Dockerfile

[dapugacheva]

Hi @carlhiggs

I've been working on the #375 D.2 point to eliminate multiple URLs for running Jupyter (actually only the second URL works), I created a set default command to launch when the container is run (copied from the OSMnx Docker file set up ). I assume it could be tested only from the host's Docker daemon. Let me know what you think about launching Jupyter without requiring authentication tokens and if we can proceed with it.

[carlhiggs]

Hi @dapugacheva , its an interesting idea, thanks for looking into this!

I don't know about launching directly into Jupyter Lab, as some users will want to use the web app, and others may have different intentions so like the command line flexibility (although there are commandline options within jupyter lab too).

One possibility is that rather than launching directly into Jupyter Lab, we could update the existing alias for launching Jupyter lab using your approach.

So this line (in the Enhancements branch, the otherwise most up to date branch; we could merge this in with the 'update' branch to make later integration easier),

global-indicators/docker/Dockerfile

Line 65 in fb7b996

echo 'alias lab="jupyter lab --no-browser --notebook-dir=/home/ghsci/process --allow-root --config=/home/ghsci/jupyter_notebook_config.py"' >> ~/.bashrc && \

could be edited somehow so lab instead launches the following command and directions,

jupyter lab --no-browser --notebook-dir=/home/ghsci/process --allow-root --config=/home/ghsci/jupyter_notebook_config.py --IdentityProvider.token='' --ServerApp.password='' --ip='0.0.0.0' --port=8888 & printf '\n$(tput bold)Jupyter Lab$(tput sgr0)\nOpen http://localhost:8888/lab to create or open a Notebook (e.g. example.ipynb)\nTo shut down Jupyter Lab, go to File > Shut Down.\n\n'

So, in the above, I edited the options to Jupyter lab you suggested because of deprecation warnings I received when I ran it:

Running the above edited version looks a bit like this:

But, I think if it were added as an alias

it would look like

the output "[12] 135" would probably be a bit confusing for users, but I'm sure there'd be a way to hide it.

I like the idea of simplifying what is printed to screen, and I'm not necessarily against running Jupyter Lab as a background process. It would be worth testing if/how it interferes with potential concurrent use of the GHSCI web app.

What do you think about the above suggestion, of not running Jupyter Lab automatically, but rather modifying the alias used to launch it?

[carlhiggs]

@dapugacheva re your question about running Jupyter without authentication tokens, I agree that we should consider the security implications. I am not certain, so think its worth being cautious. Perhaps check with @gboeing if he has thoughts on whether this being run in the context of our Docker environment would be secure for users. If we aren't certain, we should probably look into it until we are.

[gboeing]

The tokens provide authentication security for Jupyter running in a client-server environment. In a localhost only application the tokens are irrelevant for security because the server is only listening on localhost. See also https://blog.jupyter.org/security-release-jupyter-notebook-4-3-1-808e1f3bb5e2?gi=2f3a305c756c

[carlhiggs]

Thanks @gboeing ; that sounds good. I think this could be useful, but i'm still a bit uncertain about how best to implement this for users --- specifically, how to ensure they don't create duplicate servers using system resources that are inaccessible. I found this could be a problem, and will explain below. At the end, I propose a solution - love to hear your thour thoughts @dapugacheva and @gboeing .

I suggested earlier, I think its a good idea to not launch directly into Jupyter Lab. The current approach provides directions and links for usage of the software, whereas Jupyter Lab is what it is -- different software, which some people will but others won't want to use.

I tried a sketch of how @dapugacheva 's suggestion above could be implemented with modification of the jupyter_notebook_config.py script that is referenced within the lab alias:

global-indicators/jupyter_notebook_config.py

Lines 1 to 8 in 8d6861e

	c = get_config()
	c.Application.log_level = 'CRITICAL'
	c.ServerApp.use_redirect_file = False
	c.ServerApp.custom_display_url = 'http://127.0.0.1:8888/lab'
	# set the notebook ip to the Docker container ip
	c.ServerApp.allow_origin = 'host.docker.internal'
	c.ServerApp.ip = '0.0.0.0'
	c.ServerApp.port = 8888

I added this line on the end:

c.IdentityProvider.token = ''

So, the server launches when ran in this way, but without any directions:

I tested manually modifying the lab alias to display a print statement after running this, and this works --- launching the server, with directions:

So, that could be nice, but there is a problem. If a user carelessly doesn't shut down a server, like I didn't apparently, they can spawn multiple server instances. Despite specifying port=8888 in the config, subsequent instances are launched on incremental ports, yet these cannot be accessed locally (because we only open port 8888). The server on 8888 can be shut down in the browser, but the others can't. Servers launched with tokens (that produce the output we are trying to hide) can be stopped by entering jupyter server stop XXXX, but when you attempt to shut down servers launched without a token, you get HTTP 403: Forbidden error.

I'll paste screen shots below of the server list -- you can see I was experimenting, and somehow accrued a couple with tokens (ports 8888 and 8889); those could be shut down from commandline. But servers on ports 8890 and 8891 launched without tokens couldn't be terminated that I could see, except by exiting and restarting the Docker container.

But ... maybe I found a solution, kind of --- if the printf statement is put first, then the server isn't run in the background, which means multiple servers can't be run (or not easily/accidentally):

alias lab="printf '\n$(tput bold)Jupyter Lab$(tput sgr0)\nOpen http://localhost:8888/lab to create or open a Notebook (e.g. example.ipynb)\nTo shut down Jupyter Lab\n  - press Ctrl+C in this terminal window, or\n  - go to File > Shut Down in the Jupyter Lab interface.\n\n' & jupyter lab --no-browser --notebook-dir=/home/ghsci/process --allow-root --config=/home/ghsci/jupyter_notebook_config.py"

So, in the above image, useful guidance is displayed and the user can exit either via Ctrl+C or from Shut down in browser.

The down side is, when they do this, a nonsense echo of the printf code appears to be echoed; I don't know why:

But perhaps that's no big deal, and is an improvement on the current state of things

• useful directions are given for accessing and closing Jupyter Lab
• the unneccessary Jupyter Server logging is hidden
• a few artifacts appear, but mostly only after exiting when maybe it doesn't matter

Do you think this could be a useful approach then?

1. adding the extra line in jupyter_notebook_config.py, c.IdentityProvider.token = ''
2. changing the Dockerfile lab alias code to: echo 'alias lab="printf \"\n$(tput bold)Jupyter Lab$(tput sgr0)\nOpen http://localhost:8888/lab to create or open a Notebook, e.g. example.ipynb\nTo shut down Jupyter Lab\n - press Ctrl+C in this terminal window, or\n - go to File > Shut Down in the Jupyter Lab interface.\n\n\" & jupyter lab --no-browser --notebook-dir=/home/ghsci/process --allow-root --config=/home/ghsci/jupyter_notebook_config.py"' >> ~/.bashrc

If you know how to get rid of the artifact printf statement when shutting down the server, I'd love to know!

[carlhiggs]

Just closing this one as the changes discussed above have now been implemented as part of other changes; thanks @dapugacheva for the suggestion