Setting up Jupyter Notebook on my Linode
A Jupyter Notebook is an open-source web application that allows you to create and share documents that contain live code, equations, visualizations and narrative text.
Uses include:
- data cleaning and transformation
- numerical simulation
- statistical modeling
- data visualization
- machine learning
- and other stuff
I’ve been interested in how to set up a Jupyter Notebook on my Linode server for a while, but kept running into a roadblock (either mental or technical I’m not really sure).
Then I came across this ‘sweet’ solution to get them set up athttp://blog.lerner.co.il/five-minute-guide-setting-jupyter-notebook-server/
My main issue was what I needed to to do keep the Jupyter Notebook running once I disconnected from command line. The solution above gave me what I needed to solve that problem
nohup jupyter notebook
nohup allows you to disconnect from the terminal but keeps the command running in the background (which is exactly what I wanted).
The next thing I wanted to do was to have the jupyter notebook server run from a directory that wasn’t my home directory.
To do this was way easier than I thought. You just run nohup jupyter notebook from the directory you want to run it from.
The last thing to do was to make sure that the notebook would start up with a server reboot. For that I wrote a shell script
# change to correct directory
cd /home/ryan/jupyter
nohup jupyter notebook &> /home/ryan/output.log
The last command is a slight modification of the line from above. I really wanted the output to get directed to a file that wasn’t in the directory that the Jupyter notebook would be running from. Not any reason (that I know of anyway) … I just didn’t like the nohup.out file in the working directory.
Anyway, I now have a running Jupyter Notebook at http://python.ryancheley.com:88881
- I’d like to update this to be running from a port other than 8888 AND I’d like to have it on SSL, but one thing at a time! ↩︎
Making it easy to ssh into a remote server
Logging into a remote server is a drag. Needing to remember the password (or get it from 1Password); needing to remember the IP address of the remote server. Ugh.
It’d be so much easier if I could just
ssh username@servername
and get into the server.
And it turns out, you can. You just need to do two simple things.
Simple thing the first: Update the hosts file on your local computer to map the IP address to a memorable name.
The hosts file is located at /etc/hosts (at least on *nix based systems).
Go to the hosts file in your favorite editor … my current favorite editor for simple stuff like this is vim.
Once there, add the IP address you don’t want to have to remember, and then a name that you will remember. For example:
67.176.220.115 easytoremembername
One thing to keep in mind, you’ll already have some entries in this file. Don’t mess with them. Leave them there. Seriously … it’ll be better for everyone if you do.
Simple thing the second: Generate a public-private key and share the public key with the remote server
From the terminal run the command ssh-keygen -t rsa. This will generate a public and private key. You will be asked for a location to save the keys to. The default (on MacOS) is /Users/username/.ssh/id_rsa. I tend to accept the default (no reason not to) and leave the passphrase blank (this means you won’t have to enter a password which is what we’re looking for in the first place!)
Next, we copy the public key to the host(s) you want to access using the command
ssh-copy-id <username>@<hostname>
for example:
ssh-copy-id pi@rpicamera
The first time you do this you will get a message asking you if you’re sure you want to do this. Type in yes and you’re good to go.
One thing to note, doing this updates the file known_hosts. If, for some reason, the server you are ssh-ing to needs to be rebuilt (i.e. you have to keep destroying your Digital Ocean Ubuntu server because you can’t get the static files to be served properly for your Django project) then you need to go to the known_hosts file and remove the entry for that known host.
When you do that you’ll be asked about the identity of the server (again). Just say yes and you’re good to go.
If you forget that step then when you try to ssh into the server you get a nasty looking error message saying that the server identities don’t match and you can’t proceed.
Fixing the Python 3 Problem on my Raspberry Pi
In my last post I indicated that I may need to
reinstalling everything on the Pi and starting from scratch
While speaking about my issues with pip3 and python3. Turns out that the fix was easier than I though. I checked to see what where pip3 and python3 where being executed from by running the which command.
The which pip3 returned /usr/local/bin/pip3 while which python3 returned /usr/local/bin/python3. This is exactly what was causing my problem.
To verify what version of python was running, I checked python3 --version and it returned 3.6.0.
To fix it I just ran these commands to unlink the new, broken versions:
sudo unlink /usr/local/bin/pip3
And
sudo unlink /usr/local/bin/python3
I found this answer on StackOverflow and tweaked it slightly for my needs.
Now, when I run python --version I get 3.4.2 instead of 3.6.0
Unfortunately I didn’t think to run the --version flag on pip before and after the change, and I’m hesitant to do it now as it’s back to working.