-
Notifications
You must be signed in to change notification settings - Fork 35
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
Update Dockerfile #399
Update Dockerfile #399
Conversation
Set default command to launch one token when container is run.
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), could be edited somehow so lab instead launches the following command and directions,
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: it would look like 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? |
@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. |
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 |
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 I added this line on the end:
So, the server launches when ran in this way, but without any directions: I tested manually modifying the 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 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):
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
Do you think this could be a useful approach then?
If you know how to get rid of the artifact printf statement when shutting down the server, I'd love to know! |
…an, Hindi, Tamil script etc) via uharfbuzz cpython module; had to install gcc and g++ for this to work on the arm64 build; also updated Jupyter Lab start alias as per #399. Also added new languages and auto-translations of these in anticipation of translation validation, in support of #367. This image hasn't been fully tested yet, and more language features require implementation (e.g. right to left template support for Arabic and Persian; needs to be added as new issue)
…an, Hindi, Tamil script etc) via uharfbuzz cpython module; had to install gcc and g++ for this to work on the arm64 build; also updated Jupyter Lab start alias as per #399. Also added new languages and auto-translations of these in anticipation of translation validation, in support of #367. This image hasn't been fully tested yet, and more language features require implementation (e.g. right to left template support for Arabic and Persian; needs to be added as new issue)
Just closing this one as the changes discussed above have now been implemented as part of other changes; thanks @dapugacheva for the suggestion |
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.