Categories
notes tech

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
Categories
notes

linux find

Write this up as a response to someone on hackernews but didn’t submit it. Dumping here for reference…


search for exact pattern in all basenames

find . -name "<pattern>"

search for pattern at the start of basenames

find . -name "<pattern>*"

search for pattern at the end of basenames

find . -name "*<pattern>"

search for pattern anywhere in the basename

find . -name "*<pattern>*"

search for multiple patterns anywhere in the basename

find . -name "*<p1>*<p2>*"

path based patterns (same wildcards as above)

find . -path "*<p1>/*/<p2>*"

directories using basenames

find . -type d -name -f "*<pattern>*"

non directories using basenames (technically directories are files too!)

find . -type f -name -f "*<pattern>*"

only recurse 3 directories deep

find . -maxdepth 3 -name "*<pattern>*"

start 2 directories deep

find . -maxdepth 2 -name "*<pattern>*"

search only in directories 2 levels deep

find . -maxdepth 2 -mindepth 2 -name "*<pattern>*"

execute a command on each result (force remove files)

find . -type f -name "*<pattern>*" -exec rm -f {} \;

execute two commands in order on each result

find . -type f -name "*<pattern>*" -exec cp -f {} ./archive/ \; -exec rm -f {} \;

use find results with GNU parallel to speed up smaller tasks

(so long as they’re safe in parallel that is)

find . -name "*<pattern>*" | parallel ./some-script.sh {}