auth0 jupyterhub authenticator

,
, , , ,

i’m sysadmin of some linux gpu servers in the phd working group and having to manually setup new users is a massive PITA.

a few options for replacements

  • Auth0 Authentication
  • KeyCloak OIDC / OAuth2 Authentication
    • https://www.keycloak.org/
    • functional+tested implementation up and running
    • only problem is existing user data — the user’s UID inside the spawned container depends on the order in which users start logging in, rather than ownership of local files.
    • could bind mount /home/{user} into container at /mnt/server then change $NB_UID for container user during usermod to match the UID of the user’s /home/{user}/.bashrc file — means another change to jupyterhub’s start.sh script in the Docker images.
    • Could also symlink /mnt/server to /home/{user}/server at end of start.sh with everything else in /home/{user} mounted in a docker volume? although docker volumes are NOT stored on the SSD for some servers because of disk space issue so user data wouldn’t be on the SSD :[
    • Better idea would probably be mount /home/{user} as before and change $NB_UID of $NB_USER to the uid of .bashrc (without chown-ing user files)
    • If no /home/{user} exists… then…. what happens? JupyterHub server does create the user account… so should be a simple case of look at uid of .bashrc … see it’s the same as $NB_UID… do nothing…?
    • BUT … JupyterHub will only create the /home/{user} directory inside its container (if using the completely containerised version) … which means that /home would still need to be mounted in the jupyterhub-{type} containers…. This will probably cause an absolute mess for user data though there will be multiple users that have files with UID=1000 etc. And because students can still SSH onto the servers it means they might be able to access other user’s data… :[
  • Native Authenticator