Project: JupyterHub (Part 2, Edit 1)

Lessons Learned:

The virtual host was originally Ubuntu 16. To upgrade to v18 in place: [should we add some words on what it means to upgrade from Ubuntu 16 to 18?]

$ apt update

$ apt upgrade

$ apt dist-upgrade

$ apt install update-manager core

$ do-release-upgrade

This was per: per

I did those steps in a tmux session [so as not to lose the output when disconnected from the remote host] due to the length of time required to perform those steps.

The main configuration file of TLJH is a yaml file [text file with a specific syntx]. TLJH comes with a utility command, “tljh-config”, to set its values.

Example usage:

$ tljh-config set foo bar

That was cool. However it didn’t seem to handle array values [what happens when TLJH can’t handle array values?] very well, so I edited the yaml file by hand for an array value. I was unsure at first how to do arrays in yaml. They look like this:


– Array entry 1

– Array entry 2

The spacing is important – two spaces per indent. [Underlined for emphasis]

Also, and this was probably the most embarrassing mistake of all, I confused the documentation of one version of JupyterHub as the documentation for the different version [should we or identify this version? “the TLJH version” or something]  I was actually working with. They looked identical, but they were not. I spent hours configuring LDAP authentication according to its docs, only to learn at the end that when I tried to enable it for use, that it’s not an option in the version I was installing. However, as a bit of a consolation prize, it supported authenticating against GitHub credentials, so I set that up instead.

Also, after successfully installing JupyterHub, I was baffled by the method in installing additional conda packages into the environment. I could not find the installed python venvs [venvs?]  on the command line. In the JupyterHub web interface, under the same “New” menu where you launch a new notebook, you can also (or at least I could as an admin) launch a new “Terminal” session. This gave me an interface into the underlying venv environment, and I could use pip and conda to my hearts content. One of these days, I’ll figure out where those venvs live in the actual server. So that’s how I installed the ldap-authenticator plugin. ($conda install -c conda-forge jupyterhub-ldapauthenticator) The “-c” in that command tells conda to use the conda-forge channel, which I believe are the kind folks offering the ldap-authenticator plugin.

Regarding the OS. Originally I tried installing JupyterHub on one of the CentOS7 servers we had been using for a professor’s economics research. It refused to install, requiring an ubuntu 18 server. So I tried spinning up an ubuntu container on it using docker (“docker pull ubuntu:latest” to pull down an official ubuntu image from dockerhub, then a “docker container run -it ubuntu:latest /bin/bash” to start and attach a shell). However, that turned out to be a very minimal ubuntu image – it didn’t have “vi”, or “which”, or “man”, or “ping.” It was difficult to perform the simplest tasks, it seemingly catered more towards a microservices crowd [what’s the difference between a microservice crowd and the crowd for the project?]. After poking around to find a fuller ubuntu image on DockerHub (and faiIing … or was it that DockerHub failed me? [lol]) I punted and went with creating a full-blown ubuntu vm using an ubuntu template in vCenter. [This allowed me to use the tasks from a proper ubuntu image] After that it was pretty smooth sailing.

By Andrew Crawford