tljh-repo2docker
tljh-repo2docker copied to clipboard
Same User Accessing Different Environments
I'm sure I had this working differently before, but on a recent deployment of the tljh-repo2docker
recipe (modified to use the first use authenticator), I seem to have got locked into only being able to run the environment I first ran as a new user and not being able to launch any other environment.
That is, if I have created two different environments (environmentA
and environmentB
), if I log in as a new user and launch environmentA
, then shutdown that server, logout, log back in again, select environmentB
and launch that, it's actually environmentA
that launches?
In this setup, it seems the user has to commit to one environment rather than stopping and starting different environments? Whereas I had thought I could stop one server and then start another at will?
Hi @psychemedia Humm this seems weird :confused: I confirm that a given user should connect to a first env, shutdown this server and then reconnect to another env.
For instance, user stu123
has access to 2 envs : cours-python
and cours-bash-test
.
The animated gif below shows how the user will connect to the first one and then to the second:
I hope this helps.
@pierrepo Yep, that's what I thought I should happen. But whatever I select second time round, I still launch into the same container as the one I launched first. And it seems to start up really quickly...
Two tweaks I made to the config compared to your installer:
- I switched to the firstuseauthenticator:
# Full path if required: /opt/tljh/hub/bin/tljh-config
sudo tljh-config set auth.type firstuseauthenticator.FirstUseAuthenticator
sudo tljh-config set auth.FirstUseAuthenticator.create_users True
sudo tljh-config reload
- Set up a domain and added https as per here.
Demo server is at https://arms.ouseful.org/ for next few hours, but then it will be ripped down. (I can let you have an admin account if that helps.)
(I did wonder if my browser was cacheing something but I seem to get the same effect in different browsers.)
A UI note... If you stop the server, then you are presented with a Start Server button. My expectation is that that would (re)start the server you just stopped, rather than take you to the start server selection page. Tweaking the button text to Select and start server would make things clearer?
Hello @psychemedia
And it seems to start up really quickly...
That's probably a sign you're still in the same env.
Domain and https should not interfere since it's also what we did with Plasma.
Unfortunately, I'm not familiar with firstuseauthenticator
. But as far as I understand in the README, firstuseauthenticator
does not use the classical PAM Unix. This could explain the issue. Maybe @jtpio could have thought on this (but he's not yet available).
Tweaking the button text to Select and start server would make things clearer?
Thanks for the suggestion. I'll make an issue for this :+1:
I did wonder if the way the users were handled might be the issue. I've had to destroy the server for now but I'll try to explore a bit more using different authenticators/user creation methods next week to see if I can recreate the issue.
The authenticator should be agnostic to the rest of the configuration.
Meaning that Plasma uses PAMAuthenticator
but the firstuseauthenticator
should also work fine with tljh-repo2docker
.
- I switched to the firstuseauthenticator:
# Full path if required: /opt/tljh/hub/bin/tljh-config sudo tljh-config set auth.type firstuseauthenticator.FirstUseAuthenticator sudo tljh-config set auth.FirstUseAuthenticator.create_users True sudo tljh-config reload
@psychemedia is that the only tweak to the JupyterHub config?
I think I'd also set a certificate for https/ssl.
This is the (manual) script I used. https://github.com/ouseful-demos/ou-rclub#multi-user-jupyterhub-server-used-for-the-tutorial
Thanks @psychemedia for sharing this :+1:
It looks like HTTPS shouldn't have any effect on this behavior.
Don't hesitate to post here if you spin up a new VM with this setup. Otherwise it should also be possible to test locally and changing the test config to use the other authenticator.