plasmabio / tljh-repo2docker

Plugin for The Littlest JupyterHub to build multiple user environments with repo2docker

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Same User Accessing Different Environments

psychemedia opened this issue · comments

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 😕
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.

image

The animated gif below shows how the user will connect to the first one and then to the second:

Peek 13-08-2020 13-47

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:

  1. 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
  1. 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 👍

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.

  1. 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?

Thanks @psychemedia for sharing this 👍

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.